<div dir="ltr"><div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Thu, Sep 13, 2018 at 7:39 PM Doug Hellmann <<a href="mailto:doug@doughellmann.com">doug@doughellmann.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Excerpts from Jim Rollenhagen's message of 2018-09-13 12:08:08 -0600:<br>
> On Wed, Sep 12, 2018 at 2:28 PM, Doug Hellmann <<a href="mailto:doug@doughellmann.com" target="_blank">doug@doughellmann.com</a>><br>
> wrote:<br>
> <br>
> > Excerpts from Doug Hellmann's message of 2018-09-12 12:04:02 -0600:<br>
> > > Excerpts from Clark Boylan's message of 2018-09-12 10:44:55 -0700:<br>
> > > > On Wed, Sep 12, 2018, at 10:23 AM, Jim Rollenhagen wrote:<br>
> > > > > The process of operators upgrading Python versions across their<br>
> > fleet came<br>
> > > > > up this morning. It's fairly obvious that operators will want to do<br>
> > this in<br>
> > > > > a rolling fashion.<br>
> > > > ><br>
> > > > > Has anyone considered doing this in CI? For example, running<br>
> > multinode<br>
> > > > > grenade with python 2 on one node and python 3 on the other node.<br>
> > > > ><br>
> > > > > Should we (openstack) test this situation, or even care?<br>
> > > > ><br>
> > > ><br>
> > > > This came up in a Vancouver summit session (the python3 one I think).<br>
> > General consensus there seemed to be that we should have grenade jobs that<br>
> > run python2 on the old side and python3 on the new side and test the update<br>
> > from one to another through a release that way. Additionally there was<br>
> > thought that the nova partial job (and similar grenade jobs) could hold the<br>
> > non upgraded node on python2 and that would talk to a python3 control plane.<br>
> > > ><br>
> > > > I haven't seen or heard of anyone working on this yet though.<br>
> > > ><br>
> > > > Clark<br>
> > > ><br>
> > ><br>
> > > IIRC, we also talked about not supporting multiple versions of<br>
> > > python on a given node, so all of the services on a node would need<br>
> > > to be upgraded together.<br>
> > ><br>
> > > Doug<br>
> ><br>
> > I spent a little time talking with the QA team about setting up<br>
> > this job, and Attila pointed out that we should think about what<br>
> > exactly we think would break during a 2-to-3 in-place upgrade like<br>
> > this.<br>
> ><br>
> > Keeping in mind that we are still testing initial installation under<br>
> > both versions and upgrades under python 2, do we have any specific<br>
> > concerns about the python *version* causing upgrade issues?<br>
> ><br>
> <br>
> A specific example brought up in the ironic room was the way we encode<br>
> exceptions in oslo.messaging for transmitting over RPC. I know that we've<br>
> found encoding bugs in that in the past, and one can imagine that RPC<br>
> between a service running on py2 and a service running on py3 could have<br>
> similar issues.<br>
<br>
Mixing python 2 and 3 components of the same service across nodes<br>
does seem like an interesting case. I wonder if it's something we<br>
could build a functional test job in oslo.messaging for, though,<br>
without having to test every service separately. I'd be happy if<br>
someone did that.<br>
<br></blockquote><div><br></div><div>Currently that's a hole in the oslo.messaging tests.  I've opened a work item to address this in launchpad:</div><div><a href="https://bugs.launchpad.net/oslo.messaging/+bug/1792977">https://bugs.launchpad.net/oslo.messaging/+bug/1792977</a><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> It's definitely edge cases that we'd be catching here (if any), so I'm<br>
> personally fine with assuming it will just work. But I wanted to pose the<br>
> question to the list, as we agreed this isn't only an ironic problem.<br>
<br>
Yes, definitely. I think it's likely to be a bit of work to set up the<br>
jobs and run them for all services, which is why I'm trying to<br>
understand if it's really needed. Thinking through the cases on the list<br>
is a good way to get folks to poke holes in any assertions, so I<br>
appreciate that you started the thread and that everyone is<br>
participating.<br>
<br>
Doug<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail_signature">Ken Giusti  (<a href="mailto:kgiusti@gmail.com" target="_blank">kgiusti@gmail.com</a>)</div></div></div>