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