Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-10-05
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 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

Earlier   Later