| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-07-03 | |||
| 17:18:31 | mriedem | claudiub: maybe, probably depends on what that's needed for | |
| 17:18:52 | mriedem | claudiub: i'm assuming you guys have extra fields on the instance object for hyperv and you need to lazy-load stuff for the metadata api? | |
| 17:19:45 | claudiub | yeah, we need the device_metadata field when we create the instance config drive, but that's not really a niche field. it's a basic field needed for the config drive | |
| 17:20:49 | mriedem | hmm, have you talked to artom? | |
| 17:20:56 | mriedem | because i'd think libvirt needs the same thing | |
| 17:21:58 | claudiub | mriedem: so, the reason why it worked for libvirt is because libvirt always touches that instance.device_metadata field, while we only set it whenever we have device tags to set in it. | |
| 17:22:35 | mriedem | ah | |
| 17:22:40 | mriedem | claudiub: have you reported a bug? | |
| 17:22:41 | claudiub | while we can also always touch it, this isn't a driver specific issue, we shouldn't have to touch it | |
| 17:22:51 | mriedem | sure, | |
| 17:22:56 | mriedem | i think it's an oversight in dan's patch | |
| 17:22:58 | mriedem | i left a comment in there | |
| 17:23:21 | claudiub | well, i think we can simply reopen the same bug, and post a comment on launchpad about the new issue. | |
| 17:23:49 | mriedem | claudiub: it should be a new bug | |
| 17:23:56 | mriedem | otherwise LP tracking gets confusing | |
| 17:24:05 | claudiub | i see. ok then. i'll open up a new bug | |
| 17:24:57 | mriedem | it's also an unfortunate change in another way, in that obj_load_attr for these will pull the entire instance for each entry and join on another table, it would be nicer to do those all at once with expected_attrs, | |
| 17:25:02 | mriedem | but maybe don't mix those issues together | |
| 17:25:15 | mriedem | it could be optimized for sure though | |
| 17:25:50 | claudiub | yeah, that would be nicer. | |
| 17:27:29 | claudiub | mriedem: also, regarding hyper-v generation 2 vms CI testing, it is in the plan, but the main issue is that we have to test both generation 1 and generation 2 VMs, as they are both currently supported. While more and more OSes are supported on generation 2, it's still not all. | |
| 17:30:47 | claudiub | and the way the VMs are built is quite different too, especially when it comes to attaching volumes / disks, setting boot order, nic hot plugging, and other new features. | |
| 17:31:46 | claudiub | anyways. planning to have some coverage in the ci for gen 2 by the end of pike. | |
| 17:36:02 | mriedem | claudiub: if the majority of users are gen2, then i'd just run the ci on gen2 | |
| 17:36:34 | mriedem | we could always put something in the docs that since pike the hyperv CI is running against gen2 and that's the recommended configuration | |
| 18:03:52 | openstackgerrit | Merged openstack/nova master: placement: adds ProviderTree for nested resources https://review.openstack.org/415920 | |
| 18:15:16 | openstackgerrit | Merged openstack/nova master: placement: support GET /allocation_candidates https://review.openstack.org/475448 | |
| 18:26:17 | openstackgerrit | Andrey Kurilin proposed openstack/python-novaclient master: DO NOT MERGE: debug failed test https://review.openstack.org/479818 | |
| 18:45:31 | openstackgerrit | Merged openstack/nova master: libvirt: update logic to configure device for scsi controller https://review.openstack.org/459740 | |
| 18:46:06 | openstackgerrit | Merged openstack/nova master: libvirt: update the logic to configure volume with scsi controller https://review.openstack.org/459741 | |
| 18:47:34 | mriedem | jaypipes: i went through https://review.openstack.org/#/c/476631/ | |
| 18:47:52 | mriedem | jaypipes: i think we're going to have to adjust that a bit to not call placement if using the caching scheduler | |
| 18:48:44 | jaypipes | mriedem: at some point we need to bite that bullet. | |
| 18:53:25 | mriedem | jaypipes: sure, but it's easy to not do it in this change | |
| 18:53:32 | mriedem | put a flag on the scheduler driver that the host manager can check | |
| 18:53:46 | mriedem | *scheduler manager | |
| 18:54:17 | jaypipes | mriedem: back shortly. need to go pick the pugs up from the groomers. | |
| 18:54:28 | mriedem | oolala | |
| 19:32:27 | jaypipes | mriedem: nothin' better than the smell of a sweet-smellin' grumble of freshly-groomed pugs. | |
| 19:33:35 | mriedem | dry or wet? | |
| 19:34:57 | jaypipes | dry of course. :) | |
| 19:35:06 | mriedem | good | |
| 19:46:34 | jangutter | Due to some scary flu, external deadlines and various conjunctions I was out of OpenStack action for about 2 months... | |
| 19:46:53 | jangutter | And boy, did the nova and os-vif bits that I'm interested change! | |
| 19:47:54 | jaypipes | jangutter: glad you are feeling better! | |
| 19:47:57 | jangutter | My question is to do with the new OVS_ACCELERATION vif that moshele contributed... I'm not seeing where the PCI devices get allocated. | |
| 19:48:30 | jangutter | Lemme grab the patch set. | |
| 19:48:53 | jaypipes | jangutter: PCI devices do not get allocated by os-vif. They are allocated by the resource tracker when a launch instance request is received that includes a PCI device request. | |
| 19:49:09 | jangutter | Yep, that I understand. | |
| 19:49:19 | jaypipes | jangutter: the resource tracker has a PCI device manager inside it, and it's that that does the actual "allocation" of a PCI device to a guest | |
| 19:49:40 | jangutter | But does it just pick _any_ available PCI address? | |
| 19:50:01 | jangutter | ( https://review.openstack.org/#/q/topic:ovs_acc ) | |
| 19:50:17 | jaypipes | jangutter: it picks any available PCI address that matches the PCI device request that is received from the conductor. | |
| 19:50:47 | jaypipes | jangutter: are you wondering who creates that PCI device request? :) | |
| 19:51:32 | jangutter | Yep, remember, I had the brain-dead idea of putting it into neutron-api bits. | |
| 19:51:57 | jaypipes | jangutter: well, there's still quite a bit of Neutron API that is used to construct the PCI device request. | |
| 19:52:08 | jaypipes | jangutter: and that existed before your idea ;) | |
| 19:53:53 | jaypipes | jangutter: what moshele's patch did on the os-vif side was simply create a specialized VIF type class for the "new" OVS_ACCELERATED vif type. That vif type is something that still needs to be created in Neutron and supplied to the nova boot request by passing in a port_id value that corresponds to the pre-created Neutron port that has the port binding information indicating it's an "OVS_ACCELERATED" port. | |
| 19:54:14 | jangutter | Yep, that I got. | |
| 19:54:46 | jangutter | Very similar to what happened in our patch: but the OVS_ACCELERATED vif is new. | |
| 19:55:44 | jaypipes | jangutter: new in Neutron, yeah? | |
| 19:57:00 | jangutter | Oh, hang on. Does it auto-allocate because of VIFHostDevice ? | |
| 19:57:21 | jaypipes | jangutter: what do you mean by "auto-allocate"? | |
| 19:58:47 | jangutter | I'm looking for where the pci_request is made -> it's still at create_pci_requests_for_sriov_ports? | |
| 20:01:38 | jaypipes | jangutter: yep | |
| 20:10:37 | jangutter | jaypipes: OK, that's weird. It must be right before my eyes, but I can't see any way that https://review.openstack.org/#/c/398265/ triggers a pci_request. | |
| 20:14:44 | jangutter | jaypipes: Aaah, sorry, my addled mind has finally caught up: if vnic_type in network_model.VNIC_TYPES_SRIOV: | |
| 20:15:36 | jaypipes | correct | |
| 20:18:03 | jangutter | OK, now that makes sense. It picks up the PCI device from phynet_name | |
| 20:32:55 | openstackgerrit | Jackie Truong proposed openstack/nova master: [WIP] Implement certificate_utils https://review.openstack.org/479949 | |
| 20:34:01 | openstackgerrit | Jackie Truong proposed openstack/nova master: [WIP] Implement certificate_utils https://review.openstack.org/479949 | |
| 20:39:41 | ildikov | mriedem: welcome back :) | |
| 20:40:17 | mriedem | thanks - i never really left | |
| 20:40:52 | ildikov | mriedem: I was wondering whether you could review the swap volume patch by any chance, so while you celebrate freedom I can be the slave of fixing review comments? :) | |
| 20:41:09 | ildikov | mriedem: I know, but still :) | |
| 20:42:20 | mriedem | wow | |
| 20:42:48 | mriedem | maybe, i need to wrap something up first and then i'm out for a bit | |
| 20:44:28 | ildikov | I can keep myself busy with attach that's true, but would rather fix swap hoping it'll be just a long and not endless list | |
| 20:44:45 | ildikov | was just an idea :) | |
| 20:55:09 | mriedem | ildikov: did anyone get started on the grenade test changes last week? | |
| 20:55:13 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Handle uuids in os-hypervisors API https://review.openstack.org/471899 | |
| 20:55:15 | mriedem | to attach on the old side and detach on the new side? | |
| 20:56:06 | ildikov | mriedem: stvnoyes1 is looking into Grenade, he had some issues with setting it up, but he was having progress last week | |
| 20:56:24 | mriedem | ok | |
| 20:56:32 | mriedem | i'm going to run out for a bit | |
| 21:36:38 | andreykurilin | mriedem: hi | |
| 21:38:38 | andreykurilin | mriedem: just note: version list is broken in novaclient due to recent changes in devstack. I suppose it is about https://github.com/openstack-dev/devstack/commit/b90bb1a46193b052cd98513213eed688e8e29d23 . I have POC(https://review.openstack.org/#/c/479818/) of fix, tomorrow will add tests and it will be ready. | |
| 22:21:38 | openstackgerrit | Ildiko Vancsa proposed openstack/nova master: WIP/POC Implement new attach Cinder flow https://review.openstack.org/330285 | |
| 22:29:54 | mriedem | andreykurilin: ok thanks for the heads up | |
| 23:23:05 | openstack | Launchpad bug 1702194 in python-novaclient "test_version_list fails with "(TypeError): 'NoneType' object has no attribute '__getitem__'"" [Undecided,New] | |
| 23:23:05 | mriedem | andreykurilin: track it with this bug https://bugs.launchpad.net/python-novaclient/+bug/1702194 | |
| 23:28:43 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Mask password when logging connection_info during swap volume https://review.openstack.org/466533 | |
| 23:30:24 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: api-ref: Add missing parameters in limits.inc https://review.openstack.org/475640 | |
| 23:34:51 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: api-ref: Add missing parameters in limits.inc https://review.openstack.org/475640 | |
| #openstack-nova - 2017-07-04 | |||
| 00:07:50 | openstackgerrit | Ghanshyam Mann proposed openstack/nova master: Use plain routes list for os-cells endpoint instead of stevedore https://review.openstack.org/474869 | |
| 01:04:41 | openstackgerrit | Ghanshyam Mann proposed openstack/nova master: Add api-ref for os-quota-class-set APIs https://review.openstack.org/467938 | |
| 01:06:08 | openstackgerrit | Ghanshyam Mann proposed openstack/nova master: Add api-ref for os-quota-class-set APIs https://review.openstack.org/467938 | |
| 01:07:31 | openstackgerrit | Ghanshyam Mann proposed openstack/nova master: Add api-ref for os-quota-class-set APIs https://review.openstack.org/467938 | |
| 01:41:39 | openstackgerrit | Ghanshyam Mann proposed openstack/nova master: Add 'networks' quota in quota sample files https://review.openstack.org/479227 | |
| 01:42:15 | openstackgerrit | Ghanshyam Mann proposed openstack/nova master: Add 'networks' quota in quota sample files https://review.openstack.org/479227 | |