<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Sep 12, 2018 at 2:28 PM, Doug Hellmann <span dir="ltr"><<a href="mailto:doug@doughellmann.com" target="_blank">doug@doughellmann.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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>
<span class="">> > On Wed, Sep 12, 2018, at 10:23 AM, Jim Rollenhagen wrote:<br>
> > > The process of operators upgrading Python versions across their fleet came<br>
> > > up this morning. It's fairly obvious that operators will want to do this in<br>
> > > a rolling fashion.<br>
> > > <br>
> > > Has anyone considered doing this in CI? For example, running 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). General consensus there seemed to be that we should have grenade jobs that run python2 on the old side and python3 on the new side and test the update from one to another through a release that way. Additionally there was thought that the nova partial job (and similar grenade jobs) could hold the 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>
</span>> 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></blockquote><div><br></div><div>A specific example brought up in the ironic room was the way we encode exceptions in oslo.messaging for transmitting over RPC. I know that we've found encoding bugs in that in the past, and one can imagine that RPC between a service running on py2 and a service running on py3 could have similar issues.</div><div><br></div><div>It's definitely edge cases that we'd be catching here (if any), so I'm personally fine with assuming it will just work. But I wanted to pose the question to the list, as we agreed this isn't only an ironic problem.</div><div><br></div><div>// jim</div></div></div></div>