Earlier  
Posted Nick Remark
#openstack-nova - 2018-10-05
14:14:33 fried_rice which looks familiar but I can't remember wtf
14:14:33 fried_rice ImportError: bad magic number in 'nova.notifications.objects.libvirt': b'\x03\xf3\r\n'
14:14:33 fried_rice finucannot: tox -e docs is giving me
14:15:02 finucannot Let me build locally. This is unrelated, right?
14:15:20 fried_rice totally
14:15:50 fried_rice well, I was trying to build locally to experiment with the above
14:15:56 fried_rice finucannot: removing *.pyc fixed it.
14:16:00 fried_rice call off the doggs
14:16:05 finucannot ack
14:16:25 fried_rice finucannot: We did something recently to stop doing that find -delete
14:16:32 fried_rice I guess it was there for a reason :(
14:19:07 fried_rice finucannot: Interesting data point: http://paste.openstack.org/show/731591/ results in no change to the output. I was actually expecting it to turn it into a bolded one-item-per-line list with no descriptions, but it doesn't - it still looks just like https://docs.openstack.org/nova/latest/configuration/config.html#libvirt.virt_type
14:20:32 finucannot fried_rice: That's because I defensively coded against that. Oops https://github.com/openstack/oslo.config/blob/master/oslo_config/sphinxext.py#L163-L164
14:21:10 finucannot iirc, that was in place to prevent us emitting the 'Possible values' section twice for something like nova
14:21:18 fried_rice finucannot: Does '' convert to None somewhere along the line?
14:21:41 finucannot Hmm, it shouldn't but lemme check
14:22:25 fried_rice (I promise I will eventually get back to reviewing your actual patch - hopefully before another rebase is required :)
14:23:33 finucannot So it shouldn't, based on this https://github.com/openstack/oslo.config/blob/bc9b7f5d2fb4c552254263bb0843fb766a9978a0/oslo_config/types.py#L118-L121
14:24:39 finucannot Though, personally, given that we have the 'Valid values' line already, I think emitting the 'Possible values' section too probably isn't necessary https://github.com/openstack/oslo.config/blob/master/oslo_config/sphinxext.py#L117
14:24:41 fried_rice but then also did the paragraph thing with <No description provided> for each, which is ugly.
14:24:41 fried_rice Valid Values:kvm, lxc, qemu, uml, xen, parallels
14:24:41 fried_rice finucannot: Sorry, I still haven't gotten that coffee. It didn't dtrt, it printed the normal
14:25:06 finucannot Yeah, so drop back to choices=['foo', 'bar']
14:25:16 fried_rice yeah.
14:25:28 finucannot You'll keep the 'Valid Values' line but won't get those ugly lines
14:25:29 finucannot Cool
14:25:54 fried_rice finucannot: So yeah, the ones you changed are now showing up double, once in Valid Values on the third line, and then the new "Possible values" section.
14:26:10 fried_rice But that's going to be a change in oslo, if you want to dedup, not in consuming code.
14:26:30 finucannot Yup. That was on purpose. We we previously doing that in nova
14:26:34 finucannot Only by hand
14:27:28 finucannot I should probably just change the 'Possible values' title to something more meaningful, like 'Valid values description' or the likes
14:32:35 openstackgerrit Martin Midolesov proposed openstack/nova master: vmware:PropertyCollector for caching instance properties https://review.openstack.org/608278
14:33:12 openstackgerrit Stephen Finucane proposed openstack/nova master: Remove get_config_vhostuser https://review.openstack.org/565471
14:33:13 openstackgerrit Stephen Finucane proposed openstack/nova master: Make 'plugin' a required argument for '_get_vif_instance' https://review.openstack.org/608279
14:37:16 openstackgerrit Stephen Finucane proposed openstack/nova master: Remove get_config_vhostuser https://review.openstack.org/565471
14:37:17 openstackgerrit Stephen Finucane proposed openstack/nova master: Make 'plugin' a required argument for '_get_vif_instance' https://review.openstack.org/608279
14:38:30 finucannot fried_rice: Also, we still have the line to remove 'pyc' files
14:38:47 finucannot If that's not getting called, it's because the target isn't calling {[testenv]commands}
14:38:49 fried_rice hm, why didn't it hit when I did tox -e or tox -re?
14:38:58 fried_rice ...with the docs target. /me looks...
14:39:12 finucannot Yeah, we don't call it there
14:39:27 fried_rice okay. Should we?
14:40:10 finucannot If we do anything we code (which we do) then yeah, we should
14:41:03 finucannot Once we depend on tox 3.0.0, we can remove that line in favour of PYTHONDONTWRITEBYTECODE
14:41:46 finucannot https://github.com/tox-dev/tox/commit/336f4f6bd8b53223f940fc5cfc43b1bbd78d4699
14:45:42 fried_rice I'm gonna go review your actual patch now, mkay?
14:48:39 openstackgerrit Jay Pipes proposed openstack/os-traits master: Add COMPUTE_TIME_HPET trait https://review.openstack.org/608258
14:48:52 leakypipes fried_rice: ^
14:48:56 leakypipes sean-k-mooney: ^^
14:49:36 fried_rice leakypipes: +2
14:52:20 openstackgerrit Matt Riedemann proposed openstack/nova master: WIP: Cross-cell resize https://review.openstack.org/603930
14:53:24 melwitt good review for friday: trivial bug fix https://review.openstack.org/608040
14:53:31 waterloo hi, is there a list of diff between nova CLI and openstack CLI wrt parity? In particular, I would like a --property for 'openstack server rebuild'. Should i open a story about it and make the change or was there a reason not to support that?
14:55:18 melwitt there are differences, we don't have an official list. there might be an etherpad out there somewhere that describes the parity discrepancies
14:55:49 melwitt I don't know what --property is, so I need to look at the docs to see what it is
14:55:51 waterloo melwitt: should i assume it was just missed (it is --meta in 'nova server-rebuild')
14:55:55 PapaOurs mriedem: now that nova supports nested a-c, could you drop your -2 on https://review.openstack.org/#/c/599208/ ?
14:56:12 waterloo melwitt: err, 'nova rebuild'
14:56:44 melwitt waterloo: yeah, if there's anything you can do in novaclient that you can't do in osc, it's not intentional
14:57:21 waterloo melwitt: great or not great ;) I'll submit a story about it cuz i love stories! :D
14:57:30 melwitt we talked about the general problem of the lack of parity at the PTG
14:58:30 melwitt and IIRC, we talked about the possibility of moving our CLI to be an OSC plugin (which we've talked about in the past, but not too seriously) but then I think dtroyer said OSC is in the process of moving to openstacksdk so that should be completed first
14:58:36 mriedem waterloo: https://etherpad.openstack.org/p/compute-api-microversion-gap-in-osc
14:59:15 melwitt cool, I thought mriedem might have an etherpad
14:59:20 waterloo melwitt: i did it for ironic awhile ago, somewhat painful to go through and compare/address but done! you too, can do it, just need to find a guinea pig, err volunteer.
14:59:28 waterloo thx mriedem!
14:59:30 mriedem anything else thats missing unrelated to microversions is just a new parity story against OSC in SB
15:05:06 waterloo mriedem: would you mind if i opened a story (in python-openstackclient) wrt nova CLI feature parity and just link this etherpad? although maybe that won't help, not sure i would have looked for that
15:06:44 mriedem sure...there are already several osc stories created and linked *from* the etherpad since that's how the work was being tracked. doesn't matter much to me if there is an epic or something in SB though.
15:07:14 mriedem needs a project manager to create a board and all that
15:07:20 mriedem and people to test/review the changes
15:08:04 waterloo mriedem: good luck with that...
15:08:17 mriedem well if it were a community goal in T...
15:08:40 mriedem then someone could maybe justify to their employer dedicating a lot of time to this
15:09:17 waterloo mriedem: I'm sure lots of folks would support that!
15:09:28 waterloo (dunno about companies but who knows...)
15:10:15 sean-k-mooney waterloo: are ye talking about nova/osc feature partity?
15:10:37 waterloo sean-k-mooney: yeah, are you working on it? (i can only hope)
15:11:04 sean-k-mooney waterloo: finucannot: and i said we were interested in looking at it if we had time
15:11:39 mriedem melwitt: i don't think we need to care about getting these CI job changes into ocata-em https://review.openstack.org/#/q/I41b03a34795efe139d5911c605cdbd3c47a2f059 - given that, everything else is merged for ocata and we could do the final release and tag the branch
15:11:45 sean-k-mooney waterloo: that assume i get my feature dev done early in S e.g. m1/m2 so that i have tiem to look at it later in the cycle
15:12:16 waterloo sean-k-mooney: sweet, thx, I can hope then :)
15:13:47 melwitt mriedem: makes sense. I added a new [as of yesterday] bug to the ocata-em etherpad, but the more I think about it, it's super latent so probably not worth holding up for
15:14:46 mriedem yeah i saw, and commented
15:14:55 mriedem in the etherpad. i don't think we need to hold up EM forever
15:15:47 melwitt I wasn't thinking of it as forever, just someone ran into the problem and the fix fixed it for them. and it's a 5 line change
15:16:25 melwitt and I wasn't sure if there was anything else in the works or what date the rest of the community was targeting for EM, so I just thought I'd ask
15:17:04 melwitt if everything and everyone else is ready to go, then we can just go ahead
15:17:32 mriedem EM means the branch stays open so people can backport fixes and pull from stable/ocata,
15:17:38 mriedem which is good enough IMO
15:19:47 melwitt yeah. again, I didn't know when the rest of the community was targeting EM so I didn't know if there was time anyway. if everyone's ready to go now, then that's fine, let's go ahead
15:21:59 mriedem i doubt anyone else is ready to go
15:22:04 mriedem or is working on this
15:22:14 mriedem lots of projects probably just want to eol ocata
15:22:17 mriedem like heat
15:22:22 waterloo sean-k-mooney, mriedem: fyi, I added that as a story, only to try to get eyes on it and to mention the etherpad: https://storyboard.openstack.org/#!/story/2003980
15:28:25 cdent Is there some way to boot a server such that you force the host and the scheduler doesn't get involved? I know that's possible with migrations, but is it with boot?
15:28:43 sean-k-mooney cdent: yes and its kindo fo a bug
15:28:53 mriedem --availability-zone nova:<host>
15:29:03 sean-k-mooney yep that ^

Earlier   Later