| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-08-02 | |||
| 14:00:50 | efried | sdague_ And the discovery process uses a Session to talk to the discovery endpoint to grab the version document. | |
| 14:01:23 | efried | sdague_ And the Adapter business is how we tell it what combo of service type, interface, etc. we're looking for. | |
| 14:01:23 | sdague_ | ok, but that all happens in a user context right? | |
| 14:01:32 | sdague_ | can't we first order piggy back on that? | |
| 14:01:36 | efried | mordred may be able to explain it better. | |
| 14:01:38 | openstack | bug 1708171 in devstack "Nova Affinity filters no longer work" [Undecided,New] https://launchpad.net/bugs/1708171 | |
| 14:01:38 | smatzek | dansmith, can you take a look at bug 1708171 and give me some pointers as you authored the transport_url change in devstack ^ ? | |
| 14:02:10 | mordred | efried, sdague_: reading scrollback | |
| 14:03:19 | efried | sdague_ The user context may (or may not) have an appropriate auth in it. The util is set up to take that if it's present. | |
| 14:03:22 | sdague_ | I'm all fine with a glance service user to get us past snapshot timeouts, but it seems weird to have the net change be here. "Hey, great feature, remove this one config line and add these 10, including passwords, to every system" feels less compelling | |
| 14:03:37 | dansmith | smatzek: yep, known issue, you'll need to disable the multi-cell layout in your job if you need that | |
| 14:03:38 | dansmith | mriedem: ^ | |
| 14:03:39 | sdague_ | efried: doesn't have appropriate auth to find glance? | |
| 14:03:45 | mordred | sdague_, efried: so - I think we can totally use the existing auth | |
| 14:04:05 | efried | sdague_ I don't disagree the switchover feels burdensome for the glance case. | |
| 14:04:09 | mordred | the thing we might need that's new is adapter params so an admin can *override* defaults | |
| 14:04:20 | dansmith | smatzek: https://review.openstack.org/#/c/487478/ | |
| 14:04:20 | sdague_ | mordred: I'm fine with that | |
| 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 | openstack | Launchpad bug 1708171 in devstack "Nova Affinity filters no longer work" [Undecided,New] | |
| 14:15:05 | mriedem1 | dansmith: smatzek: ack on https://bugs.launchpad.net/devstack/+bug/1708171 | |
| 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 | |