Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-03-22
16:05:18 dansmith sahid: ack, after the call
16:05:18 efried and
16:05:18 efried I'm opposed to making all the existing APIs accept repeated keys in addition to accepting their current syntax.
16:05:18 efried BUT
16:05:18 efried I love repeatable queryparam keys in general.
16:05:18 efried To be completely clear on my position:
16:05:19 efried I'm pretty neutral on making the (new) member_of key repeatable, even though it deviates from the norm.
16:05:22 mriedem if you're talking about AND semantics in the API, glance already has some for filtering https://developer.openstack.org/api-ref/image/v2/index.html#show-images
16:05:43 sahid dansmith: cool thanks
16:06:09 dansmith johnthetubaguy: ^
16:06:12 edleafe sean-k-mooney: of course we should be strict in how we create and store them. But there is no harm in accepting a non-hyphenated UUID string - it's unambiguous
16:06:16 cfriesen jaypipes: I fully agree that it's resource consumption if the emulator thread is running "isolated". I'm just not sure it makes sense to use the "VCPU" resource given the name which strongly implies "virtual CPU".
16:06:23 jroll efried: that's fair
16:06:49 openstackgerrit Stephen Finucane proposed openstack/nova-specs master: Update spec to reflect reality https://review.openstack.org/555000
16:06:52 jaypipes cfriesen: so what sean-k-mooney just said " normally the emulator tread floats over teh vcpus of the guest" is wrong then?
16:06:58 sean-k-mooney edleafe: i disagree it does cause harm as we need to have normalistion code
16:07:07 efried mriedem: Unfortunately I don't see anything in there that helps us in this case.
16:07:55 cfriesen jaypipes: normally the emulator threads are allowed to run on all the host cpus that the vCPU threads run on
16:07:56 sean-k-mooney jaypipes: also the emulator threads is libvirt specific so we have to be carful not to leak too much of the implentation details via the api
16:08:02 johnthetubaguy sahid: thanks for the quick turn around on that, taking a look at it again now
16:08:46 dansmith cdent: efried: so, resources=CPU:1 AND resources=MEM:1024 would be the same semantic meaning as resources=CPU:1,MEM:1024 actually right?
16:08:52 mriedem coreycb: https://bugs.launchpad.net/nova/+bug/1758060 - i don't see that test in the upstream repo
16:08:53 openstack Launchpad bug 1758060 in nova (Ubuntu) "16.1.0 test failure UEFI is not supported" [Low,Triaged] - Assigned to Corey Bryant (corey.bryant)
16:08:59 mriedem coreycb: special sauce?
16:09:00 dansmith I think someone said that wouldn't make sense, butnow I'm not sure I get that
16:09:23 jaypipes sean-k-mooney: that's why I called it overhead_dedicated_Set
16:09:23 efried dansmith: It makes sense. I just don't think we should do it. Because testability.
16:09:25 sean-k-mooney dansmith: i would equate them as teh same form reading
16:09:35 dansmith efried: hmm, okay
16:09:35 mriedem efried: "To find images tagged with ready and approved, include tag=ready&tag=approved in your query string. (Note that only images containing both tags will be included in the response.)"
16:09:40 sahid johnthetubaguy: ack thanks
16:09:46 cfriesen jaypipes: currently if you enable "isolate" for the emulator then nova will internally allocate another physical host cpu to run the emulator threads
16:10:20 cdent I said it didn't make sense, but that may be because I'm not fully understanding dan's use case
16:10:20 jaypipes cfriesen: right, and I'm opposed to that, because it f**ks with resource tracking and inventory management.
16:10:53 dansmith cdent: I'm on a call right now, but maybe a hangout with interested parties when I'm done?
16:10:58 cdent and also because I wasn't really thinking and on the resources case, more concatenation of value
16:11:03 dansmith if it's really a misunderstanding thing
16:11:26 cdent dansmith: I'd like to understand more but today's not great, i'm in a meeting right now and have been in one or another since I started today
16:11:27 efried The problem is simply that we used ',' to mean 'AND' in the `resources` qparam; but ',' is already taken in `member_of` (to mean 'OR', unfortunately, but disambiguated by requiring `in:`, which consumes another nice piece of punctuation, the ';')
16:11:31 jaypipes cfriesen: I am attempting to create a new resource class that represents a physical dedicated CPU (sahid would rather this resource class be called CPU_DEDICATED insetad of PCPU) that can be used to inventory these kinds of resources (which are currently not tracked in the same way as other resources, much to my dismay)
16:11:51 efried s/';'/':'/
16:11:53 efried sigh
16:12:04 dansmith efried: ah okay, although that's also kindof already done, but yeah I see that now
16:12:06 sean-k-mooney jaypipes: yes, if we track the overhead sepreatly form the pcpus/vcpu resuces it could imply that the cpus the guest sees is the resouce:*CPU-overhead or we ask for resouce:*cpus + over head form placement
16:12:31 cfriesen jaypipes: the problem is if I have X "dedicated" guest vcpus, and I want to allocate X+1 physical cpus, and run the emulator threads on a physical CPU that isn't running any vCPU thread.
16:12:40 jaypipes sean-k-mooney: this has nothing to do with "what the guest sees". this is a resource accounting issue only.
16:12:42 coreycb mriedem: special sauce indeeed! my bad.
16:12:42 efried dansmith: so let's move ahead with repeatable member_of. Human reading query string will interpret '&' as 'AND', as it should be.
16:12:47 mriedem nice
16:13:30 cdent wait, efried, did you just make a new different decision? I thought we had gone the other way ten minutes ago?
16:13:39 efried vay
16:13:40 cfriesen jaypipes: I'd be fine with CPU_DEDICATED. Would we also have CPU_SHARED instead of VCPU?
16:14:01 efried cdent: Where's your purple thingy?
16:14:04 jaypipes sean-k-mooney: this is only about answering the question "how many dedicated CPUs are left on the host (or on a specific NUMA node)?" and "how many shared CPUs are left on the host (or specific NUMA node)"
16:14:06 sean-k-mooney jaypipes: well it could what im asking is the resouces we counting are track soly by the vaules of resources:PCPU and resources:VCPU and that the overhead extra spec dont effect how we claim in placement
16:14:19 cdent efried: do p!help
16:14:22 efried p!help
16:14:26 jaypipes cfriesen: no, we can't change VCPU to CPU_SHARED, unfortunately.
16:14:29 cdent p!help
16:14:46 efried p!log
16:14:53 jaypipes cfriesen: which is why I wanted PCPU to be the class name for the dedicated CPU resource, since it matched VCPU
16:15:05 cdent you can do it in a privmsg too, so we don't have to see it. there you can leave off the p! prefic
16:15:18 efried cdent: http://p.anticdent.org/logs/openstack-nova?dated=2018-03-22%2016:05:18.169011#4hT5
16:16:37 efried cdent: Basically, we collectively on average seem to hate the available options for intra-param punctuation more than we hate deviating from the rest of the API by supporting repeatable for this one new case.
16:16:52 sean-k-mooney jaypipes: can you clear up somthing for me. if i have resources:VCPU=4 resources:PCPU=1 and hw:overhead_dedicated_set=0 do i claim 5 cpus in placement (4 shared and 1 dedicated)
16:16:53 cdent oh, that's not how intepreted that
16:16:58 openstackgerrit Eric Young proposed openstack/nova master: Support extending attached ScaleIO volumes https://review.openstack.org/554679
16:17:23 purplerbot <cdent> efried: "fixable problem" was the immediate thing of "being able to accept duplicates on keys in general". I agree that addressign dan's problem in the least disruptive way is probably syntax in the param [2018-03-22 15:53:38.038412] [n 3cRQ]
16:17:23 cdent I got what I said here about being least disruptive: [t 3cRQ]
16:17:35 jaypipes sean-k-mooney: no, you claim 4 VCPU and 1 PCPU resources.
16:17:47 jaypipes sean-k-mooney: there's no such things as a generic "CPU resource"
16:17:51 sean-k-mooney jaypipes: yes that is what i ment
16:18:23 sean-k-mooney i just wanted to make sure we dont claim 4VCPUs and 2 PCPUS
16:18:50 cfriesen sean-k-mooney: jaypipes: hw:overhead_dedicated_set doesn't make sense since we may want to run emulator threads separate from all vCPU threads (this is what "isolate" does today)
16:19:05 sean-k-mooney and in this case the guest recived 5 logical cpus and the emulator tread is pinned to the PCPU that was allocated to the vm
16:19:11 cdent efried: it probably doesn't matter _that_ much as long as documentation etc
16:19:17 cdent (whichever choice we make)
16:19:31 jaypipes cfriesen: ack. I'm reworking this in the spec after your feedback.
16:19:56 sean-k-mooney cfriesen when you say isolate which isolate do you mean
16:20:00 efried cdent, dansmith, edleafe: Okay, let's make a call one way or another. And send an email. And propose a spec delta. And fix the code. And close the books.
16:20:00 jaypipes cfriesen, sean-k-mooney: can there ever be >1 emulator thread, though?
16:20:08 cfriesen jaypipes: yes
16:20:12 edleafe cdent: efried: I didn't realize that we didn't accept multiple resources= params. But I do agree that changing that now is not a good use of time
16:20:15 jaypipes sean-k-mooney: he is referring to hw:emulator_threads_policy=isolate
16:20:22 cfriesen jaypipes: and there can be multiple I/O threads too
16:20:50 jaypipes cfriesen: and how does "hw:emulator_threads_policy=isolate" account for >1 emulator thread? that was the whole point of the overhead_dedicated_set being a pinset -- allowing >1 emulator thread to be specified.
16:20:56 sean-k-mooney jaypipes: ah ok hw:cpu_threads_policy=isolate is different just makeing sure
16:21:11 cfriesen jaypipes: all the emulator threads get affined to a single physical cpu
16:21:44 jaypipes cfriesen: that sounds like a libvirt-specific assumption that will likely change at any given time (as most of these things tend to do)
16:22:03 sahid jaypipes: oh so you can't change VCPU? in that case i'm ok with PCPU
16:22:18 cfriesen jaypipes: the emulator threads don't usually have a lot of work to do (the exception is during live migration I think). the goal of "hw:emulator_threads_policy=isolate" is to ensure that the minimal work they do doesn't interrupt the guest cpu threads
16:22:25 jaypipes sahid: I mean, we *could*, but that would be a seriously annoying code change ;)
16:23:00 mriedem melwitt: if you approve a blueprint like https://blueprints.launchpad.net/nova/+spec/hurrah-for-privsep-again you should set the 'series goal' to rocky so it shows up on the actual rocky blueprints page: https://blueprints.launchpad.net/nova/rocky
16:23:36 melwitt mriedem: sorry, I missed that it wasn't set. setting now
16:24:05 jaypipes cfriesen: so it never makes sense to have emulator threads on dedicated CPUs and guest vCPU threads on shared CPUs, right?
16:24:12 cfriesen jaypipes: yes, I suppose that's qemu-specific
16:24:34 cfriesen jaypipes: no, that wouldn't make sense.
16:24:37 sahid jaypipes: yes i'm agreed with cfriesen, that never make sense
16:25:04 jaypipes cfriesen: furthermore, from what I gather from your and sean-k-mooney's feedback, it also would never make sense to have emulator threads policy set to *anything* if the guest vCPU threads were *not* pinned to dedicated CPUs.
16:25:28 cfriesen jaypipes: yes

Earlier   Later