| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-04-03 | |||
| 19:19:30 | mriedem | https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/servers.py#L1112 | |
| 19:20:08 | mriedem | https://github.com/openstack/nova/blob/master/nova/image/glance.py#L58 | |
| 19:20:13 | mordred | RESP: [202] Content-Type: text/html; charset=UTF-8 Content-Length: 0 Location: http://172.21.1.10:9292/images/f5d5b63b-e710-4d59-aa12-a9bd42f6652a Openstack-Api-Version: compute 2.1 X-Openstack-Nova-Api-Version: 2.1 Vary: OpenStack-API-Version, X-OpenStack-Nova-API-Version X-Compute-Request-Id: req-4b6fb5ed-3055-4d84-a16f-4057685ce737 Date: Sun, 02 Apr 2017 13:26:20 GMT | |
| 19:20:18 | mordred | that's the response I got | |
| 19:20:52 | mordred | but the Location _should_ have been https://image-ca-ymq-1.vexxhost.net/v2/images/f5d5b63b-e710-4d59-aa12-a9bd42f6652a | |
| 19:21:06 | mriedem | yeah i was going to say, it's wrong b/c it's missing v1 or v2 right? | |
| 19:21:14 | mordred | well - and also the host is wrong | |
| 19:21:20 | mriedem | the host comes from the config in nova | |
| 19:21:24 | mriedem | for glance api servers | |
| 19:21:26 | mordred | 172.21.1.10:9292 is unreachable by me as a user | |
| 19:21:41 | mordred | so it seems it's returning the thing that is the internal url | |
| 19:21:41 | sdague | so, the host is going to because they have private glance servers | |
| 19:21:44 | mordred | yah | |
| 19:21:52 | mriedem | yeah comes from config https://github.com/openstack/nova/blob/master/nova/image/glance.py#L107 | |
| 19:22:03 | mriedem | we'd have to get the host from the service catalog right? | |
| 19:22:05 | sdague | yeh, for historical reasons that's just a randomly picked one of their api_services | |
| 19:22:06 | mriedem | for publicUrl | |
| 19:22:19 | sdague | mriedem: yeh, it's more complicated than that, but yes | |
| 19:22:24 | mordred | kk. so this is still just part of the whole "use the catalog for glance stuff" effort | |
| 19:22:30 | sdague | because the glance stuff doesn't use the catalog anywhere | |
| 19:22:33 | sdague | mordred: yes | |
| 19:22:33 | mordred | yah | |
| 19:22:43 | mordred | cool - ok - so no new issue to file | |
| 19:22:44 | mriedem | is that an effort? | |
| 19:22:51 | mriedem | no one is working on this | |
| 19:23:34 | mordred | maybe effort is the wrong word "aspirational future state that people would love to be in but nobody is currently driving" | |
| 19:23:36 | mriedem | mordred: you should report a bug regardless | |
| 19:23:39 | mordred | kk | |
| 19:23:41 | mordred | will do | |
| 19:23:51 | mordred | also - I'm just stealing novaclient's workaround for now | |
| 19:24:02 | mriedem | i'm surprised we actually returned a location header | |
| 19:24:10 | mordred | which is to just pop the uuid off the end of the url and return _that_ | |
| 19:24:13 | sdague | mriedem: that's been there for a long time | |
| 19:24:30 | mriedem | sdague: there's lots of things that have been around for lots of years that surprise me :) | |
| 19:24:35 | sdague | :) | |
| 19:25:01 | sdague | returning location is actually a pretty good pattern, it's just that it depends on too much config being correct | |
| 19:26:12 | sdague | I'm trying to figure out if vexxhost's config is going to hurt something else in terms of migration | |
| 19:26:13 | mriedem | sdague: so is the basic idea, long-term we want to drop CONF.glance.api_servers and just have nova lookup the image service url in the catalog? | |
| 19:26:21 | sdague | mriedem: yes | |
| 19:26:29 | mriedem | same for neutron and cinder | |
| 19:26:32 | mriedem | since those are config driven | |
| 19:26:34 | mordred | yah | |
| 19:26:57 | mriedem | oh right and raj_singh had a patch to use ksa with glance in nova... | |
| 19:27:05 | sdague | right, so we probably are going to have to have a slightly more complicated case for glance where we consider an internal and a public path | |
| 19:27:14 | mriedem | https://review.openstack.org/#/c/412634/ | |
| 19:27:32 | sdague | because glance is one of those services where your would tend to build a really high bw internal path to the api service | |
| 19:27:43 | mordred | mriedem: I've also got this one: https://review.openstack.org/#/c/438512/ | |
| 19:27:48 | mriedem | we make that configurable for placement | |
| 19:27:53 | mriedem | which url to use i mean | |
| 19:27:58 | mordred | mriedem: which needs a little more cleanip before I bother you fine people with it much more | |
| 19:28:15 | sdague | mriedem: well... except we reflect urls straight to the user | |
| 19:28:22 | sdague | so we're going to need 2 config options | |
| 19:28:27 | mriedem | sdague: right i know | |
| 19:28:46 | mriedem | internal defaults to internalUrl or adminUrl or whatever, and public defaults to publicUrl | |
| 19:28:56 | mriedem | i was thinking about this https://github.com/openstack/nova/blob/master/nova/conf/placement.py#L31 | |
| 19:29:02 | sdague | mriedem: yeh | |
| 19:29:13 | mordred | yah - I'd argue to not have that | |
| 19:30:09 | mordred | internal and public are known interfaces. nova should reflect urls based on public to API consumers and should use internal to talk to other services - we shouldn't make operators tell nova to do that- if they don't want an internal url, they should just register the same url twice with keystone | |
| 19:30:10 | sdague | mordred: well, we tried to get away with be prescriptive with placement | |
| 19:30:12 | mordred | but I'm unreasonable | |
| 19:30:19 | sdague | and people got mad | |
| 19:30:23 | mordred | of course they did | |
| 19:31:02 | sdague | mordred: so, lots of deployments only use public | |
| 19:31:09 | sdague | or at least some do | |
| 19:31:17 | sdague | and just route correctly | |
| 19:31:24 | mordred | yah. that would be more smarter | |
| 19:31:40 | sdague | is there anyone else with a newton cloud? | |
| 19:32:20 | mordred | dunno - I only know vexxhost is because I was chatting with mnaser about a config-drive issue over the weekend | |
| 19:32:48 | mordred | but given the way novaclient works here, it's highly unlikely many real-world folks are broken by this issue, fwiw | |
| 19:34:06 | mordred | I mean - honestly rather than fixing it - just returning a json dict in the body with the image_id in it would be a win - those urls aren't really used much in the rest of the overall api flow | |
| 19:34:24 | mordred | and the first thing you're going to do with this as a user is make a call to glance to get the image dict by id | |
| 19:34:43 | mordred | (since you have to poll that for status to know when it's done) | |
| 19:35:00 | mriedem | mordred: yeah that's why i said i was surprised, | |
| 19:35:10 | mriedem | because we just return ids for things like this in response bodies | |
| 19:35:15 | mordred | so it likely _could_ be fixed with a microversion easier than actually fixing the internal/public glance url thing | |
| 19:35:18 | mriedem | but, changing the response will be a microversion | |
| 19:35:22 | mordred | mriedem: yah. I was very surprised myself | |
| 19:35:46 | mordred | mriedem: as you might can tell from my comment: https://review.openstack.org/#/c/452566/2/shade/openstackcloud.py | |
| 19:36:25 | mriedem | ha | |
| 19:36:32 | mriedem | so dramatic | |
| 19:36:54 | mordred | well - it was a sunday and I managed to break a server by making the api call against nova | |
| 19:37:03 | mordred | because it _ALSO_ apparently turns the server off to do the snapshot | |
| 19:37:15 | mordred | so I might have been in a bad mood at the time | |
| 19:37:29 | mriedem | live snapshot is a thing if libvirt is new enough and you've configured nova-compute to attempt it | |
| 19:37:40 | mriedem | we disabled live snapshot way back when b/c it resulted in 25% failure rate in the gate | |
| 19:37:59 | mriedem | you as the api user have no idea if it's live or cold though | |
| 19:38:04 | mriedem | since it's config drive on the compute | |
| 19:38:08 | mriedem | *driven | |
| 19:38:40 | mordred | \o/ | |
| 19:38:52 | mriedem | were you surprised that it was a cold snapshot? i see we don't mention that in the api ref | |
| 19:39:30 | mordred | well - I shouldn't have been - I know we don't use snapshots for any purpose in infra because it used to make the servers unresponsive for potentially hours - but I think I had just assumed that was some Xen/Rackspace thing | |
| 19:39:44 | mordred | but yes - I was totally unprepared for it to be a COMPLETELY unsafe thing to run | |
| 19:40:08 | mordred | that left me with a VM in a down state for an unknowable period of time | |
| 19:40:28 | mordred | and with no way that I could find for me to say "oh, crap, dude, nevermind - I need the VM back please" | |
| 19:40:58 | mriedem | build a confirm prompt into shade :) | |
| 19:41:26 | mriedem | we could note this in the docs though, that by default it's a cold snapshot so you should expect the guest to be offline during the snapshot operation | |
| 19:41:36 | mriedem | i'm not really sure if that's true for the other virt drivers, but it is for libvirt | |
| 19:42:03 | mriedem | sdague: didn't you have a patch to undo disable_libvirt_livesnapshot? | |
| 19:42:06 | mriedem | or change it to False | |
| 19:42:10 | mriedem | maybe it was sfinucan | |