Earlier  
Posted Nick Remark
#openstack-nova - 2017-04-28
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 'host' commands https://review.openstack.org/453175
15:21:46 openstackgerrit Stephen Finucane proposed openstack/nova master: nova-manage: Deprecate 'log' commands https://review.openstack.org/453176
15:21:47 openstackgerrit Stephen Finucane proposed openstack/nova master: nova-manage: Deprecate 'agent' commands https://review.openstack.org/450795
15:21:47 openstackgerrit Stephen Finucane proposed openstack/nova master: nova-manage: Deprecate 'project', 'account' commands https://review.openstack.org/453174
15:26:32 openstackgerrit Matt Riedemann proposed openstack/nova master: placement: implement get_inventory() for libvirt https://review.openstack.org/457782
15:26:34 mriedem leakypipes: i rebased that mofo
15:26:51 leakypipes mriedem: ah, cheers
15:27:09 mriedem bauwser: for your le pen pleasure https://review.openstack.org/#/c/457782/
15:31:37 cdent leakypipes: I thought that was surprisingly short
15:31:48 leakypipes heh
15:32:07 cdent I was expecting a full exegesis of the service catalog
15:32:44 leakypipes "Let me say a few more words ..." <-- understatement of the year.
15:33:52 sfinucan cdent: exegesis? TIL...
15:34:11 cdent I find that mutuality very satisfying
15:34:34 leakypipes get a room, you two. :)
15:35:01 cdent jealous!
15:37:57 clarkb speaking of mordred you didn't list anycast as an option >_>
15:43:39 mriedem leakypipes: bauwser: have you guys coordinated anything with sdague about the project onboarding stuff at the summit? since i'm not going to be there for that i wasn't sure what's going on
15:43:55 leakypipes mriedem: I have not, no.
15:44:41 smcginnis leakypipes: I was actually curious - are you guys planning something like a full hands on workshop? Or more of a thing where folks can stop by and get more info?
15:44:41 mriedem the daguester is mia
15:45:29 leakypipes smcginnis: I haven't thought about it at all :( I've been too wrapped up in completing slides for the eleventy presentations I'm giving :(
15:45:45 cdent eleventy+1
15:45:56 mordred clarkb: hahaha

Earlier   Later