sinnykumari added a new comment to an issue you are following:
To decide which option to choose, I am interested in knowing if we
have any existing fedmsg as example which just pass url and callers do processing?
Also @dustymabe and @mohanboddu what are your opinion here?
whatever works for me. It would be interesting to know if there were any other consumers
of this fedmsg other than the website. none that I know of.
Even I am also not aware of any consumers other than fedora-website who uses this fedmsg
I gave a bit of more thought on which way to go among following two options-
1. Keep existing twoweek fedmsg schema and add a new key/value "url":
"link" where link can be used by callers to fetch compose metadata json. Callers
can further parse the json data from url to get additional information like multi-arch
images detail, isos info, image size, etc. In this case, existing website Atomic page will
not break with the change.
2. Update existing twoweek fedmsg with required information (like: multi-arch images
detail, isos info, image size info) and adjust schema accordingly. In that case caller
will not have to parse compose metadata json file and they can fully rely on fedmsg data.
But, they will need to make one time change to adapt to new schema to get existing website
Atomic page working.
Considering both options and number of applications relying on this fedmsg, I am more
leaned towards updating existing fedmsg with multi-arch content. Updating existing webpage
with new schema should be an easy task. Also, this will help us to stop depending upon
autocloud and makes easy to update twoweek fedmsg with isos and image size information.
To reply, visit the link below or just reply to this email