| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-10-04 | |||
| 22:41:50 | cfriesen | if we have a trait that is requested in the flavor and forbidden in the image, do we error out currently? | |
| 23:21:32 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: Remove mox in libvirt/test_driver.py (7) https://review.openstack.org/571992 | |
| 23:22:00 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: Remove mox in libvirt/test_driver.py (8) https://review.openstack.org/571993 | |
| 23:23:09 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: Remove mox in virt/test_block_device.py https://review.openstack.org/566153 | |
| 23:23:23 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (3) https://review.openstack.org/574104 | |
| 23:23:35 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (4) https://review.openstack.org/574106 | |
| 23:23:52 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (5) https://review.openstack.org/574110 | |
| 23:33:29 | openstackgerrit | Merged openstack/nova master: Enable nested allocation candidates in scheduler https://review.openstack.org/585672 | |
| 23:38:26 | openstackgerrit | Merged openstack/nova master: Use provider tree in virt FakeDriver https://review.openstack.org/604083 | |
| 23:52:20 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: Add API ref guideline for examples https://review.openstack.org/604060 | |
| 23:52:30 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: Add API ref guideline for body text https://review.openstack.org/605628 | |
| #openstack-nova - 2018-10-05 | |||
| 00:22:49 | openstackgerrit | Merged openstack/nova master: Fix logging parameter in _populate_pci_mac_address https://review.openstack.org/607628 | |
| 00:45:53 | openstackgerrit | Merged openstack/nova master: Not set instance to ERROR if set_admin_password failed https://review.openstack.org/555160 | |
| 03:14:11 | openstackgerrit | Merged openstack/nova master: Handle missing marker during online data migration https://review.openstack.org/605164 | |
| 03:26:50 | openstackgerrit | Merged openstack/nova master: Placement: Remove usage of get_legacy_facade() https://review.openstack.org/607336 | |
| 06:05:51 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: Remove an unnecessary duplicate flag https://review.openstack.org/608162 | |
| 06:34:28 | openstackgerrit | Vlad Gusev proposed openstack/nova stable/rocky: Not set instance to ERROR if set_admin_password failed https://review.openstack.org/608165 | |
| 06:42:25 | giblet | happy Friday nova | |
| 07:33:02 | mrch_ | . | |
| 07:39:40 | PapaOurs | good Friday novaers | |
| 08:08:58 | openstackgerrit | Vlad Gusev proposed openstack/nova stable/queens: Not set instance to ERROR if set_admin_password failed https://review.openstack.org/608179 | |
| 08:09:50 | openstackgerrit | Vlad Gusev proposed openstack/nova stable/pike: Not set instance to ERROR if set_admin_password failed https://review.openstack.org/608180 | |
| 08:26:15 | openstackgerrit | Merged openstack/nova master: Refactor allocation checking in functional tests https://review.openstack.org/607287 | |
| 09:01:17 | openstackgerrit | Lee Yarwood proposed openstack/nova stable/queens: libvirt: Remove reference to transient domain when detaching devices https://review.openstack.org/608186 | |
| 09:02:30 | openstackgerrit | Sylvain Bauza proposed openstack/nova master: libvirt: implement reshaper for vgpu https://review.openstack.org/599208 | |
| 09:13:03 | PapaOurs | giblet: off the discussions we had, I just rebased ^ | |
| 09:18:40 | giblet | PapaOurs: ack | |
| 10:03:48 | openstackgerrit | Merged openstack/nova stable/queens: libvirt: Use os.stat and os.path.getsize for RAW disk inspection https://review.openstack.org/604295 | |
| 12:01:37 | openstackgerrit | Surya Seetharaman proposed openstack/nova master: Return a minimal construct for nova list when a cell is down https://review.openstack.org/567785 | |
| 12:01:37 | openstackgerrit | Surya Seetharaman proposed openstack/nova master: Modify get_by_cell_and_project() to get_not_deleted_by_cell_and_project() https://review.openstack.org/607663 | |
| 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:38 | openstackgerrit | Surya Seetharaman proposed openstack/nova master: [WIP] Refactor scatter-gather utility to return exception objects https://review.openstack.org/607934 | |
| 12:01:39 | openstackgerrit | Surya Seetharaman proposed openstack/nova master: API microversion bump for handling-down-cell https://review.openstack.org/591657 | |
| 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: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 | 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! | |