18:07:28 #startmeeting savanna 18:07:29 Meeting started Thu Jan 23 18:07:28 2014 UTC and is due to finish in 60 minutes. The chair is SergeyLukjanov. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:07:30 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:07:32 The meeting name has been set to 'savanna' 18:08:01 #topic Agenda 18:08:16 #link https://wiki.openstack.org/wiki/Meetings/SavannaAgenda#Agenda_for_January.2C_23 18:08:37 action items are partially resolved 18:08:47 will make an update next time 18:08:52 #topic Icehouse-2 dev milestone 18:09:26 #link http://lists.openstack.org/pipermail/openstack-dev/2014-January/025250.html 18:09:36 you can find links and details in this email 18:09:59 we've successfully delivered icehouse-2 with mostly all planned features and bugs fixed 18:10:12 so, my congratulations! 18:10:17 congrats all! 18:10:39 Great job everyone! 18:10:55 it's our second dev milestone 18:11:01 it's terrific to see all the progress on heat integration 18:11:02 hurrrah! 18:11:21 congrats! 18:11:25 it was handled by ttx 18:11:32 for the main savanna project 18:11:56 ok, let's move on 18:12:06 #topic News / updates 18:12:10 folks, please 18:12:14 share news 18:12:29 preferably good news, because I have some bad ones 18:12:43 UI part of java actions and HDFS are up for review, seem positive so far. 18:12:47 just a few -create cli commands short of having full coverage of the v1.1 api 18:12:51 On the HDP side, we are moving forward with EDP change, Blueprints, DiskBuilder and docs 18:12:57 I'm looking at more Oozie actions now, streaming mapreduce first 18:13:41 I'am replacing SSH configuring with the guest agent 18:13:55 continue working on Heat integration polishing, fixing some bugs, also yesterday I've realised that savanna heat engine does;t working with heat in master 18:14:23 ErikB, that's awesome to hear about dib elements for HDP 18:14:40 because of https://bugs.launchpad.net/heat/+bug/1271597 18:14:47 I'm working on blogpost about data locality support, hopefully will be published soon 18:14:49 SergeyLukjanov, will be a good change and Bob should me merging shortly. 18:15:01 but seems the bug will be fixed in the heat side soon 18:15:22 I hope to submit a patch for the HDP DIB elements sometime over the next few days. 18:15:37 bob_nettleton: awesome!! 18:15:42 bob_nettleton, awesome, ping me or mattf if any questions 18:15:51 great. thanks! 18:16:01 * mattf gets his meat grinder ready 18:16:08 SergeyLukjanov, what is the bad news… 18:16:25 the bad news are about Savanna project naming 18:16:40 forcing us to add a trailing h? 18:16:47 ;-) 18:16:53 mattf, lol 18:16:57 I've contacted OpenStack Foundation marketing team to ensure that we're using consumable names 18:17:04 * mattf hands out Gs Ns and Us 18:17:15 * SergeyLukjanov looking for the bad link 18:17:38 aaaaand 18:17:41 #link http://www.thetus.com/savanna 18:17:50 other than savannah, we're almost past out painful name collision with "havana" 18:18:16 mattf, yep, but it's not so bad 18:18:19 :-( so we should rename our wonderful project Savanna, right? 18:18:26 aignatov, yep 18:18:35 * mattf groans 18:18:52 and we should at least find the new name in next 2-4 weeks 18:19:03 to be able to rename the world before the graduation review 18:19:14 SergeyLukjanov, have a pointer to the trademark registration? 18:19:43 proposing new name - Saratov :) 18:19:46 mattf, their project was released first time Feb 2010 18:19:58 and so it's at least bad to use the same name 18:20:08 because it's a project in the same area - cloud, hadoop 18:20:11 SergeyLukjanov you may combine the fact you need new name with the fact you are not only Hadoop now - you are "Data processing" OS program 18:20:42 SergeyLukjanov, and elephants topic (Savanna) seems to be not right now, really :) 18:20:50 that's the only pros I see... 18:20:55 so maybe renaming is a good idea anyway 18:21:06 nope, I really love the Savanna naming! 18:21:12 :D 18:21:20 it could be an elephant topic still, why not? 18:21:23 we can use 'Savannah' :D 18:21:30 I dislike h 18:21:30 SergeyLukjanov, do they have a trademark on the name Savanna, is the os foundation going to acquire a trademark on our name? 18:21:43 mattf, I'll clarify that 18:21:53 How about "Grassland" ? :) 18:22:19 :) 18:22:39 StackVanna? 18:22:45 lol! 18:22:56 I'll start a ML thread when ensure all details 18:23:05 and we'll try to find the better name 18:23:08 than npthing ;) 18:23:28 I hope that will find the great naming that'll be ok for all ofus 18:23:39 we should at least 1. check is Savanna is really registered 2. contact thetus and try to buy name 18:23:41 is there an existing trademark on Savanna? is the openstack foundation going to trademark our eventual name? 18:24:14 mattf, I'll ask foundation about that 18:24:19 don't worry :) 18:24:36 this is going to be especially rough on ErikB, who still uses quantum 18:24:57 ErikB, we're here to help 18:25:52 Even Google don't know about these Thetus Savanna :) Try "cloud hadoop savanna" - you'll see only your Savanna 18:26:32 don't -> doesn't 18:26:34 this stuff is best left to the lawyers, but we definitely should jump ship on the name unless we have a solid reason 18:26:43 DinaBelova, that's right, but it looks like it'll not help us :( 18:27:26 heh, so, to summarize 18:27:47 I'll talk again with foundation folks to clarify stuff 18:28:03 and than start a mailing thread (if needed) to find the name 18:28:12 let's move on 18:28:16 #topic Meeting re-org 18:28:31 I was thinking about how our meeting working now and have some ideas 18:28:43 I'd like to share them and receive some feedback 18:29:07 #1 add topics with topic chairs how will be responsible for them 18:29:25 like Heat integration update or CI status 18:29:41 how->who? 18:29:49 yep 18:30:01 it could contain about 1-2 sentences with short clearly defined status news 18:30:05 status/news 18:30:28 idea #2: 18:30:39 heh, I completely forgot the second idea 18:30:49 any thoughts on the first one? 18:30:54 i guess we can settle #2 then 18:31:09 :) 18:31:23 #1 could just be a rundown of active bps, each has an assignee 18:31:38 what is the difference between idea1 and what is happening right now when we just say news/updates? 18:31:57 i think we get the information into the minutes anyway. if there's value in structuring it more, i'm ok witht hat 18:32:41 Chad works on the UI, he updates us about it, Trevor owirks on EDP, he updates us, I work on Heat, I update you 18:33:01 owirks -> works :) 18:33:14 aignatov, that's correct 18:33:24 the idea was to ensure that all parts are covered 18:33:26 I also don't see difference with what we have right now 18:33:35 for example I'd like to see CI status updates 18:34:06 afaict #1 is some added structure, seems low overhead, but the added value hasn't been articulated yet 18:34:06 probably structuring is overcomplexity 18:34:16 SergeyLukjanov: if you like CI updates - you can always ask about it 18:34:47 alazarev, I'd like to avoid pings, just short updates 18:35:03 because we already have enough stuff that could be shared weekly 18:35:57 so, currently it looks for me that we could distribute interesting topics between folks and everyone will now what should he/she cover 18:36:08 and will be able to prepare 18:36:10 for ex. 18:36:33 if you really dislike such idea 18:36:41 write about it :) 18:37:37 any thoughts? 18:38:09 i'm ambivalent 18:38:38 same here 18:38:39 sounds reasonable, the only thing needed is a list of topics with assignments, don't think that we need some kind of ball passing 18:38:50 I'm ambi-normal 18:38:54 Seems like it's worth a shot. Maybe it will help someone with something. If not, we can always change back. 18:39:28 well, I still do not see the much difference, but we can try, maybe I didn't get your idea 18:39:30 alazarev, sure, w/o ball passing, just updates 18:39:56 aignatov, I'd like to ensure that we have an aggregated weekly updates 18:40:16 personally I think that it's awesome to have a weekly updates in meeting logs 18:40:43 any thoughts on topics that should be covered? 18:40:46 as I understand the difference, there will be update on CI even if there are no much changes in CI 18:40:59 SergeyLukjanov: is my understanding right? 18:41:02 alazarev: exactly 18:41:08 it would be good to get update on 'active' blueprints 18:41:21 alazarev, I'd like to see some stats for CI for example 18:41:28 from CI guys 18:41:34 ErikB, nice idea 18:41:42 ErikB, agreed 18:41:44 ErikB: good point 18:41:54 dependency updates. I stumbled (painfully) across the new need for mysql and postgres installs on my dev obx 18:41:56 box 18:42:13 so, we just need to document list of topics somewhere 18:42:26 not much changes to existing structure 18:42:31 i painfully stumbled on use_namespaces requiring savanna-api be run as root, oof 18:42:50 that wasn't that painful… ;) 18:43:19 I'll try to list topics to the next meeting 18:43:21 maybe not for you! 18:43:28 let's move on to the open discussion 18:43:32 (btw, any luck corralling neutron experts) 18:43:37 #topic General discussion 18:43:39 some 18:43:56 general topic from last week - everyone wants the cli to support IDs and NAMEs 18:44:01 I would hope there's a way to configure the nature of the namespace creation 18:44:11 everyone also wants the savanna api (rest) to support them so the client can be thin 18:44:19 mattf, btw, how is your cli work? do you have estimates to name it beta cli? 18:44:29 i did some digging and it looks like we may be unique in having that functionality in our rest api 18:44:48 trail blazers! 18:44:52 mattf, all projects support it on the client side 18:44:53 sooooo... how strongly do people want the client to be thin? 18:45:05 SergeyLukjanov, yeah, where were you last week to tell us that!? 18:45:09 because mostly all other project have no constraint on resource name 18:45:20 * mattf has since learned this 18:45:23 I was on the PTL's webinar :) 18:45:40 excuses excuses 18:46:14 so, unless someone who hasn't been hitting the hwx bar pressures me really hard, the name support is going to be client side - at least for the first pass i write 18:46:30 at least for the v1.1 api 18:46:56 yeah, i dunno what magical support will be unlocked with the new v2 impl that may use an entirely different framework 18:47:27 mattf, I'd like to not harry with v2 api and include all nice features to it 18:47:38 that all of us dreaming about ;) 18:47:57 that's nice, we can have a dv2 (dream v2) too 18:48:04 like /v2/beer/one-more-please 18:48:13 in the meantime, i'll be busy on v2 18:48:36 mattf, are you planning to complete your 'run_tests.sh'? 18:48:44 sounds like no objections to name search on the client side, thank! 18:48:59 mattf, not from my side 18:49:05 SergeyLukjanov, i'll take a look again this week, but it was still busted for savanna 18:49:24 mattf: name search on client side looks fine 18:49:33 as for v1 and v1.1 - i'm a little disturbed that we store swift creds and pass them around 18:49:50 i'm curious about how we happen to call them credentials in one call and extra in another though 18:49:54 we need to add the corresponding properties to the filter 18:50:02 to not return back them from the rest api 18:50:19 tmckay: I had a quick look at the savanna channel and observed that you plan to start working on the streaming api for edp 18:50:40 data-sources uses credentials, job-binaries uses extra 18:51:19 if no one speaks up, i'll probably propose them both as "credentials" for v2 18:51:25 aignatov, yes 18:51:28 +1 18:51:38 * mattf might even if folks speak up 18:51:41 I have a question about that, but I have to run to the doctor 18:52:05 tmckay: ok, we can talk later about it 18:52:07 aignatov, essentially, should streaming map-reduce be a new job type, or extra options for current map-reduce job type? 18:52:28 it effects crobertsrh, we should consider ease of use in the UI 18:52:29 another oddity i found - clusters have a status property that provides you info about what you'd expect, cluster status 18:52:45 job-executions have an info property that has a status property that tells you about the job-execution 18:52:48 tmckay: as I remember streaming is the subset of common MapReduce, right? 18:52:55 mattf: +1 on minimizing extra 18:52:56 yes 18:53:00 anyone know why cluster.status and job-executino.info.status or know why they should be the same? 18:53:14 alazarev, thx 18:53:21 ErikB, thx 18:53:39 s/why they should/why they should not/ 18:53:41 tmckay: maybe in the UI side it should be as a separate job type but in the core EDP... 18:53:53 mattf, I'd like to have j_e.status 18:53:54 how simple to implement :) 18:54:08 aignatov, could be, I had that thought to. talk to you soon 18:54:09 we have 6 mins 18:54:18 * mattf can be done 18:54:43 tmckay: not today, ok? tomorrow, ping me 18:54:53 ack 18:55:06 mattf: does job-executino.info contain something other than status? 18:55:22 alazarev, afaik, no 18:55:45 'info': {'status': 'Pending'}, 18:56:04 mattf: may be something was supposed... 18:57:22 ok, keep an eye out. i'll probably propose it gets collapsed for v2 18:58:33 mattf, ok 18:59:02 looks like we're out of time 18:59:06 thank you all! 18:59:11 have a good night/day 18:59:16 #endmeeting