| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-10-05 | |||
| 12:01:38 | openstackgerrit | Surya Seetharaman proposed openstack/nova master: [WIP] Refactor scatter-gather utility to return exception objects https://review.openstack.org/607934 | |
| 12:01:38 | openstackgerrit | Surya Seetharaman proposed openstack/nova master: Return a minimal construct for nova show when a cell is down https://review.openstack.org/591658 | |
| 12:01:39 | openstackgerrit | Surya Seetharaman proposed openstack/nova master: Return a minimal construct for nova service-list when a cell is down https://review.openstack.org/584829 | |
| 12:01:39 | openstackgerrit | Surya Seetharaman proposed openstack/nova master: API microversion bump for handling-down-cell https://review.openstack.org/591657 | |
| 12:20:21 | leakypipes | cdent, efried, sean-k-mooney: morning sunshines. so, quick question... where should we put the HPET trait in os-traits namespace hierarchy? I was thinking either COMPUTE_HPET or HW_HPET but could also see a case for a new namespace... something like HW_TIME_HPET or just TIME_HPET. Thoughts? | |
| 12:20:47 | leakypipes | for the record, the COMPUTE_ namespace prefix is where we put the virt driver capabilities. | |
| 12:21:01 | leakypipes | and HW_ namespace is where hardware-specific things go. | |
| 12:21:21 | leakypipes | with sub-namespaces like HW_CPU_ and HW_GPU_ etc | |
| 12:23:53 | sean-k-mooney | leakypipes: i would be fine with HW_HPET or HW_TIME_HPET | |
| 12:24:14 | cdent | leakypipes: are we wanting to mean "this host provides an HPET"? If so I'd go HW_HPET or HW_TIME_HPET (in case we ever want a HW_TIME_PIT or some such) | |
| 12:25:15 | sean-k-mooney | leakypipes: the spec was suggesting HW_GUEST_HPET_CAPABLE i think | |
| 12:26:54 | sean-k-mooney | actully it was HPET_GUEST_CAPABLE.. im not sure to be honest. when i see HW_HPET i assume that means the host has a HPET available and eneabled | |
| 12:27:27 | leakypipes | sean-k-mooney: well, to continue my point about traits being capabilities... the _CAPABLE is redundant. | |
| 12:27:42 | leakypipes | sean-k-mooney: and again, the trait decorates the provider (the host) not the guest. | |
| 12:27:54 | sean-k-mooney | so maybe we want 2 traits HW_GUEST_HPET(enable guest HPET) and HW_HPET(find host with hardware hpet) | |
| 12:28:01 | leakypipes | sean-k-mooney: no.... | |
| 12:28:02 | leakypipes | :) | |
| 12:28:08 | leakypipes | sean-k-mooney: that is UNACCEPTABLE! | |
| 12:28:36 | sean-k-mooney | hehe ok so what does HW_HPET mean | |
| 12:29:19 | sean-k-mooney | "host has a hpet or is capable of emulating one" or "host has a hpet" or "host is capable of providing a hpet to a guest" | |
| 12:29:32 | leakypipes | leakypipes: it would mean that the host supports HPET. and the virt driver would see the trait:HW_HPET=require trait in the image metadata and configure the libvirt XML to enable HPET for the guest. | |
| 12:30:41 | leakypipes | leakypipes: I propose keeping it simple with the trait and just having one trait called HW_HPET (or HW_TIME_HPET). then, if the guest configuration really does need to get more complex in the future, we can always add a separate hw:hpet_policy extra spec. | |
| 12:30:47 | leakypipes | artom: :) | |
| 12:30:57 | leakypipes | artom: that ship has already sailed, my friend :P | |
| 12:31:04 | cdent | indeed | |
| 12:31:06 | cdent | sad | |
| 12:31:09 | cdent | bigly sad | |
| 12:31:09 | leakypipes | artom: we support all KINDS of pets. | |
| 12:31:12 | sean-k-mooney | leakypipes: so its virt driver specific then. e.g. ironic it means this host has a hpet and libvirt it means this host can provide a hpet. but in either case the guest will see a hpet | |
| 12:31:27 | artom | Around the world and back, with spices and native prisoners onboard. | |
| 12:32:43 | artom | Also, pet in french means fart, so I'm just giggling like a 13 year old. | |
| 12:32:59 | leakypipes | sean-k-mooney: remember at the end of the discussion last night, we said "we will go with option 2 (which is "just use a trait and have the virt driver look at the traits list for simple configurations") and IFF there is a need for more complex non-binary configuration pieces, then we can add a complementary extra spec that the virt driver can consult for that more specific configuration" | |
| 12:33:18 | leakypipes | artom: :) | |
| 12:33:44 | sean-k-mooney | leakypipes: ya im fine with the hw:hpet_policy for extra config | |
| 12:33:49 | leakypipes | cdent: you have a preference on the trait name? | |
| 12:34:24 | cdent | leakypipes: [t 39lC] | |
| 12:34:24 | purplerbot | <cdent> leakypipes: are we wanting to mean "this host provides an HPET"? If so I'd go HW_HPET or HW_TIME_HPET (in case we ever want a HW_TIME_PIT or some such) [2018-10-05 12:24:14.244038] [n 39lC] | |
| 12:34:46 | artom | Are we bikeshedding? Because HPET is High Precision Event Timer, right? | |
| 12:34:47 | leakypipes | cdent: oh, shit, sorry mate. totally missed that. | |
| 12:34:55 | artom | So please don't be redundant by putting TIME in the trait name | |
| 12:34:55 | leakypipes | artom: yessir | |
| 12:35:11 | sean-k-mooney | leakypipes: i belive this is the first time however that a HW_* trait is being used to dicribe a capablity of the hyperviror rather then a capablity of the hardware teh hypervior is running on which is the only thing i find a little confusing | |
| 12:35:20 | cdent | artom: except that we have namespaces in the traits, sort of | |
| 12:35:37 | leakypipes | sean-k-mooney: we have the COMPUTE_ namespace for virt driver capabilities. | |
| 12:36:00 | artom | cdent, is TIME (eith as _TIME or TIME_) a namespace? | |
| 12:36:06 | leakypipes | sean-k-mooney: but I was under the impression that an HPET was something the host either had or didn't... | |
| 12:36:17 | leakypipes | artom: it was intended as a namespace, yes. | |
| 12:36:19 | sean-k-mooney | leakypipes: right in that case COMPUTE_HPET woudl seam better | |
| 12:36:33 | artom | leakypipes, ah, in that case never mind me :) | |
| 12:36:35 | leakypipes | artom: to future proof if we need to add traits to describe other timer-related thingamabobs. | |
| 12:36:43 | sean-k-mooney | leakypipes: qemu can emulate a hpet with a monotonic clock or other time source | |
| 12:36:59 | sean-k-mooney | so the host does not need to have one for the guest to have one | |
| 12:37:03 | cdent | I think I'm going to write a worm to add CUSTOM_UNACCEPTABLE trait to all clouds it can find | |
| 12:37:14 | leakypipes | heh | |
| 12:37:28 | artom | cdent, or CUSTOM_PWNED | |
| 12:38:19 | sean-k-mooney | leakypipes: so my two cents would be COMPUTE_HPET is compute is capable of providing hpet and HW_HPET is host has a HPET but im not too pushed either way | |
| 12:39:35 | leakypipes | sean-k-mooney: do you see a need for a _TIME subnamespace? | |
| 12:39:53 | leakypipes | sean-k-mooney: feel free to say no... honestly I'm asking you guys since you're closest to the hw vendors. | |
| 12:40:02 | sean-k-mooney | leakypipes: ya i think that is a good idea. cybog are adding a time related feature this cycle | |
| 12:40:15 | leakypipes | sean-k-mooney: ack. to both HW_ and to COMPUTE_, yeah? | |
| 12:40:52 | sean-k-mooney | ya proably. this is the cybog one https://review.openstack.org/#/c/586994/ | |
| 12:41:06 | sean-k-mooney | Add HPTS driver, (HPTS: High Precision Time Synhronization cards) | |
| 12:41:39 | sean-k-mooney | not really sure what they are or why you need them but apparednt zte cares about them | |
| 12:43:06 | leakypipes | sean-k-mooney: the Edge! NFV! 5G! Unicorns! | |
| 12:44:32 | sean-k-mooney | leakypipes: i was thinking more cern/scientif compute but its prably finacal serverces/high frequence trading stuff | |
| 12:44:44 | leakypipes | sean-k-mooney: though, after looking through that HPTS patch, it looks more like HPTS devices are VFs and thus are resources, not traits (i.e. the host would have an inventory of something like an HPTS resource class) | |
| 12:44:55 | jroll | leakypipes: don't bring my life into this | |
| 12:44:59 | jroll | >.> | |
| 12:45:01 | leakypipes | hehe | |
| 12:45:44 | leakypipes | jroll: weren't you supposed to be busy passing through a GPU or something... now leave us! | |
| 12:48:14 | sean-k-mooney | ya i would have assumed the pf provide would be taged with a trait or something but maybe they will just use a resouce class | |
| 12:49:06 | leakypipes | sean-k-mooney: well, it seems that the PF has a limited number of VFs for doing the high-precision timing in guests, which is why I think it's probably an inventory/resource class | |
| 12:49:23 | sean-k-mooney | by the way should i review https://review.openstack.org/#/c/514713/ and https://review.openstack.org/#/c/514712/3/ for secure boot and tp-m traits or leave it to cfressen and co? | |
| 12:50:09 | openstackgerrit | Merged openstack/nova stable/ocata: Add check for invalid allocation amounts https://review.openstack.org/607320 | |
| 12:50:15 | openstackgerrit | Merged openstack/nova stable/ocata: Add check for invalid inventory amounts https://review.openstack.org/607321 | |
| 12:50:21 | openstackgerrit | Merged openstack/nova stable/ocata: Don't delete neutron port when attach failed https://review.openstack.org/607614 | |
| 12:51:19 | sean-k-mooney | leakypipes: while i think of it. i spent 4 hours this morning getting that netdevsim module to compile and load... | |
| 12:51:55 | sean-k-mooney | leakypipes: its support vfs :) they dont have pci enpoint or show up in libvirt :( but the PF does | |
| 12:52:03 | leakypipes | jroll: you know I kid, right? :) we love you here in compute land. | |
| 12:52:17 | leakypipes | sean-k-mooney: lovely. | |
| 12:53:18 | sean-k-mooney | leakypipes: i dont know if the pfs it create will be enough to do testing but its alot less usfull then i was hoping. that said i tested it with an older version so maybe a newer version will support more things | |
| 12:53:56 | sean-k-mooney | im going to park it for a few days but if we can use it to do even a little testign in the gate that would be still an improvement | |
| 12:54:33 | sean-k-mooney | im alot less optimistic now however whcih is a shame. it would be nice to have better sriov/passthough testing. | |
| 12:54:41 | leakypipes | sean-k-mooney: "newer version" <-- does that mean something like "release two nights ago as a ZIP file"? | |
| 12:55:48 | sean-k-mooney | haha no im building form the sorce rpms form fedora 28 but i used the 3.16 kernel it install with in stead of the 3.17.x kernel that is in the package manager. the gate should be using the latest kernel in the package manger | |
| 12:56:36 | openstackgerrit | Surya Seetharaman proposed openstack/nova master: Cleanup comp_node, res_prov, services, aggregate_hosts during cell deletion https://review.openstack.org/546660 | |
| 12:58:19 | sean-k-mooney | crap, when i said 3.x replace that with 4.x ... but same difference. install iso ships with much older kernel then cloud image that the gate uses | |
| 12:58:32 | leakypipes | sean-k-mooney: 3.17.x kernel!? well, at least it's 4 years old. | |
| 12:58:42 | leakypipes | alright, phew... | |
| 13:16:20 | jroll | leakypipes: of course :) | |
| 13:18:57 | openstackgerrit | Jay Pipes proposed openstack/os-traits master: Add COMPUTE_TIME_HPET trait https://review.openstack.org/608258 | |
| 13:19:23 | leakypipes | sean-k-mooney: ^ | |
| 13:26:59 | fried_rice | leakypipes, sean-k-mooney: I'm late to the naming party, but I want it noted that NO significance should be attached to the name I chucked into the spec draft. I was just a placeholder. | |
| 13:27:08 | fried_rice | I dig the name (and reasoning) leakypipes put into ---^ | |
| 13:27:27 | fried_rice | just a teeny paperwork issue with that patch and I'm +2 | |
| 13:27:46 | sean-k-mooney | fried_rice: cool | |
| 13:28:20 | leakypipes | fried_rice: coo, thx | |
| 13:30:04 | finucannot | lyarwood: Fancy hitting https://review.openstack.org/#/c/588570/2 today before you head off on your holliers | |
| 13:30:36 | lyarwood | *clicks* | |
| 13:32:23 | lyarwood | finucannot: cool thanks for doing that, it LGTM now. | |