Tuesday, 2014-04-22

*** mwagner_lap has joined #openstack-meeting-300:00
*** chuckC has quit IRC00:04
*** eguz has quit IRC00:11
*** amotoki_ has quit IRC00:12
*** wchrisj has joined #openstack-meeting-300:15
*** sarob_ has quit IRC00:15
*** sarob has joined #openstack-meeting-300:16
*** sarob has quit IRC00:21
*** krotscheck has quit IRC00:36
*** krotscheck has joined #openstack-meeting-300:39
*** peristeri has quit IRC00:40
*** SumitNaiksatam has quit IRC00:53
*** wchrisj has quit IRC00:58
*** SumitNaiksatam has joined #openstack-meeting-301:25
*** banix has joined #openstack-meeting-301:46
*** chuckC has joined #openstack-meeting-301:53
*** banix has quit IRC01:59
*** baojg has joined #openstack-meeting-302:00
*** chuckC has quit IRC02:06
*** wchrisj has joined #openstack-meeting-302:06
*** wchrisj has quit IRC02:47
*** coolsvap|afk is now known as coolsvap02:48
*** eghobo has joined #openstack-meeting-302:53
*** jpomero has quit IRC03:06
*** banix has joined #openstack-meeting-303:15
*** sarob has joined #openstack-meeting-303:20
*** sankarshan has joined #openstack-meeting-303:21
*** sarob has quit IRC03:25
*** banix has quit IRC03:38
*** TravT has quit IRC04:00
*** wchrisj has joined #openstack-meeting-304:30
*** baojg has quit IRC04:48
*** baojg has joined #openstack-meeting-304:48
*** chuckC has joined #openstack-meeting-304:52
*** sankarshan is now known as sankarshan_away05:01
*** yamahata has joined #openstack-meeting-305:06
*** wchrisj has quit IRC05:10
*** baojg_ has joined #openstack-meeting-305:10
*** yamahata has quit IRC05:12
*** yamahata has joined #openstack-meeting-305:12
*** baojg has quit IRC05:14
*** cjellick has quit IRC05:17
*** cjellick has joined #openstack-meeting-305:17
*** cjellick has quit IRC05:18
*** jtomasek has joined #openstack-meeting-305:58
*** jcoufal has joined #openstack-meeting-306:07
*** ttrifonov_zZzz is now known as ttrifonov06:17
*** cjellick has joined #openstack-meeting-306:18
*** yamahata has quit IRC06:19
*** cjellick has quit IRC06:26
*** sankarshan_away is now known as sankarshan06:30
*** ttrifonov is now known as ttrifonov_zZzz06:43
*** chuckC has quit IRC07:04
*** eghobo has quit IRC07:15
*** ttrifonov_zZzz is now known as ttrifonov07:33
*** jcoufal has quit IRC07:33
*** jcoufal has joined #openstack-meeting-307:40
*** mrunge has joined #openstack-meeting-307:42
*** nacim has joined #openstack-meeting-307:50
*** ttrifonov is now known as ttrifonov_zZzz07:53
*** ttrifonov_zZzz is now known as ttrifonov07:54
*** jtomasek has quit IRC08:04
*** jtomasek has joined #openstack-meeting-308:04
*** safchain has joined #openstack-meeting-308:18
*** jamie_h has joined #openstack-meeting-308:28
*** ttrifonov is now known as ttrifonov_zZzz08:50
*** ttrifonov_zZzz is now known as ttrifonov09:00
*** jamie_h has quit IRC09:11
*** jamie_h has joined #openstack-meeting-309:12
*** sankarshan is now known as sankarshan_away09:32
*** jamie_h has quit IRC09:36
*** jamie_h has joined #openstack-meeting-309:36
*** MaxV has joined #openstack-meeting-309:42
*** jamie_h has quit IRC09:42
*** jamie_h has joined #openstack-meeting-309:45
*** jamie_h has quit IRC09:52
*** jamie_h has joined #openstack-meeting-309:53
*** MaxV has quit IRC10:05
*** garyduan has joined #openstack-meeting-310:08
*** gduan has quit IRC10:09
*** akrivoka has joined #openstack-meeting-310:39
*** coolsvap is now known as coolsvap|afk10:40
*** akrivoka has quit IRC10:48
*** MaxV has joined #openstack-meeting-310:53
*** jamie_h has quit IRC10:56
*** jamie_h has joined #openstack-meeting-311:00
*** alexpilotti has joined #openstack-meeting-311:02
*** alexpilotti has quit IRC11:07
*** baojg_ has quit IRC11:10
*** baojg has joined #openstack-meeting-311:11
*** baojg has quit IRC11:16
*** enikanorov_ has quit IRC11:43
*** jcoufal has quit IRC12:04
*** jcoufal has joined #openstack-meeting-312:04
*** jcoufal has quit IRC12:09
*** jcoufal has joined #openstack-meeting-312:09
*** jcoufal has quit IRC12:14
*** jcoufal has joined #openstack-meeting-312:14
*** jcoufal has quit IRC12:15
*** jcoufal has joined #openstack-meeting-312:15
*** jcoufal has quit IRC12:18
*** jcoufal has joined #openstack-meeting-312:19
*** jcoufal has quit IRC12:20
*** jcoufal has joined #openstack-meeting-312:20
*** sankarshan_away is now known as sankarshan12:25
*** xuhanp has joined #openstack-meeting-312:41
*** jpich has joined #openstack-meeting-312:49
*** overlayer has joined #openstack-meeting-312:59
*** banix has joined #openstack-meeting-313:08
*** jpomero has joined #openstack-meeting-313:22
*** MaxV has quit IRC13:33
*** MaxV has joined #openstack-meeting-313:38
*** MaxV has quit IRC13:38
*** nacim_ has joined #openstack-meeting-313:40
*** nacim has quit IRC13:40
*** julim has joined #openstack-meeting-313:42
*** wchrisj has joined #openstack-meeting-313:43
*** mrunge has quit IRC13:55
*** mfer has joined #openstack-meeting-313:56
*** peristeri has joined #openstack-meeting-314:04
*** jamie_h_ has joined #openstack-meeting-314:09
*** markmcclain has joined #openstack-meeting-314:12
*** markmcclain1 has joined #openstack-meeting-314:16
*** markmcclain has quit IRC14:16
*** ttrifonov is now known as ttrifonov_zZzz14:20
*** overlayer has quit IRC14:27
*** mwagner_lap has quit IRC14:29
*** jcoufal has quit IRC14:29
*** david-lyle has joined #openstack-meeting-314:31
*** xuhanp has quit IRC14:49
*** devlaps has joined #openstack-meeting-315:03
*** alexpilotti has joined #openstack-meeting-315:04
*** nacim_ has quit IRC15:10
*** jcoufal has joined #openstack-meeting-315:12
*** markmcclain1 has quit IRC15:16
*** cjellick has joined #openstack-meeting-315:20
*** Hao has joined #openstack-meeting-315:27
*** cjellick has quit IRC15:30
*** cjellick has joined #openstack-meeting-315:31
*** absubram has joined #openstack-meeting-315:33
*** lblanchard has joined #openstack-meeting-315:34
*** tqtran has joined #openstack-meeting-315:34
*** akrivoka has joined #openstack-meeting-315:38
*** nacim_ has joined #openstack-meeting-315:38
*** mwagner_lap has joined #openstack-meeting-315:39
*** pballand has joined #openstack-meeting-315:43
*** chuckC has joined #openstack-meeting-315:51
*** eghobo has joined #openstack-meeting-315:51
*** amotoki has quit IRC15:52
*** tzumainn has joined #openstack-meeting-315:54
*** amotoki has joined #openstack-meeting-315:57
*** mrunge has joined #openstack-meeting-315:58
*** pbelanyi_ has joined #openstack-meeting-315:58
*** clu_ has joined #openstack-meeting-315:58
*** tmazur has joined #openstack-meeting-316:00
*** doug-fish has joined #openstack-meeting-316:00
tzumainnhi all!16:01
mrungeo/16:02
david-lyle#startmeeting Horizon16:02
openstackMeeting started Tue Apr 22 16:02:12 2014 UTC and is due to finish in 60 minutes.  The chair is david-lyle. Information about MeetBot at http://wiki.debian.org/MeetBot.16:02
openstackUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.16:02
*** johnma has joined #openstack-meeting-316:02
*** openstack changes topic to " (Meeting topic: Horizon)"16:02
openstackThe meeting name has been set to 'horizon'16:02
akrivokahiya16:02
pbelanyi_hi16:02
jcoufalahoy o/16:02
amotokihi16:02
absubramhi16:02
david-lyleHello everyone16:02
SergeyLukjanovo/ (lurking for Sahara related topics)16:03
lblanchardhi all!16:03
clu_hi!16:03
tqtranhello16:03
david-lyleIcehouse is officially release, on to Juno and backports to stable/icehouse.16:03
david-lyleThanks everyone for all you efforts on icehouse.16:04
david-lyleSomething we can all be proud of16:04
jcoufalnice! great job to all16:05
david-lyleThe only topic I have for today regards design session topics, the proposal deadline is past, and I need to schedule the sessions.  I want to have you help culling/combining topics.16:05
david-lyle#link http://summit.openstack.org/16:06
david-lyle2x topics to slots16:07
jcoufalHow many slots do we have?16:07
david-lyleI'm going to withdraw the node topic, I think we understand that one, and I just need to do the work.  Or we can discuss the finer points in the hall.16:07
david-lylejcoufal: 816:07
mrungewe have lots of technical things to discuss16:08
david-lylemrunge, re: node or other items16:08
mrungedavid-lyle, well, I'd say, they might be connected16:08
jpichhttp://summit.openstack.org/cfp/details/264 strikes me as not controversial, I'm not sure that a session is needed - someone just needs to do the work16:09
david-lyleI could see that, but node/npm will be a means to an end here16:09
david-lylejpich, agreed, the only thing I could see for that would be a demo, but it doesn't sound to be that far along16:10
jcoufaljpich: +116:10
tqtranis it too late to add topics?16:10
mrungejpich, I agree somehow. Although that proposal looks a bit empty16:11
mrungeor cloudy, I'd say ;-)16:11
doug-fishThis seems like an easy +1 http://summit.openstack.org/cfp/details/3216:11
jpichRe: Nodejs, there are people (Radomir?) who are investigating other alternatives for compiling CSS16:11
*** thinrichs has joined #openstack-meeting-316:11
mrungeyes, and discussed websockets, or discussed using marconi for websockets16:12
mrungenode would be the other solution for async messaging16:12
jpichtqtran: I'm afraid so, especially since we have way more sessions proposed than slots available. Though maybe exceptions can be made for a very important topics...16:12
jpichmrunge: I'd prefer to see a Python solution, I think that's where we were going with the sockets16:13
lblancharddoug-fish: thanks for the +1!!16:13
*** thinrichs has quit IRC16:14
david-lyledoug-fish: I think so too16:14
mrungejpich, me too, +1 for a python solution16:14
clu_doug-fish lblanchard: +1, important16:14
tzumainndo you guys think an etherpad might help to remember the +1s and the like?16:14
*** markmcclain has joined #openstack-meeting-316:15
*** julim has quit IRC16:15
*** mrunge has quit IRC16:15
david-lylemrunge, jpich, the issue goes beyond mere compilation.  It includes testing and development tools16:15
jpichI agree UX is an important session, though it might still need to be combined with another one16:15
jcoufaldoug-fish: can we join http://summit.openstack.org/cfp/details/315 together with discussion about http://summit.openstack.org/cfp/details/3216:16
david-lyleMy question regarding UX is, there are two cross-project UX sessions, should that topic be addressed there?16:16
doug-fishI'd expect UX and accessibility to have very little overlapping content16:16
jcoufaldavid-lyle: it would be nice - is there enough space for cross-project sessions?16:17
*** jamie_h_ has quit IRC16:17
doug-fishdavid-lyle: can you link those sessions?16:17
david-lylejcoufal: 2 UX session are already scheduled16:17
* david-lyle finding links16:18
jpichdoug-fish: Could you start the discussion on list about that topic either way? Not everything has to be decided within a 40 minutes face to face session16:18
doug-fishjpich:  great point.  Will do that.16:18
david-lylehttp://junodesignsummit.sched.org/16:18
david-lylehttp://junodesignsummit.sched.org/event/e13c8775849567fe8576c16875d5c547#.U1aWfPldXoM16:19
tzumainndavid-lyle, would it make sense to have people put their input on an etherpad like https://etherpad.openstack.org/p/horizon-atlanta-summit , so it's easier to remember where people stand?16:19
jcoufaldavid-lyle: found it, russel extended one for two slots16:19
lblancharddavid-lyle: yeah, I got notices about the UX off topic sessions…sounds like they thought we'd have a lot to cover so gave us two16:19
lblanchardback to back16:19
david-lylelblanchard, the question is with those, should we put your Horizon content in there?16:20
jcoufallblanchard: though I think that the first one can be designers gathering and second can be more practical16:20
*** julim has joined #openstack-meeting-316:20
lblancharddavid-lyle: I think if the Horizon devs plan to be there, sure…I think it's important for the Horizon session to have the devs around16:20
david-lyleor is the focus more APIs, or ?16:20
clu_this session is user-feedback-centric, maybe we can combine as well? http://summit.openstack.org/cfp/details/17516:21
lblancharddavid-lyle: I think a lot of it will be process oriented…e.g. how do we work together, share, communicate, work with the teams…what are we working on today? type stuff16:21
jcoufaltzumainn: the etherpad will be helpful, thanks16:21
jcoufallblanchard: but that can be covered in the first part16:21
*** mattf has joined #openstack-meeting-316:22
david-lylethanks tzumainn16:22
lblanchardclu_: I think this session will be very important for everyone to be at…sounds like we will have some ops in the room to discuss Horizon features needed for our users16:22
tzumainnnp!16:22
* mattf waves16:22
*** cjellick has quit IRC16:22
* mattf is a sahara lurker16:22
*** johnma has quit IRC16:22
mattfregret from chad16:22
jcoufallblanchard: I think we can use second part of the session to ease the load from Horizon to cover the usability feedback16:22
*** cjellick has joined #openstack-meeting-316:23
lblanchardjcoufal: sure. I think it's just important to note that if it's not a Horizon specific session, we might not get Horizon devs there for their feedback on practical discussions16:23
lblanchardjcoufal: I totally disagree.16:23
lblanchardjcoufal: unless the devs are there :)16:23
david-lylemrunge, does separation have open questions, or just needing off ?16:23
david-lyles/off/effort/16:23
lblanchardjcoufal: we have designs we will be showing and what to get dev feedback16:23
*** johnma has joined #openstack-meeting-316:23
jcoufallblanchard: why not? I believe it will be interesting for people from all projects, since the UI covers majority of them16:24
jcoufaland I am hoping that cross-project session will not overlap with Horizon's16:24
lblanchardjcoufal: Yes, I think anyone who is interested in Usability Feedback on Horizon should attend16:24
lblanchardjcoufal: but it should be on Horizon track16:24
*** ttrifonov_zZzz is now known as ttrifonov16:24
lblanchardjcoufal: so that there isn't another session overlapping potentially taking the Horizon devs away from that important discussion16:25
jcoufaldavid-lyle: can we do voting for sessions in tzumainn's etherpad? https://etherpad.openstack.org/p/horizon-atlanta-summit16:26
jcoufalI think that might help16:26
david-lylelblanchard, first UX session has a conflict for me, second UX session is good16:26
david-lylejcoufal, sure let's add a +1, -1 to topics on there, and maybe we can cull some obvious ones16:27
* david-lyle wishfully thinking16:27
jcoufaldavid-lyle: +1 from me16:28
doug-fishWhat about identifying potential topics to combine?  I'm looking at Do these 2 fit together into a single session?  http://summit.openstack.org/cfp/details/117 http://summit.openstack.org/cfp/details/12916:28
doug-fishthey both seem closely tied and necessary for splitting horizon16:28
*** nacim_ has quit IRC16:28
david-lyledoug-fish, yes those two can combine16:28
jpichI think a lot of the sessions should start on-list discussions, I'm sure a number of questions could be resolved without the need to wait for everyone to be in the same room16:30
jpichIt's a bit late to help a lot with the scheduling now but maybe it would reduce the scope of some discussions and make topics easier to combine16:30
tzumainnjpich, +1, I think the same thing was suggested for tripleo16:31
lblanchardjpich: +1, I will start discussions around the sessions I proposed16:31
*** tqtran has quit IRC16:32
jcoufaldavid-lyle: modular widget based approach can be combined with Horizon pluggable content?16:32
david-lylecertainly related16:33
amotokijpich: +1. totally agree.16:33
david-lylejpich: very much agree16:34
jpichGreat. We should ping the session owners who are not at this meeting and encourage them to do so soon16:34
jpichI can do this and post a comment about this on all the proposals, if that sounds like a reasonable approach16:36
tzumainnsounds reasonable to me!16:36
doug-fishI love the idea of this session http://summit.openstack.org/cfp/details/175 but I'm concerned about getting participation from people who aren't Horizon developers.16:37
amotoki+1. what we need to do first is to clarfiy the session owners want to discuss in the session and check if there is similar sessions.16:37
doug-fishI haven't been to a summit before - is that a reasonable concern?16:37
jcoufaldoug-fish: I don't think so :)16:38
lblancharddoug-fish: this will be the first time we are doing something like this. Operators haven't been allowed to attend design summit sessions in the past as far as I know.16:38
jpichdoug-fish: These are new, Tom is organising them for multiple projects and doing a lot of work advertising them to operators. It seems very much worth giving it a shot, to me16:38
lblancharddoug-fish: Tom Fifield works closely with the user committee.16:38
doug-fishcool!16:38
lblanchardjpich: +1!!16:38
david-lylejcoufal: I think http://summit.openstack.org/cfp/details/175 may come out of your http://summit.openstack.org/cfp/details/356 naturally16:38
david-lyleit did last time16:38
lblanchardit's our best bet to get past devs and chat with ops IMO!16:39
lblancharddavid-lyle: operators attended the sessions?16:39
doug-fishIt has my +1.  Like I said, I think its a good idea, was just concerned that maybe operators couldn't/wouldn't attend.16:40
david-lylethose expressing operator type concerns, what their true role was, unsure16:40
jpichlblanchard: I think a number of operators have a few contributions under their belt, so as ATC they can attend16:40
lblanchardjpich: good point!16:40
lblanchardI definitely think it's worth having a slot for. I'd be happy to use the 2nd UX slot for this…although it is very much Horizon focused.16:41
jcoufaldavid-lyle: Probably, but I can't assure this :) But there definitely will be space for ask them questions16:41
david-lyleLet's continue this on the etherpad: #link https://etherpad.openstack.org/p/horizon-atlanta-summit16:41
david-lyle#topic Open Discussion16:42
*** openstack changes topic to "Open Discussion (Meeting topic: Horizon)"16:42
*** jamie_h has quit IRC16:42
david-lylewant to leave a little time for this, if it devolves back to session planning, I'm ok with that, but others feel free to bring your topic up now16:42
mattfSergeyLukjanov, NikitaKonovalov ^^ kick off some sahara discussion?16:43
mattfSergeyLukjanov is our PTL and has a great handle on the topics like sahara v heat, which came up on the mailing list thread16:43
*** alexpilotti has quit IRC16:43
SergeyLukjanovhey16:44
SergeyLukjanovI'll send a response to jcoufal in ML16:44
david-lyleas Sahara has graduated, I don't think Horizon makes the decision it should merge with Heat :)16:44
jcoufalSergeyLukjanov: thanks16:44
SergeyLukjanovin two words sahara isn't the part of orchestration, sahara use heat for it16:44
jcoufaldavid-lyle: not proposing that, I am just trying to figure out the relationship :)16:45
SergeyLukjanovexample of existing projects with the same layout - trove16:45
david-lylejcoufal, sure16:45
SergeyLukjanovtrove has separated panel for their "cluster" (named databases)16:45
*** alexpilotti has joined #openstack-meeting-316:45
SergeyLukjanovI'll try to explain the relations more detailed in ML16:45
SergeyLukjanovre sahara dashboard merging into the horizon, I have a question16:46
SergeyLukjanovdo we need some time on summit to discuss it?16:46
mattfi'll add that horizon integration has been a primary goal for sahara. we only grew a cli interface very recently.16:46
jpichI don't think so, it doesn't seem controversial? We want you guys in :)16:46
jcoufalSergeyLukjanov: sure thing, we can continue in the ML16:46
mattfwe want to make the workflow of cluster provisioning or data processing job execution very smooth and horizon first16:47
SergeyLukjanovmy init idea is to merge current state to the horizon during the J cycle and than iterate many times on UX16:47
jcoufalSergeyLukjanov: agree with jpich, I am not disagreeing with merger, more trying to find the best place for it16:47
tzumainnout of curiosity, is there a preferred workflow when a new project integrates with horizon?16:47
NikitaKonovalovthere is a change by crobertsrh adding a sahara-client16:47
NikitaKonovalovthis one https://review.openstack.org/#/c/86648/716:48
NikitaKonovalovso that's a good first step to start with I guess16:48
jpichtzumainn: Not really so far: new project submits their code, we make it more horizony if required, then it gets merged16:48
lblanchardSergeyLukjanov: +1 to it being in Horizon, agree with jcoufal it's just a matter of finding the right place and organization within the information architecture!16:48
jcoufalSergeyLukjanov: we definitely should iterate in time, but I am afraid of OpenStack Dashboard to become unstable if project just merges in and then we try to re-organize things, which are already in master16:49
*** clu_ has quit IRC16:49
SergeyLukjanovjcoufal, I'm not proposing to merge it as is, just to not change the overall approach16:50
jcoufaltherefore I would like to reduce this effect to minimum (not that the solution will be perfect final version which will have to take us 2 cycles to design)16:50
jcoufalSergeyLukjanov: I think we are on the same page here16:50
SergeyLukjanovjcoufal, my only concern is that we should merge it during the Juno or we need to supply it separately again and disable in horizon16:51
SergeyLukjanovjcoufal, cool16:51
jpichHorizon's always aimed to support new graduated projects out of the box, so let's make sure to find at least a temporary space so we have some sort of base to work from. The first patchset tends to be larger so it takes time to merge it as is16:51
david-lyleI think with the newer panel, panel group and dashboard order management, reorganizing will be a lot simpler16:51
jcoufalSergeyLukjanov: I think Juno is no problem here16:51
SergeyLukjanovI hope ;)16:52
jcoufalSergeyLukjanov: We will make it ;)16:52
* mattf crosses fingers16:52
amotokifrom our past experience, we need to start tests a bit earlier.  devstack integration or easy-setup-dev env really helps us.16:53
SergeyLukjanovamotoki, sahara is in the integrated gate, there are not too many tests atm, but devstack integration should work ok16:53
amotokiSergeyLukjanov: great. when I tried to run trove, it was a bit tricky and i need to explore more info...16:54
SergeyLukjanovamotoki, I think that we could ask Chad (croberts) to make some short doc about how to test his patches16:54
tzumainnSergeyLukjanov, that would be awesome : )16:54
jcoufalneed to run for today, but thanks guys, will continue this topic in ML16:54
jcoufalhave a great day all16:54
jpichYep, include the steps in the blueprint maybe16:54
mattfjcoufal, thx16:54
*** jcoufal has quit IRC16:55
SergeyLukjanovwe have a good docs for sahara re installation including our plugin for dashboard - http://docs.openstack.org/developer/sahara/#user-guide16:55
mattfhe's not here, you should #action chad for bp test docs16:55
SergeyLukjanov jcoufal, thanks16:55
SergeyLukjanov#action croberts to add doc re testing his changes for merging sahara-dashboard into the horizon16:55
amotokiSahara seems to have well-formed documents :)16:56
amotoki  /FYI/ I add the link of the etherpad page to horizon meeting page as well.16:57
amotoki s/add/added/16:57
david-lylethanks amotoki16:57
jpichThanks amotoki!16:57
jpichIf I may provide some additional food for thought on the Summit: someone in a thread or other described the summit sessions as "the middle of a conversation" - I think that's important to keep in mind, the session shouldn't come out of nowhere (start on list discussions) and isn't the end of everything either, decisions can/should/will happen on list and outside of the Summit as well16:58
david-lyleI need to have the schedule together by the end of the week, so I'll be acting on organizing/culling in the next couple of days.  Make your opinions known.16:58
SergeyLukjanovthank you, folks16:59
doug-fishThanks for soliciting input david-lyle!  well handled.16:59
david-lylethanks, SergeyLukjanov, mattf, NikitaKonovalov, looking forward to adding Sahara support17:00
david-lyletime's up17:00
mattfpleasure17:00
david-lyle#endmeeting17:00
*** openstack changes topic to "OpenStack Meetings || https://wiki.openstack.org/wiki/Meetings"17:00
mattfthx folks17:00
openstackMeeting ended Tue Apr 22 17:00:29 2014 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)17:00
openstackMinutes:        http://eavesdrop.openstack.org/meetings/horizon/2014/horizon.2014-04-22-16.02.html17:00
openstackMinutes (text): http://eavesdrop.openstack.org/meetings/horizon/2014/horizon.2014-04-22-16.02.txt17:00
tzumainnthanks all17:00
openstackLog:            http://eavesdrop.openstack.org/meetings/horizon/2014/horizon.2014-04-22-16.02.log.html17:00
*** tzumainn has left #openstack-meeting-317:00
jpichThanks, everyone17:00
NikitaKonovalovthanks17:00
akrivokathanks everyone, have a good week17:00
*** rajdeep has joined #openstack-meeting-317:00
*** thinrichs has joined #openstack-meeting-317:01
lblanchardthanks all!!17:01
david-lyleHave a great week everyone!17:01
*** safchain has quit IRC17:01
*** akrivoka has left #openstack-meeting-317:01
*** jpich has left #openstack-meeting-317:01
*** johnma has quit IRC17:01
lblancharddavid-lyle: thanks for the organizing work! Let me know if you'd like to talk more about using one of the UX off-topic sessions for a Horizon focused session.17:01
*** mattf has left #openstack-meeting-317:01
amotokithanks everyone. night!17:02
*** amotoki has quit IRC17:02
pballandhowdy17:02
thinrichsHi all17:02
*** enikanorov_ has joined #openstack-meeting-317:02
rajdeephi all17:02
david-lylelblanchard, wasn's sure of the scope of those sessions17:02
*** doug-fish has left #openstack-meeting-317:02
david-lyleI'll ping you later about it17:02
*** kudva has joined #openstack-meeting-317:03
lblancharddavid-lyle: will continue in #openstack-ux17:03
*** pbelanyi_ has quit IRC17:03
*** mrunge has joined #openstack-meeting-317:03
thinrichsAnyone else here for the Congress meeting?17:03
kudvaIt's kudva17:04
thinrichsHi kudva17:04
kudvaHi17:04
rajdeeprajdeep17:04
thinrichs#startmeeting CongressTeamMeeting17:04
openstackMeeting started Tue Apr 22 17:04:55 2014 UTC and is due to finish in 60 minutes.  The chair is thinrichs. Information about MeetBot at http://wiki.debian.org/MeetBot.17:04
openstackUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.17:04
thinrichsHi rajdeep17:04
*** openstack changes topic to " (Meeting topic: CongressTeamMeeting)"17:04
openstackThe meeting name has been set to 'congressteammeeting'17:05
thinrichsUsual agenda today: recap on action items, look at todos for alpha release, open discussion17:05
pballandI’d like to chat a bit about the conference at the end if there is time17:06
thinrichsLet's start with rajdeep.  Can you report on data drivers?17:06
rajdeepyes..17:06
rajdeepi completed some key integration points for nova driver17:06
rajdeepgetting the server and flavor data in and converted to tuples17:06
rajdeepthe code has been checked in17:07
rajdeepand tim approved today morning17:07
*** eghobo has quit IRC17:07
*** eghobo has joined #openstack-meeting-317:07
rajdeep#link https://review.openstack.org/#/c/88228/17:07
*** absubram has quit IRC17:07
thinrichsSo for our running example (network connections to VMs with group constraints), do we have all the data sources that we need from Nova and Neutron?17:07
rajdeepi guess so17:08
rajdeepone challenge which i came across is how much API coverage should driver have17:08
rajdeepPOST and DELETE APIs are not needed17:08
thinrichsRight--for data source drivers we want only API calls that do not CHANGE anything17:09
rajdeepso focussing on GET requests and prioritize17:09
pballandrajdeep: I’m working through those details now - I expect that some tables will just “appear” when the data source plugin is enabled, and others can be created (for users to manually provision data through the API)17:09
thinrichsBut as we discussed during review, ideally we'll support the core API for each component.17:09
rajdeepyes we should strive for that17:10
rajdeepcover as much possible and applicable17:10
*** alexpilotti_ has joined #openstack-meeting-317:10
rajdeepnow for the use case i had few questions we can discuss during the end17:10
thinrichsEventually we'll want libraries where users say "I have Neutron v 1.2.1", and we'll use the data drivers for that version of the codebase.17:10
thinrichsBut for POC, I think the coverage we have is good.17:11
thinrichsrajdeep: sounds good.17:11
rajdeepour drivers will also evolve with the openstack and their component versions17:11
rajdeepwhich is not designed in the driver itself17:11
rajdeepi am assuming we will have separate driver for each component and version17:12
thinrichsrajdeep: agreed17:12
rajdeepperhaps a driver factory on the top17:12
rajdeepto load the right driver depending on the version17:12
thinrichsSounds good.17:13
pballandqustion: do we expect drivers to be registered at startup?17:13
thinrichskudva: how are the builtins going?17:13
kudvaOkay, I got the feedback from Tim on my document.17:13
kudvaI have started implementation in my sandbox.17:13
thinrichspballand: not sure.  Ideally we could hot-swap at runtime17:13
*** alexpilotti has quit IRC17:13
*** alexpilotti_ is now known as alexpilotti17:13
thinrichskudva: great!17:13
kudvaIn a week or so, I can put the code in for review17:13
rajdeeppballand : drivers can be instantiated but you need to call def update_from_datasource(self)17:14
kudvaRight now I am assuming my own builtin directory in congress/policy17:14
kudvabut we can decide where to put it.17:14
*** tmazur has quit IRC17:14
rajdeepto pull data17:14
thinrichskudva: that sounds about right.17:14
thinrichsI'm looking forward to doing that review--builtins have been on the list for a long time.17:15
thinrichskudva: any issues come up that need discussing with the group?17:15
*** david-lyle is now known as david-lyle_afk17:16
thinrichsperhaps kudva had to step away.17:17
thinrichspballand: how's the API going?17:18
pballandcan I ask more questions about data source plugins?17:18
thinrichssure17:18
kudvasorry, someone came into my office17:18
pballanddo we want validation between the policy and data sources?17:18
pballande.g. if a data source can dynamically start publishing data, can the policy be declared over it before it joins?17:19
thinrichsI could imagine telling the user that there are data sources referenced in policy that we don't have data for.  Is that what you mean?17:19
pballandyeah, for the API, I’m wondering how strict we should be with schemas and validation17:19
thinrichspballand: I'd say yes.  I'm thinking of upgrades.  Suppose user decides to upgrade Neutron to the next version.17:19
thinrichsEither they upgrade the data source first or the policy first.  Either way there's a window where we have a mismatch.17:20
rajdeepor we have policy meta data which ties it to a version of the data source17:20
pballandso are tables versioned? ('nova-diablo:vm’)17:20
thinrichsI could imagine versioning tables temporarily while doing an upgrade.  I think we need to think through what the right behavior should be during upgrade in terms of policy.17:21
thinrichspolicy violations that is.17:21
thinrichsI think for alpha release we're just assuming upgrades don't happen.17:22
pballandI propose we allow adding items to tuples, but force a table name change if columns are removed or the meaning of a column changes17:22
thinrichsIf we think this is important right now, does anyone want to volunteer to think through what happens during upgrade and data-source changes?17:23
pballandso we may wind up with something like nova-vm-version1, nova-vm-version217:23
thinrichspballand: forcing a table-name change would require changing policy.17:23
pballandyup - so we’d like to avoid table semantics if possible17:23
pballandavoid *changing* table semantics17:23
thinrichsPolicy is hard to get right--I worry about telling people they need to change it every time they upgrade.17:24
thinrichsWithout knowing there are no other options.17:24
rajdeepperhaps we could allow schema changes17:24
pballandI think that’s good enough for now - no need to go through a full upgrade modeling - we just need to be clear that once a table is defined for a data source, we should avoid chanign the schema17:24
thinrichsSorry--got to step away for a minute.  pballand, can you take over?17:25
rajdeepand ignore errors because of missing data17:25
pballandthinrichs: yup17:25
pballandwhat I was going to propose is that for a given datasource::table name, we can add columns between releases, but not remove any17:25
rajdeepwell it will be easier to add new colums at the end of tuple17:26
pballandrajdeep: exactly - that would be allowed17:26
rajdeepi have a new method to get metadata for a tuple17:26
rajdeep def get_tuple_metadata(self, type): 56        if type == self.SERVERS: 57            return ("id", "name", "host_id", "status", "tenant_id", "progress", 58                    "user_id", "image_id", "flavor_id") 59        elif type == self.FLAVORS: 60            return ("id", "name", "vcpus", "ram", "disk", "ephemeral", 61                    "rxtx_factor")17:26
rajdeepsorry17:27
pballandif a version change calls for changing the type of a column (or removing it), we can either leave the column empty and add a new column, or create a new table17:27
pballandok, thanks for the input17:27
pballandlets let kudva finish :)17:27
rajdeepok17:27
kudvaI think many of my questions I can ask around the code17:27
pballandmany are probably best answered by thinrichs17:28
kudvaSo, I would like to have the code out to you17:28
pballanddo you want to discuss in IRC, or after you work on the code?17:28
kudvaand then have a discussion around the code to make sure the implementations, concepts I have captured properly. This way we will have a concrete strawman17:28
pballandperfect17:29
kudvaafter I have a version ready17:29
kudvawe can do a code/concept review together. Once I get feedback, I'll go back rework it17:29
pballandthat sounds good - anything else to discuss in this forum?17:30
kudva< 1 week is the time I have set for myself17:30
pballandok, I’ll give a summary of where I am at with the API17:31
pballandI’m starting to put together a design doc just on the api/data model17:32
*** jamie_h has joined #openstack-meeting-317:32
pballandI will have something to publish by the end of the week17:32
rajdeepok, i am assuming data model will reflect the driver data structures17:32
pballandrajdeep: yes, that’s the idea17:33
pballand1/2 will be data-source oriented17:33
pballandand the other half will be based on policy17:33
rajdeepok17:33
pballandone addition is the ability to have API-sourced tables, which act like the driver data, except the user can create/update them through the API17:34
pballandI expect this to be very useful for testing, demoing, and training17:34
rajdeepyou mean REST APIs?17:34
pballandyes17:35
pballandunlike datasource-plugins, the framework would manage data storage for these ‘internal’ tables17:35
rajdeepthat will be great17:35
pballand(better name welcome)17:35
rajdeepand perhaps a client library :)17:35
pballandso there are 3 types of data - ephemeral data from a datasource-plugin, static data managed through the API and stored by the framework, and derived data computed and exposed by the policy17:36
pballand(really the static/internal data is just a datasource-plugin that is always available)17:37
pballanddoes that sound reasonable?17:37
thinrichsSounds good to me.17:37
rajdeepyes it does where will static data be stored?17:37
pballandthinrichs: you’re back :)17:37
pballandrajdeep: my thought was to just use sqlite for now17:38
thinrichsBeen following but repeatedly interrupted.  Should be back for good now.17:38
thinrichsWhy not use our normal datastore?17:38
pballandwhat is our “normal” datastore?17:38
thinrichsAre we worried about persistence?  That's something we need to worry about for policy as well.17:38
pballandthe ‘internal’ tables would need to be persisted just like policy17:39
pballandI am considering putting both in sqlite for now17:39
thinrichsOur in-memory database that we use to cache data sources, reason about policy, etc.17:39
pballand(it’s not a scalable solution, but should be adequate for the use case)17:39
pballandah, for the internal tables, I think it would be useful for the data to survive restart17:40
pballand(and policy should definitely survive restart)17:40
thinrichsWe can always look at the internal tables as extra policy statements.17:40
thinrichsAnd use the same mechanism for persisting them that we do for persisting policy.17:40
pballandthinrichs: I’d rather model them closer to datasource plugins where we manage the persistance17:40
pballandin fact, maybe there are just 2 types of data (datasource and policy) and the ‘internal’ tables are just a datasource plugin that we ship with17:41
thinrichsI had thought we'd address persistence at the same time we address the need to store history.17:41
*** amotoki has joined #openstack-meeting-317:41
*** amotoki has quit IRC17:41
thinrichsFor auditing, that is.17:41
thinrichsSo the most recent policy/data is not the only thing we want to persist--we want the history of those things.17:42
thinrichsOr at least some of the history.17:42
pballandhmm, I don’t think we want to tackle history yet17:42
pballandhow about I write up a proposal and send it out17:43
thinrichsThat's fine if we want to delay.  But if we use the usual database approach to atomicity we get both history and persistence solved at the same time.17:43
thinrichspballand: proposal sounds good17:43
pballandexcept the scale requirements for the different things are entirely different orders of magnatude17:44
pballandok, other than the modeling (document end of week), I am working on the runtime17:44
pballandmy thought was to take the existing eventlet runtime and make it more pluggable so it can run API, policy, and message bus components17:45
*** SumitNaiksatam has quit IRC17:45
pballandoptionally, data source plugins can run in the loop too17:45
pballandany thoughts?17:46
thinrichsCan you give me a brief description of the eventlet runtime?  It's the scheduler for the policy/message bus/API, etc.?  ???17:46
rajdeepintegration with the eventlet engine will be good17:47
pballandit is basically a select loop - as each component blocks, something else gets scheduled17:47
thinrichsSo this is cooperative threading?17:47
pballandbasically yes17:48
pballandpython sucks at threads, so the greenthread approach is popular17:48
pballandif we want to go multi-processor, we can use multiple processes (orchastrated over message bus) or rewrite in a different language17:49
thinrichsSo we make our classes inherit from some special threading class and insert yield() calls at appropriate places?17:49
pballandthinrichs: exactly17:49
pballand(except you probalby don’t need many/any yields)17:50
thinrichsLet's keep everything in Python for now.17:50
thinrichsIf we need to we can think about multi-processor approaches later.17:51
pballandagreed - do we think we can all live in a single event loop for now?17:51
thinrichsyes17:51
pballand(I don’t know how well the plexxi DSE code will cooperate17:51
pballandanyone from plexxi on?17:51
thinrichsBTW, I'll try to get someone from Plexxi to start attending these meetings.17:52
thinrichsOops--running short on time.17:52
thinrichsAre we finished with API?17:52
pballandyup, I’ll stop rambling :)17:53
thinrichs:)17:53
thinrichsLast things from last week's action items...17:53
thinrichsI was supposed to get the Plexxi code merged.17:53
thinrichsDone (though I didn't do much to make it happen).17:53
thinrichsI'll volunteer to work with pballand to see if we can get everything integrated.17:53
thinrichsmessage bus, policy, data drivers17:53
pballandsounds good :)17:54
rajdeepplexxi code check in is good news17:54
thinrichsagreed17:54
thinrichsrajdeep: do you have tasks for next week that you're working on?17:55
thinrichsThe rest of us do.17:55
rajdeepi am planning to add some more usecases to nova17:55
rajdeepdriver17:55
thinrichsSounds good.17:55
thinrichsSo 5 minutes of open discussion.17:55
thinrichsrajdeep: you had some questions earlier.  Were they answered?17:56
pballandI was wondering if anyone was heading to Atlanta?17:56
rajdeepi had a question on groups and users construct in our use case17:56
rajdeepgroups are not used in keystone..17:56
thinrichspballand: I'm headed to Atlanta, though late.  Arriving Wed night.17:56
thinrichsrajdeep: for groups we could use the internal tables pballand was mentioning.17:57
thinrichsOr we could use the AD integration that's there.  We'd need to port it over to your framework.17:57
rajdeepyeah ..17:57
*** chuckC has quit IRC17:57
rajdeepthat would be better17:57
thinrichsThe downside to AD is that you need it running, which is inconvenient for demos/etc.17:57
rajdeepor use a light weight ldap17:58
*** SumitNaiksatam has joined #openstack-meeting-317:58
thinrichsUsers know they need to install OS to do a reasonable demo.  But the more things we make them install to see how use case number 1 works, the more likely they'll get hung up on problems that are irrelevant.17:59
thinrichsI'd lean toward using only OS components for our first release, just to minimize that problem.  But include AD drivers/LDAP drivers/whatever, so they know it's not just about OS.18:00
rajdeep+1 to keep it simple18:00
thinrichsAnd we're over time.18:01
pballand:)18:01
pballandthanks everyone18:01
rajdeepthanks bye18:01
thinrichsSo thanks everyone, and let's keep up discussions on ML and through google docs!18:01
thinrichs#endmeeting18:01
*** openstack changes topic to "OpenStack Meetings || https://wiki.openstack.org/wiki/Meetings"18:01
openstackMeeting ended Tue Apr 22 18:01:45 2014 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)18:01
openstackMinutes:        http://eavesdrop.openstack.org/meetings/congressteammeeting/2014/congressteammeeting.2014-04-22-17.04.html18:01
*** rajdeep has quit IRC18:01
openstackMinutes (text): http://eavesdrop.openstack.org/meetings/congressteammeeting/2014/congressteammeeting.2014-04-22-17.04.txt18:01
openstackLog:            http://eavesdrop.openstack.org/meetings/congressteammeeting/2014/congressteammeeting.2014-04-22-17.04.log.html18:01
*** jpomero_ has joined #openstack-meeting-318:01
*** mrunge has quit IRC18:03
*** jpomero has quit IRC18:03
*** chuckC has joined #openstack-meeting-318:09
*** thinrichs has quit IRC18:10
*** Hao has quit IRC18:12
*** Hao has joined #openstack-meeting-318:12
*** ttrifonov is now known as ttrifonov_zZzz18:13
*** eguz has joined #openstack-meeting-318:15
*** Hao has quit IRC18:16
*** ttrifonov_zZzz is now known as ttrifonov18:17
*** eghobo has quit IRC18:19
*** ttrifonov is now known as ttrifonov_zZzz18:19
*** jtomasek has quit IRC18:20
*** jtomasek has joined #openstack-meeting-318:28
*** pballand has quit IRC18:33
*** chuckC has quit IRC18:36
*** CristianF has joined #openstack-meeting-318:37
*** jpomero_ has quit IRC18:44
*** sweston has joined #openstack-meeting-318:44
*** jpomero_ has joined #openstack-meeting-318:45
*** jpomero__ has joined #openstack-meeting-318:45
*** chuckC has joined #openstack-meeting-318:49
*** jpomero_ has quit IRC18:50
*** pballand has joined #openstack-meeting-318:51
*** overlayer has joined #openstack-meeting-318:56
*** briancurtin has joined #openstack-meeting-318:58
*** samchoi has joined #openstack-meeting-318:58
*** Alex_Gaynor has joined #openstack-meeting-318:59
*** jamielennox has joined #openstack-meeting-318:59
briancurtin#startmeeting python-openstacksdk19:00
openstackMeeting started Tue Apr 22 19:00:12 2014 UTC and is due to finish in 60 minutes.  The chair is briancurtin. Information about MeetBot at http://wiki.debian.org/MeetBot.19:00
openstackUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.19:00
*** openstack changes topic to " (Meeting topic: python-openstacksdk)"19:00
openstackThe meeting name has been set to 'python_openstacksdk'19:00
briancurtinIf you're here for the python-openstacksdk meeting, please state your name and affiliation19:00
Alex_GaynorAlex Gaynor, (Rackspace, among others)19:00
edleafeEd Leafe, Rackspace19:01
wchrisjChris Johnson, HP19:01
briancurtinBrian Curtin, Rackspace19:01
jamielennoxJamie Lennox, Red Hat19:01
*** rockyg has joined #openstack-meeting-319:01
*** terrylhowe has joined #openstack-meeting-319:02
briancurtinWhile others may be showing up, here's an agenda: https://wiki.openstack.org/wiki/Meetings/PythonOpenStackSDK#Agenda_for_2014-04-22_1900_UTC19:02
terrylhoweTerry Howe HP19:02
*** david-lyle_afk is now known as david-lyle19:03
briancurtinI guess we'll get started, if people roll in, they roll in19:03
briancurtin#topic 3 weeks out from summit, would like to see if we can tighten up and push forward19:03
*** openstack changes topic to "3 weeks out from summit, would like to see if we can tighten up and push forward (Meeting topic: python-openstacksdk)"19:03
briancurtinWhat do we think is necessary at this point to reach a consensus on either Jamie's or Ed's class proposals?19:04
briancurtinAre we close, do we need more time, more proposals, etc?19:04
*** jcoufal has joined #openstack-meeting-319:05
jamielennoxi'm biased here so not waying in but i haven't heard any more proposals19:06
edleafeThe problem for me is that there is scattered feedback - nothing to summarize what someone feels are the fundamental agreement or disagreement with an approach19:06
edleafeSomeone might object to a method name, or a particular facet of the design, but still agree with the overall direction19:07
briancurtinjamielennox: nope, haven't seen any others, not sure if any planned. just asking19:07
jamielennoxedleafe: right - either way is going to need tweaking19:07
jamielennoxmy object to managers is that the interaction between the resource object and the manager is always going to be a bit difficult19:08
jamielennoxthis we've found with the current managers19:08
*** pballand has quit IRC19:08
jamielennoxthe obvious problem with classes is that we need something higher level to manage the session (or get a user to do it)19:09
edleafejamielennox: that was with keystoneclient, right?19:09
jamielennoxedleafe: keystoneclient has all sorts of other problems as well19:09
jamielennoxbut a standard pattern is this .getid() thing19:09
jamielennoxwhere you do an update and you don't know if an object or an id has been passed to the manager19:09
edleafeThat's a desirable design for an SDK user, IMO.19:10
jamielennoxand for nested resources where you end up with multiple required id's being passed, how do you pass an object to that19:10
jamielennoxthese have just always felt clunky to me19:11
edleafewhat is a 'nested resource'?19:11
jamielennox /users/X/roles/Y19:11
terrylhowesecurity group rules I suppose19:11
edleafeah19:12
edleafenot particularly problematic19:12
briancurtinbefore we get into the specifics of the proposals, can we first work out the mechanism by which we'll make a decision? i want to make sure we know how we can make this decision before we get into debating19:12
jamielennoxagreed19:12
jamielennoxit can be made to work if we don't inherit the existing stuff19:12
edleafepass in two params: user and role. Either can be object/id. The URL is constructed with the resolved IDs.19:12
jamielennoxedleafe: right, but then you call role.update() and it routes to the manager - so role has to keep track of user as well19:13
edleafebriancurtin: import random?19:13
edleafe;-)19:13
jamielennoxedleafe: again it's not unsolvable just ugly in the existing client work19:13
edleafejamielennox: I can see that, but in practice I haven't found it any more complex than it needs to be19:14
edleafeand it buys a lot of convenience for the user19:14
jamielennoxbriancurtin: i don't know - at the moment we have one vote each way and a moderator - everyone else is quiet19:14
edleafeI try to look at it from their POV and not mine as an SDK developer19:14
briancurtinjamielennox: should we actually use gerrit for the voting by some certain date? a bunch of people aren't here19:15
jamielennoxedleafe: i'm not sure if either is better that way19:15
jamielennoxedleafe: though i consider the objects to be fairly low level - ie there will be a v1, v2, v3 object and there will most likely be another layer on top managing the versions19:16
edleafejamielennox: Understood. My view is colored by my experience with what users have liked and not liked.19:16
jamielennoxedleafe: we can do objects at low level and some sort of managers at a higher? the first draft i put up had a manager concept19:17
edleafeyou could integrate managers into resources. I've done that but the design gets heavy quickly19:18
jamielennoxhaving trouble looking that far ahead - but i agree for the user facing stuff we don't want them to deal with there own sessions19:18
edleafesession meaning… ? The authed session? Or the underlying requests-based transport?19:19
jamielennoxbriancurtin: i don't have a better idea19:19
Alex_GaynorI just want to note that I really don't feel strongly at all about this issue.19:19
jamielennoxedleafe: I want to keep talking about this - but maybe post meeting19:20
briancurtinjamielennox: would it work to clear the votes on gerrit and just have a tally of them on maybe thursday?19:20
edleafejamielennox: Sure. I gotta run shortly after the meeting, but should be online later19:20
jamielennoxedleafe: it's 5:20am here - i'll be around for a while :)19:21
edleafehaha19:21
jamielennoxbriancurtin: that or just a wiki page with two columns19:22
jamielennoxbriancurtin: i guess it's just a matter of who else cares19:22
briancurtinjamielennox: wiki seems better, can keep history. i'll set it up. i don't actually know who cares, but whoever they are i'd like to hear from. i imagine dean cares but isn't ehre19:22
briancurtin*here19:23
jamielennoxyea, i expect so - he's probably done the most with the existing clients19:23
wchrisjwiki is good19:23
briancurtinonce we have that, as far as moving on even further, can we then implement the minimal bits of Keystone to get a service implemented on top?19:24
terrylhowewhat time Thursday?19:24
terrylhoweThe end of Thursday UTC?19:24
jamielennoxbriancurtin: so do you mean auth or keystone resources?19:24
briancurtinterrylhowe: that's what i was thinking19:24
briancurtinjamielennox: actually i think i mean auth19:25
terrylhowecool19:25
jamielennoxbriancurtin: so auth is going to be tied up with session because it is carried around19:25
edleafejamielennox: yes19:25
briancurtinah, true19:26
*** gothicmindfood has quit IRC19:26
edleafethere are use cases for multiple authed sessions existing at once19:26
jamielennoxi know how i'd do it but i'm waiting to see what dtroyer is up to - we discussed this a bit post meeting last week19:26
jamielennoxi think we can say though that there is a plugin to session and mock up something simple which can be fixed later19:27
terrylhoweDid you take a look at https://review.openstack.org/#/c/88485/ jamielennox19:28
jamielennoxah - no i hadn't seen that19:28
briancurtinterrylhowe: forgot to finish that review, but for your comment - yes, that's what i was thinking19:29
Alex_Gaynorit looks like it probably needs to be rejiggered to work with the transport stuff, but looks ok to me19:29
jamielennoxterrylhowe: i seem some minor comments, but it looks good to me19:30
briancurtinjamielennox: so given a chat with dtroyer, do you think we're reasonably close to having something where we could implement, e.g., creating a server?19:30
jamielennoxbriancurtin: i think if we pick either basic design and have auth then it's mostly a matter of starting on low level apis19:31
jamielennoxlow level = version specific19:31
briancurtinah, yeah that's good enough - don't need the higher level version abstraction piece at the moment19:31
* briancurtin needs to get terminology straight19:32
* jamielennox needs to stop just throwing out terms without thinking about them19:32
*** dtroyer has joined #openstack-meeting-319:34
briancurtinso at this point we have EOD UTC thursday for the wiki vote, and a chat with dtroyer to spell out some auth ideas, and then we're on the way to version-specific API building. i think that's a decent enough summary to take away19:35
briancurtinsince i kind of interrupted to get the high level things out of there, jamielennox and edleafe did you want to continue the manager-ish discussion or is that for later?19:36
edleafeDoes anyone else have opinions on either approach?19:37
briancurtinmy experience as an implementer is close to zero, but i like the feel of jamie's approach from my reads. i don't have a super strong swing that way, though19:38
briancurtinpart of what gets me on edleafe's is the feeling of duplication. i get how it works, but i poke around and leave feeling that being able to do the same thing several different ways isn't a positive quality. however, to an end user of a higher level "compute" or "storage" abstraction, maybe that's covered up by that level19:39
edleafebriancurtin: I get what you're saying, but look at these use cases:19:40
briancurtinperhaps that is clouded (no pun intended) by having gone through it in pyrax, which does the manager/client/resource19:40
Alex_GaynorYou super intended that pun.19:41
edleafeyou have a storage_object reference, and you want to delete that in swift. calling obj.delete() is simple enough.19:41
Alex_GaynorSo my feeling on the meta issue of "multiple names" for the same thing is that it can be ok, but all the names have to be /identitical/ behaviors, you can't have multiple ways to do the same thing and whether they are the same things varies by stuff.19:42
edleafebut if you know the container and object names, you could call client.delete(cont, objname) too19:42
edleafeit is frustrating to force the user to get an object reference just to delete it19:42
edleafebriancurtin: yeah, I've gotten a *ton* of feedback over the years19:43
jamielennoxedleafe: that is handled by classmethods on mine StorageObject.delete_by_id(session, cont, objname)19:43
jamielennoxi don't know if there is a usability argument either way19:43
jamielennoxbut i do like the seperation between this is a string id and this is an object19:44
edleafejamielennox: Yeah, I think we're both used to one way19:44
jamielennoxheh, the problem is that i'm used to the managers - i recognize it's currently a terrible implementation but it makes me want something else19:44
wchrisjI prefer the classmethod approach - less things to keep track of locgically19:45
*** alexpilotti has quit IRC19:46
briancurtini think i mostly prefer that as well, but i'll take another good look with edleafe's comments in mind19:47
edleafeAnd FWIW I'm not opposed to the classmethod approach.19:48
edleafeI need to work with it more to see the pros/cons19:49
edleafeit just feels upside-down right now19:49
jamielennoxedleafe: i think when looking at it consider it mostly for the api specific work, they are going to be resources that are manipulated by a higher level before being exposed to a user19:51
edleafejamielennox: not sure I follow what you have in mind19:52
*** alexpilotti has joined #openstack-meeting-319:52
jamielennoxi don't mind the design being like this all the way up but for this in particular19:52
jamielennoxedleafe: so for most services we are going to need multiple API implementations19:53
jamielennoxkeystone v2 and v3 nova, v1 v3 etc19:53
edleafeHow does that affect the resource?19:54
jamielennoxso i expect we will have (for example) a user layer which wraps around a v2 or v3 user19:54
*** mwagner_lap has quit IRC19:55
*** markmcclain has quit IRC19:55
jamielennoxi like the design better this way in general, but if nothing else i think it will be easier to work with for the version specific layer - even if we wrap a client object around it later19:56
briancurtin2 min left, any last words before heading back to -sdks?19:58
edleafenone here19:58
*** otherwiseguy has joined #openstack-meeting-319:59
jamielennoxi'm good19:59
briancurtini will go ahead and put together that wiki page, email it, and mention it in the channel tomorrow to the few people i know weren't here. we'll figure it out EOD thursday, then see if we can move onward with the auth stuff and build on19:59
Alex_GaynorAwesome.20:00
briancurtin#endmeeting20:00
*** openstack changes topic to "OpenStack Meetings || https://wiki.openstack.org/wiki/Meetings"20:00
openstackMeeting ended Tue Apr 22 20:00:20 2014 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)20:00
openstackMinutes:        http://eavesdrop.openstack.org/meetings/python_openstacksdk/2014/python_openstacksdk.2014-04-22-19.00.html20:00
openstackMinutes (text): http://eavesdrop.openstack.org/meetings/python_openstacksdk/2014/python_openstacksdk.2014-04-22-19.00.txt20:00
openstackLog:            http://eavesdrop.openstack.org/meetings/python_openstacksdk/2014/python_openstacksdk.2014-04-22-19.00.log.html20:00
*** terrylhowe has left #openstack-meeting-320:00
*** jcoufal has quit IRC20:01
*** Alex_Gaynor has left #openstack-meeting-320:02
*** markmcclain has joined #openstack-meeting-320:03
*** TravT has joined #openstack-meeting-320:07
*** dtroyer has left #openstack-meeting-320:14
*** CristianF has quit IRC20:23
*** TravT has quit IRC20:25
*** chuckC has quit IRC20:27
*** julim has quit IRC20:30
*** TravT has joined #openstack-meeting-320:51
*** TravT has quit IRC20:55
*** TravT has joined #openstack-meeting-320:55
*** kudva has quit IRC21:04
*** jpomero__ has quit IRC21:04
*** rockyg has quit IRC21:11
*** jtomasek has quit IRC21:12
*** jpomero has joined #openstack-meeting-321:23
*** mfer has quit IRC21:35
*** overlayer has quit IRC21:40
*** lblanchard has quit IRC21:42
*** peristeri has quit IRC22:05
*** mwagner_lap has joined #openstack-meeting-322:07
*** markmcclain has quit IRC22:10
*** jamie_h has quit IRC22:14
*** banix has quit IRC22:20
*** otherwiseguy has quit IRC22:33
*** banix has joined #openstack-meeting-322:54
*** banix has quit IRC22:58
*** david-lyle has quit IRC23:10
*** samchoi has quit IRC23:13
*** eguz has quit IRC23:36
*** eghobo has joined #openstack-meeting-323:36
*** wchrisj has quit IRC23:48

Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!