Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-01-25
16:11:39 mriedem i don't have the history on that and it wasn't found in the original changes
16:11:57 stephenfin mriedem: Can do
16:12:02 melwitt s/should/shouldn't/
16:12:30 mriedem the compute manager doesn't kick cold migrate to the same host out unilateraly, the api is
16:12:38 mriedem with that 2.56 change to specify host on cold migrate
16:12:47 mriedem that's a different issue from the bug though, which was reported against ocata
16:12:52 mriedem before 2.56 existed
16:13:41 mriedem i believe migrate_to_same_host exists for the vmware driver b/c you can have a single nova-compute service in your openstack deployment which is actually managing a vcenter cluster with 1000 ESXi hosts in it
16:13:47 mriedem so your only choice to cold migrate is to the same host
16:13:50 melwitt he says he thinks it exists in ocata too from reading the code. right? I'm having trouble parsing this entire bug :(
16:14:07 mriedem my patches above are working on fixing the bug he's hitting which exists in ocata
16:14:09 mriedem 2.56 does not
16:14:09 melwitt comment #2
16:14:34 mriedem 2.56 was queens
16:14:55 mriedem comment 2 is saying 2 things
16:14:58 mriedem first is the bug i'm fixing above
16:15:03 mriedem second is the 2.56 issue i think
16:15:06 mriedem which is a different bug imo
16:15:14 melwitt yeah, I think he's not saying he's reporting it for ocata. "First, why the latest version of nova not supports migrating instance to same host event through some drivers support that function..Second, if there is any problem when user migrates instance without migration destination host but there is just one compute node."
16:15:57 melwitt eh, I dunno, I think I'm just confused by the wording of these comments
16:18:33 mriedem i left a comment to try and answer the questions from comment 2
16:20:11 melwitt thanks. I think I see now, he's saying why go to error status when it "fails" because migrating to self doesn't really do anything
16:21:07 melwitt ok that comment makes it clear. good
16:21:13 mriedem correct, but the rejection in the API is not the same as the bug in the compute that sets the instance to error status
16:21:31 mriedem i've got fixes posted above for the latter, not the former
16:21:54 melwitt gotcha. I've got it starred for review
16:29:30 mriedem melwitt: if https://blueprints.launchpad.net/openstack/?searchtext=conf-max-attach-volumes is ready for review again you want to queue it up in runways?
16:29:46 mriedem jangutter's can probably go in the open slot as well
16:30:10 melwitt mriedem: sure. I don't know why I didn't think of doing that
16:34:51 jangutter melwitt, mriedem: thanks!
16:35:41 mriedem pretty easy fix here for someone https://review.openstack.org/#/c/624959/
16:35:46 mriedem needs to be backported to queens as well
16:39:49 melwitt jangutter: the bp dependencies show that vrouter-hw-offloads also depends on the generic-os-vif-offloads too. should I add that patch link in there too for the runway review?
16:40:37 sean-k-mooney melwitt: i think the os-vif stuff was all in the 1.14 release we did this week
16:40:41 jangutter melwitt: the dependency's unblocked on that one (generic-os-vif-offloads has follow-on work)
16:41:09 sean-k-mooney jangutter: more stuff in os-vif "e.g. that i should review" or in nova
16:41:15 melwitt oh, I see, the dependency piece is unblocked but bp still needs more work to be complete
16:41:16 sean-k-mooney which i should proably also review
16:41:17 melwitt ok thank you
16:41:48 jangutter melwitt: the dominoes are all ready to fall... for the vrouter bits though.
16:42:05 melwitt coolness
16:45:51 jangutter sean-k-mooney: for the generic-os-vif-offloads I think there's just one more bit in nova (for Stein) to populate the data. The next os-vif change should really only be appropriate for Train.
16:48:48 sean-k-mooney ok
16:49:40 sean-k-mooney if there is stuff i need to review for stien let me know. the non client lib frezze is in 3-4 weeks so if another os-vif release is need we need to merge the code before then
16:50:14 sean-k-mooney form the non-client-lib freeze untill rc1 os-vif will basically be frozen
16:50:41 sean-k-mooney form rc1/rc2 on it will be reopen for train
16:51:09 melwitt feb 28 is non-client lib freeze
16:51:38 jangutter sean-k-mooney: thanks, the only open one I have for Stein is the serialization cleanup patch, and that kinda-sorta depends on a style choice.
16:52:13 sean-k-mooney ok thats what i had understood
16:52:38 jangutter sean-k-mooney: I _think_ the only affected party to that would be kuryr and not Nova.
17:06:58 melwitt leakypipes, mriedem: am I correct in my understanding that because this spec about "how to use initial allocation ratios" got stuck https://review.openstack.org/544683, we don't and will not have support for being able to set allocation ratios per aggregate?
17:08:41 mriedem you can do it via placement externally if you want, and could have since forever - and is what we said people could do in dublin
17:08:44 mriedem but no one worked on that,
17:08:48 mriedem or added anything to osc-placement for it
17:09:06 mriedem the nova spec is about mirroring aggregate allocation ratios to placement
17:09:34 mriedem which is a nice to have but less necessary since you can do that directly with placement and we have rbac support in placement now too (which was a previous reason this should go through nova - for rbac)
17:10:06 mriedem so the only sticking point on the nova spec is deciding if nova should do that mirroring / proxy orchestration work
17:10:25 mriedem clearly that isn't going to happen in stein though
17:10:28 mriedem bbiab
17:12:41 efried_mtg sean-k-mooney: not sure if you knew about this, but when resubmitting a series, git-review normally re-topics the whole series to match the top patch. You can make it not do that - i.e. leave the topic unchanged (or empty if it's the first time you're uploading it) by using the -T flag.
17:12:50 melwitt mriedem_afk: thanks, I'll make some notes about it on the blueprint tracking etherpad
17:13:31 sean-k-mooney efried_mtg: ya it has bitten me in the past
17:13:56 melwitt I've had a hard time following what was going on there. didn't realize the only thing left was mirroring, and I agree I'm not sure whether we should
17:14:32 sean-k-mooney efried_mtg: generally its does what i want as if i am working on a patch serise its all for the same bug/blueprint but it can be annoying
17:15:31 sean-k-mooney efried_mtg: i just like the fact i can "git checkout -b whatever" and then "git revew -f" and have the topic set correctly to "whatever"
17:16:42 leakypipes melwitt: I'll abandon that spec.
17:18:14 sean-k-mooney leakypipes: you spec for mirroring nova aggrages as placement aggrates was complete in rocky rigt? seperate form the allcoation ratio stuff
17:18:16 melwitt leakypipes: k. I was only asking because I'm trying to round up things we identified as priority items and that one I had trouble parsing what the second spec was about
17:18:32 melwitt *priority items at the ptg
17:19:41 melwitt sean-k-mooney: mirroring aggregates was a different thing yeah, and is already in nova
17:19:47 leakypipes sean-k-mooney: yes.
17:20:27 leakypipes melwitt: np
17:20:56 sean-k-mooney cool so in thery you coudl write a scipt/tool to find all the RPs with a specific resouce in an aggrate and set the allocation ratio in the inventory relitivly simply if you wanted too
17:26:51 melwitt yeah, we talked about adding a command to osc-placement CLI to help with that. we should do that. maybe I'll try to do it if I can get my other stuff done
17:39:59 openstackgerrit Kevin Rasmussen proposed openstack/nova master: created AggregateSubnetAvailabilityFilter https://review.openstack.org/633178
17:40:30 openstackgerrit Kevin Rasmussen proposed openstack/nova master: created AggregateSubnetAvailabilityFilter https://review.openstack.org/633178
18:17:05 artom We can just disable the Keystone middleware and run without authentication, right?
18:17:26 sean-k-mooney artom: you can disable auth yes
18:17:30 artom (Asking for a performance thing downstream, suspecting Keystone is the culprit, want to propose testing without it)
18:21:09 sean-k-mooney i guessed. let me see if i can find the config
18:21:33 artom sean-k-mooney, too late, email went out. I'll blame you if people pick me up on it :D
18:22:37 cdent artom, sean-k-mooney: I'm not positive but I think you have to choose a different auth strategy (noauth2) and still set x-auth-token headers so that policy checks still have something to chew on. If that can be avoided too, I'd love to hear about it.
18:23:01 sean-k-mooney artom: i think you set this https://docs.openstack.org/nova/latest/configuration/config.html#keystone_authtoken.auth_type
18:23:12 artom cdent, right, but that avoids the authentication calls to the Keystone API, right?
18:23:19 cdent yes
18:23:30 artom OK, because that's what I care about
18:23:59 cdent I do that noauth2 stuff all the time with placement and it seems to work fine with a 'x-auth-token: amdin' header
18:24:00 sean-k-mooney cdent: ya our functional test use noauth2 i think when they spin up apis
18:24:18 cdent except I spell admin correctly...
18:24:20 cdent sigh
18:24:39 sean-k-mooney just alias it it will be fine
18:24:52 cdent :)
18:24:58 artom Am Din. You be?
18:25:09 cdent Me be me
18:25:10 sean-k-mooney i have always beeen temeted to make "suod" and alais of "sudo"
18:25:31 artom And "temeted" an alias of "tempted", and "alais" of "alias"
18:25:33 artom ;)
18:25:46 artom cdent, but will the FCC let you be?
18:26:22 sean-k-mooney hehe the problem is i mispell things inconsitently
18:26:35 cdent artom++

Earlier   Later