| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-03-06 | |||
| 19:22:14 | mriedem | um | |
| 19:22:30 | mriedem | i have very little working knowledge of how the ec2 id mapping stuff works | |
| 19:26:27 | openstackgerrit | Matt Riedemann proposed openstack/nova stable/queens: Check for multiattach before removing connections https://review.openstack.org/550221 | |
| 19:26:27 | openstackgerrit | Matt Riedemann proposed openstack/nova stable/queens: Pass user context to virt driver when detaching volume https://review.openstack.org/550220 | |
| 19:28:11 | cfriesen | mriedem: if we don't keep the metadata instance_id in sync with the nova instance ID, what's the point of being able to query the instance_id in the metadata? | |
| 19:30:29 | openstackgerrit | Merged openstack/nova master: Updated from global requirements https://review.openstack.org/550057 | |
| 19:34:12 | mriedem | cfriesen: if an instance gets sent to cell0 why would we care about it's value in the metadata service? or is there a counter being used based on the number of instances in the nova (cell1) database? | |
| 19:35:14 | mriedem | my understanding with instance_id_mappings is that it maps the ec2 instance id to the nova instance uuid, right? | |
| 19:35:20 | mriedem | so they don't need to be the same | |
| 19:40:23 | openstackgerrit | Merged openstack/nova stable/queens: Check quota before creating volume snapshots https://review.openstack.org/546158 | |
| 19:43:53 | cfriesen | mriedem: it looks like the id returned from the metadata is "larger" than the id used by nova. Is there any way for an admin user to map the instance id returned by metadata to a nova instance id? | |
| 19:44:37 | mriedem | i don't know what any of those words mean | |
| 19:45:23 | mriedem | i fail to see why the end user needs to understand the mapping | |
| 19:45:44 | mriedem | if they get an ec2 instance-id, then they should be able to pull the instance information via the id which nova should fetch using the mapping | |
| 19:46:06 | mriedem | if that doesn't work because we aren't properly looking up cell mappings or something, then i could see that being an issue | |
| 19:46:24 | mriedem | but like i said before, i don't really know much about how this ec2 instance id stuff works, or is used | |
| 19:46:56 | mriedem | my guess would be that in a multi-cell env, this doesn't work | |
| 19:47:05 | mriedem | if the metadata service is global | |
| 19:47:14 | cfriesen | mriedem: as far as I know we removed the ec2 api from nova, so right now it seems like the ec2 instance ID isn't useful other than as some sort of unique identifier. | |
| 19:47:32 | mriedem | yeah it's likely not | |
| 19:47:49 | mriedem | someone was going through and removing all of that ec2 mapping stuff at one point but it's not trivial and abandonedi t | |
| 19:48:08 | mriedem | the metadata api was likely forgotten/ignored because...well, that's what tends to happen to the metadata api | |
| 19:48:14 | cfriesen | heh | |
| 19:48:42 | cfriesen | would it make sense to export the instance uuid via the metadata API? as a way for a guest to query who it is? | |
| 19:49:16 | mriedem | that already goes into the openstack metadata api response | |
| 19:49:19 | mriedem | it's the uuid field | |
| 19:50:37 | cfriesen | I don't see it: http://paste.openstack.org/show/693438/ | |
| 19:51:19 | mriedem | that's the ec2 response | |
| 19:51:22 | mriedem | not the openstack route response | |
| 19:51:53 | mriedem | if you're not using the ec2 compute api, don't use the ec2 metadata api either | |
| 19:53:46 | cfriesen | so that's likely my issue. how do I get the openstack version? my google-fu is failing me | |
| 19:56:02 | mriedem | curl http://169.254.169.254/openstack/latest/meta_data.json | |
| 19:56:03 | mriedem | i think | |
| 19:57:41 | cfriesen | I think you're right. interestingly, "curl http://169.254.169.254/" doesn't show "openstack" as an option, but "curl http://169.254.169.254/openstack" gives a number of version dates. | |
| 19:57:46 | cfriesen | thanks, that'll be useful. | |
| 20:00:02 | mriedem | cfriesen: https://docs.openstack.org/nova/latest/admin/networking-nova.html#metadata-service | |
| 20:00:19 | mriedem | not super discoverable as that's buried in (1) admin guide and (2) a section about nova-network | |
| 20:00:40 | mriedem | that should likely be moved closer to the config drive user docs we have | |
| 20:00:55 | cfriesen | much appreciated | |
| 20:01:30 | mriedem | which is https://docs.openstack.org/nova/latest/user/config-drive.html | |
| 20:01:44 | mriedem | https://docs.openstack.org/nova/latest/user/ is also in need of some love | |
| 20:01:49 | mriedem | since it's all admin guide stuff right now | |
| 20:02:53 | cfriesen | I'm 2wks away from a product release and busy fixing internal bugs, but I can put it on my list to look at the docs when I come up for air. | |
| 20:04:14 | mriedem | i found the breadcrumbs, main home page links to config drive https://docs.openstack.org/nova/latest/ | |
| 20:04:18 | mriedem | https://docs.openstack.org/nova/latest/user/config-drive.html | |
| 20:04:24 | mriedem | which links to metadata service docs in the first paragraph | |
| 20:04:28 | mriedem | https://docs.openstack.org/nova/latest/admin/networking-nova.html#metadata-service | |
| 20:04:38 | mriedem | anyway, i'll throw the config drive and metadata service links into the main user index page | |
| 20:15:56 | openstackgerrit | git-harry proposed openstack/nova master: Fix version cap when no nova-compute started https://review.openstack.org/549737 | |
| 20:16:38 | mriedem | stephenfin: i know you love configs, | |
| 20:16:51 | mriedem | we have metadata service config options spread throughout the various nova conf modules (api, network, service) | |
| 20:17:02 | mriedem | seems we should consolidate those under a single [metadata] group | |
| 20:24:10 | openstackgerrit | Russell Tweed proposed openstack/nova master: Fix invalid UUIDs in remaining tests https://review.openstack.org/550238 | |
| 20:31:02 | openstackgerrit | Jay Pipes proposed openstack/nova-specs master: Propose standardized provider descriptor file https://review.openstack.org/550244 | |
| 20:36:41 | dansmith | mriedem: https://review.openstack.org/#/c/549737 | |
| 20:37:04 | mriedem | word to your mother | |
| 20:41:26 | itlinux | hello guys.. is there an options to have the vms reboot once the hypervisors reboots? | |
| 20:44:15 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Re-work the metadata service docs https://review.openstack.org/550250 | |
| 20:44:16 | mriedem | cfriesen: there you go ^ should be 1000x better | |
| 20:45:23 | mriedem | itlinux: hypervisor or nova-compute? | |
| 20:45:32 | itlinux | nova compute | |
| 20:46:16 | itlinux | so when my nova-compute node reboots.. which is my hypervisor in this case i want to have vms restart | |
| 20:47:24 | mriedem | then i think you're looking for the resume_guests_state_on_host_boot config option | |
| 20:48:31 | itlinux | ok thanks | |
| 20:49:13 | itlinux | I have set this resume_guests_state_on_host_boot to true but did not work :) | |
| 20:49:50 | mriedem | "did not work" would need some expanding | |
| 20:50:07 | mriedem | which compute driver are you using? | |
| 20:50:20 | itlinux | well I rebooted the hypervisor and the vm virsh list still down | |
| 20:50:24 | dansmith | itlinux: if your init system starts libvirt shutdown before nova is down, then nova will record that the guest powered off and won't start it back up | |
| 20:50:39 | dansmith | and there's not much we can do about that | |
| 20:50:42 | itlinux | I am on centos | |
| 20:50:44 | itlinux | 7 | |
| 20:51:09 | mriedem | yeah the code that checks that option says if the nova db thinks the instance should be running, but the hypervisor says it isn't, and the option is true, nova reboots the guest | |
| 20:51:12 | itlinux | so does this https://ask.openstack.org/en/question/66880/start-vms-after-reboot-compute-node/ show the right info? | |
| 20:51:44 | mriedem | if libvirt stopped and stopped the guests with it, nova would detect that and mark them as stopped in the nova db too, so on startup we won't try to reboot those guests | |
| 20:52:17 | itlinux | ok so assuming the doc I posted is correct.. | |
| 20:53:27 | mriedem | that doc is similar to what i remember, depends on how libvirt is configured to handle the guests on restart | |
| 20:54:01 | itlinux | thanks | |
| 20:54:01 | itlinux | this is standard ooo implementation which option should I check? mriedem: | |
| 20:54:21 | dansmith | that's from 2015 and mentions chkconfig, so it's likely that it's not up-to-date with what happens on systemd in parallel | |
| 20:54:58 | dansmith | and also, ask.o.o != "docs" | |
| 20:55:09 | dansmith | some people answer questions with pretty wrong suggestions | |
| 20:56:02 | itlinux | ok | |
| 21:00:00 | dansmith | mriedem: archiving a lot more data now :) http://logs.openstack.org/71/550171/4/check/nova-next/4986796/job-output.txt.gz#_2018-03-06_20_44_12_527465 | |
| 21:00:19 | dansmith | dunno what that failure is though, given it _just_ ran | |
| 21:00:24 | mriedem | dansmith: easy fix for something i forgot about during the ptg https://review.openstack.org/#/c/548572/ - needs to go to queens | |
| 21:00:56 | dansmith | mriedem: purge purged a bunch of stuff | |
| 21:01:16 | mriedem | i don't know what that failure is either | |
| 21:02:20 | mriedem | hmm, something about instance_mappings | |
| 21:02:25 | mriedem | which is relatively new... | |
| 21:02:28 | mriedem | tssurya added | |
| 21:02:59 | dansmith | ah it must be hitting api db for something | |
| 21:03:31 | tssurya | dansmith, mriedem : removing request specs and instance mappings | |
| 21:03:35 | tssurya | during archival ? | |
| 21:03:36 | mriedem | yeah http://logs.openstack.org/71/550171/4/check/nova-next/4986796/logs/etc/nova/nova_cell1.conf.txt.gz | |
| 21:03:43 | dansmith | ah | |
| 21:03:46 | mriedem | nova_cell1.conf doesn't have [api_database] configured | |
| 21:03:55 | dansmith | right | |
| 21:04:05 | dansmith | well, if were going to do the --all-cells thing I guess it doesn't matter | |
| 21:04:12 | dansmith | s/were/we're/ | |