| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-03-21 | |||
| 13:31:08 | openstackgerrit | Matt Riedemann proposed openstack/nova-specs master: Re-propose cross-cell-resize spec for Train https://review.openstack.org/642807 | |
| 13:31:24 | mriedem | dansmith: i tried to wordsmith the personality files limitation in the re-proposed cross-cell resize spec ^ | |
| 13:32:41 | dansmith | okay I guess I'll have to diff it to see the changed part | |
| 13:35:46 | sean-k-mooney | mriedem: were we recreating the config dirve during a cross cell migration or something that would cause issue for personality files? | |
| 13:36:34 | mriedem | we are | |
| 13:37:21 | mriedem | we spawn https://review.openstack.org/#/c/635080/13/nova/compute/manager.py@5145 | |
| 13:38:21 | sean-k-mooney | ok then back to the conversation we had yesterday. if its oke to do it for cross cell resize it logically means we may be able to do the same in general. perhaps contoled by a config option to addes klindgren concers regarding ssh keys ans scp | |
| 13:38:30 | cdent | scanning across the big window and seeing "mriedem: we spawn" is chilling and worrying. Somewhere in the basement the alien mriedem's are laying eggs | |
| 13:38:57 | mriedem | muwahaha | |
| 13:39:08 | mriedem | don't worry, i only harvest their organs | |
| 13:40:46 | mriedem | sean-k-mooney: i'm not necessarily saying it's ok, but i don't have a good solution right now for dealing with those during a cross-cell resize | |
| 13:41:08 | mriedem | without glance or nova-compute running it's own http server... | |
| 13:41:13 | efried | mriedem: Didn't you (or somebody? gibi?) propose the docs for bug 1821015 ? | |
| 13:41:14 | openstack | bug 1821015 in OpenStack Compute (nova) "Attaching virtual GPU devices to guests in nova - libvirt reshaping" [Medium,Triaged] https://launchpad.net/bugs/1821015 | |
| 13:41:35 | mriedem | efried: no, i mentioned it to bauzas yesterday | |
| 13:41:48 | efried | okay, thought I saw a patch come through. | |
| 13:42:25 | mriedem | what i'd like to see in those docs is an example of the expected resource providers (2 of them) and inventory (VGPU on the child provider) in the osc command output, but since i don't have the hardware, i'd have to fake out anything about the child provider | |
| 13:42:26 | sean-k-mooney | mriedem: ok, well if for no other reason then documentation and haveing a place to discuss if its ok i can write up a short strawman spec to propose recreating config drives on migration. | |
| 13:42:41 | efried | mriedem: ack, thanks. | |
| 13:43:07 | gibi | efried: I don't have VGPU hardware either | |
| 13:43:47 | gibi | the closest I can have is to extract examples from the functional test we have | |
| 13:43:52 | sean-k-mooney | mriedem: but in any case yes for cross cell resize the option are limited | |
| 13:46:22 | bauzas | mriedem: gibi: don't worry, I'm working on it | |
| 13:46:22 | openstackgerrit | Dan Smith proposed openstack/nova-specs master: Add request-filter-image-types spec https://review.openstack.org/644625 | |
| 13:46:37 | gibi | bauzas: cool, thanks. Hit me with the review when it is ready | |
| 13:47:10 | dansmith | sean-k-mooney: yeah, I don't think it's okay either | |
| 13:47:19 | dansmith | sean-k-mooney: the user doesn't know they are getting a cross-cell resize | |
| 13:48:35 | sean-k-mooney | dansmith: that is true but what i was thinking was proposing. if file injection is disable we always recreate the config drive | |
| 13:49:07 | sean-k-mooney | dansmith: since that is the default the behavior sould be the same for cross cell and normal resizes | |
| 13:49:09 | dansmith | sean-k-mooney: as I said yesterday, file injection being disabled at the compute has nothing to do with whether or not the files end up in config drive (at least as I understand it) | |
| 13:49:33 | sean-k-mooney | oh i was not aware of that | |
| 13:49:57 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: Override the 'get' method in DriverBlockDevice class https://review.openstack.org/638821 | |
| 13:50:11 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: Remove mox in virt/test_block_device.py https://review.openstack.org/566153 | |
| 13:50:37 | sean-k-mooney | ok. that is partly why i was just going to creat a strawman spec as i honestly have not tought it true propely | |
| 13:50:41 | openstackgerrit | Takashi NATSUME proposed openstack/python-novaclient master: Remove deprecated options https://review.openstack.org/642312 | |
| 13:50:59 | dansmith | I have not chased it down fully, but I believe this is where we pass the injected files to the configdrive creation process: https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L3632-L3635 | |
| 13:51:05 | sean-k-mooney | i was pretty sure other would find holes in it | |
| 13:54:08 | mriedem | dansmith: fix the footnotes docs issue in your spec and i'm +2 | |
| 13:54:23 | mriedem | dansmith: i also mentioned a rebuild thing which you can document or omit, so long as we remember it during implementation | |
| 13:54:32 | dansmith | gah, okay | |
| 13:55:19 | dansmith | mriedem: can I leave those footnotes as bullets? | |
| 13:55:51 | mriedem | they aren't really footnotes then | |
| 13:55:53 | dansmith | i.e. "* .. [1] Glance..." | |
| 13:56:05 | mriedem | i mean, yo'ure using the [1]_ format above, so use .. [1] below | |
| 13:56:06 | dansmith | Well, I have that one caps-as-traits thing | |
| 13:56:14 | gibi | nova meeting starts in 5 minutes on openstack-meeting | |
| 13:56:18 | mriedem | i think it's fine to mix them | |
| 13:56:25 | dansmith | okay will push it up and check the render | |
| 13:56:26 | mriedem | on stephenfin will lose sleep over that | |
| 13:56:37 | mriedem | tox -e docs :) | |
| 13:56:48 | dansmith | too hard, let jenkins do the work | |
| 13:56:57 | openstackgerrit | Dan Smith proposed openstack/nova-specs master: Add request-filter-image-types spec https://review.openstack.org/644625 | |
| 13:57:14 | mriedem | actually i only noticed it because i threw it in http://rst.ninjs.org/# | |
| 13:57:15 | mriedem | and it complained | |
| 13:57:22 | mriedem | i always forget how to do footnotes in rst | |
| 13:57:32 | dansmith | me too, I looked at one of your specs to cheat, | |
| 13:57:36 | dansmith | but then copied wrong :D | |
| 13:57:39 | sean-k-mooney | dansmith looks like you are right. the only config value that i see that effect this is the injected_files quota and changing the behavior based on that seams wrong | |
| 13:57:47 | mriedem | the docs builder doesn't actually fail on busted footnotes i don't think | |
| 13:58:04 | dansmith | mriedem: but I can look at the render and see if it looks right | |
| 13:58:12 | mriedem | regarding personality files, i will say, they are best effort and broken in lots of ways | |
| 13:58:41 | mriedem | as noted in my spec known issue, you lose them on unshelve, you lose them on evacuate, and you lose them if you're only relying on the metadata api and get migrated | |
| 13:58:47 | sean-k-mooney | mriedem: ya which is part of the reaosn we deprecated them. | |
| 13:59:06 | dansmith | I know, but it does kinda suck | |
| 13:59:24 | mriedem | i'm not disagreeing | |
| 13:59:32 | mriedem | it also seems like we kind of punted on fixing that long ago | |
| 13:59:41 | mriedem | when we talked for years about deprecating personality files, and then finally did it | |
| 13:59:43 | dansmith | and it sucks because we suck, not because throwing files in a disk image that we generate is icky for any other reason | |
| 13:59:51 | sean-k-mooney | on a pure policy basis do we/should we allow behavior changes that may break deprecated api features | |
| 14:00:16 | mriedem | meeting time | |
| 14:00:17 | dansmith | deprecated api features are no different than regular ones if they're still available, | |
| 14:00:28 | dansmith | and especially if they're still the default for the base api version | |
| 14:00:30 | dansmith | (IMHO) | |
| 14:00:36 | dansmith | no nova meeting for me, I have a conflict | |
| 14:00:37 | mriedem | agree ^ | |
| 14:00:46 | sean-k-mooney | ok | |
| 14:00:49 | mriedem | people can and do still use all this stuff on 2.1 | |
| 14:00:53 | mriedem | because that's what osc defaults to | |
| 14:01:27 | sean-k-mooney | ya true. maybe we shoudl fix osc to not default to that first :) | |
| 14:19:11 | bauzas | mriedem: just to understand correctly, you want some examples using osc-placement ? | |
| 14:19:24 | bauzas | so I need to use my hardware then | |
| 14:20:08 | bauzas | yay | |
| 14:20:13 | mriedem | bauzas: yeah | |
| 14:20:20 | mriedem | because the release note is just a lot of words, | |
| 14:20:35 | mriedem | but you really need to see an example on the command line to drive this home i think | |
| 14:20:45 | bauzas | okay, I'll try to get some commands | |
| 14:20:56 | bauzas | I still have a devstack node | |
| 14:43:59 | jackding | mriedem: Hi Matt, could you or other cores have a look at this please? It's been sitting there for quite a while. https://review.openstack.org/#/c/621646/ | |
| 14:47:35 | mriedem | efried: you'll want to jump in #openstack-release at some point | |
| 14:47:56 | mriedem | i added comments and re-word suggestions to the highlight patch https://review.openstack.org/#/c/644697/ | |
| 14:48:32 | sean-k-mooney | jackding: am we are cutting RC1 today so still in code freeze mode | |
| 14:49:06 | jackding | sean-k-mooney: ok didn't know that | |
| 14:49:07 | efried | mriedem: ack; what's the timeline on this, do I need to hit it or can we wait for melwitt? | |
| 14:49:16 | sean-k-mooney | jackding: master will open for train tomorow | |
| 14:49:23 | mriedem | efried: i think it's due today | |
| 14:49:44 | sean-k-mooney | jackding: not sure if this backportable but ill take a look again | |
| 14:49:55 | jackding | sean-k-mooney: will hassle cores later then :) thanks. | |
| 14:49:57 | mriedem | http://lists.openstack.org/pipermail/openstack-discuss/2019-March/003952.html | |
| 14:49:59 | mriedem | efried: ^ | |
| 14:50:21 | mriedem | jackding: i can try to look when i'm not doing with release issues | |