| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-04-15 | |||
| 15:54:50 | openstackgerrit | Ghanshyam Mann proposed openstack/nova master: Add new default roles in remaining servers policies https://review.opendev.org/720116 | |
| 16:16:17 | openstackgerrit | Merged openstack/nova master: fup: Remove the use of the term `unstable rescue` INFO logs https://review.opendev.org/718451 | |
| 16:16:24 | openstackgerrit | Merged openstack/nova master: fup: Add missing docstrings from get_rescue_device|bus diskinfo funcs https://review.opendev.org/718464 | |
| 16:24:25 | openstackgerrit | Lee Yarwood proposed openstack/nova stable/train: libvirt: Calculate disk_over_committed for raw instances https://review.opendev.org/718964 | |
| 16:28:39 | gmann | melwitt: lyarwood stein backport is ready now (train is merges) - https://review.opendev.org/#/c/719121/ | |
| 16:29:32 | openstackgerrit | Merged openstack/nova master: libvirt: Change UEFI check to handle AArch64 better https://review.opendev.org/714311 | |
| 16:29:58 | melwitt | gmann: I thought you were gonna re-cherry-pick that one from the train change and remove the conflict note from the commit message? | |
| 16:32:18 | hrw | yay ;D | |
| 16:32:53 | gmann | melwitt: there was conflict form train also due to deps url | |
| 16:33:10 | melwitt | gmann: haha oh | |
| 16:33:30 | gmann | due to git.openstack.org and opendev.org | |
| 16:33:53 | melwitt | nevermind then | |
| 16:35:18 | hrw | does https://review.opendev.org/#/c/712607/ needs another 7h recheck? | |
| 16:38:29 | openstackgerrit | Lee Yarwood proposed openstack/nova master: fup: Fix [workarounds]/rbd_volume_local_attach config docs https://review.opendev.org/718100 | |
| 16:39:08 | lyarwood | stephenfin: ^ no idea how that ended up in merge conflict, can you +W that again if it's still okay? | |
| 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 | |