| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-04-15 | |||
| 16:41:46 | sean-k-mooney | huh i taught that already merged honestly | |
| 16:42:12 | openstackgerrit | Marcin Juszkiewicz proposed openstack/nova master: [WIP] CI: add tempest-integrated-compute-aarch64 job https://review.opendev.org/714439 | |
| 16:42:14 | sean-k-mooney | oh it did this is just a fix up for the config | |
| 16:49:34 | stephenfin | melwitt: I saw that, but wasn't sure what the conclusion was | |
| 16:50:27 | melwitt | stephenfin: no conclusion yet, wanted to see what you thought about it | |
| 16:50:47 | melwitt | since you had removed the user_data, what you thought about adding it back but by flag only | |
| 16:51:51 | stephenfin | Realistically I don't think we'd ever want that information included in raw format as part of the show command, but we clearly want it somehow. How about a new command? | |
| 16:54:27 | melwitt | I guess that seems heavier than what I was imagining. to just have it be like nova show --include-user-data or something like that | |
| 16:54:27 | stephenfin | Hmm, so it's both the 'nova boot' and 'nova show' commands that are affected | |
| 16:54:38 | melwitt | and rebuild apparently | |
| 16:54:43 | stephenfin | yup | |
| 16:55:29 | melwitt | it's not something "commonly" used but it's useful if an end user wants to see, did I pass in the user_data I expected, or what did I pass in user_data earlier | |
| 16:56:44 | sean-k-mooney | melwitt: can you see that via the metadata api | |
| 16:56:58 | melwitt | anyway, I wanted to run it by you in case you're strongly against putting it back via --<option> | |
| 16:57:17 | melwitt | sean-k-mooney: I think you could but that if you're config drive only, you wouldn't be able to | |
| 16:57:51 | sean-k-mooney | oh we dont store the user data in the db do we | |
| 16:58:08 | melwitt | we do | |
| 16:58:22 | sean-k-mooney | sorry im thinking of injected files | |
| 16:58:33 | sean-k-mooney | those are the ones that are only in the config drive | |
| 16:59:04 | melwitt | yeah, sorry, I mean like if you're not running the metadata service. and are config drive only deployment | |
| 16:59:35 | melwitt | (example: verizon media) | |
| 16:59:42 | sean-k-mooney | ya if you dont have metadata api then you would have to check the config drive unless we dumped it as part of nova show | |
| 16:59:50 | stephenfin | and we don't provide a way to configure output or output formats either. Drat | |
| 17:00:10 | sean-k-mooney | you mean in nova client | |
| 17:00:15 | stephenfin | yup | |
| 17:00:43 | sean-k-mooney | then we cant alter the format without potentally breaking people | |
| 17:01:00 | stephenfin | Yes, that's exactly what's happening here :) | |
| 17:01:26 | stephenfin | At least it was a major version bump, but still | |
| 17:01:51 | sean-k-mooney | of nova client right | |
| 17:02:07 | sean-k-mooney | i assume we are talking about the inclution of OS-EXT-SRV-ATTR:user_data in the nova show respocne right | |
| 17:02:15 | sean-k-mooney | is there a patch i can look at | |
| 17:02:44 | melwitt | https://opendev.org/openstack/python-novaclient/commit/03dca4bc823c82054869dfaf6925d5e1e068ac51 | |
| 17:02:49 | stephenfin | https://review.opendev.org/#/c/708850/ | |
| 17:02:52 | stephenfin | yeah | |
| 17:04:25 | sean-k-mooney | so melwitt you were suggesting adding an option to include it again | |
| 17:04:56 | sean-k-mooney | if we did i would proably do something like --user-data=<format> | |
| 17:05:20 | melwitt | yeah, some way to opt-in to it for end user verification purposes | |
| 17:05:36 | sean-k-mooney | possibley with --user-data=None used to not print it and restore the previous behavior of printing by default | |
| 17:06:10 | stephenfin | melwitt: I won't block the '--include-user-data' option, but I'd much rather we had a more generic '--verbose' or '--json' option that just showed the plain old response from the API or a new command to retrieve that field | |
| 17:06:12 | sean-k-mooney | if we want to maintain backward compatablity | |
| 17:06:46 | melwitt | tbc, I think not printing by default makes sense, I just think it would be ideal to have a way to opt-in if you want to verify something | |
| 17:07:07 | stephenfin | Yup, I get that :) | |
| 17:07:17 | melwitt | stephenfin: oh, I see what you mean now | |
| 17:07:18 | stephenfin | *what | |
| 17:07:42 | sean-k-mooney | so --user-data=raw|json|plain | |
| 17:07:58 | sean-k-mooney | where raw would give you hte base64 encoded string | |
| 17:08:04 | stephenfin | sean-k-mooney: no, 'nova boot --json ...' | |
| 17:08:23 | stephenfin | where the output is the raw JSON blob returned by the API rather than the pretty tables we do by default | |
| 17:08:23 | sean-k-mooney | wait is that a thing | |
| 17:08:37 | stephenfin | it is for OSC but not for novaclient | |
| 17:08:45 | stephenfin | it's also a lot more work... | |
| 17:08:54 | sean-k-mooney | no for osc we dont have --json we have -f json | |
| 17:09:10 | sean-k-mooney | unless --json has been added recently and is an alias | |
| 17:09:22 | stephenfin | yeah, sorry, I mean we have JSON-style formatting | |
| 17:09:26 | sean-k-mooney | i use the format specifers for osc the whole time | |
| 17:09:29 | stephenfin | different arg, as you say | |
| 17:09:42 | sean-k-mooney | ok well that normally applies to all the output | |
| 17:09:59 | stephenfin | yeah | |
| 17:10:13 | sean-k-mooney | i was suggesting having a way to contol the output/encoding of just that filed | |
| 17:10:38 | stephenfin | it's arbitrary data - there's nothing to really encoding | |
| 17:10:48 | stephenfin | maybe escape, but not encode | |
| 17:11:32 | sean-k-mooney | well its typically in cloud-init or could-config format or ignition format | |
| 17:11:45 | stephenfin | yeah, 'zactly | |
| 17:11:48 | sean-k-mooney | all of which are json or yaml based and human readable | |
| 17:12:08 | stephenfin | Anyway, I'm suggesting that including non-human readable data in a response designed for humans, like the 'nova show' output is supposed to be, _probably_ isn't the right thing to do and it would be nicer if we had a specific machine-readable format for that | |
| 17:12:08 | sean-k-mooney | stephenfin: do we have the --long optin in nova client | |
| 17:12:12 | sean-k-mooney | we could just use that | |
| 17:12:26 | sean-k-mooney | is it --long or --wide | |
| 17:12:41 | sean-k-mooney | there is one arg you can pass that shows addtional columns | |
| 17:12:41 | stephenfin | you have --width | |
| 17:13:02 | stephenfin | but I don't see anything else | |
| 17:15:37 | stephenfin | melwitt: Can I check out how tough a format argument would be to implement tomorrow morning and come back to you? If it's too much, I'd be okay with a '--verbose' or specific '--include-user-data' argument | |
| 17:16:13 | melwitt | stephenfin: yeah, it's not urgent. just wanted to see what you thought, no worry | |
| 17:16:42 | melwitt | whatever it is, I hope we can backport it to ussuri but not sure whether that's gonna fly | |
| 17:16:51 | sean-k-mooney | stephenfin: i was thinking of openstack hypervisor list --long | |
| 17:17:03 | sean-k-mooney | but that is specific to just that command | |
| 17:17:25 | stephenfin | Yeah, it's weird having release stable branches for a client | |
| 17:17:41 | melwitt | yeah, it's a pain | |
| 17:17:54 | stephenfin | but it is what it is | |
| 17:18:00 | stephenfin | would any opt be backportable? | |
| 17:18:09 | stephenfin | lyarwood: hit https://review.opendev.org/#/c/718100/ btw | |
| 17:18:38 | sean-k-mooney | stephenfin: well you could arge your change was a regression since you broke backwards comatiablity without any way to opt in | |
| 17:18:55 | lyarwood | stephenfin: thanks | |
| 17:19:00 | stephenfin | sean-k-mooney: but we indicated that with a major version bump | |
| 17:19:08 | stephenfin | so per Sem-Ver, we're golden | |
| 17:19:31 | stephenfin | though per the "be nice to users" rule, maybe not so much :) | |
| 17:19:59 | sean-k-mooney | true but its not nessisarly resonable to expect them to be able to pin the version to an older one since nova clint is ill advisidly used as part of sdks and other tools | |
| 17:20:32 | sean-k-mooney | anyway whats done and relased is done | |
| 17:21:32 | sean-k-mooney | stephenfin: this converation reminds me why i avoid nova clinet in the first place | |
| 17:21:42 | stephenfin | yeah, OSC FTW | |
| 17:21:45 | sean-k-mooney | i only ever use it if osc cant do the thing | |
| 17:34:05 | openstackgerrit | Sylvain Bauza proposed openstack/nova master: FUP: doc: explaining that resize works for vGPUs https://review.opendev.org/720250 | |
| 21:26:55 | openstackgerrit | Ivaylo Mitev proposed openstack/nova master: Faults from cell DB missing in GET /servers/detail https://review.opendev.org/699176 | |
| 21:31:53 | openstackgerrit | Merged openstack/nova master: fup: Fix [workarounds]/rbd_volume_local_attach config docs https://review.opendev.org/718100 | |
| 22:19:49 | sangeet | What is the best way to power off the servers. "Openstack server stop" is not a graceful shutdown. | |
| 22:19:58 | sangeet | I am using Stein | |
| 22:43:45 | sangeet | Want to shut down the VM gracefully so when it is stared again, we are back to full working mode. | |
| 22:56:51 | melwitt | sangeet: graceful shutdown is default behavior but there is a timeout used for how long to wait for the guest to shutdown gracefully, defaulting to 60s https://docs.openstack.org/nova/stein/configuration/config.html#DEFAULT.shutdown_timeout | |
| 23:00:55 | kplant | i think acpid is required in the guest too | |
| 23:00:56 | kplant | iirc | |