Posted	Nick	Remark
#openstack-nova - 2018-10-04
22:00:32	imacdonn	efried: schema migrations stuff already gets logged there
22:00:35	efried	I mean, I assume you tried this out locally and were able to see those logs
22:00:41	efried	okay
22:00:42	imacdonn	efried: affirm
22:01:41	jaypipes	cfriesen: yes, nice work on that ML post. ++
22:01:52	efried	imacdonn: oic, it gets set up in main()
22:02:29	imacdonn	efried: ah, yeah
22:05:35	openstackgerrit	Merged openstack/nova master: Don't emit warning when ironic properties are zero https://review.openstack.org/605754
22:05:41	openstackgerrit	Merged openstack/nova stable/pike: Fix service list for disabled compute using MC driver https://review.openstack.org/592337
22:06:28	efried	cfriesen: When you're spiffing up that spec, I forgot to put blueprint: support-hpet-on-guest in the commit message
22:07:18	efried	interestingly, lp seems to have picked it up anyway. Maybe based on the topic?
22:07:34	cfriesen	I noticed that too. gotta be the topic
22:07:43	cfriesen	but yes, will add it in
22:08:02	efried	okay, folks, I'm done like toast. ō/
22:08:26	imacdonn	you're fried? fnar-fnar
22:10:09	cfriesen	jaypipes: so would we need to propose changes in os-traits adding new traits for HPET and TPM?
22:13:45	jaypipes	cfriesen: go for it :)
22:13:59	cfriesen	jaypipes: just wondering what the "proper" way to do this is
22:16:20	cfriesen	is anything in nova using os-traits yet?
22:26:39	cfriesen	what do you guys think of using HW_SYSTEM_X86_* and HW_SYSTEM_* for instance traits that aren't cpu/gpu/nic specific, like HPET and TPM?
22:27:04	cfriesen	and uefi
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: Modify get_by_cell_and_project() to get_not_deleted_by_cell_and_project() https://review.openstack.org/607663
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: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 :)

Earlier   Later