Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-03-25
16:24:47 mriedem request groups baffle me which is why i've deprioritized that multiattach patch :)
16:24:57 gibi the group number from the flavor.extra_spec
16:25:18 mriedem i thought that was baked into the extra spec key name?
16:25:20 mriedem resources1 etc
16:25:22 gibi the flavor create can use resourceN where N is a positive number
16:25:34 gibi and that N ends up in the a_c query
16:25:42 gibi but the current patch renumbers the groups
16:26:01 gibi it will be 1,2,3,... in the a_c query
16:26:01 openstackgerrit Merged openstack/nova master: Replace openstack.org git:// URLs with https:// https://review.openstack.org/646682
16:26:08 openstackgerrit Merged openstack/nova stable/stein: Replace openstack.org git:// URLs with https:// https://review.openstack.org/646688
16:26:48 mriedem gibi: ok so i guess the question is does that matter as long as the groups remain....grouped
16:27:14 gibi they remain grouped. So it only hardens the troubleshooting
16:30:26 openstackgerrit Surya Seetharaman proposed openstack/nova-specs master: Support server power state update through external event https://review.openstack.org/636132
16:34:49 openstackgerrit Surya Seetharaman proposed openstack/nova-specs master: Support server power state update through external event https://review.openstack.org/636132
16:49:51 melwitt mriedem: I was wondering re: counting quotas, since we're doing a blocker migration for user_id this cycle, does that mean we don't need to check whether it's populated and fall back to legacy counting anymore? or do we still need to?
16:51:06 mriedem melwitt: i think the blocker migration missed stein so it has to be in U now
16:51:33 mriedem but probably a better question for dansmith
16:51:39 mriedem doing the blocker migration right away in Train seems overly aggressive
16:52:24 dansmith melwitt: if we do a blocker, then yes that's what that means, but if we're going to be a little softer about it, then we'd need to handle the compat
16:52:26 melwitt mriedem: ok, yeah I wasn't sure how that usually works. I was thinking since we landed all of the migration code in stein, then the blocker migration might only be related to that
16:52:30 dansmith generally we do a blocker so we can drop support for something
16:52:52 dansmith and doing that right after we opened the window would be rather aggressive as mriedem said
16:52:56 melwitt oh, I see. yeah, then T would be too early
16:53:02 mriedem i think trying to drop the compat in the same release that we add the new code that depends on that compat seems aggressive
16:53:07 dansmith and remember,
16:53:40 dansmith blocker migrations are a pain for FFU people, so we should use them sparingly for when we need to fully drop support for something vs. just avoiding some compat code
16:53:48 dansmith like if we need to drop a column or something
16:54:25 melwitt oh, ok :/ might have to amend the spec in that case
16:54:58 melwitt (since it mentions a blocker migration)
16:55:14 dansmith I'm not saying we can't (I don't remember what the spec says), I'm just saying we should be judicious in our application of that technique
16:55:53 melwitt the spec says blocker migration for being able to remove compat code/stop legacy counting
16:55:58 melwitt understood
16:56:21 dansmith right, so, when we remove that code, we should have a blocker, so depending on how the spec words it, it may not be wrong :)
16:56:33 melwitt (although we have to keep legacy counting indefinitely until partitioning of placement allocations is possible)
16:56:49 dansmith okay
16:57:20 dansmith we could also do it a different way and just roll the blocker and new constraints together in one migration, but we definitely need to give some buffer between adding the thing and requiring the thing I thnk
16:58:11 melwitt yeah, understood and agreed
17:01:04 cdent melwitt: speaking of partitioning placement allocations. Is that a thing you were planning to spec or is that a broader all of us kind of thing?
17:01:40 melwitt cdent: broader thing
17:01:41 cdent or "dunno" is of course a reasonable answer
17:02:07 cdent ✔
17:11:07 melwitt mriedem, stephenfin, gmann: fyi, I have changes proposed for re-enabling testing of console with TLS in nova-next https://review.openstack.org/#/q/topic:bug/1819794+status:open
17:11:40 gmann melwitt: thanks.
17:12:37 sean-k-mooney cdent: is partioning placemetn allocation the "owner thing"
17:13:24 cdent sean-k-mooney: it's basically a way of saying "this allocation of VCPU is from this thing (which happens to be nova X)"
17:13:49 cdent which is somewhat different from the resource provider allocation, which is supposed to be a way of saying "these rps below to cloud X"
17:13:59 cdent (which I think is something jaypipes has been thinking about, if I remember right)
17:14:28 sean-k-mooney cdent: oh its partioning in the sense of multiple nova sharing the same placment
17:14:54 cdent sean-k-mooney: not necessarily. there could be other things that consume vcpu
17:15:03 cdent which may or may not be a nova
17:15:18 sean-k-mooney sure but i thin this started as an edge usecase.
17:15:20 cdent but as you can see there's a lot of overlap and ambiguity here, which is why it needs a bit more drive and discussion
17:15:35 sean-k-mooney ya
17:16:04 cdent yes, it started as an edge usecase, with two different models for the distribution: one placement many clouds, or one placement many novas but same keystone
17:16:10 sean-k-mooney cdent: what are the other consumer of vcpu beyond nova out of interest?
17:16:16 cdent I don't know
17:16:34 cdent I'm not too savvy about either of these use cases, just have heard people mention them
17:16:45 cdent from my standpoint, until somebody steps up a bit more, they aren't yet real
17:16:54 cdent just speculative stuff to think about in the back of the mind
17:16:55 sean-k-mooney i guess maybe zun? but i would have asumed it had its only RP
17:17:14 melwitt to be clear, I didn't mention it because it's a pressing issue right now, just to note that there's another larger reason why we wouldn't be able to remove quota usage counting compat code than just a blocker migration
17:18:10 cdent It does seem like the sort of thing where if there was somebody who had the cycles to make it go, it would be a good thing to have
17:18:17 cdent but until then...
17:19:41 jhinman I'm trying to get an instance up with ovs-dpdk. but the vif doesn't get exposed because of this code: vifs_to_expose = {vif.address: vif for vif in vifs if ('tag' in vif and vif.tag) or vlans_by_mac.get(vif.address)}
17:19:59 sean-k-mooney cdent: having the list of usecasue for the feature would be a good starting point. im not entirly sure that the usecsue we all vaguly recall someone talking about at some point are actully the same feature or should be :)
17:20:23 openstackgerrit Matt Riedemann proposed openstack/nova master: Error out migration when confirm_resize fails https://review.openstack.org/647546
17:20:31 sean-k-mooney jhinman: where is that code ?
17:20:33 cdent sean-k-mooney: yeah, it is a bit vague
17:20:54 jhinman the code is in /virt/libvirt/driver.py
17:21:23 jhinman where does the tag come from?
17:21:55 sean-k-mooney jhinman: what release are you running
17:22:08 sean-k-mooney vifs_to_expose is not in that file on master
17:22:26 jhinman rocky release
17:23:09 sean-k-mooney jhinman: its not there on rocky either are you deploying a downstream version of openstack
17:23:59 jhinman I'm deploying kolla-ansible, so whatever that container has
17:24:41 sean-k-mooney jhinman: kolla-ansible has several modes. are you usign ubuntu source vs cento binary
17:25:04 openstackgerrit Sylvain Bauza proposed openstack/nova master: Add doc on VGPU allocs and inventories for nrp https://review.openstack.org/647519
17:25:19 jhinman ubuntu
17:25:53 sean-k-mooney jhinman: the tag i think is the interface tagging feature where you can associate a generic name to an interface and look it up in the metadata service
17:27:15 jhinman but how does the tag get assigned? is it something passed from neutron. or maybe the tag is not the problem? is there supposed to be a vlan associated
17:27:45 sean-k-mooney its passed in by the user on nova boot. it is not related to the neutron segmentation id
17:27:55 sean-k-mooney its a value like "wan" or "lan"
17:28:30 efried stephenfin: Are we waiting to merge https://review.openstack.org/#/c/645991/ ?
17:28:33 sean-k-mooney so this is the code that is failing https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L9284-L9286
17:29:44 sean-k-mooney looks like we just merged somthing
17:29:46 sean-k-mooney https://github.com/openstack/nova/blob/0dfbcd74642b16432b800b51f304a89d762e3ff1/nova/virt/libvirt/driver.py#L9290-L9292
17:30:54 sean-k-mooney jhinman: there should be nothing ovs-dpdk specific in that code. it shoudl be totally generic
17:34:59 sean-k-mooney jhinman: actully if that is the code that is runnign that should not run for vhost-user interfaces
17:35:00 jhinman ultimately, it ends up with line 9204: LOG.debug('No VIF found with MAC %s, not building metadata', dev.mac_addr)
17:35:09 sean-k-mooney the section i linked if for sriov
17:37:03 sean-k-mooney jhinman: can you provide a paste of the trackback on paste.openstack.org
17:37:34 sean-k-mooney vifs_to_expose = {vif.address: vif for vif in vifs
17:37:36 sean-k-mooney if ('tag' in vif and vif.tag) or
17:37:38 sean-k-mooney vlans_by_mac.get(vif.address)}
17:37:52 sean-k-mooney is in the sriov code path and should not be called when handeling vhost-user
17:39:08 sean-k-mooney well unless we use that fucntion to do generic dispatch to the others. lets see where is it called
17:39:39 sean-k-mooney actully so yes that is how it is working
17:39:50 sean-k-mooney we get the interface metadata here
17:39:52 sean-k-mooney https://github.com/openstack/nova/blob/0dfbcd74642b16432b800b51f304a89d762e3ff1/nova/virt/libvirt/driver.py#L9310
17:41:23 sean-k-mooney jhinman: we emiit that debug message when the user does not specify any device role tags

Earlier   Later