16:01:53 <dougwig> #startmeeting neutron lbaas
16:01:54 <openstack> Meeting started Tue Feb 24 16:01:53 2015 UTC and is due to finish in 60 minutes.  The chair is dougwig. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:01:55 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:01:58 <openstack> The meeting name has been set to 'neutron_lbaas'
16:02:00 <dougwig> #topic roll call
16:02:01 <johnsom> o/
16:02:03 <dougwig> #chair xgerman
16:02:03 <openstack> Current chairs: dougwig xgerman
16:02:04 <ajmiller> o/
16:02:09 <dougwig> in case i space out again
16:02:10 <dougwig> :)
16:02:12 <dougwig> hiya
16:02:17 <xgerman> dougwig thanks
16:02:45 <ptoohill> o/
16:02:54 <kobis> hi
16:02:55 <dougwig> i know that rax folks are at a big internal meeting today.
16:02:58 <dougwig> blogan is even presenting.
16:03:04 <ptoohill> yea, in 30 mins
16:03:05 <dougwig> heckle him for me, please.
16:03:12 <xgerman> wow!
16:03:15 <ptoohill> have been and will continue in your honor
16:03:24 <dougwig> start chanting.  towgan! towgan! towgan!
16:03:30 <ptoohill> :P lol
16:03:31 <xgerman> lol
16:03:31 <kobis> :)
16:03:39 <dougwig> #topic Announcements
16:03:52 <dougwig> kilo-3 submission freeze is 3/5, which is coming up fast.
16:03:56 <johnsom> I thought it, you said it....
16:04:24 <xgerman> yep, scary fast
16:04:47 <dougwig> we have several vendor drivers submitted; they will need 3rd party CI's by then.
16:04:55 <dougwig> holler at me if you need any help with those.
16:05:07 <dougwig> any other announcements today?
16:05:17 <ptoohill> Big review that needs eyes, follow the chain back: https://review.openstack.org/#/c/158189/
16:05:29 <ptoohill> The agent driver is 'done' if we consider that an announcment
16:05:40 <dougwig> save that for one topic for me. :)
16:05:46 <mwang2_> Lbaas API v2 doc has been merged :)
16:06:06 <xgerman> Aish? Your news?
16:06:07 <dougwig> ok, so we're not waiting.  :)
16:06:10 <mwang2_> min
16:06:10 <ptoohill> wooten
16:06:28 <Aish> Mine?  CLI document?
16:06:35 <xgerman> yep
16:06:36 <dougwig> #topic v2 update
16:06:45 <dougwig> I was going to ask for the status of docs and tests.
16:06:48 <johnsom> There is a fix in for the "name" required on load balancer issue in cli: https://review.openstack.org/#/c/158007/
16:06:50 <dougwig> docs has already started.  :)
16:07:06 <dougwig> the agent driver is ready for review, see ptoohill's chain above
16:07:18 <dougwig> any more reviews to highlight?
16:07:22 <ajmiller> The neutron-lbaas devstack external plugin patch is ready for final review, has 1 +2 from dougwig
16:07:23 <ajmiller> https://review.openstack.org/#/c/155540/
16:07:39 <ajmiller> I've been using it heavily the last few days, with good results.
16:07:57 <dougwig> an overview of all lbaas patches: https://review.openstack.org/#/q/(openstack/neutron-+AND+lbaas)+status:open,n,z
16:08:06 <ptoohill> pasting again just in case: https://review.openstack.org/#/c/158189/
16:08:13 <dougwig> note the tis and l7 extensions are -1 in jenkins.  evgenyf, can you look at those?
16:09:06 <dougwig> anyone from the tests group here today?
16:09:09 <evgenyf> looking
16:09:19 <Aish> lbaas v2 CLI document has been merged.
16:09:24 <dougwig> status last week was api tests by the end of last week.  did we make that?  have we started any functional tests?
16:09:29 <dougwig> Aish: nice.
16:09:41 <ptoohill> I didnt see them at desk earlier on our side, not sure if they are here at presentation or not. i may be the only from team in this meeting today
16:09:44 <Aish> Thanks. :) @dougwig
16:09:55 <dougwig> ptoohill: ok, thanks.
16:10:09 <xgerman> ok, I have asked Madhu from our site to look into the reviews
16:10:21 <ptoohill> I know they ran into a bump and our primary tester got pulled off for a v1 issue yesterday afternoon
16:10:30 <dougwig> we're in pretty good shape, with extension + plugin + cli + devstack + docs, reviews out for the agent driver + vendor drivers + tls/l7.  tests are the biggest hole, along with closing some of those reviews.
16:10:32 <ptoohill> they were saying they were close to being done from what i understood
16:11:06 <xgerman> great
16:11:19 <dougwig> ptoohill: ask them to ping me when they're done, and we can talk about rolling a jenkins job for v2.
16:11:40 <ptoohill> kk, ill make sure to let them know
16:11:43 <xgerman> our QA should come off their internal project soon, too, and I already asked them to look at this...
16:11:57 <dougwig> xgerman: which part?  jenkins or functional or other?
16:12:06 <dougwig> or just breaking v2 in general?
16:12:31 <xgerman> whatever is needed...
16:12:42 <xgerman> otherwise it's breaking ;-)
16:13:01 <dougwig> awesome.
16:13:10 <dougwig> let's talk when they're ready.
16:13:14 <xgerman> k
16:13:30 <dougwig> anyone have any other blocking issues or urgent reviews for v2?
16:13:42 <sballe__> mornin
16:13:51 <dougwig> moving on
16:13:54 <dougwig> #topic Status and Object manipulation (ptoohill)
16:13:58 <dougwig> ptoohill: the floor is yours
16:14:38 <ptoohill> So, assuming i dont get distracted and off topic the 'problem' or question i want to pose is about statuses and behaviour of the entire tree
16:15:15 <dougwig> or put another way, if a member is in error, but the parent is still operational, is it in error or active state, right?
16:15:17 <ptoohill> my question is in simple terms: If a member does not provision (for example) do we want to set the load balancer to a degraded state as well?
16:15:24 <ptoohill> yea
16:16:32 <ptoohill> If the lb is degraded or set to 'error' or whatever state that makes the load balancer immutable for the time being the user cannot update or remove the problem and becomes an operations problem
16:16:34 <dougwig> blogan and i were chatting last night, and my suggestion was: leave the object status alone (only set member), but calculate the /status tree dynamically, and if any of its children are in error state, flow a "degraded" state uphill on the fly.  it gets kind of insane if you try to ripple it in the db, and that goes against us converting those db objects to
16:16:34 <dougwig> logical entities in the future.
16:17:12 <johnsom> I think that if any of the members are not ACTIVE and not disabled the parent should be degraded
16:17:25 <xgerman> +1
16:17:28 <sballe__> +1
16:17:42 <ptoohill> then, is degraded an immutable state?
16:17:52 <ptoohill> can the user not remove the failed member and try again?
16:18:04 <johnsom> I think dougwig and I are saying the same thing for clarity
16:18:47 <ptoohill> i just think of the pain that comes if the user cant do simple operations to potentially clean up a failure on our side
16:18:58 <johnsom> I like the idea that a user can solve their own problems
16:19:05 <dougwig> i think a user should be able to remove and re-add a member.
16:19:11 <xgerman> +1
16:19:16 <dougwig> i'm not sure anything we said precludes that.
16:19:18 <johnsom> +1
16:19:23 <ptoohill> ok, if we allow that then im really fine with any status tree updates that happen
16:19:48 <xgerman> Q is how much we like dynamically chnaging the tree for output
16:19:53 <ptoohill> it didnt, i was just unclear if degraded loadbalancer or an errored member would be immutable (which it currectly is)
16:19:59 <xgerman> should we kick up that can to the UI
16:20:10 <xgerman> ?
16:20:19 <ptoohill> right now, no operations can happen after a member fails in otherwords
16:20:28 <dougwig> when i logged off last night, blogan was saying that he wanted to think about it, so i think he has some input here as well.  he was tentatively in favor of the dynamic status plan, which is a change from today.
16:20:29 <ptoohill> so this behaviour needs to change is why this topic came up
16:20:41 <ptoohill> yep
16:20:47 <ptoohill> fair enough, we can sideline this
16:21:01 <dougwig> ok
16:21:03 <dougwig> #topic Open discussion
16:21:07 <dougwig> go nuts.
16:21:10 <johnsom> I think pending delete and pending update should be immutable, but I can't think of a good reason error should be
16:21:15 <dougwig> vendors, any questions on drivers or CI's, now is a good time.
16:21:26 <dougwig> johnsom: +1
16:21:32 <santosh_ns> I have  following queries wrt NetScaler v2 driver and CI requirements: 1.Where can i find equivalent v2 api tests to include at CI setup? 2. I am planning to introduce local test script (for CI setup) with     neutron lbaas commandline tests i.e Create,Update,Delete api tests    for loadbalancer,Listener,Pool,Member,HealthMonitor in mentioned order.    Please suggest?
16:21:34 <ptoohill> fair enough johnsom
16:22:18 <dougwig> santosh_ns: it'll be in this chain: https://review.openstack.org/#/c/155431/
16:22:36 <dougwig> you may want to wait a bit for the chain to finish and a jenkins job to be added, to which you can just sub in your driver.
16:22:54 <dougwig> in the meantime, adding the basic CI/devstack/lbaasv2 install would let you get a head start on the basic CI plumbing
16:24:10 <ajmiller> FYI, I have an updated post on using the new devstack plugins to install V2
16:24:12 <ajmiller> https://chapter60.wordpress.com/2015/02/20/installing-openstack-lbaas-version-2-on-kilo-using-devstack/
16:25:18 <ptoohill> awesome ajmiller!
16:25:35 <dougwig> santosh_ns: ajmiller's post will also be relevant for you.
16:25:42 <dougwig> anything else today, or can we blast out of here?
16:26:16 <dougwig> alright, bye folks
16:26:16 <ptoohill> looks like were good here
16:26:19 <sballe__> bye
16:26:23 <ptoohill> pce \o
16:26:25 <dougwig> #endmeeting