| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-04-03 | |||
| 13:53:29 | sdague | and it's arguably a security risk given the entropy problem | |
| 13:54:57 | johnthetubaguy | sdague: yeah, I am certainly leaning that way | |
| 13:55:14 | johnthetubaguy | macsz: I think you just need to cover more details on what the API does, now the implementation is deleted | |
| 13:55:27 | edleafe | Scheduler subteam meeting in 5 minutes in #openstack-meeting-alt | |
| 13:58:21 | macsz | thanks for insights, johnthetubaguy | |
| 15:04:33 | openstackgerrit | Béla Vancsics proposed openstack/nova master: Reduced the complexity of the _init_instance method (3) https://review.openstack.org/420619 | |
| 15:09:52 | sneti_ | johnthetubaguy, can you please review https://review.openstack.org/#/q/topic:bp/additional-notification-fields-for-searchlight+status:open when you have time.. getting merge conflicts every time a versioned notification patch gets merged. | |
| 15:12:19 | openstackgerrit | Lee Yarwood proposed openstack/nova master: encryptors: Switch to os-brick encryptor classes https://review.openstack.org/391597 | |
| 15:14:36 | openstackgerrit | Scott Moser proposed openstack/nova master: Limit exposure of network device types to the guest. https://review.openstack.org/400883 | |
| 15:26:58 | openstackgerrit | Roman Podoliaka proposed openstack/nova-specs master: Ironic: add support for instance RAID configuration https://review.openstack.org/408151 | |
| 15:29:04 | andreas_s | thorst, Hey Drew, is this already on your radar? https://bugs.launchpad.net/cloud-init/+bug/1663315 | |
| 15:29:04 | openstack | Launchpad bug 1663315 in cloud-init " identify openstack kvm platform on ppc64" [Medium,Confirmed] | |
| 15:29:39 | thorst | andreas_s: looking... | |
| 15:30:40 | thorst | andreas_s: actually, it hasn't been (as I'm more PowerVM). Though PowerVM does have the same issue and we've been scratching our head how to solve. | |
| 15:30:51 | thorst | but let me see if I can get someone to take a peak at this. | |
| 15:31:01 | mriedem | artom: i looked at your tempest test for the tagged vif / volume attach test https://review.openstack.org/#/c/391947/ | |
| 15:31:15 | mriedem | artom: looks like you're not waiting for the interface to be used before checking the device tags on the guest | |
| 15:31:25 | andreas_s | thorst, ok - cause we have the same issue on s390... | |
| 15:31:42 | artom | mriedem, that's possible... | |
| 15:31:46 | mriedem | artom: what's odd is that the test fails because it doesn't find any tagged devices on the guest, but the attach_volume method will wait for the volume to be in-use, so that should be on the guest | |
| 15:31:47 | thorst | andreas_s: yeah...I know burgerk has been working that issue from a cloud-init perspective rather than a pure OpenStack perspective | |
| 15:31:52 | mriedem | unless things just aren't working yet in that series | |
| 15:31:55 | thorst | may want to sync up with him | |
| 15:32:03 | artom | mriedem, in local test I think it has something to do with metadata cache | |
| 15:32:13 | artom | Which may or may not mask the ACTIVE interface issue | |
| 15:32:39 | artom | mriedem, because it's not deterministic - sometimes I see 1 tags, sometimes 0, but never both | |
| 15:32:40 | thorst | andreas_s: I'll see if I can get him on IRC. | |
| 15:33:13 | artom | mriedem, thanks for taking a look, at any case :) I'm kind on other things now, but I'll circle back in two or 3 days | |
| 15:33:27 | mriedem | artom: hmm, isn't this using config drive though which shouldn't be racy or care about a cache? | |
| 15:33:58 | artom | mriedem, https://github.com/openstack/nova/blob/master/nova/api/metadata/handler.py#L78 | |
| 15:34:04 | mriedem | artom: how offended will you be if i -2 the bottom change in the series until the tempest test is passing? | |
| 15:34:15 | artom | mriedem, I shall write angry letters | |
| 15:34:38 | markus_z | felipemonteiro: are you around? | |
| 15:34:39 | mriedem | it's a good thing i can't read | |
| 15:34:40 | artom | I probably should have done that myself, in all seriousness | |
| 15:35:17 | artom | I shall have a towne cryer at your doorstep | |
| 15:35:28 | mriedem | ye olde towne cryer? | |
| 15:35:50 | artom | aye, ye oldeste | |
| 15:37:37 | mriedem | ok so the config drive is also dependent on this md cache? | |
| 15:38:10 | openstackgerrit | Sylvain Bauza proposed openstack/nova master: Destroy the ReqSpec object when deleting the instance https://review.openstack.org/391060 | |
| 15:38:53 | artom | mriedem, I'd have to look at the code | |
| 15:39:00 | artom | IIRC it grabs the https://github.com/openstack/nova/blob/master/nova/api/metadata/base.py#L109 object directly | |
| 15:39:03 | mriedem | lyarwood: red hat probably cares about these fixes on stable https://review.openstack.org/#/q/a41d265a19b7bcb1af8fc179bf864e00023c6cc6,n,z | |
| 15:39:04 | artom | So no cache involved | |
| 15:39:06 | mriedem | artom: i can look too | |
| 15:39:12 | mriedem | i'm just high on cold medicine | |
| 15:39:54 | bauzas | mriedem: dansmith: blushing about https://review.openstack.org/391060 | |
| 15:40:07 | bauzas | in case you wanna bite it ^ | |
| 15:40:19 | mriedem | did you fix your pep8 issue? | |
| 15:41:19 | artom | mriedem, https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L3245 | |
| 15:41:24 | artom | That seems to say I'm right | |
| 15:41:39 | artom | https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L62 | |
| 15:41:44 | artom | It's importing base, not handler | |
| 15:41:50 | openstackgerrit | Anusha Unnam proposed openstack/nova master: Add description to policies in servers.py https://review.openstack.org/451966 | |
| 15:41:50 | bauzas | mriedem: yup, hence me blushing | |
| 15:42:20 | bauzas | I should write 100 times "I shall not provide a i18n message for a debug log" | |
| 15:42:23 | mriedem | right which calls instance_md.metadata_for_config_drive() | |
| 15:43:46 | bauzas | the right-side of Gerrit makes me chilling when I see 9 concurrent patches conflicting with mine :) | |
| 15:43:55 | mriedem | god i always have a hard time chasing down what the md code does | |
| 15:44:26 | artom | Md is due for some refactoring | |
| 15:44:36 | artom | Proper versionning, to begin with | |
| 15:45:04 | artom | And if we can improve on the reason why folks don't like to deploy it, that'd be cool as well | |
| 15:45:24 | artom | IPv6, not so easy to spoof your way into another instance's md... | |
| 15:45:52 | mriedem | do we dump the guest console when your test fails? that would be interesting to see since i think it dumps the config drive | |
| 15:49:48 | mriedem | oh you're not calling verify_metadata_on_config_drive from the tempest test | |
| 15:51:18 | artom | mriedem, not for attach | |
| 15:51:32 | artom | There was agreement that we're not updating the config drive with the new tags | |
| 15:51:38 | mriedem | oh right, | |
| 15:51:42 | mriedem | yeah because we don't update config drive | |
| 15:52:42 | artom | Continuing with the improved metadata service thought, do we have a virt-agnostic way of shoving something into an instance? | |
| 15:53:10 | artom | Really, the only way to make sure it really is the instance it's claiming to be that is asking for metadata is with some sort of shared secret | |
| 15:53:44 | artom | But how do we let the guest know of that secret? | |
| 15:54:08 | artom | Anyways, maybe I'll propose that for next cycle | |
| 15:54:26 | mriedem | i thought passing secrets was part of the vendordata v2 stuff | |
| 15:54:55 | artom | But that still goes through the metadata API, right? | |
| 15:55:01 | mriedem | i thought that's what rob crittenden's vendordata service did | |
| 15:55:38 | mriedem | the initial request is made when creating the config drive, so not through the md api | |
| 15:55:59 | artom | Hrm... But the config drive is libvirt-only, no? | |
| 15:56:07 | mriedem | which is why there was also an ask at BCN for a way to make the server create fail if the vendordata stuff failed during config drive creation | |
| 15:56:13 | mriedem | no | |
| 15:56:21 | artom | As in, we can't rely on it to supply the guest with a secret that it can then use to query the metadata API | |
| 15:56:43 | artom | For real? So xenapi and hyperv support it? | |
| 15:56:46 | mriedem | yes | |
| 15:56:51 | mriedem | all virt drivers support config drive | |
| 15:57:08 | artom | Yey :) | |
| 15:57:09 | mriedem | https://docs.openstack.org/developer/nova/support-matrix.html#guest_setup_configdrive | |
| 15:57:41 | artom | Hrmm, maybe I really will propose metadata API improvement next cycle | |
| 15:58:10 | artom | Or this cycle? What's the likelyhood of a spec making its way in? | |
| 15:58:17 | artom | This late in the spec-review process | |
| 15:58:44 | mriedem | with ~100 open specs already? chances aren't great, unless it's a big win and a simple spec probably. | |
| 15:58:48 | mriedem | have you read through https://docs.openstack.org/developer/nova/vendordata.html btw? | |
| 15:59:13 | mriedem | i thought removing bdm device from the API would be easy, turns out i was way wrong on that | |
| 16:00:07 | artom | Wait, remove bdm device? | |
| 16:00:22 | mriedem | specifying the device on create and attach | |
| 16:00:26 | bauzas | jaypipes: humpf, reading thru your comments on the claims spec, do you accept now given our IRC meeting that we could POST allocations not at the same time with GET /rps, ie. after filters running ? | |
| 16:00:30 | mriedem | https://review.openstack.org/#/c/452546/ | |
| 16:00:43 | jaypipes | bauzas: yes | |
| 16:00:47 | mriedem | artom: turns out there is an ec2 use case that we've been supporting for years, | |
| 16:00:50 | mriedem | that no one really knew existed | |
| 16:00:55 | bauzas | jaypipes: I know it's not what you want, but I think it's a trade-off so that sooner or later, we could merge both calls | |