| diltram | nmagnezi: good to know | 00:00 |
|---|---|---|
| diltram | rm_work: for me even after merging into octavia it didn't worked :P | 00:01 |
| rm_work | hmm | 00:01 |
| rm_work | diltram: wait, so that patch *isn't* working? | 00:02 |
| diltram | it should work | 00:02 |
| diltram | I don't know why it's not working | 00:02 |
| rm_work | I am wondering if maybe those patches need to actually merge first | 00:03 |
| rm_work | I think i ran into this before | 00:03 |
| rm_work | when I was redoing the barbican gate | 00:03 |
| rm_work | depending on them might not actually work, because zuul doesn't allow changes to project-config to actually RUN in the gate | 00:03 |
| rm_work | or something like that | 00:03 |
| nmagnezi | johnsom, hey, would love to know what you think about https://review.openstack.org/#/c/415681/ (a sub-patch for the amphora agent work) | 00:04 |
| johnsom | Ok, I will take a look | 00:04 |
| nmagnezi | johnsom, thanks :-) | 00:05 |
| nmagnezi | night all | 00:05 |
| *** nmagnezi has quit IRC | 00:05 | |
| diltram | rm_work: but how often zuul refreshes configs | 00:06 |
| diltram | because in octavia we have this config merged and it's not working | 00:06 |
| rm_work | ah.... | 00:08 |
| rm_work | it should be immediate | 00:08 |
| rm_work | or ... hmm maybe not | 00:08 |
| rm_work | I think it might be ~1h now that I think back | 00:08 |
| diltram | hahaha :P | 00:08 |
| rm_work | man, i forgot basically everything being out for three months >_< | 00:08 |
| rm_work | johnsom / diltram: newly generated config by devstack, has the same duplicate entries | 00:13 |
| rm_work | per http://paste.openstack.org/show/593820/ | 00:13 |
| rm_work | diltram: do you know which ones it actually NEEDS/uses? | 00:14 |
| diltram | rm_work: it's not duplicated | 00:14 |
| rm_work | does it use both?! | 00:14 |
| diltram | yep | 00:14 |
| rm_work | uhh | 00:14 |
| rm_work | but they have a different setting for signing_dir (or are they both essentially default)? | 00:14 |
| rm_work | and is "auth_uri" actually used? | 00:15 |
| diltram | this config is generated using devstack method | 00:15 |
| diltram | to generate it | 00:15 |
| rm_work | well | 00:15 |
| rm_work | it's from plugin.sh right? | 00:15 |
| diltram | they have different signing_dirs because they use different accounts | 00:15 |
| diltram | yep | 00:15 |
| johnsom | Isn't one for authenticating API users and the other for our client uses? | 00:15 |
| diltram | yes | 00:16 |
| rm_work | augh ok | 00:16 |
| rm_work | so one is supposed to be ... | 00:16 |
| rm_work | admin, and the other isn't? | 00:16 |
| diltram | service_auth is used to authenticate octavia as admin in OpenStack to perform operations like create vm | 00:16 |
| diltram | and keystone_auth is used to verify user tokens - service account | 00:17 |
| *** yamamoto has joined #openstack-lbaas | 00:17 | |
| diltram | we can probably remove some options from service_auth section but devstack doesn't provide any way to configure properly this | 00:17 |
| rm_work | hmm | 00:18 |
| diltram | I was thinking about writing it based on this keystone_authtoken but didn't had time for that | 00:18 |
| rm_work | yeah so I guess I am not sure why they ever need to be different, in reality | 00:19 |
| diltram | rm_work: by mistake I rechecked your patchset | 00:20 |
| rm_work | one account who is nova and neutron admin, and one account who is keystone admin | 00:20 |
| rm_work | ? | 00:20 |
| *** fnaval has joined #openstack-lbaas | 00:20 | |
| rm_work | ah | 00:20 |
| rm_work | doesn't matter prolly | 00:20 |
| diltram | so in OpenStack you have a service account | 00:20 |
| diltram | accounts like nova, neutron, octavia | 00:20 |
| diltram | they are allowed to verify that token send with request is valid, extract data about this account etc | 00:21 |
| diltram | and there are normal accounts like demo, admin, rm_work :P | 00:21 |
| rm_work | hmm | 00:21 |
| diltram | this accounts has some projects assigned, some roles like admin, user | 00:21 |
| diltram | and they can obtain token which they will use to communicate with project like octavia which will use it's service account to verify that token | 00:22 |
| rm_work | err, both need to have admin, don't they? | 00:22 |
| diltram | yep | 00:22 |
| rm_work | so what is the point of them being different accounts | 00:22 |
| diltram | I spend a month on understanding how everything is working, how it's interacting with each other and how to configure that stuff :P | 00:22 |
| diltram | hahaha | 00:22 |
| rm_work | one is just doing keystone token validation, and the other is doing all the requests | 00:22 |
| diltram | I just wrote all how it's working :P | 00:23 |
| rm_work | lol | 00:23 |
| diltram | yep | 00:23 |
| rm_work | i don't understand why i'd bother to use two accounts | 00:23 |
| rm_work | in my sample deployment both config sections are just exactly the same... and works great :) | 00:23 |
| rm_work | and seems simpler | 00:24 |
| rm_work | maybe it is a security concern? | 00:24 |
| diltram | because you're not using keystone in octavia :P | 00:24 |
| diltram | enable keystone without configuring this | 00:24 |
| rm_work | ah, i thought your keystone patch merged | 00:24 |
| diltram | yes, it's merged because of this there are two sections | 00:24 |
| diltram | :P | 00:24 |
| rm_work | right, and auth_strategy is keystone | 00:25 |
| diltram | but remember that by default octavia is not using keystone | 00:25 |
| diltram | nope | 00:25 |
| diltram | auth_strategy is None | 00:25 |
| rm_work | hmm | 00:25 |
| diltram | because it breaks neutron-lbaas | 00:25 |
| diltram | because neutron-lbaas is not forwarding tokens to octavia | 00:26 |
| diltram | so if you're using nlbaas you need to disable octavia | 00:26 |
| diltram | after dropping nlbaas you can enable auth_strategy :P | 00:26 |
| rm_work | oh, yeah i don't have n-lbaas | 00:27 |
| rm_work | and i set auth_strategy=keystone in my config | 00:27 |
| diltram | and how your octavia.conf looks like? | 00:28 |
| rm_work | both sections for keystone look identical | 00:28 |
| rm_work | other than one has an extra auth_uri | 00:29 |
| rm_work | I can censor the password and pastebin I guess | 00:29 |
| diltram | would be great :) | 00:29 |
| diltram | ehhh, this project-config is still not refreshed | 00:30 |
| *** eezhova has quit IRC | 00:31 | |
| johnsom | It merged? | 00:31 |
| johnsom | Yeah, ok. It does sometimes take an hour | 00:33 |
| rm_work | diltram: http://paste.openstack.org/show/593824/ | 00:35 |
| rm_work | I think I don't need insecure=True there.... | 00:36 |
| rm_work | it seems to do keystone auth correctly | 00:37 |
| *** fnaval has quit IRC | 00:38 | |
| *** fnaval has joined #openstack-lbaas | 00:39 | |
| rm_work | to be clear, this all *works great* | 00:39 |
| rm_work | my point is that I don't understand why you'd need those to be different accounts | 00:39 |
| rm_work | is it a security issue? | 00:39 |
| rm_work | diltram: ah I guess it's about going-home-time for you | 00:42 |
| johnsom | I think it is a good idea. For example, the API processes should only need the "authenticate this" level account, where the backend processes (cw, hm, maybe hk) would need the account with credentials to crate things, etc. | 00:42 |
| rm_work | ok, so yeah, security | 00:42 |
| johnsom | So, if you isolate your API processes, it's config would only need the "authenticate this" account and not the config for the "make me this" | 00:42 |
| johnsom | Assuming that is how we have it setup... ha. Vacation brain | 00:43 |
| rm_work | I think it is | 00:43 |
| rm_work | I mean, I believe that will happen | 00:43 |
| rm_work | just means I have to track twice as many accounts >_< | 00:43 |
| diltram | so yest it is security but also you not suppose to be able to create load balancer using service account | 00:44 |
| rm_work | ? | 00:44 |
| diltram | or maybe you have some magic in keystone | 00:44 |
| diltram | service account - like octavia - is not admin account | 00:44 |
| rm_work | I'd POST to /loadbalancers as a user like rm_work | 00:44 |
| rm_work | it's admin on SOMETHING | 00:45 |
| rm_work | we use it to do admin operations like network plugging, no? | 00:45 |
| diltram | yes but there should be used octavia (service user) to verify "rm_work" user credentials | 00:45 |
| rm_work | i mean, one account needs keystone admin to do token validation | 00:45 |
| rm_work | the other account needs nova/neutron admin to do plugging and such | 00:45 |
| diltram | no, service account is used to keystone token validation | 00:45 |
| rm_work | they both aren't *normal* user accounts | 00:45 |
| rm_work | err | 00:46 |
| diltram | and only service account should be able to do this | 00:46 |
| rm_work | so in the devstack config, "admin" is an admin account, no? | 00:46 |
| rm_work | and "octavia" is a service account which has admin | 00:46 |
| diltram | yes but admin account which has admin role is a normal account | 00:46 |
| diltram | not service | 00:46 |
| rm_work | err | 00:46 |
| rm_work | but we use it for [service_auth] | 00:46 |
| rm_work | i wouldn't put `rm_work` as the service_auth account in octavia config <_< | 00:47 |
| diltram | in service_auth we're using account which admin role in some project | 00:47 |
| diltram | so in devstack it's admin user | 00:47 |
| diltram | because admin has admin role in project admin | 00:47 |
| rm_work | it's supposed to be a service account | 00:47 |
| rm_work | yeah but doesn't it also need admin role in neutron and nova? | 00:47 |
| diltram | this is why we're using admin | 00:48 |
| rm_work | ... | 00:48 |
| rm_work | ok so in a production deployment | 00:48 |
| diltram | because admin is admin in nova, neutron and all projects | 00:48 |
| rm_work | we'd have to create `octavia1` and `octavia2` | 00:48 |
| rm_work | octavia1 would have admin in keystone | 00:48 |
| rm_work | and octavia2 would have admin in nova/neutron? | 00:49 |
| rm_work | [service_auth] would use octavia2 | 00:49 |
| diltram | there is keystone admin | 00:49 |
| diltram | there is no* | 00:49 |
| rm_work | [keystone_authtoken] would use octavia1 | 00:49 |
| rm_work | err | 00:49 |
| rm_work | doesn't token auth need to be done via the keystone admin endpoint? | 00:50 |
| rm_work | i thought that wasn't a user-level operation | 00:50 |
| diltram | no | 00:51 |
| rm_work | so wait, using my regular user account `rm_work`, I can validate someone's token? | 00:51 |
| rm_work | using the normal keystone endpoint? | 00:51 |
| *** fnaval has quit IRC | 00:51 | |
| * rm_work looks up the API again | 00:51 | |
| diltram | no | 00:52 |
| rm_work | API says the auth token you pass has to be an admin token | 00:52 |
| *** fnaval has joined #openstack-lbaas | 00:52 | |
| rm_work | to do token validation on a subject token | 00:52 |
| rm_work | http://developer.openstack.org/api-ref/identity/v3/index.html?expanded=validate-and-show-information-for-token-detail | 00:53 |
| diltram | this is why you need to have keystone_authtoken which is configured to use service account | 00:53 |
| diltram | like octavia | 00:53 |
| rm_work | .... the octavia service account, which has keystone admin? | 00:53 |
| diltram | this service accounts are used just to verify tokens | 00:53 |
| diltram | if you say so | 00:54 |
| diltram | it's just service account | 00:54 |
| rm_work | Doesn't the API doc say so? | 00:54 |
| rm_work | X-Auth-TokenheaderstringA valid authentication token for an administrative user. | 00:54 |
| diltram | this acc type tells that it may be used to authenticate tokens | 00:54 |
| rm_work | err | 00:55 |
| rm_work | what | 00:56 |
| diltram | https://github.com/openstack/keystonemiddleware/blob/master/keystonemiddleware/auth_token/__init__.py | 00:56 |
| rm_work | So you're saying that with my account, I can validate someone else's token, as long as I'm admin on my OWN account?! | 00:57 |
| rm_work | that seems like a kind of nonsensical restriction | 00:57 |
| rm_work | but maybe it's because I'm used to how RAX sets things up | 00:58 |
| rm_work | literally every user has admin on their own account | 00:58 |
| *** eezhova has joined #openstack-lbaas | 00:59 | |
| rm_work | so backing up | 00:59 |
| rm_work | [keystone_authtoken] user needs to have at least the role "keystone:admin" | 01:00 |
| rm_work | right? | 01:00 |
| rm_work | err | 01:00 |
| rm_work | is it "identity:admin"? | 01:00 |
| diltram | based on my knowledge no | 01:00 |
| diltram | it must be service account | 01:00 |
| diltram | so one of | 01:01 |
| diltram | nova, neutron, octavia, etc | 01:01 |
| rm_work | what defines something as a "service account"? | 01:01 |
| *** eezhova has quit IRC | 01:01 | |
| rm_work | there's no "service_account = True" flag that I know of | 01:01 |
| diltram | https://github.com/openstack/octavia/blob/master/devstack/plugin.sh#L48 | 01:01 |
| rm_work | ok but what does that do >_> | 01:01 |
| rm_work | looking.... | 01:02 |
| rm_work | https://github.com/openstack-dev/devstack/blob/master/lib/keystone#L451-L458 | 01:03 |
| rm_work | https://github.com/openstack-dev/devstack/blob/master/functions-common#L860-L884 | 01:04 |
| rm_work | it's just adding specific roles | 01:04 |
| *** yamamoto has quit IRC | 01:04 | |
| rm_work | so it adds the role "service" | 01:05 |
| rm_work | for the project | 01:05 |
| rm_work | to a regular user | 01:05 |
| diltram | it's not a regular user | 01:06 |
| diltram | but this is how openstack divides "services" from normal projects and users | 01:06 |
| rm_work | until it added the service role to it, the user was the same as any other regular user | 01:07 |
| diltram | this service project is magical in keystone | 01:07 |
| *** fnaval has quit IRC | 01:07 | |
| rm_work | hmm ok | 01:07 |
| diltram | yes, they use same capabilities | 01:07 |
| diltram | but it's magical internal openstack account | 01:07 |
| rm_work | I think this diverges a lot from how RAX does their auth stuff | 01:07 |
| rm_work | which is what I'm used to | 01:08 |
| diltram | because belongs to service project and has service role | 01:08 |
| rm_work | going to have to try to forget all of that | 01:08 |
| diltram | yep | 01:08 |
| diltram | RAX is really breaking a lot of stuff in OpenStack | 01:08 |
| rm_work | :3 | 01:09 |
| diltram | they even don't understand how to use keystone endpoints :P | 01:09 |
| diltram | and because of them we need to implement workarounds in Octavia :P | 01:09 |
| johnsom | All I can say is they are not alone is some of these issues.... | 01:10 |
| diltram | I know :P | 01:10 |
| rm_work | ok so | 01:11 |
| rm_work | [keystone_authtoken] user needs to be any user with service role added, no admin roles | 01:11 |
| rm_work | [service_auth] needs to have nova:admin and neutron:admin | 01:12 |
| rm_work | is that right? | 01:12 |
| johnsom | Sounds right to me | 01:13 |
| diltram | yep | 01:13 |
| rm_work | ok | 01:13 |
| diltram | and based on this you can create "loadbalancers" user | 01:14 |
| diltram | which will be nova:admin, neutron:admin | 01:14 |
| diltram | and noone will know the password to this account | 01:14 |
| diltram | and it will be used to make Octavia working | 01:14 |
| rm_work | k | 01:14 |
| diltram | and normal admin account will be available for admins | 01:14 |
| xgerman | So the two users were not remnants of using a different account for barbican? | 01:14 |
| diltram | and they will not mess anything in octavia | 01:14 |
| rm_work | i might name them like ... octavia_tokens and octavia_service | 01:15 |
| diltram | yep | 01:15 |
| diltram | but standard is to use project name as service account | 01:15 |
| diltram | so nova uses nova | 01:15 |
| rm_work | i don't think we do that here | 01:15 |
| diltram | neutron uses neutron user | 01:15 |
| diltram | etc | 01:15 |
| diltram | yes we do | 01:16 |
| xgerman | Octavia | 01:16 |
| diltram | we're using octavia as service account user | 01:16 |
| rm_work | in fact I think I get a randomly generated string of characters+numbers as the account names I get anyway <_< | 01:16 |
| rm_work | here == godaddy | 01:16 |
| diltram | you need to take a look into how they generate that accounts | 01:16 |
| xgerman | Blame jharlow | 01:16 |
| diltram | maybe to obfuscate them a little they randomly generate names | 01:16 |
| rm_work | lol yeah | 01:17 |
| rm_work | probably | 01:17 |
| diltram | check in nova.conf what is specified | 01:17 |
| rm_work | i assume it's the same | 01:17 |
| rm_work | yeah, random | 01:18 |
| rm_work | woo >_> | 01:18 |
| rm_work | so I just have to remember two accounts | 01:18 |
| rm_work | remember / paste into config management db | 01:18 |
| diltram | yep | 01:19 |
| rm_work | hokay | 01:19 |
| diltram | ok, I'm out | 01:27 |
| diltram | CU people | 01:27 |
| *** mixos has joined #openstack-lbaas | 01:41 | |
| openstackgerrit | JingLiu proposed openstack/octavia: Set access_policy for messaging's dispatcher https://review.openstack.org/416394 | 01:48 |
| *** yamamoto has joined #openstack-lbaas | 02:02 | |
| *** gongysh has joined #openstack-lbaas | 02:03 | |
| *** kevo has quit IRC | 02:06 | |
| *** bana_k has quit IRC | 02:12 | |
| *** ducttape_ has quit IRC | 03:04 | |
| *** ducttape_ has joined #openstack-lbaas | 03:05 | |
| *** ducttape_ has quit IRC | 03:09 | |
| *** ankur-gupta-f1 has left #openstack-lbaas | 03:55 | |
| *** links has joined #openstack-lbaas | 03:56 | |
| *** ducttape_ has joined #openstack-lbaas | 04:02 | |
| *** ducttape_ has quit IRC | 04:25 | |
| *** ducttape_ has joined #openstack-lbaas | 04:26 | |
| *** ducttape_ has quit IRC | 04:26 | |
| *** ducttape_ has joined #openstack-lbaas | 04:26 | |
| *** mixos has quit IRC | 04:36 | |
| *** mixos has joined #openstack-lbaas | 05:03 | |
| *** reedip has joined #openstack-lbaas | 05:05 | |
| *** csomerville has quit IRC | 05:43 | |
| *** cody-somerville has joined #openstack-lbaas | 05:43 | |
| *** cody-somerville has quit IRC | 05:43 | |
| *** cody-somerville has joined #openstack-lbaas | 05:43 | |
| *** amotoki has joined #openstack-lbaas | 06:22 | |
| *** gcheresh_ has joined #openstack-lbaas | 06:22 | |
| *** kobis has joined #openstack-lbaas | 06:38 | |
| BlackDex | Hello there, is there someone who can please help me with fixing lbaas ? | 06:45 |
| BlackDex | i get the following messages | 06:45 |
| BlackDex | 2017-01-03 19:21:16.310 16456 INFO neutron.common.config [-] Logging enabled! | 06:45 |
| BlackDex | 2017-01-03 19:21:16.380 16456 INFO neutron.common.config [-] /usr/bin/neutron-lbaasv2-agent version 9.0.0 | 06:45 |
| BlackDex | 2017-01-03 19:21:16.380 16456 DEBUG neutron.common.config [-] command line: /usr/bin/neutron-lbaasv2-agent --config-file=/etc/neutron/neutron.conf --config-file=/etc/neutron/lbaas_agent.ini --log-file=/var/log/neutron/neutron-lbaasv2-agent.log | 06:45 |
| BlackDex | setup_logging /usr/lib/python2.7/dist-packages/neutron/common/config.py:107 | 06:45 |
| BlackDex | 2017-01-03 19:21:16.381 16456 WARNING stevedore.named [req-78b2a76b-c913-4cb4-9475-ca1c5858676f - - - - -] Could not load | 06:45 |
| BlackDex | neutron_lbaas.drivers.haproxy.namespace_driver.HaproxyNSDriver | 06:45 |
| BlackDex | 2017-01-03 19:21:16.961 16456 WARNING stevedore.named [req-78b2a76b-c913-4cb4-9475-ca1c5858676f - - - - -] Could not load | 06:45 |
| BlackDex | neutron.agent.linux.interface.OVSInterfaceDriver | 06:46 |
| *** bana_k has joined #openstack-lbaas | 06:46 | |
| *** pcaruana has joined #openstack-lbaas | 06:51 | |
| *** rcernin has joined #openstack-lbaas | 07:15 | |
| *** tesseract has joined #openstack-lbaas | 07:18 | |
| *** gongysh_ has joined #openstack-lbaas | 07:59 | |
| *** gongysh has quit IRC | 08:00 | |
| *** gongysh_ has quit IRC | 08:37 | |
| *** anilvenkata has joined #openstack-lbaas | 08:45 | |
| openstackgerrit | Jeremy Liu proposed openstack/octavia: Remove MANIFEST.in from repo https://review.openstack.org/416478 | 08:48 |
| openstackgerrit | JingLiu proposed openstack/octavia: Set access_policy for messaging's dispatcher https://review.openstack.org/416394 | 08:49 |
| *** kevo has joined #openstack-lbaas | 08:51 | |
| *** gongysh has joined #openstack-lbaas | 08:51 | |
| *** bana_k has quit IRC | 09:10 | |
| *** kevo has quit IRC | 09:22 | |
| openstackgerrit | Kevin Benton proposed openstack/neutron-lbaas: Fixing the scenario tests on master branch https://review.openstack.org/411257 | 09:23 |
| openstackgerrit | Valleriya Perelman proposed openstack/octavia: ACTIVE-ACTIVE Topology - Distributor image creation https://review.openstack.org/403594 | 09:24 |
| *** anilvenkata has quit IRC | 10:17 | |
| *** Alex_Stef has joined #openstack-lbaas | 10:27 | |
| Alex_Stef | blogan_, ping | 10:28 |
| *** anilvenkata has joined #openstack-lbaas | 10:29 | |
| *** eezhova has joined #openstack-lbaas | 10:33 | |
| *** armax has joined #openstack-lbaas | 10:36 | |
| *** mixos has quit IRC | 10:36 | |
| *** eezhova has quit IRC | 10:39 | |
| *** yamamoto has quit IRC | 10:47 | |
| *** mixos has joined #openstack-lbaas | 10:48 | |
| *** links has quit IRC | 10:57 | |
| openstackgerrit | ZhaoBo proposed openstack/octavia: Add check when plug vrrp port in LB creation https://review.openstack.org/416519 | 11:09 |
| *** links has joined #openstack-lbaas | 11:21 | |
| *** gongysh has quit IRC | 11:21 | |
| *** ducttape_ has quit IRC | 11:25 | |
| *** anilvenkata has quit IRC | 11:32 | |
| *** ducttape_ has joined #openstack-lbaas | 11:36 | |
| *** yamamoto has joined #openstack-lbaas | 11:40 | |
| openstackgerrit | Abed Abu dbai proposed openstack/octavia: ACTIVE-ACTIVE Topology: Initial Distributor Noop Driver https://review.openstack.org/313006 | 11:44 |
| openstackgerrit | Abed Abu dbai proposed openstack/octavia: ACTIVE-ACTIVE Topology: OVS-based Distributor Driver https://review.openstack.org/317629 | 11:44 |
| *** yamamoto has quit IRC | 11:46 | |
| *** anilvenkata has joined #openstack-lbaas | 11:46 | |
| *** yamamoto has joined #openstack-lbaas | 11:47 | |
| *** yamamoto has quit IRC | 11:51 | |
| *** nmagnezi has joined #openstack-lbaas | 11:53 | |
| *** ducttape_ has quit IRC | 11:54 | |
| *** nmagnezi has quit IRC | 12:02 | |
| *** catintheroof has joined #openstack-lbaas | 12:14 | |
| *** yamamoto has joined #openstack-lbaas | 12:17 | |
| *** openstackgerrit has quit IRC | 12:33 | |
| *** mixos has quit IRC | 12:34 | |
| *** openstackgerrit has joined #openstack-lbaas | 12:39 | |
| openstackgerrit | Abed Abu dbai proposed openstack/octavia: ACTIVE-ACTIVE Topology OVS-based Distributor Backend https://review.openstack.org/320422 | 12:39 |
| openstackgerrit | Abed Abu dbai proposed openstack/octavia: ACTIVE-ACTIVE - controller network tasks https://review.openstack.org/323481 | 12:39 |
| openstackgerrit | Abed Abu dbai proposed openstack/octavia: ACTIVE-ACTIVE - network driver related changes https://review.openstack.org/322494 | 12:39 |
| openstackgerrit | Abed Abu dbai proposed openstack/octavia: ACTIVE-ACTIVE Topology OVS-based Distributor Driver https://review.openstack.org/317629 | 12:39 |
| openstackgerrit | Abed Abu dbai proposed openstack/octavia: ACTIVE-ACTIVE Topology - Distributor image creation https://review.openstack.org/403594 | 12:41 |
| *** yamamoto has quit IRC | 12:42 | |
| openstackgerrit | Abed Abu dbai proposed openstack/octavia: ACTIVE-ACTIVE Topology - Initial Cluster Manager https://review.openstack.org/405238 | 12:44 |
| openstackgerrit | Abed Abu dbai proposed openstack/octavia: ACTIVE-ACTIVE Topology - Distributor related tasks https://review.openstack.org/406951 | 12:46 |
| openstackgerrit | Abed Abu dbai proposed openstack/octavia: ACTIVE-ACTIVE - distributor certificate tasks https://review.openstack.org/406952 | 12:46 |
| openstackgerrit | Adit Sarfaty proposed openstack/neutron-lbaas: [WIP] VMWare driver support for l7 rules & policies https://review.openstack.org/416211 | 12:47 |
| openstackgerrit | Abed Abu dbai proposed openstack/octavia: ACTIVE-ACTIVE Topology - distributor creation flow https://review.openstack.org/406953 | 12:50 |
| openstackgerrit | Abed Abu dbai proposed openstack/octavia: ACTIVE-ACTIVE Topology - Distributor related tasks https://review.openstack.org/406951 | 12:58 |
| openstackgerrit | Abed Abu dbai proposed openstack/octavia: ACTIVE-ACTIVE - distributor certificate tasks https://review.openstack.org/406952 | 12:58 |
| openstackgerrit | Abed Abu dbai proposed openstack/octavia: ACTIVE-ACTIVE Topology - distributor creation flow https://review.openstack.org/406953 | 12:58 |
| openstackgerrit | Abed Abu dbai proposed openstack/octavia: ACTIVE-ACTIVE Topology - create distributor network flow https://review.openstack.org/409763 | 13:03 |
| openstackgerrit | Abed Abu dbai proposed openstack/octavia: Active-Active Topology - register/uregister amphorae tasks https://review.openstack.org/409765 | 13:03 |
| openstackgerrit | Abed Abu dbai proposed openstack/octavia: Active-Active Topology - Cluster DB Tasks https://review.openstack.org/409764 | 13:03 |
| openstackgerrit | Abed Abu dbai proposed openstack/octavia: ACTIVE-ACTIVE Topology - create shared distributor https://review.openstack.org/406954 | 13:03 |
| *** yamamoto has joined #openstack-lbaas | 13:16 | |
| *** yamamoto has quit IRC | 13:28 | |
| *** reedip_ has joined #openstack-lbaas | 13:47 | |
| *** Deep_Thought has joined #openstack-lbaas | 13:55 | |
| Deep_Thought | Hello, when creating & configuring a pool for a load balancer on Horizon, where the corresponding configuration for haproxy is created? | 13:57 |
| *** reedip_outofmemo has joined #openstack-lbaas | 14:06 | |
| xgerman | o/ | 14:07 |
| *** ducttape_ has joined #openstack-lbaas | 14:20 | |
| *** fnaval has joined #openstack-lbaas | 14:59 | |
| *** links has quit IRC | 14:59 | |
| xgerman | Deep_Thought you mean in code or on disk? And are you using Octavia or Namespace driver? | 15:01 |
| openstackgerrit | Abed Abu dbai proposed openstack/octavia: ACTIVE-ACTIVE Topology - create distributor network flow https://review.openstack.org/409763 | 15:09 |
| openstackgerrit | Abed Abu dbai proposed openstack/octavia: Active-Active Topology - register/uregister amphorae tasks https://review.openstack.org/409765 | 15:09 |
| openstackgerrit | Abed Abu dbai proposed openstack/octavia: Active-Active Topology - Cluster DB Tasks https://review.openstack.org/409764 | 15:09 |
| *** armax_ has joined #openstack-lbaas | 15:12 | |
| *** armax has quit IRC | 15:13 | |
| *** armax_ is now known as armax | 15:13 | |
| *** gcheresh_ has quit IRC | 15:28 | |
| Deep_Thought | xgerman: Namespace | 15:34 |
| xgerman | ok | 15:34 |
| Deep_Thought | xgerman: I mean on the disk | 15:34 |
| xgerman | so it goes by a config option: loadbalancer_state_path | 15:39 |
| xgerman | https://github.com/openstack/neutron-lbaas/blob/36f0f578a689be3964c8bb56f07982bb22852148/neutron_lbaas/drivers/haproxy/namespace_driver.py#L48-L53 | 15:39 |
| xgerman | usually I just do find -f on a box but… | 15:40 |
| Deep_Thought | xgerman: thanks | 15:42 |
| *** reedip_ has quit IRC | 15:45 | |
| *** matt-borland has joined #openstack-lbaas | 15:54 | |
| *** Deep_Thought has left #openstack-lbaas | 15:55 | |
| *** _ducttape_ has joined #openstack-lbaas | 15:59 | |
| *** ducttape_ has quit IRC | 16:03 | |
| *** rcernin has quit IRC | 16:09 | |
| openstackgerrit | melissaml proposed openstack/octavia: Fix a typo https://review.openstack.org/416604 | 16:18 |
| *** kobis has quit IRC | 16:24 | |
| diltram | morning | 16:32 |
| *** _ducttape_ has quit IRC | 16:33 | |
| *** ducttape_ has joined #openstack-lbaas | 16:33 | |
| xgerman | o/ | 16:33 |
| openstackgerrit | Merged openstack/octavia: Add context to unit tests https://review.openstack.org/415953 | 17:01 |
| *** tesseract has quit IRC | 17:21 | |
| *** kobis has joined #openstack-lbaas | 17:27 | |
| openstackgerrit | Lubosz Kosnik (diltram) proposed openstack/octavia: Fix tenant_id reference https://review.openstack.org/416678 | 17:29 |
| *** bana_k has joined #openstack-lbaas | 17:31 | |
| *** reedip_outofmemo has quit IRC | 17:33 | |
| *** kobis has quit IRC | 17:39 | |
| *** kevo has joined #openstack-lbaas | 17:40 | |
| *** bana_k has quit IRC | 17:49 | |
| diltram | rm_work: pinggg | 17:59 |
| rm_work | Hey | 17:59 |
| diltram | any progress with this tempest? | 17:59 |
| rm_work | just abandoned mine because kevinbenton uploaded my same changes onto the original patch :P | 17:59 |
| rm_work | which should be fine | 17:59 |
| *** aleph1 is now known as agarner | 17:59 | |
| rm_work | actually JUST commented as you pinged me | 17:59 |
| rm_work | it should work once the barbican issue is resolved ... | 18:00 |
| diltram | ok :P | 18:00 |
| diltram | barbican is merged | 18:00 |
| rm_work | hmm then i'll recheck | 18:00 |
| rm_work | this permission denied thing is still super odd to me | 18:12 |
| rm_work | http://logs.openstack.org/57/411257/4/check/gate-neutron-lbaas-dsvm-functional-ubuntu-xenial-nv/8ad96a8/console.html#_2017-01-04_18_06_49_503895 | 18:12 |
| diltram | rm_work: it's sudo issue | 18:16 |
| diltram | should be sudo -H pip xxx | 18:17 |
| johnsom | o/ | 18:17 |
| diltram | hey | 18:17 |
| rm_work | yeah it mentions that but | 18:17 |
| rm_work | i thought it was an intermittent fail | 18:17 |
| johnsom | The day of my dentist appointment had to be a snow day.... | 18:17 |
| rm_work | o/ | 18:17 |
| diltram | it not even suppose to fail because of this | 18:17 |
| diltram | johnsom: problems with getting there? :P | 18:18 |
| diltram | rm_work: may you give me the url to kevinbenton patch? | 18:18 |
| *** eezhova has joined #openstack-lbaas | 18:18 | |
| johnsom | Getting there and getting back. Saw 6-7 accidents... | 18:18 |
| rm_work | it's the same one | 18:18 |
| rm_work | https://review.openstack.org/#/c/411257/ | 18:18 |
| johnsom | In good local fashion, they haven't even started sanding the roads yet. | 18:19 |
| diltram | hahaha | 18:19 |
| diltram | nice :P | 18:19 |
| johnsom | We don't get much snow.... | 18:19 |
| diltram | rm_work: it's still not refreshed | 18:21 |
| rm_work | :/ | 18:21 |
| xgerman | o/ | 18:22 |
| xgerman | no snow in my neck of the woods but they are quick to salt | 18:22 |
| rm_work | we don't salt on the west coast, we sand or dirt :P | 18:23 |
| xgerman | i am pretty sure if they could use ground up coal they would | 18:23 |
| rm_work | lol | 18:23 |
| diltram | rm_work: it's working | 18:30 |
| rm_work | k | 18:31 |
| rm_work | yeah just saw too | 18:31 |
| diltram | but it's not gonna work with this project_id | 18:31 |
| rm_work | erm | 18:31 |
| diltram | http://logs.openstack.org/78/416678/1/check/gate-octavia-v1-dsvm-scenario-ubuntu-xenial-nv/7f05c62/console.html | 18:32 |
| diltram | I done the same in octavia | 18:32 |
| rm_work | wut | 18:32 |
| rm_work | no project_id on listener | 18:32 |
| *** bana_k has joined #openstack-lbaas | 18:32 | |
| rm_work | wait | 18:33 |
| rm_work | that's the same self | 18:33 |
| rm_work | so does it not have tenant_id *or* project_id? | 18:33 |
| diltram | yep | 18:33 |
| rm_work | <_< | 18:34 |
| diltram | tempest like always make our life miserable :/ | 18:35 |
| xgerman | diltram I was long advocating to switch to rally AFAIK | 18:36 |
| johnsom | Public service announcement: Don't forget .copy() is a shallow copy in python.... That one hung me up on the darn quota patch. | 18:36 |
| diltram | johnsom: rotfl :P | 18:36 |
| diltram | xgerman: I'm advocating for using both of them, but from day to day I have a fillings that we not suppose to use rally | 18:37 |
| diltram | because it's performance benchmarker | 18:37 |
| johnsom | Oh, please, let's not bring back the rally war for a while.... | 18:37 |
| diltram | and this test what would verify | 18:37 |
| diltram | nova boot performance? | 18:37 |
| johnsom | Yeah, adding it in addition I'm more open to than replacing. At least at this point. | 18:38 |
| johnsom | But, after the merge is done????? | 18:38 |
| diltram | johnsom: but again, rally is to measuring performance | 18:39 |
| diltram | and performace of what we suppose to measure? | 18:39 |
| diltram | nova | 18:39 |
| diltram | neutron port bindingg? | 18:39 |
| johnsom | Those are two interesting metrics. The previous war was about a complete replacement of tempest with rally | 18:40 |
| diltram | but there are specific rally tests to test nova and neutron port binding feature :P | 18:40 |
| rm_work | .copy() is shallow by inference because .deepcopy() exists :P | 18:40 |
| diltram | yep I know, we discussed this on mid-cycle | 18:40 |
| diltram | :P | 18:40 |
| johnsom | Yeah, there probably are now | 18:40 |
| johnsom | rm_work Yeah, I was being an idiot and hate myself for how long it took to track that down. I was getting errors about pools not existing the DB, which I thought might be a DB session issue as that is what I have been monkeying with. | 18:42 |
| rm_work | it happens | 18:42 |
| johnsom | It turns out it was missing, because the lb.copy was missing the pool definition on the second test call. | 18:42 |
| johnsom | Anyway, just trying to share my failures so others learn... Grin. | 18:43 |
| rm_work | right now i'm trying to figure out why the routing gets hosed when the agent plugs a VIP that's on the same subnet as the Management interface | 18:43 |
| johnsom | Hmm, yeah, it shouldn't with the namespace... | 18:44 |
| rm_work | i'll let you know if i have any interesting data | 18:44 |
| johnsom | Sure, happy to provide a second set of eyes too as I touched a lot of that in the last year | 18:45 |
| diltram | rm_work: I need to tell you that this patch looks the best for me to fix this issues | 18:51 |
| diltram | https://review.openstack.org/#/c/406033/4/neutron_lbaas/tests/tempest/v2/scenario/base.py | 18:51 |
| diltram | and it's working | 18:52 |
| rm_work | fine by me | 18:52 |
| *** pcaruana has quit IRC | 18:52 | |
| rm_work | diltram: last ran tests on jan 1 | 18:53 |
| rm_work | do you mind if we recheck? | 18:53 |
| diltram | sure | 18:53 |
| rm_work | I'm glad I only spent like 15 minutes looking at this yesterday | 18:54 |
| diltram | but this guy was the first, it removes this self.tenant_id | 18:55 |
| *** Alex_Stef has quit IRC | 18:57 | |
| *** anilvenkata has quit IRC | 18:59 | |
| openstackgerrit | Lubosz Kosnik (diltram) proposed openstack/octavia: Fix tenant_id reference https://review.openstack.org/416678 | 19:05 |
| *** gcheresh_ has joined #openstack-lbaas | 19:14 | |
| rm_work | hey johnsom, one question here: https://github.com/openstack/octavia/blob/master/octavia/network/drivers/neutron/allowed_address_pairs.py#L304 | 19:15 |
| johnsom | Ok | 19:17 |
| rm_work | johnsom: that plugs the vip subnet ... but that function creates a new port only knowing a subnet_id, and then the next line uses vip.ip_address ... how could the correct ip_address be in the vip object if we JUST created the port | 19:17 |
| rm_work | err sorry, it plugs based on just network_id | 19:17 |
| rm_work | not even subnet | 19:18 |
| johnsom | Yeah, you would pick one part I didn't touch... So, it doesn't get the default subnet from the network when we ask neutron to create that port? Isn't this the same thing neutron-lbaas is doing? | 19:23 |
| *** pck has quit IRC | 19:36 | |
| *** kevinbenton has quit IRC | 19:36 | |
| *** raginbajin has quit IRC | 19:36 | |
| *** jschwarz has quit IRC | 19:36 | |
| *** adam_g has quit IRC | 19:36 | |
| *** pck has joined #openstack-lbaas | 19:36 | |
| *** jschwarz has joined #openstack-lbaas | 19:36 | |
| *** adam_g has joined #openstack-lbaas | 19:36 | |
| *** adam_g has quit IRC | 19:36 | |
| *** adam_g has joined #openstack-lbaas | 19:36 | |
| *** kevinbenton has joined #openstack-lbaas | 19:37 | |
| *** raginbajin has joined #openstack-lbaas | 19:38 | |
| *** eezhova has quit IRC | 19:41 | |
| *** TrevorV has joined #openstack-lbaas | 19:55 | |
| TrevorV | rm_work, pssss | 19:55 |
| TrevorV | psssst**** | 19:55 |
| johnsom | Hey neighor | 19:55 |
| TrevorV | Hey hey johnsom! | 19:56 |
| TrevorV | How goes it? | 19:56 |
| johnsom | Not too bad, how about you? | 19:56 |
| TrevorV | Day 2 new job, so far so good I'd say | 19:56 |
| rm_work | psssst | 19:56 |
| johnsom | +100 excellent! Congrats | 19:57 |
| TrevorV | Thanks! | 19:57 |
| TrevorV | These guys are a riot. Memes/Gifs in all the channels and whatnot. | 19:57 |
| TrevorV | Good times | 19:57 |
| xgerman | TrevorV congrats!! | 19:58 |
| TrevorV | xgerman, thanks! Heard you ended up at the Rax, how's that goin for ya? | 19:59 |
| xgerman | yep, I am at the RAX… so far so good… made top table in RookieO whatever that means | 19:59 |
| TrevorV | Well, that just means most of us that contribute to LBaaS and work(ed) at rax got #1 table | 20:00 |
| xgerman | Cool!! So I continued that tradition ;-) | 20:01 |
| johnsom | Octavia meeting starting soon on #openstack-meeting-alt | 20:01 |
| *** m-greene has joined #openstack-lbaas | 20:03 | |
| diltram | rm_work: https://review.openstack.org/#/c/406033/4 - tested | 20:06 |
| *** m-greene has quit IRC | 20:29 | |
| openstackgerrit | Lubosz Kosnik (diltram) proposed openstack/octavia: Fix tenant_id reference https://review.openstack.org/416678 | 20:33 |
| openstackgerrit | Lubosz Kosnik (diltram) proposed openstack/octavia: Fix tenant_id reference https://review.openstack.org/416678 | 20:41 |
| diltram | ok this one should work :P | 20:41 |
| rm_work | johnsom: my question wasn't about how it gets the subnet -- more like ... it's not going to assign an ip_address until that point, so how is the vip object populated? | 20:51 |
| rm_work | it does: interface = self._plug_amphora_vip(amphora, subnet.network_id) | 20:51 |
| rm_work | then: self._add_vip_address_pair(interface.port_id, vip.ip_address) | 20:51 |
| rm_work | but vip.ip_address can't possibly be populated, can it? | 20:51 |
| rm_work | oh whoops i missed the meeting while i grabbed lunch >_< | 20:53 |
| johnsom | Doesn't this get done first to setup the VIP that is passed into this? https://github.com/openstack/octavia/blob/master/octavia/network/drivers/neutron/allowed_address_pairs.py#L324 | 20:53 |
| rm_work | hmmm | 20:56 |
| rm_work | omg taskflow | 20:58 |
| rm_work | kill me now | 20:58 |
| johnsom | Seriously? It's so easy | 20:59 |
| rm_work | it was just annoying to trace through the amp flow | 21:00 |
| rm_work | found what i needed | 21:00 |
| johnsom | http://docs.openstack.org/developer/octavia/_images/LoadBalancerFlows-get_create_load_balancer_flow.svg | 21:00 |
| rm_work | in get_new_LB_networking_subflow() | 21:00 |
| rm_work | you are correct, it does AllocateVIP then PlugVIP | 21:00 |
| rm_work | but | 21:01 |
| rm_work | I still don't quite understand | 21:01 |
| rm_work | because it has allocated the vip, but | 21:01 |
| rm_work | even allocated, it will still run: interface = self._plug_amphora_vip(amphora, subnet.network_id) | 21:01 |
| rm_work | right? | 21:01 |
| rm_work | which does new_port = self.neutron_client.create_port(port) | 21:02 |
| rm_work | creating that port will allocate a totally different IP won't it? | 21:02 |
| johnsom | I will be the first to say this code could use a refactor | 21:03 |
| *** kobis has joined #openstack-lbaas | 21:06 | |
| johnsom | Ok, figured this stuff out again. So, allocate vip gets the vrrp IP, which is added to the port created by _plug_amphora_vip | 21:06 |
| xgerman | I just +1’d somethign which makes sure that we actually end up in the correct subnet | 21:07 |
| rm_work | uhh | 21:07 |
| johnsom | _plug_amphora_vip is just creating that base port on the subnet, it's the allocate and allowed address pairs port that adds the vrrp IP that moves back and forth. | 21:07 |
| xgerman | https://review.openstack.org/#/c/416519/ | 21:07 |
| rm_work | ah i see | 21:08 |
| rm_work | yeah ok | 21:08 |
| kobis | is there any doc describing creation of amphora image, excluding devstack's? | 21:15 |
| kobis | e.g if i install from packages or such? | 21:15 |
| johnsom | kobis There is an extensive readme in the diskimage-create directory | 21:16 |
| johnsom | https://github.com/openstack/octavia/tree/master/diskimage-create | 21:16 |
| kobis | johnsom but diskimage-create is not included in the pypi package | 21:17 |
| johnsom | Oh, interesting. That kind of makes sense though. Hmmm, probably should put a bug in to fix that | 21:17 |
| kobis | cool, will do | 21:18 |
| kobis | btw ive started to look at writing a native octavia driver for nsx lb | 21:22 |
| johnsom | Ah, cool! | 21:22 |
| kobis | so where do i start with this? is there any base class which i should implement? | 21:23 |
| *** _ducttape_ has joined #openstack-lbaas | 21:23 | |
| kobis | i basically need a starting point… | 21:23 |
| johnsom | kobis So I am guessing you are planning to implement a driver like you have in neutron-lbaas right? | 21:24 |
| johnsom | Or is this something you want behind the octavia controller worker? | 21:24 |
| kobis | i need this to be as thin as possible so i'd probably write something which will rpc to our neutron plugin | 21:26 |
| kobis | our LB is integrated into the networking platform… | 21:26 |
| johnsom | kobis Got you. Take a look at this: https://review.openstack.org/#/c/409398/ | 21:26 |
| *** ducttape_ has quit IRC | 21:26 | |
| kobis | so I should build my driver on top of this patch - yeah that makes sense | 21:27 |
| *** _ducttape_ has quit IRC | 21:27 | |
| rm_work | there was a native a10 driver in testing wasn't there? | 21:27 |
| johnsom | I think we may not have everything in place yet. | 21:27 |
| rm_work | this is still the nlbaas-shim, that was true-native which is different, i think | 21:27 |
| johnsom | kobis I can't say that patch is "done" or remotely complete. For one thing it still points to v1 | 21:28 |
| johnsom | kobis Also, check this out: https://github.com/openstack/octavia/blob/master/octavia/api/v1/handlers/abstract_handler.py | 21:28 |
| kobis | rm_work is there a patch for a10's? | 21:28 |
| johnsom | kobis I think you can implement that handler API and run with it. | 21:29 |
| johnsom | This is the current Octavia controller worker handler: https://github.com/openstack/octavia/blob/master/octavia/api/v1/handlers/queue/producer.py | 21:29 |
| kobis | yeah this is doable too :) | 21:29 |
| johnsom | kobis A handler would probably be the best "native" solution | 21:30 |
| kobis | I think that a handler wouldn't be a big effort comparing to a nlbaas shim | 21:31 |
| rm_work | I'm trying to find where that was | 21:31 |
| rm_work | I swear dougwig had done something | 21:31 |
| kobis | so i guess that it's the better option | 21:32 |
| rm_work | or maybe they were just testing his with the shim :/ | 21:32 |
| johnsom | kobis +1 We don't have the code to switch those handlers on the fly, but you can config it via octavia.conf for now | 21:33 |
| xgerman | he always told me he was trying to make an A10 amphora… | 21:33 |
| kobis | johnsom once we have support for multiple providers: will this support multiple handlers? | 21:34 |
| kobis | or multiple shim drivers? | 21:34 |
| johnsom | Right, we will eventually have a way that maps providers/flavors to handlers/shims | 21:34 |
| johnsom | Or you can add that too.... Grin | 21:34 |
| johnsom | Right now we are just loading the handler in the config: https://github.com/openstack/octavia/blob/master/octavia/api/v1/controllers/base.py#L32 | 21:35 |
| kobis | lets take these one at a time :) | 21:35 |
| johnsom | As Octavia API doesn't have the concept of providers yet | 21:35 |
| johnsom | Yeah, the config setting should get you far enough for your driver implementation | 21:36 |
| kobis | and that's fine - for now. but once we do - will we support multiple handlers? or multiple drivers? or both? | 21:36 |
| kobis | i guess that we will need both... | 21:37 |
| johnsom | The driver shim is a "handler", so... It's just there to try to minimize the work of driver porting. | 21:37 |
| johnsom | Safe to say, handlers are not going away and is the path forward | 21:38 |
| kobis | yeah - but if i wanna load a10 via the nlbaas shim, and use radware too via the shim... | 21:39 |
| kobis | so a) i should be able to load it twice | 21:39 |
| johnsom | Right, that would have to work | 21:39 |
| kobis | cool… | 21:39 |
| kobis | well i'm calling it a day… have a good one | 21:40 |
| johnsom | Probably some ugly legacy mapping logic that we will strive to remove as soon as we can kind of thing. | 21:40 |
| johnsom | Later | 21:40 |
| rm_work | this is lulzy... so basically, I am changing things so the VIP isn't provided by the user, it's pulled from whatever network the amp happened to boot on <_< | 21:44 |
| *** gcheresh_ has quit IRC | 21:51 | |
| openstackgerrit | Merged openstack/neutron-lbaas: Fix for error "no attribute tenant_id" https://review.openstack.org/406033 | 21:57 |
| *** matt-borland has quit IRC | 22:02 | |
| *** ducttape_ has joined #openstack-lbaas | 22:06 | |
| rm_work | johnsom: so when it runs "self.neutron_client.create_port(port)" | 22:12 |
| rm_work | the created port is *supposed* to have fixed_ips on it right? | 22:12 |
| *** kobis has quit IRC | 22:12 | |
| rm_work | I wonder if that's up to the neutron configuration? | 22:13 |
| rm_work | i create ports and they don't have fixed_ips :/ | 22:13 |
| redrobot | ohai octavia friends! | 22:14 |
| redrobot | I saw someone was pinging me during your weekly meeting? | 22:14 |
| rm_work | heya redrobot | 22:15 |
| redrobot | in regards to BBQ? | 22:15 |
| xgerman | of course | 22:15 |
| * redrobot waves at rm_work | 22:15 | |
| rm_work | yeah I guess we've still got issues with ACLs maybe? diltram has details | 22:15 |
| xgerman | diltram had questions | 22:15 |
| rm_work | redrobot: oh BTW i'm back working on octavia :P | 22:15 |
| redrobot | rm_work woot!!! | 22:15 |
| redrobot | rm_work gainful employment is always a good thing. :D | 22:15 |
| xgerman | +1 | 22:15 |
| redrobot | rm_work in JP or back in the US? | 22:15 |
| rm_work | though here we don't have barbican nor do we have short term plans for using SSL-term lol | 22:15 |
| rm_work | back in US :/ | 22:16 |
| redrobot | rm_work womp womp ... grats anyway | 22:16 |
| rm_work | yeah | 22:17 |
| rm_work | thanks :P | 22:17 |
| rm_work | it's been pretty dead in the barbican channel, how are things going over there? :/ | 22:17 |
| johnsom | rm_work No, the can be allocated ips, they don't have to be fixed. I think our default is to pass in the subnet_id and let neutron give us an IP | 22:18 |
| redrobot | rm_work I was out almost two weeks for holidays and such. pretty slow right now though. hopefully that'll be ramping up here pretty soon. | 22:19 |
| rm_work | hmmm | 22:20 |
| rm_work | johnsom: so right after `new_port = self.neutron_client.create_port(port)` it does `return self._port_to_vip(new_port, load_balancer)` | 22:20 |
| rm_work | in _port_to_vip it assumes there's fixed_ips | 22:21 |
| rm_work | return data_models.Vip(ip_address=fixed_ip.ip_address, | 22:21 |
| johnsom | Yeah, those are assigned by neutron if we didn't pass in an IP | 22:21 |
| rm_work | ok that's what I mean | 22:21 |
| rm_work | "fixed_ips" should be filled though, not None | 22:21 |
| johnsom | Um, yeah I think so. Maybe it is that bug German mentioned earlier? | 22:22 |
| rm_work | I don't think so -- i think that just means it gets one on the wrong subnet | 22:22 |
| rm_work | I wonder if behavior has changed since liberty | 22:25 |
| rm_work | i don't think so? | 22:25 |
| xgerman | rm_work youbtried the patch I referenced | 22:25 |
| xgerman | ? | 22:25 |
| rm_work | no, this is unrelated | 22:26 |
| rm_work | though i did LOOK at it | 22:26 |
| xgerman | maybe we need that fix in more places… | 22:26 |
| xgerman | given the amunt of ports we create ;-) | 22:26 |
| rm_work | ah yeah | 22:28 |
| rm_work | so apparently I need to set admin_state_up=True for it to get any fixed_ips assigned | 22:28 |
| rm_work | johnsom: any idea what the ramifications of creating it "UP" might be? | 22:29 |
| xgerman | I think we only use it to hold the IP? | 22:31 |
| xgerman | so active would make things being routed to it | 22:31 |
| rm_work | hmm | 22:37 |
| rm_work | so maybe i have to bring it up | 22:37 |
| rm_work | and then take it down | 22:37 |
| rm_work | and maybe it'll keep the IP it gets assigned | 22:37 |
| rm_work | oh | 22:38 |
| rm_work | huh weird nm | 22:38 |
| rm_work | it's not admin_state | 22:38 |
| rm_work | i see | 22:39 |
| *** m-greene has joined #openstack-lbaas | 22:40 | |
| *** openstack has joined #openstack-lbaas | 22:56 | |
| *** amotoki has quit IRC | 23:00 | |
| *** amotoki has joined #openstack-lbaas | 23:02 | |
| *** armax has quit IRC | 23:04 | |
| *** armax has joined #openstack-lbaas | 23:05 | |
| *** armax has quit IRC | 23:06 | |
| rm_work | what does the amphora lb_network_ip come from? | 23:16 |
| *** ducttape_ has quit IRC | 23:16 | |
| *** ducttape_ has joined #openstack-lbaas | 23:17 | |
| johnsom | lb_network is the management network | 23:18 |
| johnsom | A lot has changed since liberty, so... | 23:18 |
| rm_work | yeah it was just a translation issue, i figured it out | 23:18 |
| rm_work | it wasn't admin_state related, that was a false positive | 23:18 |
| rm_work | it LOOKED like fixed_ips was None, because the to_dict() method doesn't do anything with lists... i guess | 23:19 |
| johnsom | Ah | 23:19 |
| rm_work | or something. anyway, there was a list with a valid fixed_ip but doing to_dict() just returns None for fixed_ips | 23:19 |
| rm_work | port.to_dict() | 23:20 |
| rm_work | anywho, new problem | 23:20 |
| *** ducttape_ has quit IRC | 23:21 | |
| *** ducttape_ has joined #openstack-lbaas | 23:24 | |
| *** amotoki has quit IRC | 23:26 | |
| *** gongysh has joined #openstack-lbaas | 23:28 | |
| rm_work | crap, it doesn't wait long enough... | 23:29 |
| rm_work | in the nova driver, when it does `inf_list = nova_response.interface_list()` the interface_list comes back empty | 23:29 |
| rm_work | but if i pdb and run it again, it has an entry :( | 23:29 |
| rm_work | it just takes a second :/ | 23:29 |
| rm_work | that seems ... odd | 23:29 |
| *** amotoki has joined #openstack-lbaas | 23:31 | |
| rm_work | oh, it runs twice? | 23:32 |
| rm_work | derp k | 23:33 |
| *** ducttape_ has quit IRC | 23:35 | |
| *** ducttape_ has joined #openstack-lbaas | 23:35 | |
| *** ducttape_ has quit IRC | 23:40 | |
| *** ducttape_ has joined #openstack-lbaas | 23:40 | |
| rm_work | interesting ... | 23:52 |
| rm_work | plugging the VIP port (just the actual neutron plug, nothing yet with the agent) causes the routing *in* to the amp to break :( | 23:54 |
| johnsom | Hmm, it could be changing the default route to the new interface. or the SSH rebind script isn't working. Can you still SSH? | 23:57 |
| johnsom | It kind of looks like someone fixed the resolv.conf element for RedHat but didn't fix the ssh rebind element.... | 23:58 |
| johnsom | Fixed:https://github.com/openstack/octavia/blob/master/elements/no-resolvconf/finalise.d/99-disable-resolv-conf | 23:59 |
| johnsom | No fixed: https://github.com/openstack/octavia/blob/master/elements/rebind-sshd/finalise.d/98-rebind-sshd-after-dhcp | 23:59 |
| johnsom | Maybe that is is | 23:59 |
| johnsom | is it | 23:59 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!
