Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-03-25
16:14:25 mriedem i guess it's not all move ops
16:15:20 gibi mriedem: I tried to hook into the RequestSpec.flavor property setter but property setter doesn't seem to work on ovos
16:16:15 gibi mriedem: there are another problem noted in the commit message. The numbering of the request groups are lost during the process
16:17:39 mriedem so if someone is resizing with a flavor that has numbered request groups in it, we could lose that
16:17:42 mriedem and break something later
16:17:49 mriedem because we don't persist requested_resources
16:17:50 mriedem right?
16:18:11 gibi mriedem: we are not loosing the group we are loosing the number used in the flavor extra_spec for a given group
16:18:24 dansmith surely we don't want to persist requested_resources
16:18:25 gibi mriedem: besically the patch renumbers each group when generating the a_c query
16:18:35 dansmith since those could change in format or structure across releases
16:18:42 gibi dansmith: I agree
16:18:57 mriedem gibi: isn't the flavor group number coming from the flavor extra specs? which are persisted in RequestSpec.flavor.extra_specs
16:19:25 gibi mriedem: yes. The goal of this patch to create RequestGroup ovos from the flavor
16:19:25 mriedem dansmith: i'm not so sure here, persisting things in request spec has really helped us out thus far......
16:19:31 dansmith mriedem: heh
16:19:56 dansmith the resources in the flavor *are* structural and fixed, but the full set that we calculate from the flavor and other requirements (i.e. from the image, etc) shouldn't be persisted I think
16:20:00 gibi mriedem: there is no place currently in the RequestGroup to store it's ident
16:24:06 mriedem gibi: i'm not sure what that means for this
16:24:24 mriedem what is the ident? requester_id? or just the group number?
16:24:28 mriedem index?
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 openstackgerrit Merged openstack/nova master: Replace openstack.org git:// URLs with https:// https://review.openstack.org/646682
16:26:01 gibi it will be 1,2,3,... in the a_c query
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

Earlier   Later