18:01:14 <alazarev> #startmeeting sahara
18:01:14 <openstack> Meeting started Thu Nov 20 18:01:14 2014 UTC and is due to finish in 60 minutes.  The chair is alazarev. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:01:15 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:01:17 <openstack> The meeting name has been set to 'sahara'
18:01:28 <alazarev> ping sahara folks
18:01:37 <sreshetnyak> hi
18:01:37 <elmiko> o/
18:01:39 <crobertsrh> hello/
18:01:40 <alazarev> ErikB, NikitaKonovalov, RobLevas, SergeyLukjanov, aignatov, alazarev, bob_nettleton, crobertsrh, dmitryme, elmiko, jspeidel, mattf, skostiuchenko, sreshetnyak, tellesnobrega, themistymay, tmckay, tosky, ylobankov
18:01:42 <tosky> hi again!
18:01:42 <tellesnobrega_> o/
18:01:54 <alazarev> I'll char today
18:02:04 <alazarev> #link https://wiki.openstack.org/wiki/Meetings/SaharaAgenda
18:02:41 <alazarev> #topic sahara@horizon status (croberts, NikitaKonovalov)
18:03:16 <crobertsrh> Not much changing there at the moment.  I'll be talking with UX people about reworking some of the workflow soon.  If anyone here wants to be a part of that, let me know.
18:03:52 <alazarev> crobertsrh, review workflow? or workflow in code?
18:04:11 <crobertsrh> No....reworking the UI experience....wizards, etc.
18:04:23 <alazarev> crobertsrh, oh, I see
18:05:20 <alazarev> ok, let's move on
18:05:21 <alazarev> News / updates
18:05:25 <alazarev> #topic News / updates
18:06:01 <elmiko> i'm working on the spec for the security guide, and creating a swagger generator for sahara as a side project/poc
18:06:24 <tmckay> not too much from me.  Working on filtering with croberts, reviewing pads and things from summit to prioritize work for Kilo
18:06:27 <alazarev> I'm working on indirect access, core part is on review: https://review.openstack.org/#/c/133590/, next steps - python client, UI, docs
18:06:49 <tellesnobrega_> i'm working on the data_processing bug
18:06:50 <crobertsrh> I added a spec  (https://review.openstack.org/#/c/134319/) which has been merged and almost fully implemented for filtering the tables in the UI (and client library, and REST api)
18:06:55 <tellesnobrega_> i may have hit a problem
18:07:16 <tellesnobrega_> devstack and tempest fails tempest tests
18:07:18 <sreshetnyak> I'm working on auto security group
18:07:59 <tmckay> also, in open discussion, we should look at cm_api and global requirements for supporting CDH plugin in distribution (I have links to CRs)
18:08:03 <tellesnobrega_> from what i saw the problem is because the tempest tests needs to be commented so devstack can be merged and then we can pt the tests back on
18:08:13 <alazarev> tellesnobrega_, python client works with both versions of service type, so, I think tests should pass
18:09:03 <alazarev> tellesnobrega_, is it possible to change tests in a way to work with both configs?
18:09:37 <tosky> not much on my side, digging into integration tests, with some minor cleanup
18:09:40 <tellesnobrega_> i will take a look
18:09:43 <tellesnobrega_> not sure
18:10:14 <alazarev> sreshetnyak, I like your idea (discussed internaly) of separation rules for private and management networks for neutron
18:10:57 <tellesnobrega_> we can talk more after the meeting about this
18:10:58 <alazarev> sreshetnyak, it makes a lot of sense
18:11:14 <tellesnobrega_> also, i'm back with storm, hopefully i will submit a patch for that
18:11:16 <alazarev> sreshetnyak, can discuss later too
18:11:40 <alazarev> #topic Action items from the last meeting
18:11:55 <alazarev> as I see no action items from the previous meeting
18:12:07 <alazarev> #topic Design Summit @ Paris
18:12:30 <tmckay> not sure we need this topic anymore :)
18:12:47 <alazarev> it's the first meeting after the summit, please share how it was ;)
18:12:52 <elmiko> summit went well, lots of good discussion and topics generated
18:13:08 <elmiko> also, we had much larger attendence of the sahara design sessions
18:13:16 <alazarev> really sad that wasn't able to join
18:13:21 <tmckay> I think the pads are a useful outline.  Some things missing priorities, though
18:13:27 <elmiko> alazarev: yea =(
18:14:05 <tellesnobrega_> i fell the same alazarev
18:14:19 <alazarev> do we have page with all pads in one place?
18:14:30 <elmiko> tellesnobrega_: did Andrey mention our talk?
18:14:40 <tellesnobrega_> not fully
18:14:54 <elmiko> tellesnobrega_: i hope he gave you the t-shirt and stickers we sent along =)
18:14:54 <tellesnobrega_> we haven't had time to seat down and talk about the summit
18:14:58 <crobertsrh> #link https://wiki.openstack.org/wiki/Summit/Kilo/Etherpads#Sahara
18:15:00 <tellesnobrega_> i got that
18:15:07 <tellesnobrega_> thanks
18:15:07 <crobertsrh> ^^ Sahara ether pads from summit
18:15:07 <elmiko> yay
18:15:36 <alazarev> crobertsrh, think you
18:16:39 <alazarev> #topic Update meeting time to make Asia folks able to attend meetings
18:17:39 <crobertsrh> I forget, did we make any progress on this item when we met last?
18:17:51 <elmiko> i don't think so
18:17:56 <alazarev> I had a conversation with intel guys one more time, they still complaining, but no actual actions (no email to dev list, no single attendance to the IRC chat)
18:18:25 <elmiko> that's good alazarev, i think if they want to change the time they should start making noise on the ML
18:18:54 <alazarev> I also think if they need it, they should drive
18:18:56 <alazarev> agreed?
18:19:01 <elmiko> alazarev: +2
18:19:02 <crobertsrh> +1
18:19:17 <sreshetnyak> +1
18:19:40 <jodah> +1
18:19:48 <tellesnobrega_> +1
18:19:57 <alazarev> #agreed people who need time shift should drive this effort
18:20:05 <tosky> drive == proposing a time and asking? yep
18:20:24 <alazarev> #topic Open discussion
18:20:28 <elmiko> tosky: agreed
18:20:53 <tmckay> https://review.openstack.org/#/c/130153/
18:21:07 <tmckay> We need to discuss this, too bad Sergey is not here
18:21:20 <elmiko> at some point in the next few weeks, i'd like to setup a meeting with around 3-5 other developers to talk about some specific security issues in sahara. this will help our efforts to start some sort of analysis/audit
18:21:32 <tmckay> the question is -- do we push a global requirement on openstack to suport one vendor plugin for one project?
18:21:45 <tmckay> and the requirement is not not packaged, it is a vendor lib
18:21:49 <elmiko> well, and does it need to be a global requirement?
18:22:02 <elmiko> can we add sahara specific reqs?
18:22:03 <alazarev> tmckay, this is the only way we can communicate with CDH, I think we should push this to global requirements
18:22:05 <tmckay> my leaning is to document and leave it up to the end user, add instructions for the plugin
18:22:40 <tmckay> alazarev, okay, but on Fedora, Centos, Ubuntu, who is going to package it so that released distributions can use it?
18:23:53 <alazarev> tmckay, cloudera doesn't do that?
18:23:58 <elmiko> tmckay: good question, i'd like to know as well
18:24:15 <tmckay> no, I believe it is only in pypy right now, and bundled with cloudera stuff
18:24:33 <tmckay> that's where it gets iffy
18:24:49 <tmckay> We're requiring something that isn't packaged, potentially
18:25:19 <elmiko> yea, fedora has nothing for cm_api currently
18:25:30 <tmckay> Alternatives -- we could carry a copy of the library in Sahara, or we could include docs for installing optionally
18:26:02 <elmiko> i think if the cloudera folks want this they should start getting involved with packaging. i know fedora would accept new packages if they go through the proper channels.
18:26:11 <alazarev> tmckay, what the license? can we copy-past it to sahara?
18:26:12 <tellesnobrega_> +1
18:26:23 <tmckay> uh, Apache2 I think
18:26:32 <elmiko> tmckay: i'm -1 on us carrying the lib
18:26:34 <alazarev> tmckay, is it big?
18:26:50 <tosky> argh, copy/paste is bad, distributions don't like it (for good reasons)
18:27:00 <tosky> they will end up extracting it anyway
18:27:02 <jodah> very good reasons
18:27:14 <tmckay> alazarev, haven't looked, it's on github
18:27:32 <tmckay> tosky, yes, I agree.  There is not a great solution, except package
18:27:46 <tmckay> But, I think "global requirement" has to come after packaging is done.
18:27:47 <sreshetnyak> tmckay: link #https://github.com/cloudera/cm_api
18:27:52 <tmckay> just my opinion
18:27:55 <elmiko> what about prompting the cloudera folks to get involved with packaging their lib?
18:28:16 <jodah> we can't just pull it in from pypi?
18:28:26 <tmckay> jodah, we can.  But, Fedora can't
18:28:39 <elmiko> jodah: that's fine for dev installs, but if we package sahara for fedora/debian/centos we need packages that can be installed
18:28:48 <tmckay> jodah, so when RDO comes out, for example, and there is a global requirement for cm_api, what is Fedora going to do with Kilo?
18:29:04 <tmckay> kill the CDH plugin, probably
18:29:15 <tmckay> (patch and put it back to optional)
18:29:17 <elmiko> most distros won't allow packages to be installed from pypi directly
18:29:27 <alazarev> elmiko, cloudera is supporting sahara "on words" only, unfortunatelly
18:29:35 <tosky> "most" == "all" :)
18:29:36 <elmiko> alazarev: that's too bad
18:29:53 <elmiko> tosky: exaclty... but i didn't want to discount some crazy bleeding edge distro ;)
18:30:01 <tmckay> do we as a Sahara community want to package?
18:30:06 <jodah> so any 3rd party lib used requires an OS specific distro?
18:30:34 <elmiko> jodah: when it comes to packaging sahara as an official distro release, yes
18:30:38 <tmckay> yes, generally there must be an rpm.  Different distros may have different rules
18:30:48 <tmckay> (I'm not sure what ubuntu allows)
18:31:07 <tosky> tmckay: deb, of course
18:31:15 <elmiko> jodah: for example, if i want to `yum install openstack-sahara` or `apt-get install sahara` then we need better packaging for 3rd party stuff
18:31:19 <tmckay> but centos/fedora/rhel, definitely must be an rpm for every dependency
18:31:36 <tosky> and a distribution-specific package
18:32:58 <tmckay> So we need two things: 1) a decision on how we will handle it and 2) the effort to implement the answer to #1 :)
18:33:31 <elmiko> i think we need to have better engagement with the cloudera folks, not sure how to best handle that, but that's my feeling.
18:33:42 <tmckay> yes, I agree
18:33:45 <tosky> on the other side: is it really a problem? Isn't it the same issue for any new dependency on a 3rd-party library for some component?
18:33:48 <elmiko> is anyone from cloudera here?
18:34:02 <jodah> tosky that's my thought
18:34:13 <tmckay> And we need SergeyLukjanov as PTL to comment on https://review.openstack.org/#/c/130153/
18:34:17 <elmiko> tosky: yea, it is. but the question is who is going to handle packaging cm_api for RDO, for example.
18:34:19 <tosky> the concern there is more about python 3 support
18:34:28 <jodah> i can't imagine that most 3rd party libs are packaged for specific OSs. they go to languages specific repos like pypi
18:34:28 <tosky> elmiko: RDO packagers :D
18:34:43 <elmiko> tosky: ....
18:34:56 <tmckay> "By adding something to OpenStack global-requirements.txt we are  basically demanding that Linux Distros package this for the next release  of OpenStack. If they already have, great. If not, we should be  cautious of adding it"
18:35:11 <tmckay> that is the quote from the global requirements readme in OpenStack
18:35:15 <tosky> jodah: not sure I get it: they need native package for the specific distribution, and distribution packagers need to work on them
18:35:16 * tmckay looks for the page
18:35:29 <elmiko> and really, given the open nature of debian/fedora/ubuntu/centos cloudera could package it if they want to
18:35:54 <alazarev> elmiko, "if they want to"
18:35:56 <tmckay> to me, "cautious" means we don't do it for an optional feature in Sahara
18:36:01 <elmiko> i know from fedora, it's not difficult to get a package included
18:36:04 <tmckay> until its packaged
18:36:17 <elmiko> alazarev: but they obviously want it in sahara, so i'm confused.
18:36:18 <tmckay> it's not central to Sahara itself, only the plugin
18:36:47 <elmiko> i think i agree more and more with tmckay original suggestion about clear documentation about how to setup the cdh plugin
18:36:47 <tmckay> #link https://github.com/openstack/requirements
18:37:05 <tmckay> at least as step 1, and then maybe step 2 is package
18:37:24 <elmiko> we should not include the requirement, but provide a clear path for users wanting to use cdh. at least until someone is willing to create the distro packages for cm_api
18:38:10 <tmckay> yes, and then add to global requirements when the packages are done.  This is my feeling
18:38:42 <elmiko> +2
18:38:55 <alazarev> agree with the plan, this is the best we can do
18:39:16 <tmckay> alazarev, sreshnetyak?
18:39:30 <alazarev> +1
18:39:31 <tmckay> oh alazarev, sorry :)
18:39:34 <sreshetnyak> +2
18:39:49 <tmckay> should we wait for SergyLukjanov, too?  When will he be back?
18:40:05 <elmiko> agreed, we should definitely talk with SL about this
18:40:22 <tmckay> hmm, and mattf, he knows a lot about packaging/distros etc
18:40:34 <elmiko> yea, great point
18:40:39 <tmckay> k, I can summarize in an email to all cores, how about that?
18:40:46 <tmckay> And we can pick it up next week
18:40:52 <elmiko> sounds like a #action item to me =)
18:41:14 <tmckay> #action tmckay email cores summarizing discussion on cm_api global requirement
18:41:55 <tmckay> thanks guys
18:42:01 <tmckay> good discussion :)
18:43:28 <alazarev> anything else to discuss?
18:44:12 <tmckay> nothing from me
18:44:52 <crobertsrh> nothing here
18:45:19 <alazarev> ok, thank you guys then
18:45:21 <alazarev> #endmeeting