Earlier  
Posted Nick Remark
#openstack-nova - 2018-03-22
15:58:36 cdent so we dont' have to encode it
15:58:39 openstackgerrit sahid proposed openstack/nova-specs master: libvirt: add support for virtio-net rx/tx queue sizes https://review.openstack.org/539605
15:58:47 cdent and it wasn't me that was someone else
15:58:56 edleafe cdent: no, I mean multiple query params
15:59:15 efried edleafe: Because we don't support repeating queryparams elsewhere in the API where it would also make sense. E.g. resources=
15:59:29 efried and the inconsistency would make sadness
16:00:11 efried edleafe: e.g. resources=VCPU:3&resources=MEMORY_MB:1024
16:00:19 efried ^ does not work.
16:00:41 edleafe efried: there isn't a good reason why it shouldn't
16:01:08 efried edleafe: other than that the code isn't set up to make it work.
16:01:22 efried If we wanted to support that, we would have to make code changes.
16:01:30 jroll if only we knew someone that could change code :)
16:01:49 edleafe jroll: impossible!!
16:01:49 efried jroll: This would be a pretty pervasive change, for IMO negative benefit.
16:01:49 sean-k-mooney edleafe: that is correct python does not require them to have hyphens but https://tools.ietf.org/html/rfc4122 spcifies the reqiurements for the string representation on page 4 which reuires the use of - when serialising the uuid as a string to be standars complient
16:01:51 dansmith jroll: are you helping? :)
16:02:13 efried Now we've got two different ways to express the same thing - double the test matrix, double the bugs, etc.
16:02:14 cfriesen jaypipes: the emulator threads and I/O threads are separate from the vcpu threads, so it seems odd to make the user ask for a "VCPU" to run them on.
16:02:20 jroll dansmith: I'd be happy to make that work, it seems silly that it doesn't :)
16:02:42 dansmith jroll: no, I mean helping by taking shots from the stands.. and I'm just joking of course :)
16:02:49 jroll I can do that too :P
16:02:58 sahid mriedem: btw i updated the vf trusted spec to address your suggestion about metadata
16:02:59 dansmith heh
16:03:18 mriedem sahid: ok
16:03:19 jaypipes cfriesen: it's all just a processor, IMO.
16:03:27 jaypipes cfriesen: either dedicated or shared CPU resource.
16:03:29 jroll I'm just casting my vote for having the key twice in the url being the sane thing to do imho ¯\_(ツ)_/¯
16:03:57 jaypipes cfriesen: if the emulator thread is dedicated to a physical host CPU, I really don't understand why that isn't considered a "resource consumption".
16:04:00 dansmith jroll: for member_of you mean? I agree, that's what I like the best for my use case
16:04:26 jroll dansmith: yep
16:04:31 sean-k-mooney cfriesen: well normally the emulator tread floats over teh vcpus of the guest so they dont have to ask for extra cpus if they want that behavior
16:05:06 sahid dansmith: i updated tx/rx queue spec I hope you can have a look so I could address any issues
16:05:18 efried To be completely clear on my position:
16:05:18 efried I love repeatable queryparam keys in general.
16:05:18 efried BUT
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 and
16:05:18 dansmith sahid: ack, after the call
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 efried dansmith: It makes sense. I just don't think we should do it. Because testability.
16:09:23 jaypipes sean-k-mooney: that's why I called it overhead_dedicated_Set
16:09:25 sean-k-mooney dansmith: i would equate them as teh same form reading
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:35 dansmith efried: hmm, okay
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 jaypipes cfriesen: right, and I'm opposed to that, because it f**ks with resource tracking and inventory management.
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: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 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:42 coreycb mriedem: special sauce indeeed! my bad.
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 cdent I got what I said here about being least disruptive: [t 3cRQ]

Earlier   Later