Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-04-28
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
15:46:16 smcginnis leakypipes: Kind of rough timing.
15:46:25 mordred leakypipes: if you think _that_ novel is fun- you should read my writeup of consuming version discovery
15:47:07 mordred leakypipes: honestly, although it's super painful to read, I _would_ love feedback on https://review.openstack.org/#/c/459405/
15:47:19 mordred leakypipes: but I wil understand if it takes you a decade to read
15:47:31 mordred clarkb: ^^ if you haven't 'enjoyed' thatyet
15:48:06 leakypipes mordred: will try my best :)
16:09:28 cdent mriedem: did this fall of your radar, or is simply not all that urgent: https://review.openstack.org/#/c/454887/
16:09:42 mriedem leakypipes: alert: "rick james - superfreak" just came into my music rotation
16:10:01 mriedem cdent: it's still a thing
16:10:06 mriedem near and dear to my heart
16:10:23 clarkb mordred: I saw the line count and then ran away screaming
16:10:24 mriedem oh you mean replying to your question? :)
16:12:00 openstackgerrit Matt Riedemann proposed openstack/nova master: Remove compatibility code for flavors https://review.openstack.org/460377
16:12:00 openstackgerrit Matt Riedemann proposed openstack/nova master: Don't lazy-load flavor.projects during destroy() https://review.openstack.org/461032
16:13:01 cdent mriedem: no I wasn't worried about the reply to my question, I just have it in my rotating to do list as something to go back and review, and it seemed more idle than something which I would have assumed would be merged easily and quickly
16:16:55 openstackgerrit Stephen Finucane proposed openstack/nova master: Remove 'FlavorRxtxController' extension https://review.openstack.org/461010
16:16:55 openstackgerrit Stephen Finucane proposed openstack/nova master: Remove useless API tests https://review.openstack.org/461011
16:19:03 cfriesen sfinucan: you still around?
16:19:15 sfinucan cfriesen: For another 5 mins, yup
16:19:19 sfinucan what's up?
16:20:11 cfriesen sfinucan: looking at _add_cpu_pinning_constraint() I don't think the code matches the docs for the case where flavor_thread_policy is "prefer" and image_thread_policy is "isolate"

Earlier   Later