Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-04-28
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"
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?
16:29:15 dane-fichter dansmith: ok so here's the unit test failures: http://logs.openstack.org/11/457711/2/check/gate-nova-python27-ubuntu-xenial/7429f62/console.html#_2017-04-25_21_51_45_406244
16:29:18 cfriesen sfinucan: can do
16:29:23 sfinucan I'm guessing we need to fix the docs because we can't break existing deployments
16:29:33 sfinucan At least, not without a cycle of warnings
16:29:44 dane-fichter dansmith: it kinda looks like the "new" instance version isn't being added to the versioned objects registry?
16:29:46 cfriesen sfinucan: we changed the code behaviour for the thread policy from Mitaka to Newton
16:29:58 sfinucan cfriesen: On purpose?
16:30:10 cfriesen sfinucan: nope. looks like an accident
16:30:21 sfinucan cfriesen: lovely
16:30:30 cfriesen in mitaka if the flavor policy was "prefer" we would use the image thread policy
16:31:00 cfriesen in newton if the flavor policy is "prefer" we'll use "prefer", if the flavor policy is "none" we'll use the image thread policy
16:31:45 cfriesen correction, in mitaka if the flavor policy was "none" or "prefer" we would use the image thread policy
16:31:49 sfinucan damn. That was my '_get_flavor_image_meta' centralization patch, I bet
16:32:26 sfinucan OK, stick that in the report too. I don't know what we'll be able to do about it (is it a bug or a feature now?) but there should probably an errata reno added at least
16:32:34 dansmith dane-fichter: that's kinda weird looking
16:32:47 cfriesen sfinucan: looks like it was ndipanov actually
16:32:56 cfriesen will write it up
16:32:58 dane-fichter dansmith: yeah I haven't been able to figure it out
16:33:27 dane-fichter dansmith: I thought maybe the new version of Instance isn't added to the versioned objects registry
16:33:57 dane-fichter dansmith: here's the patch btw https://review.openstack.org/#/c/457711/2
16:34:11 dansmith dane-fichter: well, that isn't really a thing, but agree that it seems to be something up with the manifest and the instance object
16:34:13 dansmith yeah, looking at ti
16:36:30 dansmith dane-fichter: gimme a few
16:36:36 dansmith dane-fichter: sorry if I get snot on your patch

Earlier   Later