| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-08-10 | |||
| 20:31:32 | mriedem | sdague: per gmann's doc change, i don't see where this stable api doc is even linked from http://docs-draft.openstack.org/26/489926/9/check/gate-nova-docs-ubuntu-xenial/24e8cc4//doc/build/html/reference/stable-api.html | |
| 20:32:31 | mriedem | like https://developer.openstack.org/api-guide/compute/ | |
| 20:32:46 | mriedem | or http://docs-draft.openstack.org/26/489926/9/check/gate-nova-docs-ubuntu-xenial/24e8cc4//doc/build/html/contributor/index.html#the-nova-api | |
| 20:33:05 | sdague | reference/index | |
| 20:33:20 | sdague | http://docs-draft.openstack.org/26/489926/9/check/gate-nova-docs-ubuntu-xenial/24e8cc4//doc/build/html/reference/index.html | |
| 20:34:00 | mriedem | oh | |
| 20:34:03 | mriedem | sheesh | |
| 20:34:04 | sdague | from the reorged page it would be index -> Technical Reference Deep Dives | |
| 20:34:18 | sdague | -> Nova Stable REST API | |
| 20:34:39 | mriedem | yeah... | |
| 20:34:43 | mriedem | that was a hunt | |
| 20:35:28 | sdague | yeh, we're going to need a slice of time to figure out what the right information architecture is for all this stuff is at PTG | |
| 20:35:43 | sdague | this first stage grouping was just that, a first stage grouping, without creating *more* 404s | |
| 20:37:28 | sdague | so, the contributor and reference consolidations were first, and I made sub pages for them. But the admin subpage was already claimed as the main url for the admin guide, so I inlined the equivalent user / admin chunks into the top index page | |
| 20:37:49 | sdague | it might be good to unwind all of that for the contributor / reference pages | |
| 20:38:09 | sdague | so you get there without the intermediate hop | |
| 20:39:11 | sdague | I also think we might be able to use refs in the toctree and get something more sane out of all of that | |
| 20:41:33 | openstackgerrit | Ed Leafe proposed openstack/nova master: Handle addition of new nodes/instances in ironic flavor migration https://review.openstack.org/487954 | |
| 20:41:57 | efried | mtreinish With your fix I did indeed hit https://bugs.launchpad.net/glance/+bug/1703856 | |
| 20:41:58 | openstack | Launchpad bug 1703856 in Glance "502 Bad gateway error on image-create" [High,Confirmed] | |
| 20:45:46 | efried | mtreinish ...and so did the gate. | |
| 20:46:59 | edleafe | mriedem: melwitt: ^^ addressed your comments (and your terrible taste in indentation) | |
| 20:47:16 | melwitt | hah | |
| 20:48:35 | melwitt | +2, looks cool to me | |
| 20:49:41 | melwitt | thanks for changing those test names, makes it a lot clearer to someone not in-the-know | |
| 20:51:39 | edleafe | melwitt: yeah, well, they went through a bunch of back-and-forth as people had different opinions on how the migration should work. | |
| 20:57:47 | openstackgerrit | Merged openstack/nova master: update policy UT fixtures https://review.openstack.org/398610 | |
| 20:58:28 | openstackgerrit | Merged openstack/nova master: Require Placement 1.10 in nova-status upgrade check https://review.openstack.org/492234 | |
| 20:59:09 | openstackgerrit | Merged openstack/nova master: Add For Operators section to front page https://review.openstack.org/491815 | |
| 20:59:51 | mikal | mriedem: replying now | |
| 20:59:53 | openstackgerrit | Merged openstack/nova master: rework index intro to describe nova https://review.openstack.org/491834 | |
| 21:00:37 | openstackgerrit | Merged openstack/nova master: Bulk import all config reference figures https://review.openstack.org/492105 | |
| 21:01:20 | mriedem | if i work from home, and your dog next to my house barks non-stop for 30+ minutes, | |
| 21:01:23 | mriedem | i should be able to do something bad | |
| 21:02:06 | openstackgerrit | Merged openstack/nova master: nova-manage: Deprecate '--version' parameters https://review.openstack.org/453808 | |
| 21:04:02 | openstackgerrit | Merged openstack/nova master: doc: Import configuration reference https://review.openstack.org/491853 | |
| 21:04:45 | openstackgerrit | Merged openstack/nova master: Structure cli page https://review.openstack.org/492111 | |
| 21:12:39 | openstackgerrit | Matt Riedemann proposed openstack/nova master: doc: address review comments in stable-api guide updates https://review.openstack.org/492690 | |
| 21:12:40 | mtreinish | efried: hmm, the patch would have fixed the 502 errors. It likely means something is misconfigured elsewhere in the path | |
| 21:12:45 | mtreinish | let me take a look at the gate logs | |
| 21:13:18 | bauzas | mriedem: le woof says hello to your neighbor :p | |
| 21:13:33 | mriedem | god | |
| 21:13:44 | mriedem | i hope le woof isn't as dumb as the neighbor dog | |
| 21:13:54 | openstackgerrit | Robert Ellis proposed openstack/nova master: Clarifying node_uuid usage in ironic driver. https://review.openstack.org/485803 | |
| 21:14:56 | bauzas | eurasier FTW | |
| 21:15:39 | bauzas | FWIW https://review.openstack.org/#/c/487954 looks good to me, but is the Ironic job working fine ? | |
| 21:16:21 | mriedem | this is just an uncut newfoundland | |
| 21:17:24 | mriedem | the last ironic job run failed http://logs.openstack.org/54/487954/13/check/gate-tempest-dsvm-ironic-ipa-wholedisk-bios-agent_ipmitool-tinyipa-ubuntu-xenial-nv/fa780de/console.html | |
| 21:17:28 | mriedem | looks like due to timeout | |
| 21:17:54 | mriedem | PS12 was ok http://logs.openstack.org/54/487954/12/check/gate-tempest-dsvm-ironic-ipa-wholedisk-bios-agent_ipmitool-tinyipa-ubuntu-xenial-nv/041c03a/ | |
| 21:18:04 | mriedem | PS14 was citycloud-lon1 which is a known slow node issue right now | |
| 21:18:33 | bauzas | how many times is running the refresh cache? | |
| 21:18:41 | bauzas | I mean the period | |
| 21:21:40 | mriedem | bauzas: well, at least every 60 seconds by default because it's called from get_available_nodes which is called from the update_available_resources periodic task | |
| 21:23:10 | bauzas | I'm trying to understand if concurrent runs would be some problems | |
| 21:23:16 | bauzas | looks not | |
| 21:23:49 | bauzas | that said, a question | |
| 21:24:05 | bauzas | if we spawn, do we have the same cache ? | |
| 21:24:08 | bauzas | mriedem: ^ | |
| 21:24:49 | mriedem | i don't understand the question | |
| 21:25:40 | bauzas | we would run multiple greenlets, right? | |
| 21:25:54 | bauzas | so my question is about the node cache | |
| 21:26:06 | bauzas | do we share the same node cache object between greenlets ? | |
| 21:26:55 | mriedem | oh eventlet spawn | |
| 21:27:00 | mriedem | not driver.spawn | |
| 21:28:21 | bauzas | yup eventlet.spawn_n even | |
| 21:28:59 | bauzas | maybe it's a stupid question, but I'm not remembering if coroutines accept to just share the same objects | |
| 21:29:59 | mriedem | _pike_flavor_migration is passed to the spawn and updates self._migrated_instance_uuids and yes i'd assume that's all pointing back to self | |
| 21:30:01 | mriedem | as the same object | |
| 21:30:10 | mriedem | otherwise that would be crazy | |
| 21:32:03 | mriedem | http://logs.openstack.org/54/487954/12/check/gate-tempest-dsvm-ironic-ipa-wholedisk-bios-agent_ipmitool-tinyipa-ubuntu-xenial-nv/041c03a/logs/screen-n-cpu.txt.gz#_Aug_09_19_31_21_252127 | |
| 21:32:03 | mriedem | you see things getting hit in the logs | |
| 21:32:11 | mriedem | because the ironic jobs don't yet set resource_class on the nodes | |
| 21:32:37 | bauzas | mriedem: I should explain more my concern | |
| 21:32:50 | bauzas | mriedem: say we have pike flavor migration run that takes more than 60 secs | |
| 21:33:03 | bauzas | then, we would have 2 concurrent migrations | |
| 21:33:13 | bauzas | that looks okay to me because we check the cache | |
| 21:33:53 | bauzas | but the question I wonder is whether all the greenlets share the same cache, so when the first migration updates the cache, the latter gets the updates | |
| 21:34:06 | bauzas | maybe it's pointless, and I'm just silly | |
| 21:34:17 | bauzas | but I'm just thinking out loud | |
| 21:34:51 | mriedem | both greenlets should be working on the same self._migrated_instance_uuids | |
| 21:34:56 | mriedem | melwitt: edleafe: ^? | |
| 21:35:44 | bauzas | mriedem: looking at StackOverflow, looks like yup | |
| 21:35:47 | melwitt | yeah, I think the self._migrated_instance_uuids would be shared between them (if one was still running longer than 60 sec). so maybe we need to synchronize access to that set? | |
| 21:36:20 | mriedem | oh if only we could be using synchronized collections from java! | |
| 21:37:34 | mriedem | what's the worst that would happen here? | |
| 21:37:47 | mriedem | wouldn't we just double migrate the same instance.flavor.extra_spec? | |
| 21:37:52 | melwitt | that's what I was trying to think about. | |
| 21:38:03 | mriedem | continue | |
| 21:38:03 | mriedem | # has already been migrated | |
| 21:38:03 | mriedem | # The compute must have been restarted, and the instance.flavor | |
| 21:38:03 | mriedem | if resource_key in specs: | |
| 21:38:06 | bauzas | mriedem: melwitt: well, the more I think about the problem, the more I think it wouldn't be a prolem | |
| 21:38:06 | mriedem | ^ should save it | |
| 21:38:16 | bauzas | at least because it's for flavors | |
| 21:38:20 | melwitt | yeah | |
| 21:38:33 | bauzas | not sure operators have a lot of flavors needing more than 60 secs for a migration | |
| 21:39:17 | mriedem | well, unless you're hitting rpc timeouts on sending updates to conductor or something | |
| 21:39:26 | bauzas | and if so, well, not a problem given the current code which is not synchronised but failproof | |
| 21:39:39 | melwitt | it's a good point to think about though. I think mriedem is right that it would skip an already migrated one even if it got a stale view of the shared set | |