*** mwagner_lap has joined #openstack-meeting-3 | 00:00 | |
*** chuckC has quit IRC | 00:04 | |
*** eguz has quit IRC | 00:11 | |
*** amotoki_ has quit IRC | 00:12 | |
*** wchrisj has joined #openstack-meeting-3 | 00:15 | |
*** sarob_ has quit IRC | 00:15 | |
*** sarob has joined #openstack-meeting-3 | 00:16 | |
*** sarob has quit IRC | 00:21 | |
*** krotscheck has quit IRC | 00:36 | |
*** krotscheck has joined #openstack-meeting-3 | 00:39 | |
*** peristeri has quit IRC | 00:40 | |
*** SumitNaiksatam has quit IRC | 00:53 | |
*** wchrisj has quit IRC | 00:58 | |
*** SumitNaiksatam has joined #openstack-meeting-3 | 01:25 | |
*** banix has joined #openstack-meeting-3 | 01:46 | |
*** chuckC has joined #openstack-meeting-3 | 01:53 | |
*** banix has quit IRC | 01:59 | |
*** baojg has joined #openstack-meeting-3 | 02:00 | |
*** chuckC has quit IRC | 02:06 | |
*** wchrisj has joined #openstack-meeting-3 | 02:06 | |
*** wchrisj has quit IRC | 02:47 | |
*** coolsvap|afk is now known as coolsvap | 02:48 | |
*** eghobo has joined #openstack-meeting-3 | 02:53 | |
*** jpomero has quit IRC | 03:06 | |
*** banix has joined #openstack-meeting-3 | 03:15 | |
*** sarob has joined #openstack-meeting-3 | 03:20 | |
*** sankarshan has joined #openstack-meeting-3 | 03:21 | |
*** sarob has quit IRC | 03:25 | |
*** banix has quit IRC | 03:38 | |
*** TravT has quit IRC | 04:00 | |
*** wchrisj has joined #openstack-meeting-3 | 04:30 | |
*** baojg has quit IRC | 04:48 | |
*** baojg has joined #openstack-meeting-3 | 04:48 | |
*** chuckC has joined #openstack-meeting-3 | 04:52 | |
*** sankarshan is now known as sankarshan_away | 05:01 | |
*** yamahata has joined #openstack-meeting-3 | 05:06 | |
*** wchrisj has quit IRC | 05:10 | |
*** baojg_ has joined #openstack-meeting-3 | 05:10 | |
*** yamahata has quit IRC | 05:12 | |
*** yamahata has joined #openstack-meeting-3 | 05:12 | |
*** baojg has quit IRC | 05:14 | |
*** cjellick has quit IRC | 05:17 | |
*** cjellick has joined #openstack-meeting-3 | 05:17 | |
*** cjellick has quit IRC | 05:18 | |
*** jtomasek has joined #openstack-meeting-3 | 05:58 | |
*** jcoufal has joined #openstack-meeting-3 | 06:07 | |
*** ttrifonov_zZzz is now known as ttrifonov | 06:17 | |
*** cjellick has joined #openstack-meeting-3 | 06:18 | |
*** yamahata has quit IRC | 06:19 | |
*** cjellick has quit IRC | 06:26 | |
*** sankarshan_away is now known as sankarshan | 06:30 | |
*** ttrifonov is now known as ttrifonov_zZzz | 06:43 | |
*** chuckC has quit IRC | 07:04 | |
*** eghobo has quit IRC | 07:15 | |
*** ttrifonov_zZzz is now known as ttrifonov | 07:33 | |
*** jcoufal has quit IRC | 07:33 | |
*** jcoufal has joined #openstack-meeting-3 | 07:40 | |
*** mrunge has joined #openstack-meeting-3 | 07:42 | |
*** nacim has joined #openstack-meeting-3 | 07:50 | |
*** ttrifonov is now known as ttrifonov_zZzz | 07:53 | |
*** ttrifonov_zZzz is now known as ttrifonov | 07:54 | |
*** jtomasek has quit IRC | 08:04 | |
*** jtomasek has joined #openstack-meeting-3 | 08:04 | |
*** safchain has joined #openstack-meeting-3 | 08:18 | |
*** jamie_h has joined #openstack-meeting-3 | 08:28 | |
*** ttrifonov is now known as ttrifonov_zZzz | 08:50 | |
*** ttrifonov_zZzz is now known as ttrifonov | 09:00 | |
*** jamie_h has quit IRC | 09:11 | |
*** jamie_h has joined #openstack-meeting-3 | 09:12 | |
*** sankarshan is now known as sankarshan_away | 09:32 | |
*** jamie_h has quit IRC | 09:36 | |
*** jamie_h has joined #openstack-meeting-3 | 09:36 | |
*** MaxV has joined #openstack-meeting-3 | 09:42 | |
*** jamie_h has quit IRC | 09:42 | |
*** jamie_h has joined #openstack-meeting-3 | 09:45 | |
*** jamie_h has quit IRC | 09:52 | |
*** jamie_h has joined #openstack-meeting-3 | 09:53 | |
*** MaxV has quit IRC | 10:05 | |
*** garyduan has joined #openstack-meeting-3 | 10:08 | |
*** gduan has quit IRC | 10:09 | |
*** akrivoka has joined #openstack-meeting-3 | 10:39 | |
*** coolsvap is now known as coolsvap|afk | 10:40 | |
*** akrivoka has quit IRC | 10:48 | |
*** MaxV has joined #openstack-meeting-3 | 10:53 | |
*** jamie_h has quit IRC | 10:56 | |
*** jamie_h has joined #openstack-meeting-3 | 11:00 | |
*** alexpilotti has joined #openstack-meeting-3 | 11:02 | |
*** alexpilotti has quit IRC | 11:07 | |
*** baojg_ has quit IRC | 11:10 | |
*** baojg has joined #openstack-meeting-3 | 11:11 | |
*** baojg has quit IRC | 11:16 | |
*** enikanorov_ has quit IRC | 11:43 | |
*** jcoufal has quit IRC | 12:04 | |
*** jcoufal has joined #openstack-meeting-3 | 12:04 | |
*** jcoufal has quit IRC | 12:09 | |
*** jcoufal has joined #openstack-meeting-3 | 12:09 | |
*** jcoufal has quit IRC | 12:14 | |
*** jcoufal has joined #openstack-meeting-3 | 12:14 | |
*** jcoufal has quit IRC | 12:15 | |
*** jcoufal has joined #openstack-meeting-3 | 12:15 | |
*** jcoufal has quit IRC | 12:18 | |
*** jcoufal has joined #openstack-meeting-3 | 12:19 | |
*** jcoufal has quit IRC | 12:20 | |
*** jcoufal has joined #openstack-meeting-3 | 12:20 | |
*** sankarshan_away is now known as sankarshan | 12:25 | |
*** xuhanp has joined #openstack-meeting-3 | 12:41 | |
*** jpich has joined #openstack-meeting-3 | 12:49 | |
*** overlayer has joined #openstack-meeting-3 | 12:59 | |
*** banix has joined #openstack-meeting-3 | 13:08 | |
*** jpomero has joined #openstack-meeting-3 | 13:22 | |
*** MaxV has quit IRC | 13:33 | |
*** MaxV has joined #openstack-meeting-3 | 13:38 | |
*** MaxV has quit IRC | 13:38 | |
*** nacim_ has joined #openstack-meeting-3 | 13:40 | |
*** nacim has quit IRC | 13:40 | |
*** julim has joined #openstack-meeting-3 | 13:42 | |
*** wchrisj has joined #openstack-meeting-3 | 13:43 | |
*** mrunge has quit IRC | 13:55 | |
*** mfer has joined #openstack-meeting-3 | 13:56 | |
*** peristeri has joined #openstack-meeting-3 | 14:04 | |
*** jamie_h_ has joined #openstack-meeting-3 | 14:09 | |
*** markmcclain has joined #openstack-meeting-3 | 14:12 | |
*** markmcclain1 has joined #openstack-meeting-3 | 14:16 | |
*** markmcclain has quit IRC | 14:16 | |
*** ttrifonov is now known as ttrifonov_zZzz | 14:20 | |
*** overlayer has quit IRC | 14:27 | |
*** mwagner_lap has quit IRC | 14:29 | |
*** jcoufal has quit IRC | 14:29 | |
*** david-lyle has joined #openstack-meeting-3 | 14:31 | |
*** xuhanp has quit IRC | 14:49 | |
*** devlaps has joined #openstack-meeting-3 | 15:03 | |
*** alexpilotti has joined #openstack-meeting-3 | 15:04 | |
*** nacim_ has quit IRC | 15:10 | |
*** jcoufal has joined #openstack-meeting-3 | 15:12 | |
*** markmcclain1 has quit IRC | 15:16 | |
*** cjellick has joined #openstack-meeting-3 | 15:20 | |
*** Hao has joined #openstack-meeting-3 | 15:27 | |
*** cjellick has quit IRC | 15:30 | |
*** cjellick has joined #openstack-meeting-3 | 15:31 | |
*** absubram has joined #openstack-meeting-3 | 15:33 | |
*** lblanchard has joined #openstack-meeting-3 | 15:34 | |
*** tqtran has joined #openstack-meeting-3 | 15:34 | |
*** akrivoka has joined #openstack-meeting-3 | 15:38 | |
*** nacim_ has joined #openstack-meeting-3 | 15:38 | |
*** mwagner_lap has joined #openstack-meeting-3 | 15:39 | |
*** pballand has joined #openstack-meeting-3 | 15:43 | |
*** chuckC has joined #openstack-meeting-3 | 15:51 | |
*** eghobo has joined #openstack-meeting-3 | 15:51 | |
*** amotoki has quit IRC | 15:52 | |
*** tzumainn has joined #openstack-meeting-3 | 15:54 | |
*** amotoki has joined #openstack-meeting-3 | 15:57 | |
*** mrunge has joined #openstack-meeting-3 | 15:58 | |
*** pbelanyi_ has joined #openstack-meeting-3 | 15:58 | |
*** clu_ has joined #openstack-meeting-3 | 15:58 | |
*** tmazur has joined #openstack-meeting-3 | 16:00 | |
*** doug-fish has joined #openstack-meeting-3 | 16:00 | |
tzumainn | hi all! | 16:01 |
---|---|---|
mrunge | o/ | 16:02 |
david-lyle | #startmeeting Horizon | 16:02 |
openstack | Meeting 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 |
openstack | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 16:02 |
*** johnma has joined #openstack-meeting-3 | 16:02 | |
*** openstack changes topic to " (Meeting topic: Horizon)" | 16:02 | |
openstack | The meeting name has been set to 'horizon' | 16:02 |
akrivoka | hiya | 16:02 |
pbelanyi_ | hi | 16:02 |
jcoufal | ahoy o/ | 16:02 |
amotoki | hi | 16:02 |
absubram | hi | 16:02 |
david-lyle | Hello everyone | 16:02 |
SergeyLukjanov | o/ (lurking for Sahara related topics) | 16:03 |
lblanchard | hi all! | 16:03 |
clu_ | hi! | 16:03 |
tqtran | hello | 16:03 |
david-lyle | Icehouse is officially release, on to Juno and backports to stable/icehouse. | 16:03 |
david-lyle | Thanks everyone for all you efforts on icehouse. | 16:04 |
david-lyle | Something we can all be proud of | 16:04 |
jcoufal | nice! great job to all | 16:05 |
david-lyle | The 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-lyle | 2x topics to slots | 16:07 |
jcoufal | How many slots do we have? | 16:07 |
david-lyle | I'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-lyle | jcoufal: 8 | 16:07 |
mrunge | we have lots of technical things to discuss | 16:08 |
david-lyle | mrunge, re: node or other items | 16:08 |
mrunge | david-lyle, well, I'd say, they might be connected | 16:08 |
jpich | http://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 work | 16:09 |
david-lyle | I could see that, but node/npm will be a means to an end here | 16:09 |
david-lyle | jpich, agreed, the only thing I could see for that would be a demo, but it doesn't sound to be that far along | 16:10 |
jcoufal | jpich: +1 | 16:10 |
tqtran | is it too late to add topics? | 16:10 |
mrunge | jpich, I agree somehow. Although that proposal looks a bit empty | 16:11 |
mrunge | or cloudy, I'd say ;-) | 16:11 |
doug-fish | This seems like an easy +1 http://summit.openstack.org/cfp/details/32 | 16:11 |
jpich | Re: Nodejs, there are people (Radomir?) who are investigating other alternatives for compiling CSS | 16:11 |
*** thinrichs has joined #openstack-meeting-3 | 16:11 | |
mrunge | yes, and discussed websockets, or discussed using marconi for websockets | 16:12 |
mrunge | node would be the other solution for async messaging | 16:12 |
jpich | tqtran: 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 |
jpich | mrunge: I'd prefer to see a Python solution, I think that's where we were going with the sockets | 16:13 |
lblanchard | doug-fish: thanks for the +1!! | 16:13 |
*** thinrichs has quit IRC | 16:14 | |
david-lyle | doug-fish: I think so too | 16:14 |
mrunge | jpich, me too, +1 for a python solution | 16:14 |
clu_ | doug-fish lblanchard: +1, important | 16:14 |
tzumainn | do you guys think an etherpad might help to remember the +1s and the like? | 16:14 |
*** markmcclain has joined #openstack-meeting-3 | 16:15 | |
*** julim has quit IRC | 16:15 | |
*** mrunge has quit IRC | 16:15 | |
david-lyle | mrunge, jpich, the issue goes beyond mere compilation. It includes testing and development tools | 16:15 |
jpich | I agree UX is an important session, though it might still need to be combined with another one | 16:15 |
jcoufal | doug-fish: can we join http://summit.openstack.org/cfp/details/315 together with discussion about http://summit.openstack.org/cfp/details/32 | 16:16 |
david-lyle | My question regarding UX is, there are two cross-project UX sessions, should that topic be addressed there? | 16:16 |
doug-fish | I'd expect UX and accessibility to have very little overlapping content | 16:16 |
jcoufal | david-lyle: it would be nice - is there enough space for cross-project sessions? | 16:17 |
*** jamie_h_ has quit IRC | 16:17 | |
doug-fish | david-lyle: can you link those sessions? | 16:17 |
david-lyle | jcoufal: 2 UX session are already scheduled | 16:17 |
* david-lyle finding links | 16:18 | |
jpich | doug-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 session | 16:18 |
doug-fish | jpich: great point. Will do that. | 16:18 |
david-lyle | http://junodesignsummit.sched.org/ | 16:18 |
david-lyle | http://junodesignsummit.sched.org/event/e13c8775849567fe8576c16875d5c547#.U1aWfPldXoM | 16:19 |
tzumainn | david-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 |
jcoufal | david-lyle: found it, russel extended one for two slots | 16:19 |
lblanchard | david-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 two | 16:19 |
lblanchard | back to back | 16:19 |
david-lyle | lblanchard, the question is with those, should we put your Horizon content in there? | 16:20 |
jcoufal | lblanchard: though I think that the first one can be designers gathering and second can be more practical | 16:20 |
*** julim has joined #openstack-meeting-3 | 16:20 | |
lblanchard | david-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 around | 16:20 |
david-lyle | or 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/175 | 16:21 |
lblanchard | david-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 stuff | 16:21 |
jcoufal | tzumainn: the etherpad will be helpful, thanks | 16:21 |
jcoufal | lblanchard: but that can be covered in the first part | 16:21 |
*** mattf has joined #openstack-meeting-3 | 16:22 | |
david-lyle | thanks tzumainn | 16:22 |
lblanchard | clu_: 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 users | 16:22 |
tzumainn | np! | 16:22 |
* mattf waves | 16:22 | |
*** cjellick has quit IRC | 16:22 | |
* mattf is a sahara lurker | 16:22 | |
*** johnma has quit IRC | 16:22 | |
mattf | regret from chad | 16:22 |
jcoufal | lblanchard: I think we can use second part of the session to ease the load from Horizon to cover the usability feedback | 16:22 |
*** cjellick has joined #openstack-meeting-3 | 16:23 | |
lblanchard | jcoufal: 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 discussions | 16:23 |
lblanchard | jcoufal: I totally disagree. | 16:23 |
lblanchard | jcoufal: unless the devs are there :) | 16:23 |
david-lyle | mrunge, does separation have open questions, or just needing off ? | 16:23 |
david-lyle | s/off/effort/ | 16:23 |
lblanchard | jcoufal: we have designs we will be showing and what to get dev feedback | 16:23 |
*** johnma has joined #openstack-meeting-3 | 16:23 | |
jcoufal | lblanchard: why not? I believe it will be interesting for people from all projects, since the UI covers majority of them | 16:24 |
jcoufal | and I am hoping that cross-project session will not overlap with Horizon's | 16:24 |
lblanchard | jcoufal: Yes, I think anyone who is interested in Usability Feedback on Horizon should attend | 16:24 |
lblanchard | jcoufal: but it should be on Horizon track | 16:24 |
*** ttrifonov_zZzz is now known as ttrifonov | 16:24 | |
lblanchard | jcoufal: so that there isn't another session overlapping potentially taking the Horizon devs away from that important discussion | 16:25 |
jcoufal | david-lyle: can we do voting for sessions in tzumainn's etherpad? https://etherpad.openstack.org/p/horizon-atlanta-summit | 16:26 |
jcoufal | I think that might help | 16:26 |
david-lyle | lblanchard, first UX session has a conflict for me, second UX session is good | 16:26 |
david-lyle | jcoufal, sure let's add a +1, -1 to topics on there, and maybe we can cull some obvious ones | 16:27 |
* david-lyle wishfully thinking | 16:27 | |
jcoufal | david-lyle: +1 from me | 16:28 |
doug-fish | What 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/129 | 16:28 |
doug-fish | they both seem closely tied and necessary for splitting horizon | 16:28 |
*** nacim_ has quit IRC | 16:28 | |
david-lyle | doug-fish, yes those two can combine | 16:28 |
jpich | I 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 room | 16:30 |
jpich | It'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 combine | 16:30 |
tzumainn | jpich, +1, I think the same thing was suggested for tripleo | 16:31 |
lblanchard | jpich: +1, I will start discussions around the sessions I proposed | 16:31 |
*** tqtran has quit IRC | 16:32 | |
jcoufal | david-lyle: modular widget based approach can be combined with Horizon pluggable content? | 16:32 |
david-lyle | certainly related | 16:33 |
amotoki | jpich: +1. totally agree. | 16:33 |
david-lyle | jpich: very much agree | 16:34 |
jpich | Great. We should ping the session owners who are not at this meeting and encourage them to do so soon | 16:34 |
jpich | I can do this and post a comment about this on all the proposals, if that sounds like a reasonable approach | 16:36 |
tzumainn | sounds reasonable to me! | 16:36 |
doug-fish | I 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-fish | I haven't been to a summit before - is that a reasonable concern? | 16:37 |
jcoufal | doug-fish: I don't think so :) | 16:38 |
lblanchard | doug-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 |
jpich | doug-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 me | 16:38 |
lblanchard | doug-fish: Tom Fifield works closely with the user committee. | 16:38 |
doug-fish | cool! | 16:38 |
lblanchard | jpich: +1!! | 16:38 |
david-lyle | jcoufal: I think http://summit.openstack.org/cfp/details/175 may come out of your http://summit.openstack.org/cfp/details/356 naturally | 16:38 |
david-lyle | it did last time | 16:38 |
lblanchard | it's our best bet to get past devs and chat with ops IMO! | 16:39 |
lblanchard | david-lyle: operators attended the sessions? | 16:39 |
doug-fish | It 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-lyle | those expressing operator type concerns, what their true role was, unsure | 16:40 |
jpich | lblanchard: I think a number of operators have a few contributions under their belt, so as ATC they can attend | 16:40 |
lblanchard | jpich: good point! | 16:40 |
lblanchard | I 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 |
jcoufal | david-lyle: Probably, but I can't assure this :) But there definitely will be space for ask them questions | 16:41 |
david-lyle | Let's continue this on the etherpad: #link https://etherpad.openstack.org/p/horizon-atlanta-summit | 16:41 |
david-lyle | #topic Open Discussion | 16:42 |
*** openstack changes topic to "Open Discussion (Meeting topic: Horizon)" | 16:42 | |
*** jamie_h has quit IRC | 16:42 | |
david-lyle | want 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 now | 16:42 |
mattf | SergeyLukjanov, NikitaKonovalov ^^ kick off some sahara discussion? | 16:43 |
mattf | SergeyLukjanov is our PTL and has a great handle on the topics like sahara v heat, which came up on the mailing list thread | 16:43 |
*** alexpilotti has quit IRC | 16:43 | |
SergeyLukjanov | hey | 16:44 |
SergeyLukjanov | I'll send a response to jcoufal in ML | 16:44 |
david-lyle | as Sahara has graduated, I don't think Horizon makes the decision it should merge with Heat :) | 16:44 |
jcoufal | SergeyLukjanov: thanks | 16:44 |
SergeyLukjanov | in two words sahara isn't the part of orchestration, sahara use heat for it | 16:44 |
jcoufal | david-lyle: not proposing that, I am just trying to figure out the relationship :) | 16:45 |
SergeyLukjanov | example of existing projects with the same layout - trove | 16:45 |
david-lyle | jcoufal, sure | 16:45 |
SergeyLukjanov | trove has separated panel for their "cluster" (named databases) | 16:45 |
*** alexpilotti has joined #openstack-meeting-3 | 16:45 | |
SergeyLukjanov | I'll try to explain the relations more detailed in ML | 16:45 |
SergeyLukjanov | re sahara dashboard merging into the horizon, I have a question | 16:46 |
SergeyLukjanov | do we need some time on summit to discuss it? | 16:46 |
mattf | i'll add that horizon integration has been a primary goal for sahara. we only grew a cli interface very recently. | 16:46 |
jpich | I don't think so, it doesn't seem controversial? We want you guys in :) | 16:46 |
jcoufal | SergeyLukjanov: sure thing, we can continue in the ML | 16:46 |
mattf | we want to make the workflow of cluster provisioning or data processing job execution very smooth and horizon first | 16:47 |
SergeyLukjanov | my init idea is to merge current state to the horizon during the J cycle and than iterate many times on UX | 16:47 |
jcoufal | SergeyLukjanov: agree with jpich, I am not disagreeing with merger, more trying to find the best place for it | 16:47 |
tzumainn | out of curiosity, is there a preferred workflow when a new project integrates with horizon? | 16:47 |
NikitaKonovalov | there is a change by crobertsrh adding a sahara-client | 16:47 |
NikitaKonovalov | this one https://review.openstack.org/#/c/86648/7 | 16:48 |
NikitaKonovalov | so that's a good first step to start with I guess | 16:48 |
jpich | tzumainn: Not really so far: new project submits their code, we make it more horizony if required, then it gets merged | 16:48 |
lblanchard | SergeyLukjanov: +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 |
jcoufal | SergeyLukjanov: 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 master | 16:49 |
*** clu_ has quit IRC | 16:49 | |
SergeyLukjanov | jcoufal, I'm not proposing to merge it as is, just to not change the overall approach | 16:50 |
jcoufal | therefore 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 |
jcoufal | SergeyLukjanov: I think we are on the same page here | 16:50 |
SergeyLukjanov | jcoufal, my only concern is that we should merge it during the Juno or we need to supply it separately again and disable in horizon | 16:51 |
SergeyLukjanov | jcoufal, cool | 16:51 |
jpich | Horizon'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 is | 16:51 |
david-lyle | I think with the newer panel, panel group and dashboard order management, reorganizing will be a lot simpler | 16:51 |
jcoufal | SergeyLukjanov: I think Juno is no problem here | 16:51 |
SergeyLukjanov | I hope ;) | 16:52 |
jcoufal | SergeyLukjanov: We will make it ;) | 16:52 |
* mattf crosses fingers | 16:52 | |
amotoki | from our past experience, we need to start tests a bit earlier. devstack integration or easy-setup-dev env really helps us. | 16:53 |
SergeyLukjanov | amotoki, sahara is in the integrated gate, there are not too many tests atm, but devstack integration should work ok | 16:53 |
amotoki | SergeyLukjanov: great. when I tried to run trove, it was a bit tricky and i need to explore more info... | 16:54 |
SergeyLukjanov | amotoki, I think that we could ask Chad (croberts) to make some short doc about how to test his patches | 16:54 |
tzumainn | SergeyLukjanov, that would be awesome : ) | 16:54 |
jcoufal | need to run for today, but thanks guys, will continue this topic in ML | 16:54 |
jcoufal | have a great day all | 16:54 |
jpich | Yep, include the steps in the blueprint maybe | 16:54 |
mattf | jcoufal, thx | 16:54 |
*** jcoufal has quit IRC | 16:55 | |
SergeyLukjanov | we have a good docs for sahara re installation including our plugin for dashboard - http://docs.openstack.org/developer/sahara/#user-guide | 16:55 |
mattf | he's not here, you should #action chad for bp test docs | 16:55 |
SergeyLukjanov | jcoufal, thanks | 16:55 |
SergeyLukjanov | #action croberts to add doc re testing his changes for merging sahara-dashboard into the horizon | 16:55 |
amotoki | Sahara 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-lyle | thanks amotoki | 16:57 |
jpich | Thanks amotoki! | 16:57 |
jpich | If 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 well | 16:58 |
david-lyle | I 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 |
SergeyLukjanov | thank you, folks | 16:59 |
doug-fish | Thanks for soliciting input david-lyle! well handled. | 16:59 |
david-lyle | thanks, SergeyLukjanov, mattf, NikitaKonovalov, looking forward to adding Sahara support | 17:00 |
david-lyle | time's up | 17:00 |
mattf | pleasure | 17:00 |
david-lyle | #endmeeting | 17:00 |
*** openstack changes topic to "OpenStack Meetings || https://wiki.openstack.org/wiki/Meetings" | 17:00 | |
mattf | thx folks | 17:00 |
openstack | Meeting ended Tue Apr 22 17:00:29 2014 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 17:00 |
openstack | Minutes: http://eavesdrop.openstack.org/meetings/horizon/2014/horizon.2014-04-22-16.02.html | 17:00 |
openstack | Minutes (text): http://eavesdrop.openstack.org/meetings/horizon/2014/horizon.2014-04-22-16.02.txt | 17:00 |
tzumainn | thanks all | 17:00 |
openstack | Log: http://eavesdrop.openstack.org/meetings/horizon/2014/horizon.2014-04-22-16.02.log.html | 17:00 |
*** tzumainn has left #openstack-meeting-3 | 17:00 | |
jpich | Thanks, everyone | 17:00 |
NikitaKonovalov | thanks | 17:00 |
akrivoka | thanks everyone, have a good week | 17:00 |
*** rajdeep has joined #openstack-meeting-3 | 17:00 | |
*** thinrichs has joined #openstack-meeting-3 | 17:01 | |
lblanchard | thanks all!! | 17:01 |
david-lyle | Have a great week everyone! | 17:01 |
*** safchain has quit IRC | 17:01 | |
*** akrivoka has left #openstack-meeting-3 | 17:01 | |
*** jpich has left #openstack-meeting-3 | 17:01 | |
*** johnma has quit IRC | 17:01 | |
lblanchard | david-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-3 | 17:01 | |
amotoki | thanks everyone. night! | 17:02 |
*** amotoki has quit IRC | 17:02 | |
pballand | howdy | 17:02 |
thinrichs | Hi all | 17:02 |
*** enikanorov_ has joined #openstack-meeting-3 | 17:02 | |
rajdeep | hi all | 17:02 |
david-lyle | lblanchard, wasn's sure of the scope of those sessions | 17:02 |
*** doug-fish has left #openstack-meeting-3 | 17:02 | |
david-lyle | I'll ping you later about it | 17:02 |
*** kudva has joined #openstack-meeting-3 | 17:03 | |
lblanchard | david-lyle: will continue in #openstack-ux | 17:03 |
*** pbelanyi_ has quit IRC | 17:03 | |
*** mrunge has joined #openstack-meeting-3 | 17:03 | |
thinrichs | Anyone else here for the Congress meeting? | 17:03 |
kudva | It's kudva | 17:04 |
thinrichs | Hi kudva | 17:04 |
kudva | Hi | 17:04 |
rajdeep | rajdeep | 17:04 |
thinrichs | #startmeeting CongressTeamMeeting | 17:04 |
openstack | Meeting 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 |
openstack | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 17:04 |
thinrichs | Hi rajdeep | 17:04 |
*** openstack changes topic to " (Meeting topic: CongressTeamMeeting)" | 17:04 | |
openstack | The meeting name has been set to 'congressteammeeting' | 17:05 |
thinrichs | Usual agenda today: recap on action items, look at todos for alpha release, open discussion | 17:05 |
pballand | I’d like to chat a bit about the conference at the end if there is time | 17:06 |
thinrichs | Let's start with rajdeep. Can you report on data drivers? | 17:06 |
rajdeep | yes.. | 17:06 |
rajdeep | i completed some key integration points for nova driver | 17:06 |
rajdeep | getting the server and flavor data in and converted to tuples | 17:06 |
rajdeep | the code has been checked in | 17:07 |
rajdeep | and tim approved today morning | 17:07 |
*** eghobo has quit IRC | 17:07 | |
*** eghobo has joined #openstack-meeting-3 | 17:07 | |
rajdeep | #link https://review.openstack.org/#/c/88228/ | 17:07 |
*** absubram has quit IRC | 17:07 | |
thinrichs | So 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 |
rajdeep | i guess so | 17:08 |
rajdeep | one challenge which i came across is how much API coverage should driver have | 17:08 |
rajdeep | POST and DELETE APIs are not needed | 17:08 |
thinrichs | Right--for data source drivers we want only API calls that do not CHANGE anything | 17:09 |
rajdeep | so focussing on GET requests and prioritize | 17:09 |
pballand | rajdeep: 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 |
thinrichs | But as we discussed during review, ideally we'll support the core API for each component. | 17:09 |
rajdeep | yes we should strive for that | 17:10 |
rajdeep | cover as much possible and applicable | 17:10 |
*** alexpilotti_ has joined #openstack-meeting-3 | 17:10 | |
rajdeep | now for the use case i had few questions we can discuss during the end | 17:10 |
thinrichs | Eventually 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 |
thinrichs | But for POC, I think the coverage we have is good. | 17:11 |
thinrichs | rajdeep: sounds good. | 17:11 |
rajdeep | our drivers will also evolve with the openstack and their component versions | 17:11 |
rajdeep | which is not designed in the driver itself | 17:11 |
rajdeep | i am assuming we will have separate driver for each component and version | 17:12 |
thinrichs | rajdeep: agreed | 17:12 |
rajdeep | perhaps a driver factory on the top | 17:12 |
rajdeep | to load the right driver depending on the version | 17:12 |
thinrichs | Sounds good. | 17:13 |
pballand | qustion: do we expect drivers to be registered at startup? | 17:13 |
thinrichs | kudva: how are the builtins going? | 17:13 |
kudva | Okay, I got the feedback from Tim on my document. | 17:13 |
kudva | I have started implementation in my sandbox. | 17:13 |
thinrichs | pballand: not sure. Ideally we could hot-swap at runtime | 17:13 |
*** alexpilotti has quit IRC | 17:13 | |
*** alexpilotti_ is now known as alexpilotti | 17:13 | |
thinrichs | kudva: great! | 17:13 |
kudva | In a week or so, I can put the code in for review | 17:13 |
rajdeep | pballand : drivers can be instantiated but you need to call def update_from_datasource(self) | 17:14 |
kudva | Right now I am assuming my own builtin directory in congress/policy | 17:14 |
kudva | but we can decide where to put it. | 17:14 |
*** tmazur has quit IRC | 17:14 | |
rajdeep | to pull data | 17:14 |
thinrichs | kudva: that sounds about right. | 17:14 |
thinrichs | I'm looking forward to doing that review--builtins have been on the list for a long time. | 17:15 |
thinrichs | kudva: any issues come up that need discussing with the group? | 17:15 |
*** david-lyle is now known as david-lyle_afk | 17:16 | |
thinrichs | perhaps kudva had to step away. | 17:17 |
thinrichs | pballand: how's the API going? | 17:18 |
pballand | can I ask more questions about data source plugins? | 17:18 |
thinrichs | sure | 17:18 |
kudva | sorry, someone came into my office | 17:18 |
pballand | do we want validation between the policy and data sources? | 17:18 |
pballand | e.g. if a data source can dynamically start publishing data, can the policy be declared over it before it joins? | 17:19 |
thinrichs | I 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 |
pballand | yeah, for the API, I’m wondering how strict we should be with schemas and validation | 17:19 |
thinrichs | pballand: I'd say yes. I'm thinking of upgrades. Suppose user decides to upgrade Neutron to the next version. | 17:19 |
thinrichs | Either they upgrade the data source first or the policy first. Either way there's a window where we have a mismatch. | 17:20 |
rajdeep | or we have policy meta data which ties it to a version of the data source | 17:20 |
pballand | so are tables versioned? ('nova-diablo:vm’) | 17:20 |
thinrichs | I 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 |
thinrichs | policy violations that is. | 17:21 |
thinrichs | I think for alpha release we're just assuming upgrades don't happen. | 17:22 |
pballand | I propose we allow adding items to tuples, but force a table name change if columns are removed or the meaning of a column changes | 17:22 |
thinrichs | If 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 |
pballand | so we may wind up with something like nova-vm-version1, nova-vm-version2 | 17:23 |
thinrichs | pballand: forcing a table-name change would require changing policy. | 17:23 |
pballand | yup - so we’d like to avoid table semantics if possible | 17:23 |
pballand | avoid *changing* table semantics | 17:23 |
thinrichs | Policy is hard to get right--I worry about telling people they need to change it every time they upgrade. | 17:24 |
thinrichs | Without knowing there are no other options. | 17:24 |
rajdeep | perhaps we could allow schema changes | 17:24 |
pballand | I 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 schema | 17:24 |
thinrichs | Sorry--got to step away for a minute. pballand, can you take over? | 17:25 |
rajdeep | and ignore errors because of missing data | 17:25 |
pballand | thinrichs: yup | 17:25 |
pballand | what I was going to propose is that for a given datasource::table name, we can add columns between releases, but not remove any | 17:25 |
rajdeep | well it will be easier to add new colums at the end of tuple | 17:26 |
pballand | rajdeep: exactly - that would be allowed | 17:26 |
rajdeep | i have a new method to get metadata for a tuple | 17: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 |
rajdeep | sorry | 17:27 |
pballand | if 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 table | 17:27 |
pballand | ok, thanks for the input | 17:27 |
pballand | lets let kudva finish :) | 17:27 |
rajdeep | ok | 17:27 |
kudva | I think many of my questions I can ask around the code | 17:27 |
pballand | many are probably best answered by thinrichs | 17:28 |
kudva | So, I would like to have the code out to you | 17:28 |
pballand | do you want to discuss in IRC, or after you work on the code? | 17:28 |
kudva | and then have a discussion around the code to make sure the implementations, concepts I have captured properly. This way we will have a concrete strawman | 17:28 |
pballand | perfect | 17:29 |
kudva | after I have a version ready | 17:29 |
kudva | we can do a code/concept review together. Once I get feedback, I'll go back rework it | 17:29 |
pballand | that sounds good - anything else to discuss in this forum? | 17:30 |
kudva | < 1 week is the time I have set for myself | 17:30 |
pballand | ok, I’ll give a summary of where I am at with the API | 17:31 |
pballand | I’m starting to put together a design doc just on the api/data model | 17:32 |
*** jamie_h has joined #openstack-meeting-3 | 17:32 | |
pballand | I will have something to publish by the end of the week | 17:32 |
rajdeep | ok, i am assuming data model will reflect the driver data structures | 17:32 |
pballand | rajdeep: yes, that’s the idea | 17:33 |
pballand | 1/2 will be data-source oriented | 17:33 |
pballand | and the other half will be based on policy | 17:33 |
rajdeep | ok | 17:33 |
pballand | one addition is the ability to have API-sourced tables, which act like the driver data, except the user can create/update them through the API | 17:34 |
pballand | I expect this to be very useful for testing, demoing, and training | 17:34 |
rajdeep | you mean REST APIs? | 17:34 |
pballand | yes | 17:35 |
pballand | unlike datasource-plugins, the framework would manage data storage for these ‘internal’ tables | 17:35 |
rajdeep | that will be great | 17:35 |
pballand | (better name welcome) | 17:35 |
rajdeep | and perhaps a client library :) | 17:35 |
pballand | so 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 policy | 17:36 |
pballand | (really the static/internal data is just a datasource-plugin that is always available) | 17:37 |
pballand | does that sound reasonable? | 17:37 |
thinrichs | Sounds good to me. | 17:37 |
rajdeep | yes it does where will static data be stored? | 17:37 |
pballand | thinrichs: you’re back :) | 17:37 |
pballand | rajdeep: my thought was to just use sqlite for now | 17:38 |
thinrichs | Been following but repeatedly interrupted. Should be back for good now. | 17:38 |
thinrichs | Why not use our normal datastore? | 17:38 |
pballand | what is our “normal” datastore? | 17:38 |
thinrichs | Are we worried about persistence? That's something we need to worry about for policy as well. | 17:38 |
pballand | the ‘internal’ tables would need to be persisted just like policy | 17:39 |
pballand | I am considering putting both in sqlite for now | 17:39 |
thinrichs | Our 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 |
pballand | ah, for the internal tables, I think it would be useful for the data to survive restart | 17:40 |
pballand | (and policy should definitely survive restart) | 17:40 |
thinrichs | We can always look at the internal tables as extra policy statements. | 17:40 |
thinrichs | And use the same mechanism for persisting them that we do for persisting policy. | 17:40 |
pballand | thinrichs: I’d rather model them closer to datasource plugins where we manage the persistance | 17:40 |
pballand | in fact, maybe there are just 2 types of data (datasource and policy) and the ‘internal’ tables are just a datasource plugin that we ship with | 17:41 |
thinrichs | I had thought we'd address persistence at the same time we address the need to store history. | 17:41 |
*** amotoki has joined #openstack-meeting-3 | 17:41 | |
*** amotoki has quit IRC | 17:41 | |
thinrichs | For auditing, that is. | 17:41 |
thinrichs | So the most recent policy/data is not the only thing we want to persist--we want the history of those things. | 17:42 |
thinrichs | Or at least some of the history. | 17:42 |
pballand | hmm, I don’t think we want to tackle history yet | 17:42 |
pballand | how about I write up a proposal and send it out | 17:43 |
thinrichs | That'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 |
thinrichs | pballand: proposal sounds good | 17:43 |
pballand | except the scale requirements for the different things are entirely different orders of magnatude | 17:44 |
pballand | ok, other than the modeling (document end of week), I am working on the runtime | 17:44 |
pballand | my thought was to take the existing eventlet runtime and make it more pluggable so it can run API, policy, and message bus components | 17:45 |
*** SumitNaiksatam has quit IRC | 17:45 | |
pballand | optionally, data source plugins can run in the loop too | 17:45 |
pballand | any thoughts? | 17:46 |
thinrichs | Can you give me a brief description of the eventlet runtime? It's the scheduler for the policy/message bus/API, etc.? ??? | 17:46 |
rajdeep | integration with the eventlet engine will be good | 17:47 |
pballand | it is basically a select loop - as each component blocks, something else gets scheduled | 17:47 |
thinrichs | So this is cooperative threading? | 17:47 |
pballand | basically yes | 17:48 |
pballand | python sucks at threads, so the greenthread approach is popular | 17:48 |
pballand | if we want to go multi-processor, we can use multiple processes (orchastrated over message bus) or rewrite in a different language | 17:49 |
thinrichs | So we make our classes inherit from some special threading class and insert yield() calls at appropriate places? | 17:49 |
pballand | thinrichs: exactly | 17:49 |
pballand | (except you probalby don’t need many/any yields) | 17:50 |
thinrichs | Let's keep everything in Python for now. | 17:50 |
thinrichs | If we need to we can think about multi-processor approaches later. | 17:51 |
pballand | agreed - do we think we can all live in a single event loop for now? | 17:51 |
thinrichs | yes | 17:51 |
pballand | (I don’t know how well the plexxi DSE code will cooperate | 17:51 |
pballand | anyone from plexxi on? | 17:51 |
thinrichs | BTW, I'll try to get someone from Plexxi to start attending these meetings. | 17:52 |
thinrichs | Oops--running short on time. | 17:52 |
thinrichs | Are we finished with API? | 17:52 |
pballand | yup, I’ll stop rambling :) | 17:53 |
thinrichs | :) | 17:53 |
thinrichs | Last things from last week's action items... | 17:53 |
thinrichs | I was supposed to get the Plexxi code merged. | 17:53 |
thinrichs | Done (though I didn't do much to make it happen). | 17:53 |
thinrichs | I'll volunteer to work with pballand to see if we can get everything integrated. | 17:53 |
thinrichs | message bus, policy, data drivers | 17:53 |
pballand | sounds good :) | 17:54 |
rajdeep | plexxi code check in is good news | 17:54 |
thinrichs | agreed | 17:54 |
thinrichs | rajdeep: do you have tasks for next week that you're working on? | 17:55 |
thinrichs | The rest of us do. | 17:55 |
rajdeep | i am planning to add some more usecases to nova | 17:55 |
rajdeep | driver | 17:55 |
thinrichs | Sounds good. | 17:55 |
thinrichs | So 5 minutes of open discussion. | 17:55 |
thinrichs | rajdeep: you had some questions earlier. Were they answered? | 17:56 |
pballand | I was wondering if anyone was heading to Atlanta? | 17:56 |
rajdeep | i had a question on groups and users construct in our use case | 17:56 |
rajdeep | groups are not used in keystone.. | 17:56 |
thinrichs | pballand: I'm headed to Atlanta, though late. Arriving Wed night. | 17:56 |
thinrichs | rajdeep: for groups we could use the internal tables pballand was mentioning. | 17:57 |
thinrichs | Or we could use the AD integration that's there. We'd need to port it over to your framework. | 17:57 |
rajdeep | yeah .. | 17:57 |
*** chuckC has quit IRC | 17:57 | |
rajdeep | that would be better | 17:57 |
thinrichs | The downside to AD is that you need it running, which is inconvenient for demos/etc. | 17:57 |
rajdeep | or use a light weight ldap | 17:58 |
*** SumitNaiksatam has joined #openstack-meeting-3 | 17:58 | |
thinrichs | Users 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 |
thinrichs | I'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 simple | 18:00 |
thinrichs | And we're over time. | 18:01 |
pballand | :) | 18:01 |
pballand | thanks everyone | 18:01 |
rajdeep | thanks bye | 18:01 |
thinrichs | So thanks everyone, and let's keep up discussions on ML and through google docs! | 18:01 |
thinrichs | #endmeeting | 18:01 |
*** openstack changes topic to "OpenStack Meetings || https://wiki.openstack.org/wiki/Meetings" | 18:01 | |
openstack | Meeting ended Tue Apr 22 18:01:45 2014 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 18:01 |
openstack | Minutes: http://eavesdrop.openstack.org/meetings/congressteammeeting/2014/congressteammeeting.2014-04-22-17.04.html | 18:01 |
*** rajdeep has quit IRC | 18:01 | |
openstack | Minutes (text): http://eavesdrop.openstack.org/meetings/congressteammeeting/2014/congressteammeeting.2014-04-22-17.04.txt | 18:01 |
openstack | Log: http://eavesdrop.openstack.org/meetings/congressteammeeting/2014/congressteammeeting.2014-04-22-17.04.log.html | 18:01 |
*** jpomero_ has joined #openstack-meeting-3 | 18:01 | |
*** mrunge has quit IRC | 18:03 | |
*** jpomero has quit IRC | 18:03 | |
*** chuckC has joined #openstack-meeting-3 | 18:09 | |
*** thinrichs has quit IRC | 18:10 | |
*** Hao has quit IRC | 18:12 | |
*** Hao has joined #openstack-meeting-3 | 18:12 | |
*** ttrifonov is now known as ttrifonov_zZzz | 18:13 | |
*** eguz has joined #openstack-meeting-3 | 18:15 | |
*** Hao has quit IRC | 18:16 | |
*** ttrifonov_zZzz is now known as ttrifonov | 18:17 | |
*** eghobo has quit IRC | 18:19 | |
*** ttrifonov is now known as ttrifonov_zZzz | 18:19 | |
*** jtomasek has quit IRC | 18:20 | |
*** jtomasek has joined #openstack-meeting-3 | 18:28 | |
*** pballand has quit IRC | 18:33 | |
*** chuckC has quit IRC | 18:36 | |
*** CristianF has joined #openstack-meeting-3 | 18:37 | |
*** jpomero_ has quit IRC | 18:44 | |
*** sweston has joined #openstack-meeting-3 | 18:44 | |
*** jpomero_ has joined #openstack-meeting-3 | 18:45 | |
*** jpomero__ has joined #openstack-meeting-3 | 18:45 | |
*** chuckC has joined #openstack-meeting-3 | 18:49 | |
*** jpomero_ has quit IRC | 18:50 | |
*** pballand has joined #openstack-meeting-3 | 18:51 | |
*** overlayer has joined #openstack-meeting-3 | 18:56 | |
*** briancurtin has joined #openstack-meeting-3 | 18:58 | |
*** samchoi has joined #openstack-meeting-3 | 18:58 | |
*** Alex_Gaynor has joined #openstack-meeting-3 | 18:59 | |
*** jamielennox has joined #openstack-meeting-3 | 18:59 | |
briancurtin | #startmeeting python-openstacksdk | 19:00 |
openstack | Meeting 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 |
openstack | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 19:00 |
*** openstack changes topic to " (Meeting topic: python-openstacksdk)" | 19:00 | |
openstack | The meeting name has been set to 'python_openstacksdk' | 19:00 |
briancurtin | If you're here for the python-openstacksdk meeting, please state your name and affiliation | 19:00 |
Alex_Gaynor | Alex Gaynor, (Rackspace, among others) | 19:00 |
edleafe | Ed Leafe, Rackspace | 19:01 |
wchrisj | Chris Johnson, HP | 19:01 |
briancurtin | Brian Curtin, Rackspace | 19:01 |
jamielennox | Jamie Lennox, Red Hat | 19:01 |
*** rockyg has joined #openstack-meeting-3 | 19:01 | |
*** terrylhowe has joined #openstack-meeting-3 | 19:02 | |
briancurtin | While others may be showing up, here's an agenda: https://wiki.openstack.org/wiki/Meetings/PythonOpenStackSDK#Agenda_for_2014-04-22_1900_UTC | 19:02 |
terrylhowe | Terry Howe HP | 19:02 |
*** david-lyle_afk is now known as david-lyle | 19:03 | |
briancurtin | I guess we'll get started, if people roll in, they roll in | 19:03 |
briancurtin | #topic 3 weeks out from summit, would like to see if we can tighten up and push forward | 19: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 | |
briancurtin | What do we think is necessary at this point to reach a consensus on either Jamie's or Ed's class proposals? | 19:04 |
briancurtin | Are we close, do we need more time, more proposals, etc? | 19:04 |
*** jcoufal has joined #openstack-meeting-3 | 19:05 | |
jamielennox | i'm biased here so not waying in but i haven't heard any more proposals | 19:06 |
edleafe | The problem for me is that there is scattered feedback - nothing to summarize what someone feels are the fundamental agreement or disagreement with an approach | 19:06 |
edleafe | Someone might object to a method name, or a particular facet of the design, but still agree with the overall direction | 19:07 |
briancurtin | jamielennox: nope, haven't seen any others, not sure if any planned. just asking | 19:07 |
jamielennox | edleafe: right - either way is going to need tweaking | 19:07 |
jamielennox | my object to managers is that the interaction between the resource object and the manager is always going to be a bit difficult | 19:08 |
jamielennox | this we've found with the current managers | 19:08 |
*** pballand has quit IRC | 19:08 | |
jamielennox | the obvious problem with classes is that we need something higher level to manage the session (or get a user to do it) | 19:09 |
edleafe | jamielennox: that was with keystoneclient, right? | 19:09 |
jamielennox | edleafe: keystoneclient has all sorts of other problems as well | 19:09 |
jamielennox | but a standard pattern is this .getid() thing | 19:09 |
jamielennox | where you do an update and you don't know if an object or an id has been passed to the manager | 19:09 |
edleafe | That's a desirable design for an SDK user, IMO. | 19:10 |
jamielennox | and for nested resources where you end up with multiple required id's being passed, how do you pass an object to that | 19:10 |
jamielennox | these have just always felt clunky to me | 19:11 |
edleafe | what is a 'nested resource'? | 19:11 |
jamielennox | /users/X/roles/Y | 19:11 |
terrylhowe | security group rules I suppose | 19:11 |
edleafe | ah | 19:12 |
edleafe | not particularly problematic | 19:12 |
briancurtin | before 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 debating | 19:12 |
jamielennox | agreed | 19:12 |
jamielennox | it can be made to work if we don't inherit the existing stuff | 19:12 |
edleafe | pass in two params: user and role. Either can be object/id. The URL is constructed with the resolved IDs. | 19:12 |
jamielennox | edleafe: right, but then you call role.update() and it routes to the manager - so role has to keep track of user as well | 19:13 |
edleafe | briancurtin: import random? | 19:13 |
edleafe | ;-) | 19:13 |
jamielennox | edleafe: again it's not unsolvable just ugly in the existing client work | 19:13 |
edleafe | jamielennox: I can see that, but in practice I haven't found it any more complex than it needs to be | 19:14 |
edleafe | and it buys a lot of convenience for the user | 19:14 |
jamielennox | briancurtin: i don't know - at the moment we have one vote each way and a moderator - everyone else is quiet | 19:14 |
edleafe | I try to look at it from their POV and not mine as an SDK developer | 19:14 |
briancurtin | jamielennox: should we actually use gerrit for the voting by some certain date? a bunch of people aren't here | 19:15 |
jamielennox | edleafe: i'm not sure if either is better that way | 19:15 |
jamielennox | edleafe: 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 versions | 19:16 |
edleafe | jamielennox: Understood. My view is colored by my experience with what users have liked and not liked. | 19:16 |
jamielennox | edleafe: we can do objects at low level and some sort of managers at a higher? the first draft i put up had a manager concept | 19:17 |
edleafe | you could integrate managers into resources. I've done that but the design gets heavy quickly | 19:18 |
jamielennox | having trouble looking that far ahead - but i agree for the user facing stuff we don't want them to deal with there own sessions | 19:18 |
edleafe | session meaning… ? The authed session? Or the underlying requests-based transport? | 19:19 |
jamielennox | briancurtin: i don't have a better idea | 19:19 |
Alex_Gaynor | I just want to note that I really don't feel strongly at all about this issue. | 19:19 |
jamielennox | edleafe: I want to keep talking about this - but maybe post meeting | 19:20 |
briancurtin | jamielennox: would it work to clear the votes on gerrit and just have a tally of them on maybe thursday? | 19:20 |
edleafe | jamielennox: Sure. I gotta run shortly after the meeting, but should be online later | 19:20 |
jamielennox | edleafe: it's 5:20am here - i'll be around for a while :) | 19:21 |
edleafe | haha | 19:21 |
jamielennox | briancurtin: that or just a wiki page with two columns | 19:22 |
jamielennox | briancurtin: i guess it's just a matter of who else cares | 19:22 |
briancurtin | jamielennox: 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 ehre | 19:22 |
briancurtin | *here | 19:23 |
jamielennox | yea, i expect so - he's probably done the most with the existing clients | 19:23 |
wchrisj | wiki is good | 19:23 |
briancurtin | once 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 |
terrylhowe | what time Thursday? | 19:24 |
terrylhowe | The end of Thursday UTC? | 19:24 |
jamielennox | briancurtin: so do you mean auth or keystone resources? | 19:24 |
briancurtin | terrylhowe: that's what i was thinking | 19:24 |
briancurtin | jamielennox: actually i think i mean auth | 19:25 |
terrylhowe | cool | 19:25 |
jamielennox | briancurtin: so auth is going to be tied up with session because it is carried around | 19:25 |
edleafe | jamielennox: yes | 19:25 |
briancurtin | ah, true | 19:26 |
*** gothicmindfood has quit IRC | 19:26 | |
edleafe | there are use cases for multiple authed sessions existing at once | 19:26 |
jamielennox | i 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 week | 19:26 |
jamielennox | i think we can say though that there is a plugin to session and mock up something simple which can be fixed later | 19:27 |
terrylhowe | Did you take a look at https://review.openstack.org/#/c/88485/ jamielennox | 19:28 |
jamielennox | ah - no i hadn't seen that | 19:28 |
briancurtin | terrylhowe: forgot to finish that review, but for your comment - yes, that's what i was thinking | 19:29 |
Alex_Gaynor | it looks like it probably needs to be rejiggered to work with the transport stuff, but looks ok to me | 19:29 |
jamielennox | terrylhowe: i seem some minor comments, but it looks good to me | 19:30 |
briancurtin | jamielennox: 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 |
jamielennox | briancurtin: i think if we pick either basic design and have auth then it's mostly a matter of starting on low level apis | 19:31 |
jamielennox | low level = version specific | 19:31 |
briancurtin | ah, yeah that's good enough - don't need the higher level version abstraction piece at the moment | 19:31 |
* briancurtin needs to get terminology straight | 19:32 | |
* jamielennox needs to stop just throwing out terms without thinking about them | 19:32 | |
*** dtroyer has joined #openstack-meeting-3 | 19:34 | |
briancurtin | so 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 away | 19:35 |
briancurtin | since 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 |
edleafe | Does anyone else have opinions on either approach? | 19:37 |
briancurtin | my 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, though | 19:38 |
briancurtin | part 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 level | 19:39 |
edleafe | briancurtin: I get what you're saying, but look at these use cases: | 19:40 |
briancurtin | perhaps that is clouded (no pun intended) by having gone through it in pyrax, which does the manager/client/resource | 19:40 |
Alex_Gaynor | You super intended that pun. | 19:41 |
edleafe | you have a storage_object reference, and you want to delete that in swift. calling obj.delete() is simple enough. | 19:41 |
Alex_Gaynor | So 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 |
edleafe | but if you know the container and object names, you could call client.delete(cont, objname) too | 19:42 |
edleafe | it is frustrating to force the user to get an object reference just to delete it | 19:42 |
edleafe | briancurtin: yeah, I've gotten a *ton* of feedback over the years | 19:43 |
jamielennox | edleafe: that is handled by classmethods on mine StorageObject.delete_by_id(session, cont, objname) | 19:43 |
jamielennox | i don't know if there is a usability argument either way | 19:43 |
jamielennox | but i do like the seperation between this is a string id and this is an object | 19:44 |
edleafe | jamielennox: Yeah, I think we're both used to one way | 19:44 |
jamielennox | heh, the problem is that i'm used to the managers - i recognize it's currently a terrible implementation but it makes me want something else | 19:44 |
wchrisj | I prefer the classmethod approach - less things to keep track of locgically | 19:45 |
*** alexpilotti has quit IRC | 19:46 | |
briancurtin | i think i mostly prefer that as well, but i'll take another good look with edleafe's comments in mind | 19:47 |
edleafe | And FWIW I'm not opposed to the classmethod approach. | 19:48 |
edleafe | I need to work with it more to see the pros/cons | 19:49 |
edleafe | it just feels upside-down right now | 19:49 |
jamielennox | edleafe: 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 user | 19:51 |
edleafe | jamielennox: not sure I follow what you have in mind | 19:52 |
*** alexpilotti has joined #openstack-meeting-3 | 19:52 | |
jamielennox | i don't mind the design being like this all the way up but for this in particular | 19:52 |
jamielennox | edleafe: so for most services we are going to need multiple API implementations | 19:53 |
jamielennox | keystone v2 and v3 nova, v1 v3 etc | 19:53 |
edleafe | How does that affect the resource? | 19:54 |
jamielennox | so i expect we will have (for example) a user layer which wraps around a v2 or v3 user | 19:54 |
*** mwagner_lap has quit IRC | 19:55 | |
*** markmcclain has quit IRC | 19:55 | |
jamielennox | i 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 later | 19:56 |
briancurtin | 2 min left, any last words before heading back to -sdks? | 19:58 |
edleafe | none here | 19:58 |
*** otherwiseguy has joined #openstack-meeting-3 | 19:59 | |
jamielennox | i'm good | 19:59 |
briancurtin | i 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 on | 19:59 |
Alex_Gaynor | Awesome. | 20:00 |
briancurtin | #endmeeting | 20:00 |
*** openstack changes topic to "OpenStack Meetings || https://wiki.openstack.org/wiki/Meetings" | 20:00 | |
openstack | Meeting ended Tue Apr 22 20:00:20 2014 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 20:00 |
openstack | Minutes: http://eavesdrop.openstack.org/meetings/python_openstacksdk/2014/python_openstacksdk.2014-04-22-19.00.html | 20:00 |
openstack | Minutes (text): http://eavesdrop.openstack.org/meetings/python_openstacksdk/2014/python_openstacksdk.2014-04-22-19.00.txt | 20:00 |
openstack | Log: http://eavesdrop.openstack.org/meetings/python_openstacksdk/2014/python_openstacksdk.2014-04-22-19.00.log.html | 20:00 |
*** terrylhowe has left #openstack-meeting-3 | 20:00 | |
*** jcoufal has quit IRC | 20:01 | |
*** Alex_Gaynor has left #openstack-meeting-3 | 20:02 | |
*** markmcclain has joined #openstack-meeting-3 | 20:03 | |
*** TravT has joined #openstack-meeting-3 | 20:07 | |
*** dtroyer has left #openstack-meeting-3 | 20:14 | |
*** CristianF has quit IRC | 20:23 | |
*** TravT has quit IRC | 20:25 | |
*** chuckC has quit IRC | 20:27 | |
*** julim has quit IRC | 20:30 | |
*** TravT has joined #openstack-meeting-3 | 20:51 | |
*** TravT has quit IRC | 20:55 | |
*** TravT has joined #openstack-meeting-3 | 20:55 | |
*** kudva has quit IRC | 21:04 | |
*** jpomero__ has quit IRC | 21:04 | |
*** rockyg has quit IRC | 21:11 | |
*** jtomasek has quit IRC | 21:12 | |
*** jpomero has joined #openstack-meeting-3 | 21:23 | |
*** mfer has quit IRC | 21:35 | |
*** overlayer has quit IRC | 21:40 | |
*** lblanchard has quit IRC | 21:42 | |
*** peristeri has quit IRC | 22:05 | |
*** mwagner_lap has joined #openstack-meeting-3 | 22:07 | |
*** markmcclain has quit IRC | 22:10 | |
*** jamie_h has quit IRC | 22:14 | |
*** banix has quit IRC | 22:20 | |
*** otherwiseguy has quit IRC | 22:33 | |
*** banix has joined #openstack-meeting-3 | 22:54 | |
*** banix has quit IRC | 22:58 | |
*** david-lyle has quit IRC | 23:10 | |
*** samchoi has quit IRC | 23:13 | |
*** eguz has quit IRC | 23:36 | |
*** eghobo has joined #openstack-meeting-3 | 23:36 | |
*** wchrisj has quit IRC | 23:48 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!