| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-03-06 | |||
| 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/ | |
| 21:04:43 | mriedem | so what would happen if we also passed --config-file /etc/nova/nova.conf which has [api_database] but also [database] pointed at cell0? i've always wondered how oslo.config handles specifying 2 config files that have conflicting options set | |
| 21:05:13 | mriedem | we could at least avoid the ugly traceback if we checked if CONF.api_database.connection is set | |
| 21:05:21 | mriedem | before trying to delete instance mappings and request specs | |
| 21:05:29 | dansmith | I'd have to look to see which order they need to be in, | |
| 21:05:42 | dansmith | but that's what I'd do for now if we weren't going to do the --all-cells thing | |
| 21:06:09 | dansmith | mriedem: yeah, because I think it actually did archive things and failed to print status, which is why the subsequent run found nothing | |
| 21:06:22 | tssurya | dansmith : doesn't Kevin have a patch for --all-cells ? | |
| 21:06:33 | mriedem | yeah i'll open a bug quick | |
| 21:06:38 | dansmith | tssurya: yep, that's what I'm saying | |
| 21:06:41 | mriedem | tssurya: he does but it needs work | |
| 21:07:23 | tssurya | dansmith, mriedem : oh okay, let me know if I can help | |
| 21:07:39 | tssurya | or if my extra stuff needs an extra check | |
| 21:07:57 | dansmith | tssurya: yeah I think mriedem is filing a bug against it right now | |
| 21:08:07 | dansmith | tssurya: just to catch that exception if we can't do the api bit and report it cleanly | |
| 21:08:47 | tssurya | dansmith : okay, nice | |
| 21:09:35 | openstackgerrit | Jay Pipes proposed openstack/nova-specs master: Propose standardized provider descriptor file https://review.openstack.org/550244 | |
| 21:09:37 | mriedem | tssurya: congratulations. you have advanced to the level of nova developer that not only fixes bugs, but introduces regressions from your bug fixes. | |
| 21:09:42 | mriedem | this is a joyous occasion | |
| 21:09:55 | jaypipes | amen | |
| 21:10:06 | mriedem | we should have colored belts | |
| 21:10:13 | tssurya | mriedem : :D | |
| 21:11:09 | tssurya | jaypipes : I will start working on the CLI as planned this week | |
| 21:11:16 | tssurya | I mean as promised8 | |
| 21:11:50 | tssurya | I was wondering if it needed a bp? | |