| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-08-02 | |||
| 14:04:21 | mordred | (which I left some notes on as comments in the efried change) | |
| 14:04:30 | sdague_ | I just want to be able to run without that | |
| 14:05:01 | sdague_ | because, to the best of my knowledge every glance action happens within a user context in the current nova flows | |
| 14:05:26 | mordred | yes. we should make sure that a) the admin can still provide api_servers and all works as before b) the admin can provide nothing and a proper setup will work c) the admin can provide override values for the adapter parameters and those will affect what discovery finds correctly | |
| 14:05:39 | sdague_ | especially because screwing up 10 service auth config variables is actually *very* common | |
| 14:05:52 | mordred | basically everyone gets them all wrong :) | |
| 14:05:58 | sdague_ | we get a regular trickle of bugs in which are people having done that in neutron all the time | |
| 14:06:08 | sdague_ | i.e. the neutron part of the nova config | |
| 14:06:13 | sdague_ | then 500s all over the place | |
| 14:06:19 | mordred | efried: I'll take another pass through your patch with the above in mind - I may not have tracked the auth flow completely the last time | |
| 14:06:49 | efried | It's worth pointing out that one of my motivations in this change set was to be as non-intrusive as possible to the code. E.g. in glance, isolate the change to where it finds the service URL, as opposed to doing a far-reaching rework to find a good auth to use, etc. | |
| 14:06:50 | mordred | sdague_: incidentally - morgan had a question the other day which I don't think is terribly tractable at the moment... | |
| 14:06:51 | larivee | /join #openstack-i18n | |
| 14:07:00 | sdague_ | the reality is the only service I think Nova talks to outside of a user context is neutron | |
| 14:07:20 | sdague_ | because it does background processing in a periodic to catch certain changes | |
| 14:07:28 | mordred | sdague_: but currently the config sections are glance/cinder/ironic - but we've got this whole "use service-types" thing going on | |
| 14:07:37 | sdague_ | mordred: sure | |
| 14:07:52 | mordred | sdague_: maybe for the S cycle we should do a transition from glance to image - but certainly not for right now | |
| 14:07:54 | sdague_ | I was just thrown with the idea that 10 lines of config needed to be added here | |
| 14:08:00 | mordred | yah | |
| 14:08:06 | sdague_ | mordred: yeh, that's low priority on the naming | |
| 14:08:10 | sdague_ | just nice to have | |
| 14:08:11 | mordred | I mean - there are a bunch of lines of potential config that need to be possible to set | |
| 14:08:27 | mordred | but I agree, we need to make sure things work without them being set too | |
| 14:08:44 | sdague_ | I just want to get us down to super minimal configs, because every line of config we can pull out of manditory setup docs makes it easier to get right | |
| 14:08:50 | mordred | yup | |
| 14:08:54 | smatzek | dansmith, thanks, so I can set singleconductor and it should work. The comment block says this option will be removed in the future. I assume the affinity filters will be fixed to not need it before that's removed? | |
| 14:08:55 | mordred | 100% agree | |
| 14:09:20 | mordred | and that's actually why we made some of the ksa changes - the ability to specify version ranges and lists of intefaces, for instance ... | |
| 14:09:28 | dansmith | smatzek: we have several things that we have to fix before we can remove that thing, yeah | |
| 14:09:35 | sdague_ | mordred: yep | |
| 14:09:43 | efried | sdague_ So in this impl, a) api_servers is still supported, and takes precedence; b) if you set endpoint_override, you *shouldn't* need the other fields (I should edit https://review.openstack.org/#/c/489671/2/lib/nova to verify that) - that should be a straight swap. | |
| 14:09:48 | mordred | is so that nova can say "I can handle v1-v2 of glance and prefer internal interface then public interface" | |
| 14:10:14 | mordred | efried: we should supply defaults for adapter values so that it works ifyou don't set endpoint_override too | |
| 14:10:22 | sdague_ | mordred: I'm all for this effort, just wanted to make sure I can land - https://review.openstack.org/#/c/490031/ | |
| 14:10:33 | sdague_ | I legit want to land that as default devstack | |
| 14:10:43 | mordred | sdague_: yes - what I'm saying is that we added a bunch of things to ksa so that you can | |
| 14:10:47 | sdague_ | cool | |
| 14:10:56 | mordred | sdague_: because otherwise it's not possible to actually express a good enough default value | |
| 14:11:00 | sdague_ | ok, great | |
| 14:11:13 | sdague_ | I might have misunderstood efried | |
| 14:11:19 | efried | sdague_ That (getting glance auth from... somewhere else) was going to be a subsequent step in the process. | |
| 14:11:43 | mordred | efried: we should be able to use what's there - it's already getting auth from somewhere else ... OH - I think I get whatyou're saying | |
| 14:11:47 | efried | But it's the reason I coded the util to take an auth param. | |
| 14:11:55 | mordred | efried: the util function doesn't currently have 'pass auth in' plumbed in | |
| 14:11:59 | efried | mordred Yeah, there's no auth in that method | |
| 14:12:23 | mordred | ok. I grok the whole end to end | |
| 14:12:24 | efried | Exactly. And adding it in would have required some pretty far-reaching changes, which I wanted to put off for a followup. | |
| 14:12:42 | efried | And focus this change on setting up and proving the viability of the util itself. | |
| 14:13:04 | efried | Mm, I should clarify that with a TODO in the code. | |
| 14:15:05 | mriedem1 | dansmith: smatzek: ack on https://bugs.launchpad.net/devstack/+bug/1708171 | |
| 14:15:05 | openstack | Launchpad bug 1708171 in devstack "Nova Affinity filters no longer work" [Undecided,New] | |
| 14:15:44 | mordred | efried: yes - I think a TODO will help - I have a couple of more comments - and also I see why it's complex to pass in the auth | |
| 14:15:47 | mriedem1 | fwiw the affinity filter tests in tempest seem fine with the superconductor change | |
| 14:15:55 | mriedem1 | maybe trove tests things differently | |
| 14:16:52 | sdague_ | mriedem1: so you think that the wait for nova patch is needed back on ocata as well | |
| 14:16:54 | mordred | sdague_: (for context, get_api_servers in nova/image/glance.py doesn't have the auth context atm since it's currently just dealing with config data - so efried is going to have to plumb that through in nova/image/glance.py | |
| 14:17:04 | efried | mordred Roger, will respin today. Also ( sdague_ ) updated https://review.openstack.org/#/c/489671/ to see if *just* setting endpoint_override will work. I actually suspect it won't - I think we'll fail to build the Adapter. | |
| 14:17:29 | smatzek | does nova have a negative test to ensure anti-affinity fails? (deploying 2 instances in 1 server group when we have 1 host) | |
| 14:17:38 | mordred | efried: I agree with you - we will fail to do that - but I think that patch will be a good testcase of when the things have been plumbed all the way through | |
| 14:17:41 | mriedem1 | smatzek: maybe in functional | |
| 14:17:52 | mriedem1 | smatzek: the affinity filter test in tempest is here http://logs.openstack.org/32/489632/1/check/gate-tempest-dsvm-neutron-multinode-full-ubuntu-xenial-nv/ae3cb6f/console.html#_2017-08-01_15_57_46_709238 | |
| 14:18:01 | dansmith | smatzek: is that what you're doing and failing? | |
| 14:18:02 | mriedem1 | i'm working on an anti-affinity multi-node test in tempest | |
| 14:19:20 | smatzek | anti-affinity tests with 2 instances, 1 servergroup, 1 host, and verifying that the 2nd instance goes to error. The gate is failing because the second server goes to active. | |
| 14:19:23 | mriedem1 | sdague: the wait for nova patch isn't working on all CIs | |
| 14:20:07 | dansmith | smatzek: ack | |
| 14:20:45 | dansmith | mriedem: I really thought that a test like that requires the send-instance-info stuff in order to actually work | |
| 14:20:49 | mriedem | smatzek: has anyone posted a patch for trove? | |
| 14:20:58 | dansmith | I forget why all, something about when it refreshes the host list | |
| 14:21:13 | sdague_ | mriedem: xenserver looks like the last one right? | |
| 14:21:22 | sdague_ | I just pushed a patch to skip there | |
| 14:21:23 | mriedem | dansmith: and i thought the scheduler / host manager would just pull the instance info if it wasn't getting updates | |
| 14:21:37 | mriedem | sdague_: who knows how many others don't run on devstack changes which would be broken | |
| 14:21:42 | smatzek | mriedem, no, I've been the only one digging into this gate failure and finally narrowed it down to that cells change yesterday late afternoon | |
| 14:21:43 | dansmith | mriedem: but not fast enough or something | |
| 14:22:17 | dansmith | smatzek: you have what you need now to set that conductor mode as a workaround though right? | |
| 14:22:19 | mriedem | smatzek: is the trove job that's failing controlled through the trove repo? | |
| 14:22:21 | mriedem | or something else? | |
| 14:23:49 | mriedem | nvm i see it | |
| 14:23:52 | mriedem | i can push a patch in a minute | |
| 14:23:53 | smatzek | I'm relatively new to Trove in the Trove channel have asked amrith the proper place to set the CELLSV2_SETUP=singleconductor env var. The trove job is controlled through the trove repo and its own devstack plugin.sh | |
| 14:24:02 | mriedem | yeah i'm on it | |
| 14:24:49 | smatzek | Unfortunately I'm going to be afk for the rest of the day starting in a bit. I'm going to take a stab and putting up a review that sets CELLSV2_SETUP where I think it needs to go and we'll see if the gate passes. | |
| 14:24:50 | sdague_ | mriedem: it is possible, that's why I sent an email. | |
| 14:25:08 | sdague_ | the xenserver folks popped up with their concerns | |
| 14:25:31 | dansmith | smatzek: sounds like mriedem is doing that | |
| 14:25:57 | gibi | mriedem: just for your info I pushed functional test for resize to same host https://review.openstack.org/#/c/489973/ | |
| 14:26:19 | smatzek | dansmith, mriedem thanks | |
| 14:27:04 | cdent | gibi++ | |
| 14:27:09 | dansmith | gibi: does that pass with the normal assertions on top of jaypipesjuryduty's current set? | |
| 14:27:29 | dansmith | gibi: I found it super useful to make sure the other one passed on top, then rebase on master and comment out the assertions that failed | |
| 14:27:42 | mriedem | gibi: yup i saw it, thanks | |
| 14:27:53 | mriedem | jay's on jury duty?! | |
| 14:28:03 | dansmith | again | |
| 14:28:09 | dansmith | third time in four years or some such | |
| 14:28:19 | mriedem | he is the youngest citizen in the county | |
| 14:28:30 | dansmith | might be why they want him | |
| 14:29:16 | cdent | dansmith: we don’t have a strategy for accounting for the allocations on same host yet, do we? | |
| 14:29:21 | gibi | dansmith: I haven't tried yet and I think it won't pass there | |