16:00:37 <vivek_> #startmeeting Horizon LBaaS v2 UI discussion
16:00:38 <openstack> Meeting started Thu Jul 16 16:00:37 2015 UTC and is due to finish in 60 minutes.  The chair is vivek_. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:39 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:42 <openstack> The meeting name has been set to 'horizon_lbaas_v2_ui_discussion'
16:00:45 <vivek_> Hi All
16:01:41 <ajmiller> hi
16:01:50 <vivek_> o/
16:01:56 <KunalGandhi> o/
16:02:04 <xgerman> o/
16:02:16 <madhu_ak> hi
16:02:40 <ganeshna> hi
16:02:41 <mtonse> hi
16:02:50 <amotoki> hi
16:02:52 <jwarendt> hi
16:03:17 <vivek_> @dougwig joining ?
16:03:48 <xgerman> he might be getting his MRI
16:04:25 <vivek_> everything ok ?
16:04:47 <xgerman> he has some pulled muscle thing
16:04:58 <vivek_> ok. hope things are fine.
16:04:59 <vivek_> lets get started.
16:05:10 <xgerman> yep
16:05:25 <vivek_> The agenda for this meeting is to discuss Horizon LBaaS v2 UI
16:05:46 <vivek_> We have developed UI panels keeping v2 APIs in mind
16:06:07 <vivek_> The code is currently sitting in my public github:
16:06:18 <vivek_> https://github.com/vivekjain7/horizon
16:06:28 <vivek_> plan is to move it under: https://github.com/openstack/neutron-lbaas
16:06:38 <vivek_> for development and coloboration
16:06:39 <xgerman> no, we have a new repo
16:06:53 <vivek_> oh ok...we got new repo already ?
16:07:11 <amotoki> I think the key question is whether we want to have a separate repo or a code in horizon tree for *long term*.
16:07:24 <xgerman> https://review.openstack.org/#/c/202281/
16:07:32 <ypraveen> I think code in horizon tree is the best way going forward;
16:07:55 <xgerman> dougwig created a new repo so Horizon + LBaaS cores can collaborate modeled on how Designate does it
16:08:19 <vivek_> i prefer name lbaas-dashboard vs neutron-lbaas-dashboard
16:08:27 <ypraveen> what are the arguments against having it in horizon?
16:08:31 <amotoki> xgerman: yes. it is a good direction that we can move things fast.
16:08:45 <xgerman> it’s unlikely Horizon will make LBaaS people core and vice versa
16:09:00 <KunalGandhi> @vivek_ .. +1
16:09:11 <xgerman> vivek_ please comment on the patch
16:09:31 <vivek_> ok
16:09:49 <xgerman> thanks
16:10:18 <vivek_> so once the repo is available, I will push initial code there.
16:10:30 <xgerman> that would be great
16:10:38 <ypraveen> how easy is it to later merge it into horizon?
16:11:41 <vivek_> We need to discuss how separate project will be build and integrated with horizon ?
16:11:41 <amotoki> honeslty horizon team is exploring a way how "horizontal project works effectively"
16:12:06 <amotoki> which means how horizon team and each service team can collabotrate.
16:12:23 <xgerman> yeah, I think we don’t have enough info at that point
16:12:59 <vivek_> ok, so for short term lbaas team and horizon team can work on this new repo for lbaas dashboard development
16:13:05 <KunalGandhi> @xgerman .. so once the code is contributed to a different repo, does it need to get merged with the horizon code for releases ?
16:13:07 <amotoki> I think a single tree is the only answer.
16:13:28 <amotoki> It is one of possible ways. I haven't reached david today.
16:13:38 <vivek_> we can merge the code to horizon in case we choose that route or time is limited.
16:14:04 <ypraveen> @vivek_ From what I know, designate-dashboard can be downloaded as a pip package and one can add it "enabled" list in their horizon settings file to enable it
16:14:59 <ypraveen> only difference with designate I can think of: designate is creating a totally new panel, where horizon already has "loadbalancer" panel
16:15:12 <vivek_> @ypraveen got it. We have a developer at ebay who also worked on designate dashboard. I will chat will him as well.
16:15:23 <amotoki> ypraveen: it is a good point.
16:15:31 <xgerman> that might be a good idea + I don’t think we need to solve that today
16:15:31 <ypraveen> users would most likely use either v1 or v2..
16:15:32 <vivek_> horizon's existing LB panel is for v1
16:15:37 <xgerman> +1
16:15:38 <vivek_> v2 panel will be totally different
16:16:35 <ypraveen> so they will have to disable the lbpanel that comes with horizon and add the v2 panel if they want to use v2
16:17:14 <vivek_> Right. lets decide on short-term path while we continue debating on long-term approach.
16:17:23 <ypraveen> Most likely it will work ok; probably good to have some horizon core weigh on this
16:17:29 <amotoki> ypraveen: it is an option. we need to discuss the short term approach
16:17:53 <vivek_> i think irrespective of where code will go finally, we need to develop the code first
16:18:19 <amotoki> I think an important thing is what is a suggested approach as we, lbaas team.
16:18:29 <crc32> xgerman what time is everyone meeting in the room?
16:18:38 <xgerman> 9 am
16:18:55 <amotoki> 1am for me
16:18:59 <crc32> so has rackspace arrived? Its 9:00 now right?
16:19:05 <xgerman> different discussion
16:19:21 <ypraveen> @vivek_ agreed; we can figure out the how to plug in after a bit
16:19:40 <vivek_> correct @ypraveen. lbaas-dashboard new repo will be a good place to bring lbaas v2 dashboard to completion.
16:19:47 <xgerman> +1
16:19:48 <crc32> hello blogan
16:19:56 <blogan_> hello
16:20:03 <crc32> whats the VCV url?
16:20:06 <crc32> VC
16:20:10 <blogan_> i have no idea
16:20:22 <crc32> is adam there?
16:20:24 <vivek_> so xgerman, any timeline on how long it takes for repo to appear in openstack github ?
16:20:26 <crc32> yet?
16:20:29 <vivek_> once approved ?
16:20:40 <blogan_> haven't set it up, trying to figure some internal stuff out
16:20:53 <xgerman> almost immediately - there is another patch for gerri though which also needs to land
16:21:06 <amotoki> i think we can easily disable LBaaS v1 panel. It has no dependency on ohter panels (though we need to chekc it carefully).
16:21:38 <vivek_> @amotoki lbaas v1 panel comes disabled by default
16:21:45 <vivek_> as far as i remember
16:22:09 <amotoki> vivek_: I think it is enabled by default now, but it may depned on distros.
16:22:29 <amotoki> but it is not so important.
16:23:26 <xgerman> agreed
16:23:36 <ypraveen> @amotoki someone mentioned that the floating-ip panel depends on it? I might be wrong
16:24:04 <vivek_> so we have agreement on short-term approach that development will happen in new repo.
16:24:06 <amotoki> ypraveen: yes. i think I mentioned it. I need to check it carefully
16:24:09 <ypraveen> @amotoki  +1 for "not so important"
16:24:21 <vivek_> lets discuss the strategy for development.
16:24:29 <ypraveen> @vivek_ +1
16:24:34 <vivek_> I can update on current status
16:24:37 <amotoki> vivek_: +1
16:24:50 <xgerman> vivek_ +1
16:25:54 <vivek_> lbaas v2 UI panel is mostly ready on READ part
16:26:22 <vivek_> i mean when entities are created via CLI/API, v2 UI is able to display most of the information
16:26:39 <vivek_> We have UI panels in place for Create , Update and DELETE
16:27:03 <vivek_> UI flow is similar to nova instance creation flow
16:27:28 <dougwig> here, sorry, just finished getting my arm MRI'ed.
16:27:42 <vivek_> which means one create workflow (multiple tabs) to create all entities to make functional LB  end-to-end
16:28:01 <vivek_> @dougwig, no problem. hope you are doing well.
16:28:03 <amotoki> dougwig: no problem. is your arm okay?
16:28:37 <ypraveen> awesome vivek_, wish I could see you demo it. I will try it out in a short while.
16:28:49 <vivek_> Most part remaining in for create/update flow is the API calls and orchestration.
16:28:50 <dougwig> nothing life threatening. tore my bicep tendon. find out soon if it needs surgery.
16:29:28 <vivek_> dougwig: wish you a faster recovery
16:29:36 <xgerman> +1
16:29:45 <amotoki> +many
16:30:14 <madhu_ak> dougwig: hope you recovers soon
16:30:31 <dougwig> scrolling back, i'm fine with horizon or separate repo. i personally think that monolithic cross-functional repos are not going to scale, which has me lean away from "in horizon repo", but it's not a strong lean, nor is it an indication that i'm at all unhappy with folks on that team.
16:30:39 <dougwig> ty all.  :)
16:30:40 <vivek_> create flow will collect all LB related information in one go, ex: LB name,port,method,members, SSL, monitor
16:31:44 <vivek_> now since there is no one API for create...horizon lbaasv2.py needs to all create APIs one by one and orchestrate
16:32:00 <sjmc7> from horizon's perspective, they are moving away from having UIs live in the horizon tree
16:32:04 <vivek_> ex: createLB, createPool, createMonitor, createMember etc.
16:32:11 <sjmc7> sahara has moved to a contrib/ module inside horizon as a halfway house
16:32:58 <amotoki> I think we have (perhaps) many features in LBaaS on top of v2 efforts, so a seprarete repo works for fast imrpovement and horizontal projects can scale more
16:33:34 <amotoki> sjmc7: true. "contrib" means we share horizon and sahara cores for improvements.
16:34:00 <sjmc7> yeah. one model discussed in vancouver was separate repos (or contrib modules) with join cores
16:34:18 <sjmc7> the horizon midcycle is next week and this will be a topic
16:34:27 <dougwig> certainly a joint core team would make sense here, i agree.
16:35:26 <ypraveen> @sjmc7 that sounds better; we need similar thing for heat too -- both those are always several features behind
16:35:54 <sjmc7> yes - it's a problem that horizon-core doesn't have enough context on the services so nobody feels able to review
16:36:17 <sjmc7> the intent is service teams can consult with horizon cores but not be held up waiting for reviews
16:36:22 <amotoki> sjmc7: really true. I can only catch up with neutron changes :-(
16:36:34 <sjmc7> anyway, didn't mean to derail but german asked me to keep an eye on this :)
16:36:48 <vivek_> thanks sjmc7.
16:37:08 <amotoki> In addition, gerrit dashboard help us review multiple repos, so I don't have much worries on having separete repos related to horizon.
16:37:32 <xgerman> thanks sjmc7
16:37:47 <ypraveen> @vivek_ one complication with multi-post workflow is that we have to be able to cleanup if something fails
16:38:11 <vivek_> @ypraveen, might not be needed entirely
16:38:23 <amotoki> "multi-post"?
16:38:37 <vivek_> current behavior in openstack is that if things fails...leave it there with error state
16:38:48 <dougwig> blogan: you around?  he submitted a spec for a one-shot create.
16:39:13 <vivek_> awesome. one-shot create is what we need :)
16:39:24 <vivek_> i have been asking for that since long :)
16:39:25 <ypraveen> @amotoki, if we have one workflow for creating several objects in one shot, then we need to do multiple post APIs
16:39:35 <blogan_> dougwig: i'm here, wasn't getting notifications
16:39:47 <amotoki> ypraveen: i see.
16:39:49 * xgerman walked over and lerted him
16:39:49 <dougwig> blogan_: that's because there's two of you
16:39:58 <blogan_> dougwig: not right now
16:40:04 <blogan_> soon though...
16:40:05 <ypraveen> @vivek for all other workflows, as far as I know, there is only one post API call
16:40:18 <ypraveen> so, it is ok to leave them in error state
16:40:27 <blogan_> but yeah one-shot create i have a spec for, it got accepted, i have not started on it yet though
16:40:37 <TrevorV> dougwig, You just missed a crucial step in the ritual summoning.
16:41:03 <crc32> blogan_ whats the eather pad for the mid cycle. The one that has the VC URL?
16:41:10 <ypraveen> but, if someone tries to create a LB instance with 10 members and it fails, then we may have several objects left around
16:41:24 <blogan_> https://etherpad.openstack.org/p/LBaaS-FWaaS-VPNaaS_Summer_Midcycle_meetup
16:41:27 <vivek_> blogan_, if we can get one-shot create, it will ease lot of work on horizon side
16:41:44 <vivek_> can you please expedite this request ?
16:41:45 <blogan_> vivek_: i know :), it'll help us out too
16:42:11 <ypraveen> +1 for one_shot API
16:42:14 <blogan_> vivek_: by Liberty?
16:42:15 <crc32> the VC URL is not up yet?
16:42:19 <amotoki> it is a kind of bulk create. it would help horizon much
16:42:20 <blogan_> Liberty-3
16:42:38 <dougwig> if we can't get it by liberty-2, i don't think there's time to adapt horizon by liberty-3.
16:42:45 <blogan_> crc32: don't think adam has it up yet, he's heads down in hte usage poller stuff
16:42:53 <blogan_> dougwig: when is liberty-2?
16:43:14 <dougwig> july 30th
16:43:15 <dougwig> https://wiki.openstack.org/wiki/Liberty_Release_Schedule
16:43:19 <blogan_> oye
16:43:26 <vivek_> i mean much sooner than liberty :)
16:43:42 <crc32> ok I'll be back in half an hour. :/
16:44:10 <blogan_> honestly, im not sure ill be able to get it done by then
16:44:43 <vivek_> ok, then we can proceed with multi-api calls..without rollbacks
16:44:58 <vivek_> and replace with one-shot when ready...what say everyone ?
16:45:02 <xgerman> +!
16:45:04 <xgerman> +1
16:45:06 <KunalGan_> +1
16:45:07 <xgerman> works for me
16:45:07 <dougwig> vivek_: i think that's reasonable.
16:45:21 <blogan_> if i happen to think i can get it done by then ill let yall know asap
16:45:35 <openstackgerrit> Sherif Abdelwahab proposed openstack/octavia: Keepalived supporting amphorae image  https://review.openstack.org/202691
16:45:39 <amotoki> sounds reasonable. one-shot for create is useful
16:45:40 <vivek_> by blogan_liberty-2 ?
16:45:46 <blogan_> vivek_: yes
16:45:56 <vivek_> that will be great..thanks.
16:46:01 <amotoki> we can delete them one by one :-)
16:46:12 <vivek_> assuming that one-shot is also for update ?
16:46:32 <blogan_> vivek_: i wouldn't count on that for the first commit
16:46:38 <amotoki> vivek_: it can be deferred...
16:46:40 <ypraveen> rollback may not be that hard;
16:47:00 <vivek_> blogan_, updates are ok independently .
16:47:24 <ypraveen> +1 for independent updates
16:48:06 <vivek_> @ganeshna @mtonse any ideas / questions ?
16:48:46 <ypraveen> does anyone know when Barbican UI support will be added?
16:48:55 <ypraveen> for uploading and managing certificates?
16:50:06 <amotoki> I don't know any so far about barbican
16:50:08 <ganeshna> vivek_: no questions from me now..
16:50:21 <vivek_> we can simplify lbaas UI to just take container ID for pre-existing cert created via barbican
16:50:36 <xgerman> rm_work barbican?
16:50:54 <mtonse> so can we proceed with multi-api calls?
16:51:11 <vivek_> i think that is the approach for now
16:51:19 <dougwig> mtonse: yes
16:51:24 <mtonse> ok
16:51:51 <dougwig> horizon that leaks objects on error states is about 1000x better than what we have *today*, and we can iterate on it.
16:51:59 <ypraveen> +1 for multi-api call;
16:52:04 <xgerman> +1
16:52:19 <amotoki> +1 :)
16:52:21 <vivek_> dougwig +1 :)
16:52:40 <vivek_> ok. now most important question of all
16:53:07 <vivek_> who all on table for contributing to horizon lbaas dashboard :)
16:53:21 <xgerman> :-)
16:53:28 <ypraveen> @dougwig, if object is in error state, then it is ok; with multi-api call, some objects will be left in ACTIVE state. I think cleaning up if the multi-api call fails at some point should be pretty easy
16:53:50 <dougwig> vivek_: i'm guessing the folks that are interacting here, plus whatever horizon cores we can wrangle in to help.
16:54:22 <vivek_> @blogan_, does one-shot API rolls back on error of single entity ?
16:54:48 <ypraveen> one-shot should be done in a transaction, so I am assuming it will
16:55:15 <KunalGan_> @vivek_ .. i am thinking the one-shot API would be ATOMIC..
16:55:30 <vivek_> ypraveen, i assume that too..just wanted to get confirmation from blogan_
16:55:32 <amotoki> at least I can join reviews as horizon-core
16:55:49 <KunalGan_> we can have @blogan_ confirm if that is the case
16:56:01 <vivek_> i think since we will be moving to one-shot anyways, lets not invest much time on rollbacks during multi-api calls
16:56:11 <ypraveen> we can make sure that @blogan_ implements it that way :)
16:56:48 <dougwig> one-shot can't be a transaction, because it involves driver calls, but it should appear "atomic" in terms of rolling back on errors.
16:56:51 <dougwig> i think.
16:57:17 <ypraveen> @dougwig makes sense; for a second, I forgot about the drivers :)
16:57:19 <blogan_> vivek_: thats yet to be determined, what do yall think is best? i would think a rollback would be good but just tossing it into ERROR state would be faster
16:57:39 <vivek_> thanks dougwig. that's what i call in atomic from user prespective
16:58:08 <dougwig> i think error state is fine for a first commit, then rollback could be added later. but that's me.
16:58:16 <blogan_> yeah thats what i mean
16:58:18 <vivek_> +1 dougwig
16:58:46 <openstackgerrit> Sherif Abdelwahab proposed openstack/octavia: Keepalived supporting amphorae image  https://review.openstack.org/202691
16:59:02 <amotoki> I think one-shot has two meanings: one-shot operation for usesrs, and the other is less number of calls of APIs. error states works for me too.
16:59:15 <ypraveen> @vivek_ I think it will be good to have individual create panels anyways, in addition to the one-shot; I am assuming that you already have that in plan
16:59:49 <vivek_> @ypraveen, i do not have plan for individual create panels
17:00:26 <dougwig> i'm not sure they're needed if the create pane is complete.  i use nova launch as a comparison, e.g.
17:00:39 <vivek_> UI panels will be one-shot. Initially horizon will make individual API calls.
17:00:53 <ypraveen> I am thinking of how to add "member" to an existing LB
17:00:56 <vivek_> later horizon will switch to one-shot API and that completes our story :)
17:01:10 <ypraveen> or how to add a monitor
17:01:12 <vivek_> it will be easy...you need to check the current UI ypraveen
17:01:16 <ypraveen> or a new listener
17:01:29 <vivek_> all cases are covered ypraveen with current ui
17:02:07 <vivek_> i mean - all cases are covered with currently proposed one-shot ui
17:02:19 <KunalGan_> @vivek_ .. it might make sense to share the demo video with everyone so it is easier to visualize for folks who have not seen it
17:03:14 <ypraveen> Will check; thanks
17:03:48 <ypraveen> +1 for demo link
17:03:58 <amotoki> vivek_: could you summarize and post our discussion and consensus to the list? we can input our discussions to David. sjmc7 may input in the next week.
17:04:13 <vivek_> sure amotoki
17:04:26 <amotoki> vivek_: appreciated!
17:04:39 <ypraveen> vivek_, thanks for leading the effort.
17:05:07 <xgerman> +1
17:05:29 <vivek_> ypraveen, please refer this video we presented at Vancouver summit: https://www.youtube.com/watch?v=fNR0SW3vj_s
17:06:00 <vivek_> it will answer most questions on lbaas  UI workflows
17:06:21 <ypraveen> thanks!
17:06:25 <vivek_> how to add/remove members, how to add monitors, how to reuse IPs with different listers etc
17:06:31 <vivek_> feedbacks are welcome
17:06:53 <vivek_> ok, i will conclude this meeting
17:07:00 <vivek_> thanks everyone for participating
17:07:05 <blogan_> thanks everyone, we relaly need this :)
17:07:29 <vivek_> blogan_ i know. lets make it happen this time.
17:07:33 <amotoki> thanks
17:07:46 <amotoki> do we need #endmeeting in this channel?
17:07:48 <dougwig> many thanks all.
17:07:50 <vivek_> yes
17:07:50 <dougwig> yep
17:07:54 <vivek_> #endmeeting