| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-04-28 | |||
| 14:23:25 | sfinucan | melwitt: Cheers :) | |
| 14:24:20 | sfinucan | melwitt: I can't use underscore-separated command names (usage_refresh) with cliff :( | |
| 14:24:27 | sfinucan | see last comment on that patchset | |
| 14:24:30 | melwitt | sfinucan: even as the subcommand? oh | |
| 14:24:52 | sfinucan | nope. it's why I need to do this https://review.openstack.org/#/c/453809/ | |
| 14:24:58 | melwitt | I was thinking only the first command had that limitation | |
| 14:25:34 | sfinucan | Afraid so. You can switch off that behavior but it's all or nothing | |
| 14:26:16 | sfinucan | ...which would prevent us nesting commands entirely, which we can't do | |
| 14:26:23 | sfinucan | cliff is broken by design but the community won't listen to me and switch to click :P | |
| 14:27:06 | melwitt | okay. I guess our choices are refresh or usagerefresh then. I'm not too concerned about it since my quotas patch set removes that nova-manage command anyway, so meh | |
| 14:27:33 | mriedem | why wouldn't we just have: nova-manage usage refresh? | |
| 14:27:38 | mriedem | don't call the subcommand QuotaCommands | |
| 14:27:43 | mriedem | call it UsageCommands | |
| 14:28:02 | melwitt | it might be mysterious what kind of usage is it talking about | |
| 14:28:08 | melwitt | "usage of what" | |
| 14:28:13 | mriedem | that's part of the excitement | |
| 14:28:15 | mriedem | but yeah | |
| 14:28:25 | melwitt | +1 to excitement | |
| 14:28:31 | mriedem | nova-manage quota usage_refresh then | |
| 14:28:37 | mriedem | or you can't _? | |
| 14:28:41 | melwitt | he said we can't have any underscores anywhere | |
| 14:28:52 | mriedem | we have nova-manage api_db | |
| 14:29:07 | mriedem | nova-manage quota_usage refresh? | |
| 14:29:08 | melwitt | he has a patch up to make that apidb https://review.openstack.org/#/c/453809/ | |
| 14:29:21 | mriedem | gdi, the whole world is upside down | |
| 14:29:31 | melwitt | yeah | |
| 14:29:48 | mriedem | when EmilienM and every other deployment tooling person comes screaming, i'm pointing them all at sfinucan | |
| 14:29:55 | melwitt | hah yup | |
| 14:30:02 | EmilienM | hey hi | |
| 14:30:06 | melwitt | it's all your fault sfinucan :) | |
| 14:30:11 | mriedem | but EmilienM, sfinucan wanted to use click! | |
| 14:30:14 | EmilienM | you'll notice I didn't complain for a while | |
| 14:30:22 | mriedem | EmilienM: that's only because you don't care anymore | |
| 14:30:28 | EmilienM | no, it's because things work | |
| 14:30:34 | mriedem | we can fix that | |
| 14:30:55 | EmilienM | :) | |
| 14:36:42 | sfinucan | melwitt, mriedem: So, what's your poison? 'usage refresh' or 'quotas refresh' | |
| 14:36:51 | sfinucan | I'm pretty sure we can't do camel case either | |
| 14:36:59 | bauwser | mriedem: so, seeing https://review.openstack.org/#/c/457577/1 and its cherry-picks, we can easily fix the problem like that ? | |
| 14:37:01 | sfinucan | I could do 'quotausage' but that's ugly | |
| 14:37:36 | sfinucan | mriedem: maybe the deployment guys will like the shiny new (auto-generated) man pages though? :) | |
| 14:37:41 | melwitt | sfinucan: commenting on the review, I think the choices are effectively 'quota usagerefresh' or 'quota refresh' and I'm not too opinionated about it bc it's going to be removed soon as part of the quota counting stuff I'm doing | |
| 14:38:14 | sfinucan | melwitt: Ooh, that's happening this cycle right? Could I just deprecate the whole command instead? | |
| 14:38:53 | sfinucan | "this particular commands *isn't* accessibly via the API, but it won't be used soon so we're deprecating it too" | |
| 14:39:06 | sfinucan | s/accessibly/accessible/ | |
| 14:39:37 | openstackgerrit | Jay Pipes proposed openstack/nova master: placement: implement get_inventory() for libvirt https://review.openstack.org/457782 | |
| 14:39:40 | leakypipes | mriedem: sigh :) fixed ^ | |
| 14:40:27 | melwitt | sfinucan: yeah. if deprecate == remove, I guess I'd be wary of going that far because we can't 100% guarantee when quota counting will get merged and any time lag there would be a gap in the command not being available | |
| 14:40:33 | mriedem | bauwser: i took pause with it too, and there wasn't discussion from alex_xu or sdague in the change, | |
| 14:40:44 | mriedem | bauwser: but if you're thinking new microversion or something, i don't really know how that would work | |
| 14:41:29 | bauwser | mriedem: FWIW, I merged the change | |
| 14:45:18 | bauwser | mriedem: because whatever the resolution is, we should have the same between all the releases | |
| 14:47:33 | mriedem | anyone know of a way to pull down existing ML threads after you've subscribed? | |
| 14:48:21 | mriedem | bauwser: except mitaka which is eol and introduced the regression.. :) | |
| 14:48:26 | mriedem | oops! | |
| 14:48:57 | bauwser | mriedem: looks to me something I should BZ internally :p | |
| 14:50:27 | sfinucan | melwitt: Sounds fair. Let's go with 'quota refresh' so. A good help message will clarify any potential issues | |
| 14:50:37 | bauwser | mriedem: about the pulldown issue when you have a new IMAP or POP service, that's why I subscribed to the -dev ML with 2 accounts | |
| 14:50:59 | bauwser | mriedem: so I can get the full list from one account and transfer it to another | |
| 14:51:01 | melwitt | sfinucan: sounds good | |
| 14:51:06 | sfinucan | bauwser: well??? :) | |
| 14:51:17 | sfinucan | RE: 'reserved_host_cpus' vs. 'vcpu_pin_set' | |
| 14:51:23 | bauwser | oh snap | |
| 14:51:34 | mriedem | sfinucan: for one thing they mean two different things | |
| 14:51:35 | bauwser | this is what happens when your brain is multitask | |
| 14:51:45 | mriedem | sfinucan: bauwser: we should probably call out each as related options though | |
| 14:52:13 | bauwser | mriedem: sfinucan: I'd advocate they look similar but they have very different usecases | |
| 14:52:26 | bauwser | mriedem: that's why I used the word "random" for my reno file | |
| 14:52:28 | johnthetubaguy | melwitt: ah, quotas chain is looked read-ier I should take a look at that | |
| 14:52:55 | johnthetubaguy | turns out I can't type, thats early on a friday to loose the will to type | |
| 14:53:02 | melwitt | johnthetubaguy: thanks for noticing! I'm going to push an update today to address leakypipes comments so you can wait for that | |
| 14:54:08 | johnthetubaguy | melwitt: ah, maybe something for monday then, cool | |
| 14:55:38 | melwitt | johnthetubaguy: yeah, thanks. will be really great to get your thoughts on it monday | |
| 14:56:23 | openstackgerrit | Jiri Suchomel proposed openstack/nova master: Retry few times when creating the initial connection to libvirtd. https://review.openstack.org/416928 | |
| 14:57:35 | sfinucan | mriedem: Are they really that different? It just seems like one is random while another is not? | |
| 14:57:56 | sfinucan | idk, maybe a less specific way to reserve CPUs is a desirable thing | |
| 15:02:41 | blancos | sfinucan johnthetubaguy I was wondering if you had a moment to discuss https://review.openstack.org/#/c/444036/ ? | |
| 15:02:52 | sfinucan | blancos: Sure, what's up? | |
| 15:03:30 | openstackgerrit | Chris Friesen proposed openstack/nova master: Fix units for description of "flavor_swap" parameter https://review.openstack.org/461074 | |
| 15:03:47 | cfriesen | ^ This is a totally trivial fix to the units of a parameter description. | |
| 15:03:59 | blancos | I guess I'm just a little confused about what the recommended direction would be. My original intention was to modify the policy, then to remove the policy check entirely since it's not really used. | |
| 15:04:17 | blancos | Now it seems like the idea is to remove the flavor-rxtx controller? | |
| 15:04:32 | mriedem | sfinucan: not having to specify specific CPUs to adjust for overhead is much more desirable imo yes | |
| 15:05:48 | sfinucan | blancos: Yup, the last one was my idea. I thought that controller did nothing, but that's not true | |
| 15:06:43 | johnthetubaguy | blancos: let me find you a link, I am agreed it can probably go, but we need to deprecate it first | |
| 15:07:39 | blancos | johnthetubaguy Okay. So that would involve an addition to the releasenotes and...that's it? (Apologies, I'm not familiar with this process) | |
| 15:09:00 | sfinucan | blancos: I'm not sure for policy but for configuration options we generally raise a LOG.warning when someone tries to use anything but the default value | |
| 15:09:10 | openstackgerrit | Chris Friesen proposed openstack/nova master: show flavor info in server details https://review.openstack.org/434514 | |
| 15:09:15 | johnthetubaguy | blancos: this is the backgroud, see the configuration bit: https://governance.openstack.org/tc/reference/tags/assert_supports-upgrade.html#requirements | |
| 15:09:29 | sfinucan | cfriesen: Checking out the first one now | |
| 15:09:48 | johnthetubaguy | blancos: yeah, its not something we have done much for policy actually, but sfinucan is spot on, its about making sure we warn the deployer (reno notes are a big part of that too!) | |
| 15:10:16 | sfinucan | blancos: tl;dr: on that first one - you must be able to use the same configuration file between release N and N+1 of nova | |
| 15:10:26 | sfinucan | *on that link from John | |
| 15:10:52 | sfinucan | so we log to warn operators "this still works, but it won't in the next release. Fix right now or you're in for a world of hurt" | |
| 15:12:01 | blancos | sfinucan johnthetubaguy I see. Thank you for the help and the clarification. :) | |
| 15:12:36 | johnthetubaguy | blancos: thanks for looking into it, all good :) | |
| 15:12:58 | sfinucan | blancos: np. Also, this is up to you, but you might want to base your changes on top of https://review.openstack.org/#/c/461010 even still | |
| 15:13:08 | sfinucan | actually, maybe not. That's a lot of red :O | |
| 15:13:29 | sfinucan | *on top of that once I fix it :) | |
| 15:21:46 | openstackgerrit | Stephen Finucane proposed openstack/nova master: nova-manage: Deprecate 'log' commands https://review.openstack.org/453176 | |