| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-10-05 | |||
| 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 | leakypipes | artom: we support all KINDS of pets. | |
| 12:31:09 | cdent | bigly sad | |
| 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 | 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:24 | cdent | leakypipes: [t 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 | leakypipes | artom: yessir | |
| 12:34:55 | artom | So please don't be redundant by putting TIME in the trait name | |
| 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. | |
| 13:33:39 | finucannot | lyarwood: ta | |
| 13:34:07 | openstackgerrit | Stephen Finucane proposed openstack/nova master: conf: Improve documentation for defer_iptables_apply https://review.openstack.org/445436 | |
| 13:34:59 | openstackgerrit | Stephen Finucane proposed openstack/nova master: conf: Undeprecate the 'dhcp_domain' option https://review.openstack.org/480616 | |
| 13:35:37 | sean-k-mooney | leakypipes: actuly just reading your comment regarding a harware htpe and resouce class i dont think that is how it works | |
| 13:36:01 | sean-k-mooney | leakypipes: you dont actully pass the hardware hpet to the guest | |
| 13:36:36 | sean-k-mooney | leakypipes: qemu just can use it as its time source for the guest hpet or it can use another timesoucre | |
| 13:37:03 | leakypipes | sean-k-mooney: oh? I thought you said that only a single guest could use the hardware HPET on a host at a time? | |
| 13:37:15 | sean-k-mooney | leakypipes: no that was for the TPM | |
| 13:37:20 | leakypipes | ahhhhhhhhh | |
| 13:37:38 | leakypipes | sorry, yeah, I was confused. I'll fix the HPET patch ASAP. | |
| 13:38:09 | openstackgerrit | Stephen Finucane proposed openstack/nova master: Modify PciDevice.uuid generation code https://review.openstack.org/530487 | |
| 13:38:10 | openstackgerrit | Stephen Finucane proposed openstack/nova master: Add an online migration for PciDevice.uuid https://review.openstack.org/530905 | |
| 13:38:40 | finucannot | fried_rice: Could you take a look at https://review.openstack.org/#/c/530924/ before it ends up in merge conflict again? :) | |
| 13:39:43 | mdbooth | mriedem: So this one is looking good: https://review.openstack.org/#/c/578846/. I got a clean (of relevant failures) run against your evacuate ci test. | |
| 13:40:12 | openstackgerrit | Stephen Finucane proposed openstack/nova master: objects: Remove legacy '_from_dict' functions https://review.openstack.org/537414 | |
| 13:41:00 | fried_rice | finucannot: Cool feature. Reviewing... | |