Update currently built containers - #111
Conversation
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
| neutron/neutron-metadata-agent-ovn: | ||
| - edpmNeutronMetadataAgentImage | ||
| neutron/neutron-ovn-agent: | ||
| - edpmNeutronOvnAgentImage |
There was a problem hiding this comment.
I have omitted neutron/neutron-server because I couldn't find the var in openstackversions.spec.customContainerimages.
Please someone let me know the right value!
There was a problem hiding this comment.
it should be
neutron/neutron-server:
- neutronAPIImage
but a confirmation from @openstack-k8s-operators/network team is totally appreciated :)
There was a problem hiding this comment.
Yes correct neutronAPIImage to be used, but we can't add it now, can add it as commented and once neutron-operator is adapted to support these eventletless images we can uncomment. Planning to work on that next week.
There was a problem hiding this comment.
@karelyatin That means we can't deploy operators in current state with these s2i images? If so, you plan in doing the changes in the operator backwards compatible?
BTW, adding it to this file has actually not impact, I think, other than having it ready for future CI jobs.
There was a problem hiding this comment.
<< @karelyatin That means we can't deploy operators in current state with these s2i images? If so, you plan in doing the changes in the operator backwards compatible?
@amoralej plan is to make it such that greenfield deploy run with master/19 images, while handling the minor update case where deployment strategy change only during minor update but not when operator rollouts happen. This may require some CI hacks until fully migrated so will take care of those.
Or you mean we need to also support running antelope images during greenfield install as well?
<< BTW, adding it to this file has actually not impact, I think, other than having it ready for future CI jobs.
From recent meetings i understood CI jobs preparation is in progress and AFAIU this file will be used to detect available images, and if this is true we can't add neutron-server yet there until we adapt neutron-operator.
There was a problem hiding this comment.
This may require some CI hacks until fully migrated so will take care of those. Or you mean we need to also support running antelope images during greenfield install as well?
@karelyatin My concern was the transition and avoid dependency between changing neutron-operator and updating defaults and CI to use new images. Making the change backwards compatible may help for transition I guess but if there is any way to avoid those dependencies that may block moving to new containers or may add dependency to other projects switch, no problem.
WRT update from 18 to 19. I'm not very familiar with the RHOSO update process but after initial update of the operators only, wouldn't the operators run with the former openstackversion as an intermediate step? Is the update of operator and openstackversion atomic? I'm not sure how that's is handled tbh.
i understood CI jobs preparation is in progress and AFAIU this file will be used to detect available images
All that is right, it was just about timing. I though we are not in the status to run that yet (actually, iiuc deployment will fail on neutron-server anyway) although I may be wrong.
There was a problem hiding this comment.
@karelyatin My concern was the transition and avoid dependency between changing neutron-operator and updating defaults and CI to use new images. Making the change backwards compatible may help for transition I guess but if there is any way to avoid those dependencies that may block moving to new containers or may add dependency to other projects switch, no problem.
It would be kind of backward compatible only for the upgrade scenario i.e neutron pod will keep running with operator updates to support new way. The only thing is greenfield/fresh setup to use new images always and switch to new method during update. For CI we may need some hacks to switch default images as they are managed across different repos, so will see that once i push that next week
WRT update from 18 to 19. I'm not very familiar with the RHOSO update process but after initial update of the operators only, wouldn't the operators run with the former openstackversion as an intermediate step? Is the update of operator and openstackversion atomic? I'm not sure how that's is handled tbh.
During update:-
- First stage operators are updated, which provides newer OpenStackVersion and all service operators are updated, this can result in rolling out changes to already deployed services . So in this stage, neutron and other pods will keep running/functional with older container images, there may be some restarts though
- To trigger minor update(in this case it could be major version though but not have any visibility on plan for these in general), spec.targetVersion is updated, at this pods will be rolled out with new(s2i) images and at this stage we will switch to the the new deploy strategy for neutron. Add ServiceDefaults mechanism for updates support openstack-operator#1439 should provide some picture on how it's being done, it's already used for glance/rabbitmq/manila transitions
|
I was thinking in updating it at the end to avoid forcing ongoing PRs to rebase under the assumption that this is not used yet but we can merge it if needed. |
2488b47 to
255d82b
Compare
I added the README and containers/image-mapping updates to the developer docs, so hopefully, we have this included in PRs from now on and this won't be an ongoing update. |
255d82b to
90de894
Compare
|
Build failed (check pipeline). Post ✔️ s2i-openstack-containers-molecule SUCCESS in 2m 08s |
README and containers/image-mappings are out of date
The following commands were used to create the new lists:
README:
find -name Containerfile | xargs dirname {} | awk -F/ '{print "- `openstack-"$NF"`;"}' | sort
containers/image-mappings:
find -name Containerfile | xargs dirname {} | sed 's:^./containers/::' | sort | awk '{print " "$NF":"}'
get a list of openstackversions image vars
oc explain openstackversions.spec.customContainerImages | grep Image | awk '{ print $q}'
90de894 to
6e4ab47
Compare
|
PR needs rebase. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
4 participants
README and containers/image-mappings are out of date
The following commands were used to create the new lists:
README:
find -name Containerfile | xargs dirname {} | awk -F/ '{print "-
openstack-"$NF";"}' | sortcontainers/image-mappings:
find -name Containerfile | xargs dirname {} | sed 's:^./containers/::' | sort | awk '{print " "$NF":"}'
get a list of openstackversions image vars
oc explain openstackversions.spec.customContainerImages | grep Image | awk '{ print $q}'