Earlier  
Posted Nick Remark
#openstack-nova - 2019-06-20
16:12:42 aspiers ah ok thanks
16:14:13 mriedem aspiers: kill pyc
16:14:17 mriedem d'oh
16:14:36 mriedem stephenfin: remember when i said something about still having a tox.ini line to delete pycs when building docs?
16:15:10 aspiers yup there was a pyc somewhere
16:15:38 stephenfin I'm not sure why the docs target isn't respecting the PYTHONDONTWRITEBYTECODE option
16:15:57 stephenfin aspiers: Have you recently jumped back through stable branches?
16:16:10 aspiers don't think so
16:16:15 sean-k-mooney1 PYTHONDONTWRITEBYTECODE has issue if you cahnge branches
16:16:24 aspiers it's possible
16:16:27 sean-k-mooney1 unless we backport it to all brances
16:16:29 stephenfin Yeah, that's why I was asking
16:16:31 aspiers I haven't built the docs for a while
16:16:36 stephenfin I had backports proposed somewhere
16:16:47 sean-k-mooney1 that is why i prefered the find command
16:16:48 aspiers but I used --recreate and that didn't help, I had to remove .pyc from nova/
16:16:57 stephenfin Yeah, all the backports are there
16:17:07 stephenfin and Google doesn't help
16:17:21 sean-k-mooney1 the backport will only help if you have a clean repo
16:17:42 sean-k-mooney1 and you dont use the repor for devstack
16:17:46 sean-k-mooney1 but ya
16:18:41 openstackgerrit Stephen Finucane proposed openstack/nova master: Ignore hw_vif_type for direct, direct-physical vNIC types https://review.opendev.org/609460
16:18:42 openstackgerrit Stephen Finucane proposed openstack/nova master: vif: Stop using getattr for VIF lookups https://review.opendev.org/666630
16:18:42 openstackgerrit Stephen Finucane proposed openstack/nova master: vif: Skip most of 'get_base_config' if not using virtio https://review.opendev.org/666629
16:18:43 openstackgerrit Stephen Finucane proposed openstack/nova master: vif: Resolve a TODO and update another https://review.opendev.org/666631
16:19:22 stephenfin dansmith: I think that's closer to what you were looking for ^
16:20:41 dansmith stephenfin: ack, lemme pull that down and poke at that other test
16:20:44 dansmith but probably
16:21:14 sean-k-mooney1 stephenfin: ya https://review.opendev.org/#/c/609460/4/nova/virt/libvirt/vif.py look logically correct
16:24:07 dansmith stephenfin: okay, so on the test...
16:24:26 dansmith er, wait, lemme try something
16:30:11 stephenfin sean-k-mooney1: You should take a look at https://review.opendev.org/#/c/666630/ at some point too, if possible. I've been wanting to do that for as long as I've known it
16:30:15 dansmith stephenfin: okay, yeah, nevermind
16:34:41 stephenfin dansmith: On the same note, you'll probably like https://review.opendev.org/#/c/666629/ too (it's the same principle)
16:37:16 dansmith hrm, parallels uses virtio?
16:37:24 dansmith that seems, weird to me.
16:38:54 sean-k-mooney1 paralles have two backens
16:39:04 sean-k-mooney1 one based on openvz container and a vm based one
16:39:17 sean-k-mooney1 they use virtio if you are using the vm based one
16:44:11 dansmith ah
16:44:18 dansmith I only know of the container part I guess
16:44:25 openstackgerrit Matt Riedemann proposed openstack/nova stable/stein: Raise InstanceFaultRollback for UnableToMigrateToSelf from _prep_resize https://review.opendev.org/666639
16:44:25 openstackgerrit Matt Riedemann proposed openstack/nova stable/stein: Change InstanceFaultRollback handling in _error_out_instance_on_exception https://review.opendev.org/666638
16:48:08 openstackgerrit Stephen Finucane proposed openstack/nova master: vif: Stop using getattr for VIF lookups https://review.opendev.org/666630
16:48:09 openstackgerrit Stephen Finucane proposed openstack/nova master: vif: Resolve a TODO and update another https://review.opendev.org/666631
16:50:43 gibi What will happen in review https://review.opendev.org/#/c/666666 ? We are pretty close to that number
16:53:44 sean-k-mooney1 efried: i responed to your comments on the storageTransfrom as to why i intentionally did it this way. https://review.opendev.org/#/c/665844/1/nova/scheduler/request_filter.py@169 let me know if that is resonable
16:54:09 efried sean-k-mooney1: will look
16:56:59 sean-k-mooney1 i do admit the code is somewhat clever which is not always a smart thing to do but i can achive the same intent with multple moduels too
17:01:56 openstackgerrit Merged openstack/nova-specs master: Change new image property to hw_mem_encryption https://review.opendev.org/664397
17:02:01 stephenfin sean-k-mooney1: Want to hit https://review.opendev.org/#/c/666387/1 ?
17:03:13 sean-k-mooney1 ill take a look now
17:04:25 sean-k-mooney1 we dont actully support python 3.4 sp that proably shoudl be 3.5 https://review.opendev.org/#/c/666387/1/doc/requirements.txt
17:04:44 sean-k-mooney1 that said its fine
17:04:53 sean-k-mooney1 let me check upper constratints
17:05:24 openstackgerrit Adam Spiers proposed openstack/nova master: WIP: Document AMD SEV support for encrypted VMs in libvirt https://review.opendev.org/666617
17:05:39 sean-k-mooney1 stephenfin: how did the too long titles in teh rst not casue an error?
17:05:46 sean-k-mooney1 do we not have a check for that
17:05:48 stephenfin no idea
17:05:57 stephenfin we don't use doc8, which could catch these
17:06:04 stephenfin though I though Sphinx usually complained about them
17:06:21 sean-k-mooney1 but we do you warn as error for sphinx build
17:06:37 sean-k-mooney1 which i would have assumed would complain
17:07:49 sean-k-mooney1 stephenfin: so this is wrong
17:08:06 sean-k-mooney1 we should not be setting an upper limit in our requirements file
17:08:27 stephenfin we have to for sphinx on Python 2
17:08:32 sean-k-mooney1 sphinx is already caped for py2.7 in upperconstraitns to https://github.com/openstack/requirements/blob/master/upper-constraints.txt#L459
17:08:44 stephenfin It is, but it complains if we don't sync them
17:08:45 sean-k-mooney1 no we cap to 1.8.5 for py27
17:08:53 sean-k-mooney1 in upper constatints
17:08:59 stephenfin Yup
17:09:02 sean-k-mooney1 we might not be using it in the docs target
17:09:27 sean-k-mooney1 no we should be
17:09:38 stephenfin Propose a patch that touches requirements.txt without modifying the sphinx stuff and see what happens
17:09:44 stephenfin the requirements gate job will fail it
17:09:59 stephenfin infra might know why but I just know if we do this, it fixes things
17:10:29 sean-k-mooney1 we should not have teh <2.0.0 however
17:10:56 sean-k-mooney1 we are not ment to cap in repo
17:12:36 mriedem gibi: the end times is what
17:14:42 stephenfin sean-k-mooney1: I'd suggest proposing a WIP patch without that cap and seeing what happens. There have been a lot of these patches going in across oslo projects lately
17:16:11 sean-k-mooney1 stephenfin: well we also use python3 for building docs not python 2
17:16:25 sean-k-mooney1 so i also dont see why we would need the python 2 version
17:16:28 stephenfin We do if you build docs using tox
17:16:38 sean-k-mooney1 yes which is the only thing we suport
17:16:55 sean-k-mooney1 that is what the pti also requires
17:16:57 stephenfin Right, but other projects use sphinx for things other than building docs
17:17:06 stephenfin for example, oslo_config.sphinxext
17:17:07 sean-k-mooney1 theat project supprot building docs via tox
17:17:26 stephenfin For those projects, we still need to support Python2
17:17:35 sean-k-mooney1 why
17:17:54 sean-k-mooney1 they can move to running that under python3
17:18:12 sean-k-mooney1 they need to do that this cycle anyway
17:18:41 stephenfin They can't drop py27 tests
17:19:29 stephenfin and if the project specifies sphinx as a requirement (vs. a test-requirement), it's going to pull in sphinx
17:19:30 sean-k-mooney1 well i guess not until U
17:19:36 bnemec It's kind of irrelevant. The requirements job isn't smart enough to differentiate, so you need the cap whether you support python 2 or not.
17:19:43 sean-k-mooney1 stephenfin: sure
17:19:53 sean-k-mooney1 but upper contratits caps it
17:19:57 stephenfin so attempting to install something like oslo.config on Python 2.7 would no longer be possible
17:20:00 sean-k-mooney1 so it should not be an issue

Earlier   Later