Wednesday, 2018-05-09

« Tuesday, 2018-05-08 Index Thursday, 2018-05-10 »
rm_workugh00:02
*** fnaval has quit IRC00:02
rm_workmember statuses are making me die now00:02
*** fnaval has joined #openstack-lbaas00:06
*** fnaval has quit IRC00:07
*** fnaval has joined #openstack-lbaas00:07
openstackgerritAdam Harwell proposed openstack/octavia-tempest-plugin master: Create api+scenario tests for members  https://review.openstack.org/56619900:20
johnsomWhat is wrong with the statuses?00:21
openstackgerritAdam Harwell proposed openstack/octavia-tempest-plugin master: Create basic traffic balancing scenario test  https://review.openstack.org/56670000:21
johnsomAt least they aren’t hidden in a status tree only00:21
*** Swami_ has quit IRC00:21
*** Swami has quit IRC00:21
*** longkb has joined #openstack-lbaas00:23
rm_workyes00:25
rm_workit's just wonky00:25
rm_workbecause in NOOP mode, it will always be NO_MONITOR regardless of admin_state_up00:25
rm_workbut if you aren't noop, we will actually update a member to OFFLINE even without a monitor, if it's admin_state_up is False00:26
rm_workbecause we know even without a monitor00:26
rm_workbut it makes the states weirdly unpredictable00:26
*** harlowja has quit IRC00:51
*** longkb has quit IRC01:12
*** longkb has joined #openstack-lbaas01:13
openstackgerritAdam Harwell proposed openstack/octavia-tempest-plugin master: Create basic traffic balancing scenario test  https://review.openstack.org/56670001:20
*** ianychoi has joined #openstack-lbaas01:21
*** username_ has joined #openstack-lbaas01:22
*** username_ is now known as username__01:23
openstackgerritAdam Harwell proposed openstack/octavia master: WIP: Floating IP Network Driver (spans L3s)  https://review.openstack.org/43561201:54
*** atoth has quit IRC02:15
openstackgerritAdam Harwell proposed openstack/octavia-tempest-plugin master: Create api+scenario tests for members  https://review.openstack.org/56619902:16
openstackgerritAdam Harwell proposed openstack/octavia-tempest-plugin master: Create basic traffic balancing scenario test  https://review.openstack.org/56670002:16
*** yamamoto has joined #openstack-lbaas02:20
*** yamamoto has quit IRC02:24
*** username__ has quit IRC02:35
*** yamamoto has joined #openstack-lbaas02:37
*** dayou_ has joined #openstack-lbaas03:01
*** rcernin has quit IRC03:14
*** yamamoto has quit IRC03:31
openstackgerritMerged openstack/octavia-dashboard master: Imported Translations from Zanata  https://review.openstack.org/56680303:33
*** threestrands has joined #openstack-lbaas03:38
*** links has joined #openstack-lbaas03:42
*** yamamoto has joined #openstack-lbaas03:44
*** amotoki has joined #openstack-lbaas04:19
*** fnaval_ has joined #openstack-lbaas04:34
*** fnaval has quit IRC04:34
openstackgerritMerged openstack/octavia master: Fix periodic job  https://review.openstack.org/56672604:36
*** phuoc_ has quit IRC05:12
*** yamamoto has quit IRC05:15
*** phuoc has joined #openstack-lbaas05:16
*** aojea has joined #openstack-lbaas05:17
*** yboaron has joined #openstack-lbaas05:17
*** yamamoto has joined #openstack-lbaas05:20
*** fnaval_ has quit IRC05:26
*** aojea has quit IRC05:31
*** Swami has joined #openstack-lbaas05:32
*** Swami_ has joined #openstack-lbaas05:32
*** threestrands has quit IRC05:54
*** pcaruana has joined #openstack-lbaas05:57
*** Swami has quit IRC06:13
*** Swami_ has quit IRC06:13
*** annp has joined #openstack-lbaas06:22
*** yamamoto_ has joined #openstack-lbaas07:10
*** yamamoto has quit IRC07:10
*** tesseract has joined #openstack-lbaas07:22
*** yamamoto_ has quit IRC07:29
*** yamamoto has joined #openstack-lbaas07:30
openstackgerritOpenStack Proposal Bot proposed openstack/octavia-dashboard master: Imported Translations from Zanata  https://review.openstack.org/56714207:45
*** rpittau has joined #openstack-lbaas07:57
*** yamamoto has quit IRC08:15
*** yamamoto has joined #openstack-lbaas08:17
*** salmankhan has joined #openstack-lbaas08:49
*** yamamoto has quit IRC08:55
*** salmankhan has quit IRC09:00
*** salmankhan has joined #openstack-lbaas09:03
*** yamamoto has joined #openstack-lbaas09:11
*** salmankhan has quit IRC09:20
*** phuoc has quit IRC09:26
*** phuoc has joined #openstack-lbaas09:26
*** phuoc has quit IRC09:27
*** phuoc has joined #openstack-lbaas09:28
*** salmankhan has joined #openstack-lbaas09:37
openstackgerritCarlos Goncalves proposed openstack/neutron-lbaas master: DNM: testing LoggingNoop service provider driver  https://review.openstack.org/56717809:54
*** longkb has quit IRC10:00
*** annp has quit IRC10:33
*** yamamoto has quit IRC10:49
*** yamamoto has joined #openstack-lbaas10:51
*** AlexStaf has joined #openstack-lbaas11:12
*** atoth has joined #openstack-lbaas11:25
*** yamamoto has quit IRC11:25
*** yamamoto has joined #openstack-lbaas11:31
*** yamamoto has quit IRC11:32
*** yboaron has quit IRC11:54
*** yboaron has joined #openstack-lbaas11:54
*** yamamoto has joined #openstack-lbaas11:58
*** yboaron has quit IRC11:58
*** pcaruana has quit IRC12:21
*** yamamoto has quit IRC12:39
openstackgerrithuangshan proposed openstack/python-octaviaclient master: Add loadbalancer status show client api and osc  https://review.openstack.org/54271512:40
*** yamamoto has joined #openstack-lbaas12:44
*** yamamoto has quit IRC12:45
*** sapd has quit IRC13:05
*** samccann has joined #openstack-lbaas13:06
*** fnaval has joined #openstack-lbaas13:12
*** pcaruana has joined #openstack-lbaas13:40
openstackgerritMerged openstack/octavia master: Updates the docs with new admin tips  https://review.openstack.org/56203513:45
*** yamamoto has joined #openstack-lbaas13:46
*** dayou_ has quit IRC13:49
*** yamamoto has quit IRC13:56
*** pcaruana has quit IRC14:05
*** AlexStaf has quit IRC14:06
*** pcaruana has joined #openstack-lbaas14:08
*** dayou_ has joined #openstack-lbaas14:13
*** nmagnezi_ is now known as nmagnezi14:17
*** pcaruana has quit IRC14:25
*** pcaruana has joined #openstack-lbaas14:26
*** dayou_ has quit IRC14:30
*** srihas has quit IRC14:52
*** links has quit IRC15:25
*** yboaron has joined #openstack-lbaas15:33
openstackgerritMerged openstack/octavia-dashboard master: Imported Translations from Zanata  https://review.openstack.org/56714215:36
*** Swami has joined #openstack-lbaas16:55
*** atoth_ has joined #openstack-lbaas16:55
*** atoth has quit IRC16:57
*** phuoc has quit IRC17:08
*** tesseract has quit IRC17:15
*** salmankhan has quit IRC17:17
rm_workugh this member issue17:25
*** dmellado has quit IRC17:29
*** atoth has joined #openstack-lbaas17:34
johnsomWell, I'm having fun writing mind numbing unit tests....17:37
rm_workjohnsom: you have a devstack up?17:37
rm_workcan you do me a favor? :P17:37
johnsomYeah17:37
rm_workmake LB->Listener->Pool17:37
rm_workadd a member, no HM17:37
*** atoth_ has quit IRC17:37
johnsomSure, just a minute17:38
rm_workk17:38
rm_workyou may already have one sitting around17:38
rm_worki just need to know that: A) it definitely is in state NO_MONITOR17:38
rm_workB) what is the socat stats17:38
johnsomk17:38
rm_workin my cloud, i run this test and the thing is in NO_MONITOR as I expect17:39
rm_workbut in the gate... it's SOMETIMES IN "OFFLINE" instead17:39
rm_worklike17:39
rm_work3/4 maybe?17:39
johnsomhttps://www.irccloud.com/pastebin/SjvSoFsx/17:40
johnsomhttps://www.irccloud.com/pastebin/8X99Fmgx/17:41
rm_workhmm k yeah17:41
rm_workno check17:41
rm_workis what i expect17:41
johnsomMaybe an issue in noop driver?17:41
rm_workthis is scenario17:41
rm_workand it's *not consistent*17:42
rm_worki assume because of timing17:42
rm_workmy guess is it starts in one status and goes to the other17:42
johnsomhttps://www.irccloud.com/pastebin/5ZdTeEEQ/17:42
rm_workgiven the code, i assume that means it starts in NO_MONITOR and goes to OFFLINE via health17:42
rm_workyes17:42
johnsomSo, initial create should be right17:42
rm_workright17:43
rm_workso it'd go to OFFLINE via HM17:43
rm_work*Healthmanager17:43
johnsomhmm17:43
rm_workbut no idea why17:43
rm_workhttp://logs.openstack.org/00/566700/11/check/octavia-v2-dsvm-scenario/ce3e244/job-output.txt.gz#_2018-05-09_03_10_34_98371617:44
rm_workreading through this line-by-line now17:44
rm_workanyway yeah, it started in NO_MONITOR and then switched to BACKUP between the first and second GET18:12
rm_workerr18:12
rm_workOFFLINE18:12
rm_workbefore it even went to ACTIVE, during PENDING_CREATE18:13
rm_workI wonder if it would switch back18:13
rm_worki wonder if there's another status change in the flows18:13
rm_workeugh though this flow is out of order a tiny bit i think18:14
rm_workwe mark the Pool ACTIVE *after* the LB and Listener T_T18:15
openstackgerritAdam Harwell proposed openstack/octavia master: WIP: Floating IP Network Driver (spans L3s)  https://review.openstack.org/43561218:15
openstackgerritAdam Harwell proposed openstack/octavia master: Slightly reorder member flows  https://review.openstack.org/56730618:18
rm_workjohnsom: i bet it flips to OFFLINE *briefly* and then back to NO_MONITOR because of this:18:20
rm_workhttps://github.com/openstack/octavia/blob/master/octavia/controller/healthmanager/health_drivers/update_db.py#L267-L26818:21
rm_workwhich would explain why it's inconsistent18:21
rm_workthere's a brief moment when it could go OFFLINE depending on when the health message comes in18:22
johnsomThat could be18:23
rm_workgonna ... fix that I think18:23
johnsomJust have it take the DB status?18:25
rm_workthat would work18:31
rm_workwell no18:31
rm_worki am gonna be a little smarter i think18:31
rm_worksec18:31
rm_workfixing the testing first, because this should have been caught18:31
rm_workin fact i am pretty sure we have a test that does this on purpose and thinks it's right18:31
openstackgerritMichael Johnson proposed openstack/octavia master: Implement provider drivers - L7 Policy  https://review.openstack.org/56705918:34
rm_workI *think* that we can just avoid updating the status if it's in NO_MONITOR18:38
openstackgerritMichael Johnson proposed openstack/octavia master: Implement provider drivers - L7 Rules  https://review.openstack.org/56707318:39
rm_workbut, gotta do lunch today18:45
*** fnaval has quit IRC18:49
*** fnaval has joined #openstack-lbaas18:51
johnsomYeah, me too.  Time to run the tests  and grab bite to eat18:52
*** dmellado has joined #openstack-lbaas18:58
openstackgerritAdam Harwell proposed openstack/octavia master: Healthmanager shouldn't update NO_MONITOR members  https://review.openstack.org/56732219:05
openstackgerritAdam Harwell proposed openstack/octavia-tempest-plugin master: Create api+scenario tests for members  https://review.openstack.org/56619919:06
openstackgerritAdam Harwell proposed openstack/octavia-tempest-plugin master: Create basic traffic balancing scenario test  https://review.openstack.org/56670019:06
rm_workok19:06
rm_workbbl19:06
johnsomGotta put an agenda together19:07
nmagnezio/19:08
johnsomnmagnezi We keep missing each other, do you still have an RBAC question?19:11
nmagnezijohnsom, yes19:12
nmagnezi:)19:12
johnsomFire away19:12
nmagnezijohnsom, okay so some context19:12
nmagnezijohnsom, I think I kinda miss the usecase for this, but I kinda assume that it relates to the fact that Octavia can operate as a standalone thing.. anyhow. I looked at projects like Cinder and Nova and what is the policy-in-code they implemented19:14
nmagnezithey chose to go with admin or owner (with minor adaptations)19:14
nmagnezijust wanted to ask, why did we chose differently19:14
nmagneziwhat was the incentive to have the roles that were implemented in our policy19:15
johnsomYeah, so the lovely history of OpenStack.  At the time we did our RBAC, nova and keystone were planning and had patches up to implement their policy-in-code the same way we did. We agreed that the rich capabilities it provided was what our users (customers) were asking for, so we just did it.19:15
johnsomFast forward a bit and those keystone/nova patches never landed.19:16
johnsomHowever, the discussion continues to this very day, and is being proposed as a Stein community goal.19:16
johnsomSee http://lists.openstack.org/pipermail/openstack-dev/2018-May/130207.html19:17
johnsomThis is actually a topic I was just putting on the agenda.19:17
nmagneziagain, I know I probably lack context and details, but I'll ask anyway: Don't that create a worse user experience both for operators and their users?19:17
johnsomAnd this one: https://review.openstack.org/#/c/523973/19:18
nmagnezithe meaning is that they need to manually assign roles for *each* newly created user just in order to interact with Octavia, no?19:18
nmagneziagain, please correct me when I'm wrong :)19:18
johnsomNo, not really. It actually makes it much better.  So roles are inherited, so when an operator is ready to allow Octavia in their cloud, they can add the load_balancer_member(or something similar, I don't remember now) to their "member role" and instantly every user in the cloud has access.19:19
nmagnezihow can you add a role to a role?19:20
* nmagnezi looks at openstack docs19:21
johnsomvia groups19:21
johnsomopenstack group role add nonadmins19:22
johnsomsomething like that19:22
nmagneziI'll look it up19:22
nmagnezisec19:22
*** links has joined #openstack-lbaas19:22
johnsomYeah, I'm not remembering the details of how that works on the keystone side19:23
nmagneziyou're not using this feature in house?19:23
johnsomI think for one customer, but that is handled by the keystone/identity folks19:24
nmagnezilooks kinda related: https://blueprints.launchpad.net/keystone/+spec/inherited-domain-roles19:24
johnsomopenstack role assignment list19:25
johnsomshows you the roles that are inherited19:25
johnsomYeah, ok, so to add a role to a group: openstack role add --group foo and there is an inherited flag19:27
johnsomnmagnezi You are up in the storyboard meeting19:27
nmagnezijohnsom, thanks :)19:28
nmagnezijohnsom, do you recall who added the bullet about notifications?19:32
nmagnezithere's no name. and it actually works okay for me19:32
johnsomnmagnezi I added that it works for me, so I don't know who added the original19:32
nmagnezijohnsom, ack. thanks.19:32
johnsomCarlos maybe?19:32
nmagnezicgoncalves, o/19:33
*** links has quit IRC19:45
*** atoth has quit IRC19:46
*** yboaron has quit IRC19:54
cgoncalvesI'm here19:57
cgoncalveswhat's up?19:57
cgoncalvesnotifications? maybe me, not sure19:58
cgoncalvesI think so yeah19:58
nmagnezicgoncalves, hey. re: https://etherpad.openstack.org/p/storyboard-issues ==> number 519:58
nmagnezidid you add it to the list?19:58
cgoncalvesnmagnezi, I added 4 and 6 which has same color. number 5 does not so it was not me19:59
nmagnezicgoncalves, ack. thanks20:00
johnsom#startmeeting Octavia20:00
openstackMeeting started Wed May  9 20:00:18 2018 UTC and is due to finish in 60 minutes.  The chair is johnsom. Information about MeetBot at http://wiki.debian.org/MeetBot.20:00
openstackUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.20:00
*** openstack changes topic to " (Meeting topic: Octavia)"20:00
openstackThe meeting name has been set to 'octavia'20:00
johnsomHi folks20:00
nmagnezio/20:00
cgoncalvesahoy!20:00
johnsomOye, the storyboard meeting....20:01
johnsom#topic Announcements20:01
*** openstack changes topic to "Announcements (Meeting topic: Octavia)"20:01
johnsomI don't have much here.20:01
johnsomThe summit in Vancouver is coming up quickly, just a few weeks out.20:01
johnsomI will probably cancel the Octavia meeting the week of the summit unless others want run it.20:02
johnsomAny other announcements I missed?20:02
johnsom#topic Brief progress reports / bugs needing review20:03
*** openstack changes topic to "Brief progress reports / bugs needing review (Meeting topic: Octavia)"20:03
xgerman_o/20:03
cgoncalvesmade progress on grenade support: https://review.openstack.org/#/c/549654/20:03
johnsomI have been a busy person and as of yesterday we have a fully functional (aside from bugs/cleanup ) provider driver for Octavia and interface for other drivers.20:03
johnsomI'm working on one last patch for the cleanup/bugs/release notes, etc. now20:04
*** rm_mobile has joined #openstack-lbaas20:04
cgoncalvesit is now upgrading from stable/queens. post-upgrade octavia tempest was failing on 4 jobs. cause is known and rm_work has a patch up20:04
rm_mobileo/20:04
rm_mobileSorry I'm late. Lunch going long20:05
johnsomCool, I will check it out.  I also promised a UDP protocol review that needs to happen soonish20:05
johnsomrm_work has also been busy getting the tempest plugin in shape, so good stuff there too!20:06
johnsomAny other updates?20:07
johnsom#topic Default value for haproxy_amphora.connection_max_retries (300 at 5 seconds each)20:07
cgoncalvesstable/pike gates were broken because of tempest (brancheless) bumped ostestr from 0.8.x to 1.0.x. ostestr switched default from testr to stestr and with that broke stable/pike which was still expecting testr underneath. we've fixed stable/pike already20:07
*** openstack changes topic to "Default value for haproxy_amphora.connection_max_retries (300 at 5 seconds each) (Meeting topic: Octavia)"20:07
xgerman_?20:07
johnsomThis came in as a bug report and is worth a discussion20:08
johnsomcgoncalves Cool, thanks for helping with that20:08
xgerman_+120:08
johnsomWe currently set the connection timeouts super high to allow for super slow cloud infrastructure (virtualbox I look at you in shame).20:09
*** samccann has quit IRC20:09
johnsomThis eases folks trying out octavia on these not-so-great hosts as when the nova instance eventually boots they will get a working LB.20:09
*** leitan has joined #openstack-lbaas20:09
johnsomHowever, it also has the side effect that things can take a long time to timeout and go into ERROR states if the cloud is broken20:10
johnsomThis default is 25 minutes.20:10
johnsomNow, I know we need to keep this a bit high for some zuul gate hosts, but that can be configured in the gate job definition.20:11
johnsomSo, the question is, now that folks are running this more in production style deployments, should we consider lowering this default?20:11
johnsomSo things give up quicker20:11
johnsomThoughts? Comments?20:12
xgerman_yeah, that might be good20:12
cgoncalvesas long as it is configurable, I don't see reason not to lower timeout20:13
nmagneziyeah, makes sense to move this high value to the job config and have a more sane (lower) value as production default20:13
johnsomIt could lead to more folks complaining that LBs don't come up, especially if they are using virutalbox, etc.20:14
johnsomThough they probably complain that it's "stuck in pending_create" now anyway... lol20:14
nmagneziha. maybe we can provide a local.conf for slow testing envs?20:15
johnsomEither way we need to write up a guide.  The dev guide would mention needing it higher, the operator guide would say lower20:15
johnsomOk, so mostly hearing yes, our defaults should be more in line with production style use cases.20:17
rm_mobileI agree, lower the default20:17
johnsomI will comment on the story20:17
nmagnezijohnsom, please link the story20:17
johnsom#link https://storyboard.openstack.org/#!/story/200198220:17
johnsomThanks for the reminder!20:17
johnsom#topic New default RBAC roles20:18
*** openstack changes topic to "New default RBAC roles (Meeting topic: Octavia)"20:18
johnsomSo, as some of you are aware we have "advanced" style RBAC defaults.20:18
johnsomAnd the other two projects that were championing this never merged their patches.20:18
johnsomWell, the spec and topic are still alive and well20:18
johnsom#link http://lists.openstack.org/pipermail/openstack-dev/2018-May/130207.html20:19
cgoncalvesso advanced that users cannot CRUD resources out of the box :P20:19
johnsomThere is a new proposal for standard roles. It is pretty close to ours already.20:19
johnsomcgoncalves Correct, the operator has to opt-in users or groups for load balancer features.20:20
johnsomEasy way is to add LB member role to the non-admin user group and be done.20:20
johnsomAnyway, keystone is moving forward with this, as is nova. They are talking about including us in the early adopter list as well. (I support, but not yet signed up to staff, this).20:21
nmagneziyup. I need to look at this again. but manually assigning roles for each new user is a pain. so hopefully groups makes it more sane20:21
johnsomYeah, don't do it per user, that would be un-pleasant20:21
johnsomThe current discussion is when a few projects do it, it would become a community goal for Stien or T20:22
johnsomAny questions or comments on this?20:22
johnsomI know we have customers asking for the more advanced roles, not sure if others are in the same camp or not20:23
nmagnezinot at the moment, but I might have some after I learn more about how it works20:23
johnsomI will also not, it is super easy to disable the advanced and go back to owner/admin by copying over the policy file20:23
johnsom#link https://review.openstack.org/#/c/566377/20:24
nmagneziyup. I double checked and it worked for me20:24
johnsomThat is the current home of the spec20:24
nmagnezi(adding policy.json)20:24
johnsomYeah, some of our gate tests run with that enabled20:24
johnsomThe new tempest pluign does test the advanced roles as well20:24
nmagnezigood to know. and in any case i think it's good that we have that option20:24
johnsomOk, I will communicate our general support for standardizing these roles.20:25
johnsomThough I'm not sure I'm signing up right now to do the work. I have Rocky commitments to work on20:25
nmagneziwe should update our devstack plugin to use role inheritance instead of manually assignment to user demo btw20:26
rm_mobileYeah it's good but with a personal history working on rbac, there is a lot of work they still need to do even in the design side20:26
johnsomSure if you would like.20:26
nmagnezis/manually/manual20:26
johnsom#topic Open Discussion20:27
*** openstack changes topic to "Open Discussion (Meeting topic: Octavia)"20:27
johnsomBTW, the ticket price for the PTG goes up on the 18th of May20:27
johnsomSo if you are planning to go to Denver in Sept. you might want to get your ticket early20:27
johnsomOther topics today?20:28
cgoncalvesyes20:28
nmagnezijust to keep everyone posted. we had another discussion with the storyboard team20:28
cgoncalvesgo on Nir20:28
johnsom(you don't have to raise your hand, just jump in) grin20:29
nmagnezithis will take time.. you can see some of their feedback in the etherpad20:29
nmagnezicgoncalves, I'm done :)20:29
nmagnezioh, the etherpad:20:30
nmagnezi#link https://etherpad.openstack.org/p/storyboard-issues20:30
cgoncalveswe've had patches merged without stories or release notes included. I'd like to propose having at least one in20:30
cgoncalvesI'm not asking for trivial bugs (even though a release note would be nice and easier/less consuming than opening a story)20:31
johnsomI just got an e-mail that 5 people have added the Octavia onboarding session to their summit schedule, so thanks folks for adding it to your schedule. grin20:31
rm_mobileOh yeah I need to get going on the ptg... Who else thinks they'll be there?20:31
rm_mobileJohnsom do you want my help on that? Throw me on it if so20:31
rm_mobileI'll probably be there regardless20:31
johnsomcgoncalves Yes, please -1 all of the patches you see that should have release notes!!!!!!20:31
rm_mobileIt's just a talk? Or lab?20:31
johnsomJust a talk20:32
cgoncalvesjohnsom, duly noted :D20:32
* rm_mobile prepares to hate cgoncalves20:32
cgoncalvesrm_mobile, I wasn't expecting anything less ;)20:32
nmagnezias soon as storyboard fix some key issues I think we'll need to improve the stories/patches ratio20:33
johnsomRelease notes are important for communicating out20:33
nmagneziso at the end of it, we'll have a proactive backports (driven by severity etc) process20:33
cgoncalvesrm_mobile, if you want make a git hook that takes the commit title and creates a reno note ('fixes' type by default) haha20:33
nmagnezicgoncalves, lol20:34
johnsomOh don't give him ideas20:34
* johnsom has visions of the quality of our release notes sinking20:34
johnsomOther items?20:35
*** rm_mobile| has joined #openstack-lbaas20:36
johnsomAfter this cleanup patch is in and the tempest patch is fixed (so the gates don't -1) I would really like to get some review time on provider drivers. It's a big chain so can be a conflict magnet.20:36
johnsomOk, either we had a net split again or that is it for today.20:38
nmagnezinothing on my end20:38
nmagnezi:)20:38
johnsomThanks folks!20:38
johnsom#endmeeting20:38
*** openstack changes topic to "Discussion of OpenStack Load Balancing (Octavia) | https://etherpad.openstack.org/p/octavia-priority-reviews"20:38
openstackMeeting ended Wed May  9 20:38:51 2018 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)20:38
openstackMinutes:        http://eavesdrop.openstack.org/meetings/octavia/2018/octavia.2018-05-09-20.00.html20:38
nmagnezio/20:38
openstackMinutes (text): http://eavesdrop.openstack.org/meetings/octavia/2018/octavia.2018-05-09-20.00.txt20:38
openstackLog:            http://eavesdrop.openstack.org/meetings/octavia/2018/octavia.2018-05-09-20.00.log.html20:38
*** rm_mobile has quit IRC20:39
*** leitan has quit IRC20:44
*** rm_mobile| has quit IRC20:54
*** rm_mobile has joined #openstack-lbaas20:54
rm_workplz to be merging https://review.openstack.org/#/c/567322/20:56
rm_workjohnsom: ^^20:57
rm_workxgerman_: ^^20:57
rm_worknmagnezi: ^^20:57
johnsomrm_work You mean reviewing....20:57
rm_worksure, yeah, whatever20:57
johnsomGrin20:57
rm_workif you want20:57
rm_workbut this is A++ code if you ask me20:57
rm_workthe author20:57
rm_workno bias20:58
johnsomGauntlet thrown20:58
xgerman_do we have a bug # for that? Just sayng?20:58
rm_workjust discovered it. could make one if it bugs you20:59
rm_work(pun intended)20:59
*** pcaruana has quit IRC20:59
cgoncalveswhere's my release note? hahaha21:00
* cgoncalves disconnects :)21:00
* rm_work gets out his shiv21:00
johnsomDo we really want to put bugs that haven't impacted users in the release notes? I think it's a pretty high bar to get a bug in the release notes IMB21:00
johnsomIMO21:00
rm_work^^ agree ;P21:01
*** AlexStaf has joined #openstack-lbaas21:07
*** kbyrne has quit IRC21:09
*** kbyrne has joined #openstack-lbaas21:12
rm_workjohnsom: responded21:14
rm_workjohnsom: you're suggesting we just *don't update status* if the member is missing, and don't try to be smart about it?21:15
*** dmellado has quit IRC21:15
rm_workI am fine with that I guess, if you really want that21:15
johnsomI'm suggesting not forcing the status to NO_MONITOR just because the DB says so.21:15
johnsomI am advocating for filling in the info if the amp doesn't report the member.21:16
rm_workerr21:16
rm_workthat's exactly the current bug21:16
rm_workif the amp doesn't report the member at all21:16
rm_workit means it is literally not in the haproxy config yet21:16
rm_workwhich means whatever their "templates have set" for hms, it doesn't matter21:16
johnsomIt forces it to OFFLINE if there is no report, I'm saying if there is no report then check the DB no monitor status21:17
rm_workk i'll try one for you21:17
johnsomRight now you have that the DB trumps all status from the amp itself21:18
johnsomDo you follow or what be to push a version?21:19
openstackgerritAdam Harwell proposed openstack/octavia master: Healthmanager shouldn't update NO_MONITOR members  https://review.openstack.org/56732221:19
johnsomOr I guess I could pastebin it too21:19
rm_work^^21:19
rm_workeh hold on21:19
rm_worklet me reverse that if21:19
johnsomI don't think pass is good21:19
johnsomIt should just set it no monitor21:20
rm_work... it's already that21:20
rm_workNone means no change21:20
rm_workand it already is21:20
johnsomYeah, but the lower logic assumes there is some value set in the message right?21:20
openstackgerritAdam Harwell proposed openstack/octavia master: Healthmanager shouldn't update NO_MONITOR members  https://review.openstack.org/56732221:20
rm_workthe lower logic assumes if it's None, it's a no-change21:20
rm_workand thus skips the emit21:21
rm_work^^ fixed21:21
rm_workand yes, the nested-if is the most efficient way to write that AFAICT21:21
rm_workunless i'm missing something dumb, which is possible21:22
rm_workbut the alternative I think would be ....21:22
johnsomOk, yeah, that last one looks good assuming the none is correct(haven't read all the way down yet)21:22
*** dmellado has joined #openstack-lbaas21:23
johnsomYeah, that should work21:24
rm_workhttp://paste.openstack.org/show/720716/21:24
rm_workthat is ... annoying21:24
rm_workso, nested-if21:24
rm_workdoes that seem right?21:24
johnsomI like what you have posted now21:25
rm_workk21:25
johnsomYes, this logic is a bit, if-y21:25
johnsomlol21:25
johnsomBut, it's kind of a decision tree, so...21:25
rm_worklol21:25
rm_worknice one21:25
rm_workrechecking the tempest patches21:26
rm_workshould be fine21:26
rm_workWTB merge on https://review.openstack.org/#/c/565640/21:26
rm_workto shorten this tree21:26
rm_workand so it actually runs on more changes21:26
johnsomAh, you fixed the member one, good, it was tanking my chain too21:26
rm_workyes the member one was broken *because of this bug*21:27
rm_workthis bug is the fix :P21:27
rm_work*this bugfix21:27
*** dmellado has quit IRC21:27
openstackgerritMichael Johnson proposed openstack/octavia master: Implement provider drivers - Cleanup  https://review.openstack.org/56743122:00
johnsomNot done yet, but wanted to push a version up.22:00
rm_workk22:03
*** zigo has quit IRC22:11
*** zigo has joined #openstack-lbaas22:11
johnsomSo here is question.  As I have it now, the providers are just a list of names.  Should we make that a list of names and some description string?  I guess that could be added later.22:17
rm_workyeah22:17
rm_worklater22:17
johnsomK22:18
johnsomCould be a pain upgrade wise22:18
rm_workweird, your +2 isn't showing up on those patches22:18
rm_worki wonder if gerrit is broken22:18
* johnsom wonders if I am broken22:18
rm_work</troll>22:19
johnsomMust be gerrit, I don't see any +2s from you either22:19
rm_worklol22:19
rm_workgotta merge the tests first22:19
* rm_work shrugs22:20
rm_workmy plan is:22:20
rm_work1) get all tests written and ready to merge22:20
rm_work2) start reviewing producer code with the tests running against it22:20
johnsomMany of my patches are depends-on with the test, so...22:21
rm_work3) easy +2 because now merged tests pass22:21
rm_workright, so the legitimately NEED the tests to merge first, eh? :P22:21
rm_workalso an EASY one that would make my life a lot easier: https://review.openstack.org/#/c/564082/22:22
rm_workhaving to manually carry that patch22:22
openstackgerritAdam Harwell proposed openstack/octavia master: Add element and flag to disable DHCP on amp images  https://review.openstack.org/52059022:25
johnsomHmm, odd, I thought I did review that failover patch....22:32
*** threestrands has joined #openstack-lbaas22:33
*** threestrands has quit IRC22:33
*** threestrands has joined #openstack-lbaas22:33
johnsomOh, this is api side22:34
johnsomrm_work on this failover API thing, what happens when you call it with a bogus amp ID?22:35
*** threestrands_ has joined #openstack-lbaas22:36
*** threestrands has quit IRC22:38
*** mstrohl has joined #openstack-lbaas22:39
rm_workhmmmm22:42
rm_workthat's a good question22:42
rm_worki think i assumed it was part of the lookup but it might not be22:42
johnsomYeah, something is wrong there, I get 40522:42
johnsomMaybe this is part of that crazy neutron 405 thing22:43
rm_workhmmmm22:44
rm_workyeah 405 because it's a PUT on an amp that doesn't exist I guess?22:44
rm_workwait22:44
johnsomFrankly it's not working for me on existing amps either22:45
rm_workno22:45
rm_workbecause you're doing GET22:45
rm_workit's a PUT22:45
rm_workand it works as expected22:45
johnsomcurl -v -X PUT -H "Content-Type: application/json" -H "Accept: application/json" -H "X-Auth-Token: $current_token"  $test_API_ENDPOINT/v2.0/octavia/amphorae/09f72b8b-0f08-4790-b8ed-ab2f5af766cd22:45
rm_workhttp://paste.openstack.org/show/720718/22:46
johnsom{"code": 405, "description": "", "title": "Method Not Allowed"}22:46
rm_workPUT to /failover22:46
rm_workyou're fail-ing to use the right failover URL :P22:46
johnsomderp22:47
johnsomThis is what happens when you ask me to context switch....  grin22:47
rm_workpecan lookup does the needful22:47
rm_work;)22:47
rm_workwill take "explaining to confused johnsom and getting a review" over "no review"22:47
rm_workliterally any time22:47
johnsomno review for you!22:48
rm_workT_T22:48
rm_workI'm just happy I got to use the phrase "does the neeful"22:48
rm_work*needful22:48
*** mstrohl has quit IRC22:49
johnsomrm_work Trade: https://review.openstack.org/#/c/561369/22:52
rm_worki was actually looking at that one already, but ran into a testing issue due to the heavy rebasing i have to do on top of it22:53
*** fnaval has quit IRC22:56
rm_workjohnsom: interestingly, this makes things a little MORE dangerous for me22:56
rm_workif an amp fails to delete, right now I can see a whole list of them via a quick DB query22:57
rm_workbecause in a pinch I can just delete all health messages, and wait to see which ones come back and which don't22:57
rm_workand then query+join the amp and amp-health tables and see where i'm missing matches22:57
rm_workthis will block the updates for those amps, which means they'll fly under the radar for me until i start doing log inspection22:58
rm_workwhich is almost never at the moment22:58
rm_worki actually have sensu alerts that rely on that DB join method of finding bad amps22:59
rm_workalso, the point you made in the other patch for the amp-cleanup stuff was that we wanted even DELETED amps to stick around if they were still receiving health messages23:00
rm_workwhich ... this will negate23:00
johnsomWell, it's a review, comment it  up so I can re-evaluate later23:01
johnsomHeck I'm tempted to do whack-a-mole and just delete them23:02
rm_workthat's what i do in a lot of cases in my driver <_<23:05
rm_workjohnsom: actually, commented, I think it's *really* wrong23:06
rm_workI think it's doing exactly not what you think it is23:06
rm_workdid you test this and see it doing what you expect?23:06
johnsomUgh, I'm going to add descriptions now.  I think it's an important thing for the UI and to make it not be an upgrade nightmare.23:06
rm_workk23:07
johnsomJust making the config file use a dict instead of a list23:07
rm_workerr is that a thing?23:07
johnsomYeah23:07
rm_workneat I guess23:07
johnsomSo, um, I think I did, but that has been open so long I cannot confirm nor deny testing that code.23:07
johnsomI think I did, but, that was a ton of driver patches ago23:08
openstackgerritAdam Harwell proposed openstack/octavia master: Fix amphora failover API to work with spares  https://review.openstack.org/56408223:09
rm_work^^ plz to redo +223:10
rm_workfixed your nit because it bothered me too23:10
johnsomIt was the cupboard part wasn't it....23:10
rm_workyes T_T23:11
rm_workreminded me of my gradeschool math teachers23:11
rm_work"Oh, so you have 3 left, eh? 3 what? 3 potatoes?"23:11
johnsomlol23:11
rm_work"USE UNITS"23:11
rm_work"No Mrs. Krabappel, 3 *meters*."23:12
rm_workhttps://www.youtube.com/watch?v=ON4sOlxvtbU23:12
rm_workxgerman_: https://review.openstack.org/#/c/564082/23:16
rm_workoh wait hold on that's not the one i need23:17
rm_workhttps://review.openstack.org/#/c/567322/23:17
rm_workyou verbally +2'd :P23:17
rm_work^^ johnsom23:17
rm_workwhich is proved out by https://review.openstack.org/#/c/566199/ passing now23:17
johnsomYeah, waiting on the gates to make sure there isn't something I overlooked23:18
rm_workk23:18
rm_workjohnsom: is something wrong on members?23:22
rm_workhttp://logs.openstack.org/31/567431/1/check/octavia-v2-dsvm-noop-api/3aa2030/testr_results.html.gz23:23
rm_workthat's still in gate, but... already failed the api-noop for member updates, due to timeout23:23
rm_workcan it really be that slow?23:23
johnsomNoOp?23:23
rm_workerr23:24
rm_workok yeah it can't be that slow23:24
johnsomShouldn't that be PENDING_UPDATE it's looking for? with noop there is nothing to make it active right?23:24
rm_worksomething is up23:24
rm_workerr23:24
rm_workI think noop it still goes active23:24
rm_workit uses the "noop amp driver"23:25
rm_workso it goes through to the worker and such23:25
rm_workand it should go active23:25
rm_workit passes on all the other patchsets, like ... master for example23:25
rm_workalso the rest of them passed (create / show / etc) which also all wait for ACTIVE23:26
rm_workso my initial guess would be "something broke update"23:26
rm_worksame failure on the members patch23:26
rm_workhttp://logs.openstack.org/39/566939/3/check/octavia-v2-dsvm-noop-api/6df97ea/testr_results.html.gz23:26
rm_workdid not fail on the pools patch23:27
rm_worksticking with my guess23:27
rm_workyep failing on everything after members23:27
rm_worki think23:27
rm_workon the plus side, https://review.openstack.org/#/c/567322/ is good now23:29
rm_workah no, stuff after members didn't run23:30
rm_workexcept cleanup23:30
rm_workbut it did fail on both in the same way23:30
rm_workjohnsom: you've got a +2 on the first two in the chain23:37
johnsomNice23:37
rm_workI assume you're going to update the third one (LB) for the description?23:38
johnsomWait, what is wrong with the description?23:38
rm_worki thought you wanted to add a description to providers in the initial migration?23:39
johnsomIt's in the config file23:39
johnsomWe only store the provider name in DB23:39
rm_workerrr23:39
rm_workoh23:39
rm_worki mean yes23:39
rm_worki thought you were saying you wanted to add the description to the DB23:39
rm_worknot what you meant?23:39
johnsomI've already done it in this patch I'm working on. Super easy23:39
rm_workso... you ARE. but it's a separate migration?23:40
johnsomhttps://www.irccloud.com/pastebin/2kZW54jD/23:40
rm_workerrr23:40
johnsomNo, it will never be in the DB23:40
rm_workok23:40
rm_workhow will the UI get to it?23:40
rm_worki thought the point was because the UI would want it23:40
rm_workso the API would return it23:40
johnsom /providers API23:40
rm_workah, i guess it would return from the config too23:40
johnsomYep23:41
rm_workwait so why do we even have them in the DB23:41
rm_workso we can have a constraint?23:41
johnsomI don't want to store what drivers exist or are enabled in the DB. That means people have to touch the DB adding /removing drivers23:41
rm_workI feel like personally I might rather simplify the config file, and have the descriptions go in the DB23:41
rm_workerr23:41
rm_workbut we DO store them?23:41
rm_workor no23:41
rm_worknot at all?23:41
rm_workah i guess it is just a column of text23:42
johnsomNo, we store the provider name the LB was created with. nothing elese23:42
rm_workok, i thought they were going in the DB23:42
rm_workwell, nm them23:42
rm_work*then23:42
rm_workOH this is the patch where i was going on about a thing23:42
*** fnaval has joined #openstack-lbaas23:46
*** Swami has quit IRC23:49
johnsomYeah, look at listener, I think I changed it there23:51
rm_workjohnsom: https://review.openstack.org/#/c/563795/23:57
rm_workdid you update all of what I just commented already in another patch? lol23:57
johnsomYeah, maybe, sorry, I will reply on the comments if so.23:58
rm_workI could probably do a follow-up and just do it all ;P23:58
« Tuesday, 2018-05-08 Index Thursday, 2018-05-10 »

Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!