18:00:20 <SergeyLukjanov> #startmeeting sahara
18:00:20 <openstack> Meeting started Thu Oct  1 18:00:20 2015 UTC and is due to finish in 60 minutes.  The chair is SergeyLukjanov. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:00:21 <elmiko> very classy crobertsrh
18:00:22 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:00:24 <openstack> The meeting name has been set to 'sahara'
18:00:25 <SergeyLukjanov> #link https://wiki.openstack.org/wiki/Meetings/SaharaAgenda
18:00:27 <crobertsrh> I try
18:00:27 <vgridnev> hello
18:00:31 <esikachev> hi
18:00:38 <SergeyLukjanov> #topic sahara@horizon status (crobertsrh, vgridnev)
18:00:45 <SergeyLukjanov> #link https://etherpad.openstack.org/p/sahara-reviews-in-horizon
18:00:51 <SergeyLukjanov> how is it going with horizon?
18:00:57 <vgridnev> I have nothing in this topic today
18:01:03 <crobertsrh> No progress on the existing reviews.
18:01:12 <crobertsrh> I haven't added anything new
18:01:32 <crobertsrh> We should start a list of some things to improve in the UI for M
18:01:47 <vgridnev> crobertsrh, good idea, I have some
18:02:04 <vgridnev> ideas*
18:02:08 <crobertsrh> Maybe start an etherpad.  If there are "big" things, we can talk about them at summit.
18:02:13 <elmiko> +1
18:02:24 <SergeyLukjanov> agree
18:03:22 <SergeyLukjanov> #topic News / updates
18:03:37 <david-lyle> there is a fair amount of validation that could be happening in the guides that would be helpful (flashback to patch testing)
18:03:47 <elmiko> not much from me, i've mainly been working on the sparkhara presentation for summit
18:04:11 <crobertsrh> david-lyle:  Yes.  Guide improvement is on my radar.
18:04:15 <elmiko> on the upside, i've got a small spark app that is processing sahara contriller logs =)
18:04:21 <elmiko> *controller
18:04:33 <vgridnev> I want to start removal direct engine, any objections?
18:04:45 <crobertsrh> No objection from me.
18:04:57 <elmiko> vgridnev: would we support it for M then have it removed for N?
18:05:30 <esikachev> improvement scenario framework, add ambari 2.3 job on ci, working on cluster verification checks
18:05:41 <elmiko> vgridnev: or just remove it as of M-1?
18:06:40 <vgridnev> not sure, by initial plan we should remove that in M
18:07:27 <elmiko> do we have a spec for deprecating the direct engine?
18:07:31 <SergeyLukjanov> the plan was to remove in eraly M
18:07:37 <elmiko> ok, cool
18:07:43 <SergeyLukjanov> elmiko, it was deprecated in early L
18:07:47 <crobertsrh> It was dep in L
18:07:48 <vgridnev> elmiko, yes
18:08:03 <SergeyLukjanov> #link http://specs.openstack.org/openstack/sahara-specs/specs/liberty/deprecate-direct-engine.html
18:08:03 <elmiko> ok, no objection from me then
18:08:09 <crobertsrh> I think that's when I finally stopped using it myself :)
18:08:20 <elmiko> i thought we did, just couldn't remember >.<
18:08:26 <elmiko> thanks SergeyLukjanov
18:08:46 <SergeyLukjanov> vgridnev, I think you should make a spec "final direct engine removal"
18:09:04 <elmiko> +1, i think that would be great for the downstream =)
18:09:26 <SergeyLukjanov> actually, we already have a deletion working even after direct engine removal - https://review.openstack.org/#/c/173762/
18:09:34 <SergeyLukjanov> so, it should be ok from backward compat PoV
18:09:56 <vgridnev> ok, will do that
18:10:11 <SergeyLukjanov> actually, warning was placed as well
18:10:11 <SergeyLukjanov> https://review.openstack.org/#/c/173740/17/doc/source/userdoc/configuration.guide.rst,cm
18:10:46 <SergeyLukjanov> in this file https://review.openstack.org/#/c/173740/17/sahara/main.py,cm
18:10:55 <SergeyLukjanov> so, as promised it's time to do it
18:10:56 <SergeyLukjanov> :)
18:11:07 <elmiko> i knew we had the warning, and yea i agree it's probably time to remove it
18:11:41 <SergeyLukjanov> let's raise concerns on spec if there will be any
18:11:45 <elmiko> +1
18:11:47 <SergeyLukjanov> any other news or updates?
18:12:20 <crobertsrh> Nothing from me
18:12:28 <SergeyLukjanov> #topic Liberty release
18:12:42 <SergeyLukjanov> so, we have an RC1 last Friday
18:12:55 <SergeyLukjanov> and final stable liberty client 0.11.1
18:13:00 <elmiko> \o/
18:13:12 <vgridnev> great
18:13:15 <SergeyLukjanov> I don't see any release critical bugs so far
18:13:23 <SergeyLukjanov> so, no need for rc2 now
18:13:28 <elmiko> nice
18:13:38 <SergeyLukjanov> #link https://wiki.openstack.org/wiki/Liberty_Release_Schedule
18:13:53 <SergeyLukjanov> esikachev, how is it going with testing rc1 &
18:13:55 <SergeyLukjanov> ?*
18:14:42 <vgridnev> SergeyLukjanov, it looks like he is working with cluster verifications checks implementation
18:15:10 <esikachev> SergeyLukjanov: rc1 works good, i do bug verification on Mon
18:15:42 <esikachev> *done
18:15:51 <vgridnev> *did
18:15:59 <esikachev> yes)
18:16:09 <SergeyLukjanov> good
18:17:27 <SergeyLukjanov> we'll have L release on a week Oct 12-16
18:18:58 <SergeyLukjanov> actually we already have a draft schedule for Mitaka
18:19:08 <SergeyLukjanov> #link https://wiki.openstack.org/wiki/Mitaka_Release_Schedule
18:19:53 <SergeyLukjanov> April 7 is the M release date now
18:20:03 <SergeyLukjanov> #topic Open discussion
18:21:11 <crobertsrh> Are we going forward with our own UI repo for M?
18:21:44 <elmiko> good question
18:21:44 <SergeyLukjanov> I would say it's a question to discuss on summit
18:21:59 <SergeyLukjanov> (as we agreed on meeting somewhere mid summer I think)
18:22:10 <crobertsrh> Fair enough.
18:22:31 <SergeyLukjanov> we need to collect the +\- and have a session to discuss it and make a final decision
18:22:35 <crobertsrh> It does seem like something that we'd want to do sooner rather than later, if we are going to do it at all.
18:23:04 <SergeyLukjanov> IMO summit is a deadline for decision
18:23:13 <egafford> crobertsrh: +1 to decisiveness (and to the change itself.)
18:23:20 <elmiko> would we want to use a separate repo again, or make it a top level directory in the sahara repo?
18:23:35 <elmiko> akin to the devstack plugin stuff
18:23:41 <SergeyLukjanov> good question
18:23:42 <crobertsrh> Manila uses a separate repo
18:23:50 <elmiko> (i'm not sure if horizon places any limits)
18:23:56 <crobertsrh> Not sure of any other examples
18:24:01 <SergeyLukjanov> I like separate repo because we could have separate list of core reviewers
18:24:03 <elmiko> i kinda like having it all in one repo
18:24:07 <elmiko> lol
18:24:13 <elmiko> that is a good point SergeyLukjanov
18:24:23 <crobertsrh> Might also be worthwhile to talk to the trove people.  I think they may be in a similar situation.
18:24:39 <SergeyLukjanov> and actually we'll need to package it separately, so, it will be better to keep in own repo
18:25:06 <elmiko> would horizon ever support something dynamic like devstack, where you just point it at a repo for a plugin?
18:25:27 <elmiko> SergeyLukjanov: yea, probably best to keep it separate
18:25:32 <crobertsrh> I would guess "no"
18:25:43 <elmiko> would be cool though, if it did =)
18:25:49 <crobertsrh> absolutely
18:26:02 <crobertsrh> It's actually not far from that right now
18:26:18 <crobertsrh> Just a couple configs really to get your plugin up and going in horizon.
18:26:58 <egafford> crobertsrh: Seems like a logical next step if they want less big tent maint.
18:26:58 <elmiko> maybe fodder for a horizon spec?
18:27:25 <SergeyLukjanov> I would say that it shouldn't be difficult to automate it using plugins
18:27:42 <SergeyLukjanov> like pip install sahara-dashboard and it'll be discovered and enabled
18:27:52 <SergeyLukjanov> using stevedore for example
18:28:22 <elmiko> yea, that would be aweomse
18:28:27 <elmiko> awesome even... ;)
18:28:52 <SergeyLukjanov> so, we need to understand - should we move codebase out of horizon or not
18:29:13 <crobertsrh> Right...multiple questions surrounding this.
18:29:18 <SergeyLukjanov> from the efforts PoV it'll take I think 2-3 month to move the code, fix it and setup the CI / jobs
18:29:45 <tmckay> hi folks!  I forgot, sorry
18:29:46 <SergeyLukjanov> let's make a separate etherpad for it and start collecting questions
18:29:52 <SergeyLukjanov> probably it'll require some RnD
18:29:54 <crobertsrh> +1
18:29:57 <SergeyLukjanov> tmckay, hey!
18:29:59 <tmckay> I will read the trace
18:30:00 * SergeyLukjanov creating
18:30:29 <SergeyLukjanov> https://etherpad.openstack.org/p/TYO-sahara-horizon-future
18:30:34 <david-lyle> I started a pass at moving the code out of horizon, but far from done. Was going to use as an example
18:30:48 <david-lyle> for plugins
18:31:08 <elmiko> oh nice, so you have been thinking about how to integrate external plugins?
18:31:20 <egafford> david-lyle: That's great; makes a ton of sense.
18:31:33 <david-lyle> yes, we have methods for having external plugins, just some questions around testing
18:31:55 <elmiko> neat
18:31:57 <crobertsrh> david-lyle:  Great!  If there is anything I can help with, let me know.
18:32:02 <david-lyle> will do
18:32:31 <SergeyLukjanov> so, if it's going to happen anyway
18:32:46 <SergeyLukjanov> we probably should sit on summit together, solve issue and make it happen in Mitaka
18:32:49 <david-lyle> SergeyLukjanov: doesn't have to
18:32:50 <SergeyLukjanov> david-lyle
18:32:56 <david-lyle> was experimenting
18:33:09 <SergeyLukjanov> I mean due to the Big Tent
18:33:16 <david-lyle> I think it would be better for both sides though
18:33:35 <crobertsrh> Yes, I'm leaning +1 on our eviction.
18:33:36 <cp16net> fwiw trove is in the contrib folder in horizon currently and trove still needs to figure out what the strategy is to move trove out of horizon to its own repo
18:33:57 <david-lyle> I think trove would also benefit
18:34:02 <crobertsrh> cp16net:  sounds like a similar issue :)
18:34:10 <cp16net> yup :)
18:34:13 <SergeyLukjanov> I would say that if we'll solve plugin mechanism and testing questions than external repo will benefit all :)
18:34:19 <david-lyle> sahara is actually a more complicated example
18:35:18 <david-lyle> due to existing integration tests
18:37:02 <david-lyle> for reference https://github.com/openstack/horizon/blob/master/doc/source/plugins.rst
18:39:24 <crobertsrh> Next topic?
18:40:01 <SergeyLukjanov> actually it's Open Discussion :)
18:40:12 <tmckay> ok then! so, I just asked on openstack-sahara whether or not we think we will deprecate the python-saharaclient CLI during the M cycle. Because if we keep it, we should fix some things I think.
18:40:38 <tmckay> like, use positional arguments instead of --id and --name, and support name or id, etc
18:40:47 <tmckay> to be more like other openstack things
18:41:08 <elmiko> we should probably double down on the effort to continue moving things into the openstackclient
18:41:18 <tmckay> that was my thought
18:41:28 <elmiko> i'd be ok with deprecating, once we have everything in openstackcli
18:41:34 <tmckay> but if the old CLI exists past M, we should fix it up, too
18:41:52 <crobertsrh> Yeah, we should move to one CLI ASAP
18:41:57 <elmiko> fix and improve are 2 different things though ;)
18:42:21 <tmckay> sreshetnyak has been leading the work on that, I think, I wonder if he needs some help
18:42:28 <elmiko> i hear a spec whistling in the distance...
18:42:40 <elmiko> ;)
18:42:58 <egafford> +1 to total deprecation of the old CLI for M being a priority. It's a fair bit of drag on the project to maintain both.
18:43:10 <tmckay> So, if the old CLI stopped working sometime in M, would anyone care?
18:43:18 <elmiko> i think we would need to signal deprecation in M, but actually deprecate in N
18:43:27 <crobertsrh> Right
18:43:36 <tmckay> elmiko, depends on your definition of deprecate
18:43:36 <elmiko> like have the cli throw up warnings for M
18:43:50 <elmiko> i mean take out completely==deprecate
18:44:03 <tmckay> elmiko, yes ...  in my lingo, the warning is "deprecation", followed by removal
18:44:08 <SergeyLukjanov> IMO we should just move to openstackclient and deprecate client CLI in Mitaka
18:44:22 <elmiko> tmckay: ok, cool
18:44:47 <tmckay> SergeyLukjanov, so, remove in M, or warn in M and remove 1st day of N?
18:44:53 <elmiko> ^
18:45:07 <elmiko> (wishes tosky was here)
18:45:08 <SergeyLukjanov> tmckay ++ for the warning is "deprecation", followed by removal
18:45:15 <elmiko> ok, i'm +1 for that
18:45:17 <crobertsrh> +1 SergeyLukjanov
18:45:24 <SergeyLukjanov> the only question when
18:45:50 <SergeyLukjanov> Andrey Pavlov is now actively working on implementing openstack client
18:45:53 <SergeyLukjanov> for sahara
18:45:53 <tmckay> okay.  So we can add a spec.  I will try to ping sreshetnyak about it, since he seems to know both clients well
18:46:00 <tmckay> oh, even better!
18:46:01 <elmiko> adding the warning for M-1 with removal by N-1 seems appropriate
18:46:17 <SergeyLukjanov> elmiko, or even earlier
18:46:27 <SergeyLukjanov> actually, we have some parts already implemented and merged
18:46:30 <SergeyLukjanov> and other parts on review
18:46:37 <tmckay> okay, thanks.  I was looking for things to fix, and this came up
18:46:45 <SergeyLukjanov> AFAIK he was thinking to complete it till the summit
18:46:53 <elmiko> oh wow, that would be awesome
18:47:08 <SergeyLukjanov> I will ask him to write the spec for the current CLI deprecation and move to the new one
18:47:41 <SergeyLukjanov> and IMO we could release last version of client with current CLI with deprecation warning and fully implemented new one
18:47:53 <SergeyLukjanov> somewhere around summit
18:47:57 <SergeyLukjanov> and then remove old CLI
18:48:16 <elmiko> sounds good
18:48:39 <SergeyLukjanov> here is a spec actually - http://specs.openstack.org/openstack/sahara-specs/specs/saharaclient/cli-as-openstackclient-plugin.html for new CLI impl itself
18:49:24 <tmckay> oh, I went to look for that right when vgridnev reminded me of the meeting :)
18:50:20 <vgridnev> tmckay, np
18:50:55 <SergeyLukjanov> 10 mins left, anything else to discuss?
18:50:57 <tmckay> thanks folks, probably nothing else to say about that
18:51:08 <sreshetnyak> http://specs.openstack.org/openstack/sahara-specs/specs/saharaclient/cli-as-openstackclient-plugin.html#work-items
18:51:14 <sreshetnyak> Old CLI will be deprecated and removed after some time
18:52:13 <sreshetnyak> I think need to update current spec and not need to create new spec
18:52:37 <tmckay> sreshetnyak, agreed, thanks
18:53:17 <elmiko> yea, probably not
18:53:53 <SergeyLukjanov> sreshetnyak, let's have a separated one for the old CLI deprecation
18:53:59 <SergeyLukjanov> to agree on dates / plans
18:54:11 <tmckay> I knew this was in progress, but I was unsure of the schedule
18:54:27 <tmckay> that also makes sense
18:54:31 <tmckay> should be an easy spec
18:54:38 <SergeyLukjanov> yeah
18:54:45 <SergeyLukjanov> just a deprecation / removal plaj
18:54:45 <sreshetnyak> I think current CLI should be deprecated in Mitaka release and should be removed in N release
18:54:46 <tmckay> can list this one as a reference
18:54:58 <tmckay> agreed
18:55:07 <tmckay> (we all agreed earlier)
18:55:08 <elmiko> +1
18:56:23 <SergeyLukjanov> :)
18:57:02 <sreshetnyak> SergeyLukjanov: I don't understand why we need to create two specs for implementation one feature
18:57:40 <SergeyLukjanov> sreshetnyak, it's not a one feature, creating new CLI and removing old one - it's not backward compatible
18:57:49 <SergeyLukjanov> we need to explicitly track it IMO
18:58:16 <egafford> It may also become more complex if we do implement a v2 API this cycle,
18:58:44 <tmckay> v2, v2, v2, you will be so beautiful
18:58:51 <egafford> 2 active clients x 2 API versions; we'd want to talk specifically about the support cycle for each bit of the matrix.
18:59:06 <tmckay> egafford, that is a very good point
18:59:32 <sreshetnyak> SergeyLukjanov: I think it's a one feaure: Migration to OpenStack client
18:59:50 <tmckay> should we vote? :)
19:00:13 * elmiko swoons for v2
19:00:15 <SergeyLukjanov> let's continue in openstack-sahara
19:00:18 <SergeyLukjanov> #endmeeting