| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-02-03 | |||
| 19:22:34 | mriedem | let me see if i can find the thread | |
| 19:22:56 | johnthetubaguy | mriedem: files will get lost, it only appears in the initial config drive, we don't store them | |
| 19:23:09 | mriedem | johnthetubaguy: yup i know | |
| 19:23:09 | cfriesen | mriedem: right. so currently we don't allow specifying files on an evacuate, but they are preserved | |
| 19:23:17 | mriedem | it was one of the reasons for killing file injection | |
| 19:23:32 | mriedem | cfriesen: http://lists.openstack.org/pipermail/openstack-dev/2016-November/107195.html | |
| 19:23:39 | cfriesen | mriedem: preserved in the config drive, right | |
| 19:24:04 | johnthetubaguy | cfriesen: well, depends if you are using shared storage I guess | |
| 19:24:05 | cfriesen | mriedem: yes | |
| 19:24:37 | cfriesen | mridem: so if we're still going to allow --user-data on boot, I think it'd make sense to allow it on rebuild | |
| 19:24:38 | figleaf | johnthetubaguy: the _init_compute_node is one place, yes | |
| 19:24:59 | johnthetubaguy | figleaf: because tracked instances is empty to start with, so everything is treated as a new instance? | |
| 19:25:03 | mriedem | cfriesen: yeah i think that's fine | |
| 19:25:10 | figleaf | johnthetubaguy: then self._update_usage_from_instances keeps them in sync | |
| 19:25:14 | melwitt | cfriesen: I'm still stuck on the part where you say userdata gets wiped out. it didn't use to on rebuild, it should just stay on the config drive? | |
| 19:25:42 | melwitt | this came up before at my last company and we tested it and userdata stayed intact across a rebuild | |
| 19:25:50 | figleaf | johnthetubaguy: yeah, that happens in _init_compute_node | |
| 19:25:52 | mriedem | 14:20:38 <johnthetubaguy> #action deprecate localfs file injection in ocata, remove in pike | |
| 19:25:52 | cfriesen | melwitt: currently injected files get lost on evacuate | |
| 19:25:53 | mriedem | damn! | |
| 19:26:07 | melwitt | hmm | |
| 19:26:15 | cfriesen | melwitt: currently userdata stays intact over a rebuild. my usecase is for people that want to rebuild to a different image with different userdata | |
| 19:26:40 | melwitt | cfriesen: yeah. okay, that makes sense. I thought earlier you said something about userdata getting wiped out during a rebuild | |
| 19:26:40 | cdent | figleaf, johnthetubaguy: tracked_instances is emptied every periodic job and _init_compute_node is called every periodic job | |
| 19:26:50 | superdan | cfriesen: isn't that called "boot" ? | |
| 19:27:03 | figleaf | cdent: oh geez - really? | |
| 19:27:10 | cdent | figleaf: you read this yet: http://lists.openstack.org/pipermail/openstack-dev/2017-January/110953.html | |
| 19:27:24 | cfriesen | superdan: you would think | |
| 19:27:30 | EmilienM | superdan: do you think I need to file a bug on tripleo side for the ironic thing? (wrt the patch in tripleo-common owalsh did) | |
| 19:27:42 | cfriesen | superdan: as I recall it ended up being related to heat updates | |
| 19:27:49 | figleaf | cdent: yes, but I don't have it committed to memory :) | |
| 19:28:03 | cdent | figleaf: oh, but you should | |
| 19:28:10 | figleaf | cdent: Ok, I see the tracked_instances.clear() line | |
| 19:28:13 | sdague | EmilienM: any behavior in the nova osapi_compute_listen field is because of the way oslo.service works - https://github.com/openstack/oslo.service/blob/7fa34bf8e7a37a6d9355aaf55aa85b1931567cd6/oslo_service/wsgi.py#L127-L151 | |
| 19:28:33 | cdent | figleaf: it's all very bewildering and amazing | |
| 19:28:47 | superdan | EmilienM: no | |
| 19:28:53 | EmilienM | sdague: ok I see, thanks | |
| 19:30:05 | johnthetubaguy | cdent: I guess thats where all those fetch inventory calls come from, from the attempted update | |
| 19:30:41 | johnthetubaguy | cdent: hmm, I meant allocations | |
| 19:31:15 | cdent | I'm gonna escape for the evening unless there's something needing me? | |
| 19:31:36 | johnthetubaguy | cdent: I need to do the same really | |
| 19:31:39 | johnthetubaguy | I have the oven on | |
| 19:31:51 | figleaf | Have a great weekend, cdent and johnthetubaguy | |
| 19:33:04 | cdent | johnthetubaguy: yeah, dinner calls | |
| 19:35:43 | big_macsz | bon appetit | |
| 19:35:45 | cfriesen | mriedem: did anyone actually start on a spec for deprecating file injection? | |
| 19:36:04 | mriedem | cfriesen: no it was on my todo list at some point and then i forgot about it | |
| 19:36:10 | mriedem | i blame the holidays | |
| 19:36:23 | cfriesen | heh...so are we now looking at deprecating in pike? | |
| 19:36:31 | cfriesen | removing in q? | |
| 19:36:39 | mriedem | yeah | |
| 19:36:47 | mriedem | johnthetubaguy: it was on me | |
| 19:37:26 | cfriesen | heh...okay, I can write that one up if you like. | |
| 19:37:41 | openstackgerrit | Emilien Macchi proposed openstack/nova master: DNM - test tripleo without nova api in WSGI/apache https://review.openstack.org/429008 | |
| 19:38:23 | johnthetubaguy | figleaf: that last question I had was about the inventory, it seems odd to need to update it when updating the instances, surely thats been done already in the RT? | |
| 19:38:28 | EmilienM | mriedem: now rc1 is cut, can you look https://review.openstack.org/#/c/428424/ please? | |
| 19:42:12 | figleaf | johnthetubaguy: the only way inventory is updated there is if it doesn't match the number of allocations | |
| 19:42:47 | figleaf | johnthetubaguy: so it removes everything and rebuilds everything to the "correct" way (old and new style) | |
| 19:42:57 | johnthetubaguy | figleaf: which is for new instances too right? | |
| 19:43:16 | figleaf | johnthetubaguy: next pass through, it should find that len(cur_allocs) == len(inv_data), so it won't do that again | |
| 19:43:29 | johnthetubaguy | figleaf: but its not needed, if you look here: https://github.com/openstack/nova/blob/cab5dbfac7513d2cef1073787e49f6d063ec8fa7/nova/compute/resource_tracker.py#L575 | |
| 19:43:39 | figleaf | johnthetubaguy: well, what we might think are "new instances" is different | |
| 19:43:47 | johnthetubaguy | figleaf: we always update the inventory first | |
| 19:43:56 | figleaf | johnthetubaguy: as cdent mentioned, the tracker is cleared on every pass, so they are always "new" | |
| 19:44:15 | johnthetubaguy | yes, but thats a red herring here | |
| 19:44:29 | johnthetubaguy | I mean if you boot an instance, every time we would now re-write the inventory | |
| 19:44:37 | johnthetubaguy | (well attempt an update) | |
| 19:46:04 | figleaf | johnthetubaguy: what we need is to map this all out visually. It's all too confusing otherwise | |
| 19:46:43 | johnthetubaguy | figleaf: that probably would help | |
| 19:46:45 | figleaf | johnthetubaguy: I still trip myself up following the ironic vs. non-ironic paths | |
| 19:47:25 | johnthetubaguy | figleaf: so generally, the code updates the inventory, then updates the allocations | |
| 19:47:41 | johnthetubaguy | figleaf: I think this new code should do the same thing, rather than trying to re-update the inventory | |
| 19:47:54 | dtp | reading the release notes. do cells v1 deployments need to go through the cells v2 setup for Ocata? | |
| 19:48:17 | superdan | dtp: yes | |
| 19:48:25 | superdan | I thought it said that explicitly | |
| 19:49:01 | dtp | it does, but from discussions we had previously, i'm under the impression folks can still run v1 cells w/ the CELLS_ENABLED flag or whatever it was | |
| 19:49:02 | superdan | we've been through so many cells related renos I've lost track | |
| 19:49:12 | superdan | they can | |
| 19:49:17 | superdan | but they still have to do the cellsv2 stuff | |
| 19:49:40 | dtp | ok, including creating a cell 1? or just the cell 0? | |
| 19:49:51 | mriedem | both | |
| 19:49:54 | mriedem | dtp: also https://review.openstack.org/#/c/427981/ | |
| 19:51:02 | figleaf | johnthetubaguy: understood, but I'm not seeing where the problem is. I can only see that happening when the allocations don't match inventory for ironic | |
| 19:51:41 | johnthetubaguy | figleaf: no, its a bit different | |
| 19:52:22 | johnthetubaguy | ... trying to think of how to describe it | |
| 19:52:36 | johnthetubaguy | we have the inventory update, so it includes the new resource calss | |
| 19:52:39 | johnthetubaguy | class | |
| 19:52:40 | figleaf | johnthetubaguy: hey! how about writing a functional test! :) | |
| 19:52:46 | johnthetubaguy | we now call the update | |
| 19:52:51 | figleaf | (which is what we should have done from the outset) | |
| 19:52:53 | johnthetubaguy | figleaf: if it were not 7.50pm, sure | |
| 19:53:25 | johnthetubaguy | basically, we start with updating the inventory | |
| 19:53:37 | johnthetubaguy | then we have to check if the allocations match what should be in the inventory | |
| 19:53:49 | johnthetubaguy | thats not the case if its new, or we are hitting the upgrade bump | |
| 19:54:02 | johnthetubaguy | in that case we need to fix up the allocations, thats all good | |
| 19:54:12 | johnthetubaguy | but there is no need to update the inventory, its already been done | |
| 19:55:05 | figleaf | johnthetubaguy: so you're saying that they inventory always has to be correct? IOW, it's always the allocations that are out of whack? | |
| 19:55:30 | johnthetubaguy | I am saying the inventory is always updated before we update the allocations | |
| 19:58:16 | figleaf | johnthetubaguy: that could well be the case | |
| 19:58:36 | figleaf | johnthetubaguy: I think leakypipes must have trying the belts and braces approach | |