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