Ihar Hrachyshka wrote: > I guess the next steps are: > - monitoring the job for a week, making sure it’s stable enough (comparing > failure rate to non-partial grenade job?); > - if everything goes fine, propose project-config change to make it voting; > - propose governance patch to enable rolling-upgrade tag for neutron repo (I > believe not for *aas repos though?).
Agree - I believe this is our next steps. > I guess with that we would be able to claim victory for the basic 'server > vs. agent’ part of rolling scenario. Right? Correct - it also tests "new agent vs. old agent" since the primary node runs the neutron agent, upgrades it, while the subnode runs the neutron agent that is not upgraded. I think there could be some work done to ensure that instances are scheduled on both the primary node and the subnode so we get more coverage. > Follow up steps would probably be: > - look at enabling partial job for DVR flavour; Agree - I guess we can resurrect https://review.openstack.org/#/c/250215 ? > - proceed on objectification of neutron db layer to open doors for later > mixed server versions in the same cluster. Sounds good. > Anything I missed? I think that's a good starting point. If we think of of other things we can add them. > Also, what do we do with non-partial flavour of the job? Is it staying? Is it useful? I think operators are more likely to upgrade components of a cluster incrementally - so the partial jobs are going to reflect the reality on the ground better. -- Sean M. Collins __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
