| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-01-30 | |||
| 19:47:57 | mriedem | not trying to be sarcastic, | |
| 19:48:00 | mriedem | if you look at the api-ref | |
| 19:48:06 | artom | Heh, you are right though | |
| 19:48:24 | mriedem | look at the description for networks.tag here http://developer.openstack.org/api-ref/compute/?expanded=create-server-detail#id7 | |
| 19:48:30 | artom | I think I was trying to be generic, because... reasons, I guess? | |
| 19:48:34 | mriedem | and block_device_mapping_v2.tag | |
| 19:48:53 | mriedem | generic is fine, and what you have in the api-ref is good | |
| 19:49:01 | mriedem | i'm on the fence about over documenting this to death | |
| 19:49:56 | artom | Surely more docs is better? | |
| 19:50:03 | mriedem | probably | |
| 19:50:25 | mriedem | you might want to make those specific parameter types then though | |
| 19:50:41 | artom | What would we gain by mentioning it less? Someone's bound to run into this, we might as well make the explanation of wtf happened as accessible as possible | |
| 19:50:52 | mriedem | so for device_network_tag you just make the comment about 2.32-2.36, and for device_bdm_tag you make the comment about 2.32 | |
| 19:51:12 | mriedem | know what i mean? | |
| 19:51:24 | artom | Aha, and then set the correct min and max version on each | |
| 19:51:27 | mriedem | yeah | |
| 19:51:28 | artom | Yep, I agree | |
| 19:51:31 | mriedem | since device_tag is used for both right now | |
| 19:51:39 | artom | Well | |
| 19:51:46 | artom | min, max, and min again | |
| 19:51:51 | artom | If I can manage that | |
| 19:52:02 | mriedem | fwiw i don't know if the sphinx plugin supports a max_version | |
| 19:52:19 | mriedem | sdague: do you know if there is a max_version for https://review.openstack.org/#/c/424759/9/api-ref/source/parameters.yaml@1506 ? | |
| 19:52:29 | mriedem | oh there is | |
| 19:52:29 | mriedem | nvm | |
| 19:52:45 | mriedem | artom: i don't think you can do min and max and then min again | |
| 19:53:04 | mriedem | so probably just min-version: 2.32, and then notes in the description about the snafu between 2.32 and 2.42 | |
| 19:54:09 | artom | mriedem, maybe if I split it again into nic_tag_2.32-2.37 and another one... | |
| 19:54:14 | artom | Worth it? | |
| 19:54:26 | mriedem | then we have the same parameter listed in the table twice | |
| 19:54:33 | artom | Or will it just be more confusing then writing it in English words | |
| 19:54:39 | artom | *than | |
| 19:54:48 | mriedem | i think english be gooder | |
| 19:55:01 | mriedem | sorry, *me think* | |
| 20:04:10 | artom | The schema deepcopy thing is a minefield :( | |
| 20:04:31 | artom | You caught the network uuid checking, presumably because you wrote 2.37 yourself | |
| 20:04:49 | mriedem | artom: exactly | |
| 20:05:09 | mriedem | artom: the tempest guys stopped doing the deepcopy i think | |
| 20:05:10 | mriedem | for this very reason | |
| 20:05:23 | mriedem | oomichi: right? ^ | |
| 20:06:52 | artom | Maybe I'll remove the network_type refactoring then and stick to copy-pasting | |
| 20:08:00 | oomichi | mriedem: yeah, you are right. gmann takes care of it on Tempest side | |
| 20:09:01 | oomichi | mriedem: that requrest came from sdague and mtreinish because the deepcopy of schema seems unreadable to know whole schema on each microversion | |
| 20:17:17 | mriedem | hmm, what's a better place for the nova-status CLI in the release notes, features or upgrades? | |
| 20:17:31 | mriedem | i assume the upgrades section gets more reads | |
| 20:18:46 | dansmith | yeah, probably | |
| 20:18:48 | dansmith | hopefully anyway | |
| 20:19:11 | dansmith | the placement patches got reset so they're still in the running | |
| 20:19:24 | dansmith | I'm going to wander off for a bit and will come back to check on them | |
| 20:20:10 | openstackgerrit | Artom Lifshitz proposed openstack/nova: Pass APIVersionRequest to extensions https://review.openstack.org/425876 | |
| 20:20:11 | openstackgerrit | Artom Lifshitz proposed openstack/nova: Fix tag attribute disappearing in 2.33 and 2.37 https://review.openstack.org/424759 | |
| 20:24:10 | edleafe | jaypipes: Found a test failure in https://review.openstack.org/#/c/404472/ due to an incomplete test I added. Do you want me to remove it, or are you working on anything else with that patch? | |
| 20:29:33 | bauzas | mriedem: I wrote about the nova-status in the prelude | |
| 20:30:00 | bauzas | mriedem: https://review.openstack.org/#/c/426864/ | |
| 20:30:12 | mriedem | was coincidentally reading that now | |
| 20:30:28 | jaypipes | edleafe: please go ahead! | |
| 20:31:23 | bauzas | mriedem: about the nova-status CLI, I think we should provide a 'feature' section | |
| 20:31:49 | bauzas | mriedem: "upgrade" section is just for discussing about what to need to modify before upgrading | |
| 20:32:04 | bauzas | mriedem: but you could still add a separate section if you want too | |
| 20:32:19 | mriedem | bauzas: i assume operators are more likely to read the upgrades release notes first, | |
| 20:32:26 | mriedem | and we want them using nova-status prior to upgrading | |
| 20:32:34 | mriedem | so seems best to just have it in the upgrade section | |
| 20:32:38 | bauzas | mriedem: sure, but the upgrades section will be huge | |
| 20:32:42 | mriedem | i didn't really want to mention the exact same thing in both ugprades and features | |
| 20:32:47 | bauzas | mriedem: so that's why I provided the prelude | |
| 20:32:48 | mriedem | it already is... | |
| 20:33:03 | bauzas | mriedem: so I think operators would see that by the prelude | |
| 20:33:57 | dtp | anyone need anything? cup of coffee, etc | |
| 20:34:05 | mriedem | just had one thanks | |
| 20:34:14 | mriedem | bauzas: ok i guess i can rebase my reno on top of yours | |
| 20:34:51 | mriedem | bauzas: and your reno needs a rebase too because your change and dan's change below it are both adding something to the prelude about cells v2 | |
| 20:35:23 | bauzas | mriedem: fine by me, which rebase? | |
| 20:35:58 | mriedem | your change isn't on top of the latest version of https://review.openstack.org/#/c/424737/ | |
| 20:36:53 | bauzas | mriedem: okay | |
| 20:38:16 | dtp | ok. let me know if there's anything i can do | |
| 20:38:54 | openstackgerrit | Matt Riedemann proposed openstack/nova: Add release note for nova-status upgrade check CLI https://review.openstack.org/426911 | |
| 20:43:56 | mriedem | bauzas: i suppose we still want to get something into nova-status for warning if CoreFilter/RamFilter/DiskFilter aren't in filter_scheduler.enabled_filters... | |
| 20:44:31 | bauzas | mriedem: mmm, it could be nice, agreed | |
| 20:44:40 | bauzas | mriedem: I can write that if you want | |
| 20:45:09 | bauzas | mriedem: you mean, adverting to modify the ratios then ? | |
| 20:45:24 | mriedem | yeah something along those lines, | |
| 20:45:31 | mriedem | (1) is the filter_scheduler being used, | |
| 20:45:43 | mriedem | (2) are any of those things NOT in enabled_filters | |
| 20:46:07 | mriedem | (3) for each filter that's not enabled, check it's related allocation ratio and see if it's the default value and if so, issue a warning | |
| 20:46:08 | mriedem | something likethat | |
| 20:46:22 | bauzas | yeah, like I wrote in the note | |
| 20:46:33 | bauzas | very good point | |
| 20:46:52 | bauzas | mriedem: just one point, where operators are running the CLI ? | |
| 20:47:14 | mriedem | we don't know yet | |
| 20:47:23 | bauzas | mriedem: they need to do that in not in a computer, right? rather close to the other services, I guess | |
| 20:47:26 | mriedem | as we haven't integrated nova-status into the CI system yet | |
| 20:47:40 | mriedem | well, it's really, give me your full config | |
| 20:47:57 | mriedem | so api db, main db, compute config, scheduler config, all of it | |
| 20:48:02 | mriedem | and probably run it in a venv or container | |
| 20:48:23 | mriedem | so you can install and run it in isolation from the newton deployment code (which doesn't have the CLI) | |
| 20:49:16 | bauzas | ok | |
| 20:49:19 | mriedem | i'm thinking about writing a wip patch to grenade to run nova-status in the from-netwon script, after we'd done our necessary setup for ocata | |
| 20:50:30 | dansmith | mriedem: did you abandon that devstack patch that sets the db host to the primary? | |
| 20:50:39 | mriedem | yeah | |
| 20:50:42 | mriedem | i can find it | |