| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-04-03 | |||
| 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 | |
| 16:00:56 | mriedem | and now i can't break it | |
| 16:01:10 | bauzas | jaypipes: okay, thanks for the clarification | |
| 16:01:11 | jaypipes | bauzas: yes. | |
| 16:01:16 | artom | mriedem, and actually I think it would break device tagging as well | |
| 16:01:26 | mriedem | artom: why? | |
| 16:01:38 | artom | mriedem, https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L7696 | |
| 16:01:50 | artom | We use device name to match the XML to the bdm | |
| 16:01:57 | oomichi | alex_xu: can you take a look at https://review.openstack.org/#/c/452284 ? | |
| 16:02:03 | bauzas | jaypipes: and sorry, I thought you were in favor of a "ticket" (let's call it UUID), at least that's what I remember from some very old midcycle | |
| 16:02:13 | mriedem | artom: the libvirt driver completely ignores any user-supplied device name, and calculates it's own | |
| 16:02:13 | artom | (I'm right in saying that it's the device name the user passed in, right?) | |
| 16:02:46 | jaypipes | bauzas: no, I think the APIs we have will work fine as-is for the moment. | |
| 16:03:18 | bauzas | jaypipes: good with me | |
| 16:03:28 | mriedem | artom: https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L7833 | |
| 16:03:29 | artom | mriedem, fair enough, I need to refresh myself on how the above link works then :/ | |
| 16:03:32 | mriedem | ^ been there since liberty | |
| 16:03:59 | mriedem | artom: i think this code is what sets the device names on the bdm objects https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L7840 | |
| 16:04:08 | artom | Ah, so there's still a matching name between the bdm and XML | |
| 16:04:16 | artom | But it's libvirt that sets it, not the user | |
| 16:04:19 | mriedem | correct | |
| 16:04:29 | mriedem | it's all very confusing where libvirt sets it, because the libvirt driver doesn't actually set it | |
| 16:04:33 | mriedem | block_device.default_device_names does | |
| 16:04:49 | mriedem | like most of the bdm code, it's a lot of smoke and mirrors | |
| 16:05:14 | artom | Any sentence that matches /.*block.*device.*confusing.*/ is a tautology | |
| 16:05:37 | mriedem | nvm i guess it is specific to the libvirt driver https://github.com/openstack/nova/blob/master/nova/virt/libvirt/blockinfo.py#L466 | |
| 16:05:54 | mriedem | it has those driver bdm wrapper objects | |
| 16:06:02 | mriedem | so it can mutate the underlying bdm object, and then update it in the db | |
| 16:06:05 | mriedem | using driver_bdm.save() | |
| 16:06:20 | mriedem | and get_disk_info(virt_type, instance, image_meta, block_device_info) is not read-only :) | |
| 16:07:02 | artom | Well, get_guest_xml() isn't read-only either IIRC, so it's at least internally consistent | |
| 16:07:21 | mriedem | https://github.com/openstack/nova/blob/master/nova/virt/libvirt/blockinfo.py#L488 | |
| 16:07:50 | mriedem | yeah anyway, point is, the libvirt driver sets the device name for the bdm, the user doesn't | |
| 16:08:43 | mriedem | sdague: johnthetubaguy: dansmith: did you read that thread in the ML on removing user-supplied bdm devices from requests in the API? i had no idea people were using our crappy data model for overriding image bdms | |
| 16:09:12 | openstack | Launchpad bug 1679223 in OpenStack Compute (nova) "tempest.api.compute.servers.test_server_tags.ServerTagsTestJSON fail on centos7 nodes" [Undecided,New] | |
| 16:09:12 | markus_z | felipemonteiro: Would be cool if you could take a look at: https://bugs.launchpad.net/nova/+bug/1679223 | |
| 16:10:43 | dansmith | mriedem: I saw it, didn't read it | |
| 16:11:00 | dansmith | mriedem: but yeah, I knew | |
| 16:11:01 | sdague | mriedem: it didn't fully sink in, I'll have to revisit | |
| 16:14:21 | bauzas | mriedem: jaypipes: I have a thought, and I'd love your feedback about claims | |
| 16:14:28 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Factor out duplicated notification sample data (2) https://review.openstack.org/452819 | |
| 16:14:28 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Factor out duplicated notification sample data https://review.openstack.org/452818 | |
| 16:14:29 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Factor out duplicated notification sample data (3) https://review.openstack.org/452820 | |
| 16:14:44 | bauzas | mriedem: jaypipes: I have a long standing BP targeting to pass the Spec object down to the compute, mostly for rescheduling needs | |
| 16:14:53 | jaypipes | bauzas: I'll trade ya for a review of https://review.openstack.org/#/c/448282/? :) | |
| 16:15:31 | bauzas | mriedem: jaypipes: if we would pass the allocations as part of the Spec object down to the compute, it would prevent us to have a very specific RPC modification for something abstract enough | |
| 16:16:04 | jaypipes | bauzas: yup, makes sense to me. | |
| 16:16:05 | bauzas | mriedem: jaypipes: ie. the conductor gets the Spec object, pass it to the scheduler, and gives back a list of allocations (because the scheduler would claim) | |
| 16:16:07 | mriedem | i'm out of the loop on the claims stuff. | |
| 16:16:21 | bauzas | then, it would pass it down to the compute by setting those claims | |
| 16:16:30 | mriedem | what is the compute going to do with them? | |
| 16:16:50 | mriedem | isn't the whole point that the compute no longer needs to care about setting allocations in the RT? | |
| 16:16:50 | bauzas | jaypipes: it would allow us to change the RPC interface to just accept a spec_obj attribute and read the allocations UUIDs | |
| 16:16:58 | bauzas | mriedem: in case something goes wrong | |
| 16:17:03 | mriedem | what does that mean? | |
| 16:17:06 | bauzas | mriedem: the compute would DELETE those allocations | |
| 16:17:06 | jaypipes | mriedem: if the compute sees the allocations in the request spec, it wouldn't need to do the claims.Claim() build. | |
| 16:17:35 | bauzas | and it would trigger the reschedule by passing back the Spec | |
| 16:17:54 | mriedem | i thought the scheduler was going to delete the allocations if something failed on a given compute host? | |
| 16:18:03 | bauzas | jaypipes: yeah, the Spec object would signal if we support new-style of claiming | |
| 16:18:24 | bauzas | mriedem: the scheduler would POST allocations | |
| 16:18:30 | jaypipes | bauzas: yeah, the presence of allocation objects in the RequestSpec would be that signal. | |
| 16:18:30 | bauzas | mriedem: and get the UUIDs | |