Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-04-28
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
15:21:46 openstackgerrit Stephen Finucane proposed openstack/nova master: nova-manage: Deprecate 'host' commands https://review.openstack.org/453175
15:21:47 openstackgerrit Stephen Finucane proposed openstack/nova master: nova-manage: Deprecate 'project', 'account' commands https://review.openstack.org/453174
15:21:47 openstackgerrit Stephen Finucane proposed openstack/nova master: nova-manage: Deprecate 'agent' commands https://review.openstack.org/450795
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 mriedem the daguester is mia
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: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: Don't lazy-load flavor.projects during destroy() https://review.openstack.org/461032
16:12:00 openstackgerrit Matt Riedemann proposed openstack/nova master: Remove compatibility code for flavors https://review.openstack.org/460377
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 useless API tests https://review.openstack.org/461011
16:16:55 openstackgerrit Stephen Finucane proposed openstack/nova master: Remove 'FlavorRxtxController' extension https://review.openstack.org/461010
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"
16:20:36 cfriesen sfinucan: the way it's supposed to work is that if the flavor is "prefer" or not set then the image can set whatever it wants
16:20:55 sfinucan cfriesen: I think it's the other way round, no?
16:21:02 sfinucan image takes priority
16:21:09 cfriesen https://specs.openstack.org/openstack/nova-specs/specs/mitaka/implemented/virt-driver-cpu-thread-pinning.html
16:21:12 sfinucan i.e. image unset = set the flavor
16:21:14 cfriesen flavor takes priority
16:21:34 cfriesen from the link "This will only be honored if the flavor specifies the ‘prefer’ policy, either explicitly or implicitly as the defalt option. This ensures that the cloud administrator can have absolute control over threads policy if desired."
16:22:37 sfinucan cfriesen: Ah
16:22:50 sfinucan so the actual admin guide docs agree with the code https://docs.openstack.org/admin-guide/compute-cpu-topologies.html
16:22:59 sfinucan "Image metadata takes precedence over flavor extra specs."
16:23:15 sfinucan which means the spec needs to be updated
16:24:04 sfinucan cfriesen: Is there any reason image metadata shouldn't take priority?
16:25:27 cfriesen sfinucan: then the docs are wrong. look at the code in _add_cpu_pinning_constraint() for the cpu_policy. if the flavor says it's dedicated, then it's dedicated and we don't even look at the image
16:26:20 cfriesen historically the flavor took priority since it was set by the admin. If the admin didn't set it in the flavor, then the image was allowed to set it
16:26:38 cfriesen and if the flavor set it to shared the image was allowed to set it to shared
16:27:04 dane-fichter dansmith: I'm working on trying to modify the Instance object and I can't figure out the unit test failures
16:27:13 dane-fichter dansmith: do you have a sec?
16:27:42 dansmith dane-fichter: I'm drugged up and snot-filled, but I can try
16:28:24 sfinucan cfriesen: Aye. I was looking at 'cpu_thread_policy' for a bit there
16:28:37 sfinucan damn. So both docs need to be fixed, I guess
16:29:04 sfinucan cfriesen: I've to grab a lift home, but could you file a bug and I'll take a look later or on Monday?

Earlier   Later