"Generated image ", "Started image download", "Re-used existing image" events should contain Content-Length: and Content-Disposition <filename> This information will be very useful especially with validation and switching between minimal and full How reproducible: 100% Steps to Reproduce: (UI or API). This example from API 1) export AUTH="<your auth code" export CLUSTER_ID="<your cluster id> export API_ENDPOINT=http://x.x.x.x:pppp/api/assisted-install/v1 2) generate minimal-iso curl -v -s -H "${AUTH}" -H "Content-Type:application/json" -X POST "${API_ENDPOINT}/clusters/${CLUSTER_ID}/downloads/image" -d '{ "image_type": "minimal-iso" }' 3) download iso Actual results: 4) pull events curl -v -s -H "${AUTH}" -H "Content-Type:application/json" -X POST "${API_ENDPOINT}/clusters/${CLUSTER_ID}/events Expected results: Started image download (filename="cluster-99bd0ab8-10a6-4042-b198-bb5e3aa4c74d-discovery.iso", size="97091584") Re-used existing image (filename="cluster-99bd0ab8-10a6-4042-b198-bb5e3aa4c74d-discovery.iso", size="97091584") rather than generating a new one Generated image (Image type is "minimal-iso", SSH public key is not set, filename="cluster-99bd0ab8-10a6-4042-b198-bb5e3aa4c74d-discovery.iso", size="97091584") Additional info: curl -v -s -H "${AUTH}" -H "Content-Type:application/json" -X POST "${API_ENDPOINT}/clusters/${CLUSTER_ID}/downloads/image" -d '{ "image_type": "minimal-iso" }' curl -v -s -H "${AUTH}" -H "Content-Type:application/octet-stream" -X GET "${API_ENDPOINT}/clusters/${CLUSTER_ID}/downloads/image" -o cluster-$CLUSTER_ID-minimal-discovery.iso * Trying 10.9.76.12... * TCP_NODELAY set * Connected to 10.9.76.12 (10.9.76.12) port 6008 (#0) > GET /api/assisted-install/v1/clusters/99bd0ab8-10a6-4042-b198-bb5e3aa4c74d/downloads/image HTTP/1.1 > Host: 10.9.76.12:6008 > User-Agent: curl/7.64.1 > Accept: */* > eyJhbGciOiJSU > Content-Type:application/octet-stream > <removed encryption code> < HTTP/1.1 200 OK < Server: nginx < Date: Mon, 15 Feb 2021 19:29:48 GMT < Content-Type: application/octet-stream < Content-Length: 97091584 < Connection: keep-alive < Content-Disposition: attachment; filename="cluster-99bd0ab8-10a6-4042-b198-bb5e3aa4c74d-discovery.iso" < X-Frame-Options: SAMEORIGIN < { [2706 bytes data] * Connection #0 to host 10.9.76.12 left intact * Closing connection 0 curl -v -s -H "${AUTH}" -H "Content-Type:application/json" -X POST "${API_ENDPOINT}/clusters/${CLUSTER_ID}/events
Hi Mike, The filename in Content-Disposition is merely the suggested name for file into which the resource is downloaded by the client. So I'm not sure it's very helpful for the user as it can modified when initiating the download. Also, the file name pattern simply consists of the cluster ID ('cluster-<cluster_id)-discovery.iso'). In which scenario do you think it could assist the user to be included in the event? As for Content-Length: * 'Generated image' event - already included an indication for the image type: (Generated image (Image type is "minimal-iso...). * 'Re-used existing image' event - the user already specified the image type, but we can indeed include it in the event to be explicit. * 'Started image download' - we can include the type as well. I.e. 'Started image download (Image type is "minimal-type")'. What do you think, sounds good enough?
(In reply to Daniel Erez from comment #1) > Hi Mike, > > The filename in Content-Disposition is merely the suggested > name for file into which the resource is downloaded by the client. > So I'm not sure it's very helpful for the user as it can modified > when initiating the download. Also, the file name pattern simply > consists of the cluster ID ('cluster-<cluster_id)-discovery.iso'). > In which scenario do you think it could assist the user to > be included in the event? [mlammon] Hi Daniel, Just to be clear. Are you referring to the name of the cluster? Is this a parameter inside image-create-params ? If so, I think if user sets some cluster name, probably best, else use the UUID of cluster. > > As for Content-Length: > * 'Generated image' event - already included an indication for the image > type: > (Generated image (Image type is "minimal-iso...). > * 'Re-used existing image' event - the user already specified the image type, > but we can indeed include it in the event to be explicit. > * 'Started image download' - we can include the type as well. > I.e. 'Started image download (Image type is "minimal-type")'. > What do you think, sounds good enough? [mlammon] Here is event quickly just pulled from UI event for discuss purpose: Re-used existing image rather than generating a new one: <-- Add name of image, size Started image download: <---- Add name of image, size Generated image (Image type is "minimal-iso", SSH public key is set): <--- Add name of image I think name of image in each message as there could be multiple images for different clusters right? WDYT? We can discuss further if needed.
(In reply to mlammon from comment #2) > (In reply to Daniel Erez from comment #1) > > Hi Mike, > > > > The filename in Content-Disposition is merely the suggested > > name for file into which the resource is downloaded by the client. > > So I'm not sure it's very helpful for the user as it can modified > > when initiating the download. Also, the file name pattern simply > > consists of the cluster ID ('cluster-<cluster_id)-discovery.iso'). > > In which scenario do you think it could assist the user to > > be included in the event? > > [mlammon] > > Hi Daniel, > Just to be clear. Are you referring to the name of the cluster? > Is this a parameter inside image-create-params ? > If so, I think if user sets some cluster name, probably best, else > use the UUID of cluster. > > > > > As for Content-Length: > > * 'Generated image' event - already included an indication for the image > > type: > > (Generated image (Image type is "minimal-iso...). > > * 'Re-used existing image' event - the user already specified the image type, > > but we can indeed include it in the event to be explicit. > > * 'Started image download' - we can include the type as well. > > I.e. 'Started image download (Image type is "minimal-type")'. > > What do you think, sounds good enough? > > [mlammon] > > Here is event quickly just pulled from UI event for discuss purpose: > > > Re-used existing image rather than generating a new one: <-- Add name of > image, size > Started image download: <---- Add name of image, size > Generated image (Image type is "minimal-iso", SSH public key is set): > <--- Add name of image > > > I think name of image in each message as there could be multiple images for > different clusters right? WDYT? > We can discuss further if needed. Thanks Mike for the quick response. We currently support only a single image for each cluster. I.e. only the most recent generated image is being downloaded. So the single file name is always in this format: 'cluster-<cluster_id)-discovery.iso' So I think that the only missing information in the events is the type of the image. I'll just add it for now in the aforementioned events then.
It looks like upstream code has merged. This should be moved to ON_QA and add Fixed In Version
(In reply to mlammon from comment #4) > It looks like upstream code has merged. This should be moved to ON_QA and > add Fixed In Version Added. Thanks!
Do we need a separate bugzilla to get this fix into UI?
(In reply to mlammon from comment #6) > Do we need a separate bugzilla to get this fix into UI? The image type should already be available for the relevant events in the 'Cluster Events' dialog. E.g. "Re-used existing image rather than generating a new one (image type is "minimal-iso")" "Generated image (Image type is "minimal-iso", SSH public key is not set)"
I hit this issue trying to verify https://bugzilla.redhat.com/show_bug.cgi?id=1946303
Re-used existing image rather than generating a new one (image type is "full-iso") Started image download (image type is "full-iso") Verified with compent_version { "release_tag": "v1.0.18.1", "versions": { "assisted-service": "quay.io/app-sre/assisted-service:fcf7264", "openshift4-assisted-installer-agent-rhel8": "registry-proxy.engineering.redhat.com/rh-osbs/openshift4-assisted-installer-agent-rhel8:v1.0.0-26", "openshift4-assisted-installer-reporter-rhel8": "registry-proxy.engineering.redhat.com/rh-osbs/openshift4-assisted-installer-reporter-rhel8:v1.0.0-28", "openshift4-assisted-installer-rhel8": "registry-proxy.engineering.redhat.com/rh-osbs/openshift4-assisted-installer-rhel8:v1.0.0-27" } }
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (Moderate: OpenShift Container Platform 4.9.0 bug fix and security update), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2021:3759