18:04:52 <SergeyLukjanov> #startmeeting savanna
18:04:53 <openstack> Meeting started Thu Nov 21 18:04:52 2013 UTC and is due to finish in 60 minutes.  The chair is SergeyLukjanov. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:04:54 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:04:57 <openstack> The meeting name has been set to 'savanna'
18:05:00 <SergeyLukjanov> #topic Agenda
18:05:11 <SergeyLukjanov> #link https://wiki.openstack.org/wiki/Meetings/SavannaAgenda#Agenda_for_November.2C_21
18:05:19 <SergeyLukjanov> #topic Action items from the last meeting
18:05:29 <SergeyLukjanov> #info there are no action items from the prev. meeting
18:05:37 <SergeyLukjanov> #topic News / updates
18:06:28 <SergeyLukjanov> folks, please
18:06:50 <SergeyLukjanov> #info our next release will be icehouse-1 (Dec, 5)
18:06:54 <mattf> looks like the bug day went well, and rather fast. i had a couple morning calls and you guys were 95% done by 11ET!
18:07:37 <mattf> https://wiki.openstack.org/wiki/Icehouse_Release_Schedule
18:07:38 <SergeyLukjanov> #info we have an awesome bug day and almost all issues are now in actual state
18:07:50 <aignatov> this week I started to check dmitryme patch about preliminary heat integration and stucked in heat installation on my laptop
18:08:57 <aignatov> it seems heat was installed successfully but patch seem to be not working properly :)
18:09:03 <SergeyLukjanov> btw at the last project meeting we decided that I'll release (tag) i1 and the ttx will take over and start doing it by icehouse-2
18:09:21 <SergeyLukjanov> and then*
18:09:53 <jmaron> does dmitryme patch make provisioning pluggable?  It's be nice to be able to accommodate any other provisioning techs we come across..
18:09:56 <SergeyLukjanov> so, we'll be a part of centralized release, not integrate yet :)
18:10:14 <SergeyLukjanov> jmaron, not yet
18:10:22 <jmaron> :(
18:10:31 <aignatov> no, right now, his patch just replace main logic of provisioning
18:10:33 <SergeyLukjanov> it was done to check possibility of Heat integration
18:10:38 <SergeyLukjanov> it's a PoC
18:10:43 <jmaron> gotcha
18:11:09 <aignatov> and it works on his Laptop ;)
18:11:15 <SergeyLukjanov> we'll make a pluggable mechanism to transparently merge and polish Heat support
18:11:17 <jmaron> :)
18:11:19 <jspeidel> ship it ;)
18:11:23 <SergeyLukjanov> and then make it defailt
18:11:54 <jmaron> de-fail?  ;)
18:12:11 <aignatov> yeah, I like this approach, Sergey
18:12:35 <jmaron> +1
18:13:02 <jmaron> we should probably maintain the current nova based scheme as another plugin
18:13:35 <ruhe> is there something which heat is missing, but current provisioning mechanism already provides? for instance anti-affinity
18:13:53 <jmaron> some of the /etc/hosts manipulation, I believe
18:14:09 <SergeyLukjanov> jmaron, I think it'll live at least before Heat-based provisioning will be completed
18:14:10 <jmaron> is missing
18:14:16 <SergeyLukjanov> jmaron, yep
18:14:25 <SergeyLukjanov> but we'll start from resources orchestration
18:14:50 <SergeyLukjanov> and I hope that we'll land some kind of agents till the end of I
18:15:17 <SergeyLukjanov> and so we'll avoid all the ssh/http from controller to vms
18:15:36 <nadya_> will anybody start working on contribution to heat?
18:15:40 <aignatov> jmaron, as i remember and understood it correctly, heat guys told us that Neutron somehow can apply ip addresses before provisioning, so etc host manipulation could be done during cloud init script running
18:15:52 <SergeyLukjanov> aignatov, could you please make an update about our CI lab
18:16:12 <aignatov> CI Lab is broken :(
18:16:23 <aignatov> so it will set -1 always from now
18:16:56 <jmaron> any sense how long to fix?
18:16:57 <jspeidel> is this a temporary issue that is being resolved?
18:17:01 <SergeyLukjanov> aignatov, yep, AFAIK it's possible to acquire IP addresses from Neutron and then generate Heat template
18:17:03 <aignatov> it happened during moving ci from grizzly to havana
18:17:03 <alazarev> aignatov: will this work for floating IPs?
18:17:41 <aignatov> jspeidel: this temporary, our deployers do the best to make it work again
18:18:20 <aignatov> alazarev: don't know, need to dig it
18:18:46 <SergeyLukjanov> ok, let's move on
18:18:50 <nadya_> i think ips assignment is the idea for the one more PoC
18:18:50 <ruhe> alazarev, we don't need floating ip for /etc/hosts
18:18:51 <jmaron> neutron client allows querying for floating IP pools, I believe, so it seems possible
18:19:18 <jmaron> ruhe:  oh yeah…true
18:19:23 <SergeyLukjanov> only internal IPs needed to generate etc hosts
18:19:32 <SergeyLukjanov> #topic Icehouse-1 plans
18:19:53 <SergeyLukjanov> i1 will be in two weeks
18:20:06 <SergeyLukjanov> so, looks like it's too late to plan something big on it
18:20:22 <alazarev> ruhe: oh, true
18:20:31 <aignatov> jspeidel: we will retrigger ci jobs for all failed tests in each patch
18:20:38 <SergeyLukjanov> are there any thoughts about critical issues or bps that should be landed in i1?
18:20:47 <jspeidel> aignatov: thanks for the update
18:21:24 <jspeidel> for hdp, we are working on
18:21:24 <jspeidel> https://blueprints.launchpad.net/savanna/+spec/hdp-specify-local-repo
18:21:24 <jspeidel> and https://blueprints.launchpad.net/savanna/+spec/hdp-hdp2-support
18:21:31 <aignatov> SergeyLukjanov: may be we just need to fix all high priority bugs in i1. what do you think?
18:21:38 <aignatov> or at least all
18:22:16 <SergeyLukjanov> jspeidel, I prefer to not land huge patches more one week before the milestone
18:22:19 <mattf> fyi, next week is a standard vacation week in the US
18:22:44 <aignatov> at least -> almost
18:22:48 <ruhe> is it turkey week?
18:22:57 <SergeyLukjanov> US folks, how'll be on vacation next week? :)
18:22:59 <jspeidel> SergeyLukjanov: agreed that this work will not be complete for i1
18:23:04 <ErikB> ruhe, yes
18:23:22 <jmaron> turkey/dreidel week, actually
18:23:48 <mattf> ruhe, it is
18:23:55 <SergeyLukjanov> jspeidel, I'm talking only about icehouse-1 now, don't worry about rest 4.5 months :)
18:24:33 <SergeyLukjanov> aignatov, it'll be great if we'll close high prio bugs
18:25:10 <SergeyLukjanov> in fact only one is https://bugs.launchpad.net/savanna/+bug/1243638
18:25:25 <SergeyLukjanov> https://bugs.launchpad.net/savanna/+bug/1240511 is randomly reproducable
18:25:40 <SergeyLukjanov> and https://bugs.launchpad.net/savanna/+bug/1249063
18:25:47 <SergeyLukjanov> I'll take it
18:26:06 <SergeyLukjanov> https://bugs.launchpad.net/savanna/+bug/1252684 I'm not sure that it's doable atm
18:26:18 <aignatov> https://bugs.launchpad.net/savanna/+bug/1240511 is wired, yeah
18:26:40 <SergeyLukjanov> any thoughts?
18:27:28 <SergeyLukjanov> ok, let's move on
18:27:35 <SergeyLukjanov> #topic Versioning and issues/bps management
18:28:04 <SergeyLukjanov> I've talked today with ttx about savanna subprojects versioning and releasing
18:28:17 <SergeyLukjanov> there are two mandatory changes needed
18:28:39 <SergeyLukjanov> #info use a separate project and versions for the client
18:29:05 <aignatov> jfyi, ttx is release manager of openstack
18:29:14 <SergeyLukjanov> and release -extra separately too because it's not really connected to the main project
18:29:25 <SergeyLukjanov> and should moved to the Hadoop community
18:29:46 <SergeyLukjanov> ttx == Thierry Carrez
18:30:14 <aignatov> what you mean should moved to hadoop community?
18:30:43 <nadya_> they dont want to have java code
18:30:44 <SergeyLukjanov> OpenStack community is not the best place for Hadoop FS and java code :)
18:31:14 <SergeyLukjanov> and due to the fact that it was partially landed to the Hadoop, we should push it to the Hadoop eco I think
18:31:17 <mattf> -extra is currently swift plugin for hadoop and edp example
18:31:22 <SergeyLukjanov> yep
18:31:25 <mattf> +1 to that
18:31:43 <mattf> stevel has posted backports of the swift plugin to both the hadoop 1.x and 2.x branches
18:32:03 <SergeyLukjanov> as for the edp example - it's strongly wired with main code and could be moved to the savanna repo
18:32:24 <alazarev> mattf: it is in 2.x only for now
18:32:24 <ruhe> there is a problem with this plugin being a part of hadoop code
18:32:25 <mattf> i'm mildly concerned about the edp test jar files
18:32:36 <mattf> i was thinking about proposing they get moved to -extra
18:32:50 <ruhe> it'll be difficult to update it with changes in OpenStack api
18:32:58 <alazarev> mattf: do you have info about 1.x?
18:33:01 <SergeyLukjanov> all tests will be moved to the tempest eventually
18:33:05 <nadya_> i think i should find sources of jars
18:33:09 <SergeyLukjanov> all integration tests*
18:33:12 <nadya_> and publish
18:33:14 <mattf> alazarev, yeah, i can share the email w/ you after the meeting
18:33:29 <nadya_> anybody hear me?
18:33:30 <mattf> nadya_, +1 at a minimum
18:33:39 <nadya_> great :)
18:33:44 <SergeyLukjanov> nadya_, it'll be great to publish sources
18:33:46 <alazarev> mattf: thank you, please do it
18:34:13 <aignatov> udf.jar is piggybank, all rest code is self-written
18:34:22 <aignatov> that's all examples
18:34:36 <SergeyLukjanov> so, for now, I think to keep -extra as is and release it with main savanna code
18:34:49 <SergeyLukjanov> to keep examples near to the project
18:34:50 <alazarev> mattf: because I'm doing back port to 1.x right now, it would be great if everything is already done
18:35:03 <mattf> alazarev, i would imagine!
18:35:22 <rnirmal> backport the swift plugin to 1.x ?
18:35:30 <mattf> yes
18:35:32 <alazarev> yes
18:35:44 <rnirmal> yeah it works with 1.x .. one or two minor tweaks
18:35:45 <SergeyLukjanov> we'll have separated launchpad projects for both client and dashboard plugin
18:35:59 <alazarev> the next step is to push data locality patch to both 1.x and 2.x
18:36:01 <mattf> SergeyLukjanov, btw, call me a purist, but committing a jar to git is wrong
18:36:16 <ruhe> mattf, that's wrong indeed
18:36:17 <aignatov> agree with mattf
18:36:20 <jmaron> purist
18:36:22 <alazarev> swift data locality
18:36:24 <jspeidel> mattf: +1
18:36:25 <SergeyLukjanov> mattf, I'm absolutely agree, that's just temp solution
18:36:38 <mattf> git never forgets
18:36:42 <aignatov> we just need to describe instructions where to find needed jar file
18:36:53 <nadya_> what jar do you mean?
18:36:53 <alazarev> mattf: +1
18:37:00 <ruhe> can't we upload it to the same place where qcow2 images are hosted?
18:37:01 <aignatov> udf.jar in current examples is here https://cwiki.apache.org/confluence/display/PIG/PiggyBank
18:37:02 <SergeyLukjanov> nadya_, any jar
18:37:08 <nadya_> udf.jar ?
18:37:10 <SergeyLukjanov> nadya_, any binary file
18:37:10 <jmaron> yes
18:37:31 <nadya_> sergey, I mean our case
18:37:41 <mattf> nadya_, specifically these jars = https://review.openstack.org/#/c/56235/
18:37:54 <SergeyLukjanov> yep
18:38:10 <SergeyLukjanov> we have 2 more subprojects - dashboard and elements and here we have several options
18:38:28 <nadya_> we move swift plugins to Hadoop, udf i will publish. i thought we have no more jars
18:38:28 <aignatov> edp-lib.jar is udf.jar or piggybank, edp-job.jar is renamed oozie-examples
18:38:36 <jmaron> alazarev:  data locality patch?
18:38:40 <aignatov> we don;tneed to keep it in any repo
18:39:29 <SergeyLukjanov> let's return back to the releasing/versions
18:39:29 <nadya_> ah, libs...i see
18:39:38 <alazarev> jmaron: https://review.openstack.org/#/c/47824/
18:40:16 <SergeyLukjanov> we'll release client much faster than savanna and so we can release dashboard too
18:40:35 <SergeyLukjanov> the question is - should we adjust our dashboard releases with savanna or not
18:40:35 * mattf considers getting off his client soapbox
18:40:51 <SergeyLukjanov> the same with elements
18:40:53 <mattf> adjust with savanna?
18:41:00 <nadya_> anyway, looks like we may add lib to maven dependencies w.g. I think we may find a way to avoid jars
18:41:05 <SergeyLukjanov> I mean main code
18:41:12 <ruhe> SergeyLukjanov, definitely should
18:41:18 <mattf> adjust = align?
18:41:32 <SergeyLukjanov> yep
18:41:51 <alazarev> SergeyLukjanov: we should somehow sync APIs they use/provide
18:41:57 <ruhe> SergeyLukjanov, otherwise it'll make a hell to those who bundle savanna into distro packages
18:42:34 <SergeyLukjanov> ruhe, sounds reasonable
18:42:39 <jspeidel> agreed, they should be aligned
18:42:45 <mattf> we have a handful of deliverables: savanna, dashboard, elements, client, extra. we're versioning and releasing them all together. what's the desired end state?
18:43:18 <aignatov> so, in such case, if savanna is in active development and savannaclient is not because it already has need functional, savannaclient amy become i2 from i1 without any patch, right?
18:43:20 <SergeyLukjanov> mattf, we'll have separated versioning for client starting from today
18:43:37 <mattf> sounds like extra -> /dev/null, client -> independent entity, savanna -> independent entity, dashboard -> horizon
18:43:57 <SergeyLukjanov> yep, we'll do it after graduating from the incubation
18:44:06 <alazarev> mattf: in this case after API change in any component it could be used only in next release
18:44:11 <SergeyLukjanov> (I mean horizon)
18:44:38 <mattf> alazarev, i'm not as firmly on my soapbox so long as the releases cycles are separated
18:44:41 <SergeyLukjanov> client should keep backward compatibility and support prev. APIs versions
18:45:07 <jmaron> is extra going away?  I got impression some EDP code would remain
18:45:17 <mattf> alazarev, if we release client in i1 and have to wait 6 weeks to fix dashboard in i2, ugh
18:45:49 <SergeyLukjanov> client will be released separately anyway, it's not a question to discuss
18:46:15 <mattf> SergeyLukjanov, yeah, well done identifying the problem and defusing the argument
18:46:15 <SergeyLukjanov> the question is only about -dashboard and -image-elements
18:46:40 <mattf> what if we start pushing our elements up to dib?
18:46:40 <ruhe> i demand client releases on the same date with the main code. there might be additional releases for sure
18:46:42 <nadya_> mattf, lol
18:47:15 <mattf> ruhe, is SergeyLukjanov close enough to throw something at you?
18:47:24 <ruhe> no :)
18:47:28 <mattf> darn
18:48:11 <SergeyLukjanov> ruhe, it's not a common approach in OpenStack
18:48:14 <mattf> ruhe, you're proposing a stronger alignment. not only is client released whenever we feel like it but it is also _always_ released w/ savanna main?
18:48:34 <SergeyLukjanov> clients have new releases after some important fixes or after some period of time
18:48:39 <mattf> to that i'd say sure, as long as i'm not doing the extra, potentially unnecessary, work to do that release
18:48:40 <SergeyLukjanov> minor releases
18:48:49 <SergeyLukjanov> and major for new release cycles and API versions
18:49:22 <ruhe> mattf, otherwise how can we align all the dependencies when packaging savanna, dashboard and client into disto packages
18:49:39 <mattf> i think we accept that version numbers no longer match
18:49:43 <SergeyLukjanov> ruhe, I don't think that it's a problem
18:49:58 <mattf> imho version numbers should not be aligned to identify compatibility. that's what deps are for.
18:50:07 <SergeyLukjanov> ruhe, the same story with all other OpenStack projects
18:50:16 <jmaron> mattf:  +1
18:50:59 <ruhe> SergeyLukjanov, i only want all the dependencies to be aligned. otherwise newer version of pythonclient might be api-compatible for denendency-incompatible
18:51:15 <ruhe> *but denendency-incompatible
18:51:24 <SergeyLukjanov> btw, the next releases will be 2014.1.b1 for savanna, 0.4 for python-savannaclient and if we decided to keep rest subprojects aligned with main savanna releases than they'll be 2013.1.b1 too
18:52:05 <mattf> how about the idea of elements -> dib ?
18:52:20 <SergeyLukjanov> mattf, only after incubation
18:52:40 <mattf> why's that?
18:52:59 <SergeyLukjanov> it's an integrated project
18:53:08 <jmaron> dib, that is?
18:53:17 <ruhe> https://github.com/openstack/diskimage-builder
18:53:33 <SergeyLukjanov> ttx suggests to move them to the savanna repo for the I release (like trove guys done) and then move them to dib or tripleo
18:54:10 <SergeyLukjanov> but it looks like that we should keep them separately and just release them with main code
18:54:21 <aignatov> mattf, who wanted to move elements to savanna repo originally? ;)
18:54:48 <SergeyLukjanov> aignatov, not me, I have concerns about gating them and just using
18:54:53 <SergeyLukjanov> the same story with -extra repo
18:55:56 <SergeyLukjanov> so, I think the main question is still about -dashboard
18:56:17 <SergeyLukjanov> is it better to be possible to push more versions for it?
18:56:44 <jmaron> how fluid do we think it's going to be, feature wise?
18:56:47 <alazarev> dashboard should indicate with which savanna version it works
18:57:06 <alazarev> is any way to do that without having releases synced?
18:57:18 <SergeyLukjanov> dashboard only depends on client :)
18:57:25 <SergeyLukjanov> that's released separately
18:57:35 <SergeyLukjanov> that's my concern
18:58:17 <SergeyLukjanov> [savanna, -image-elements, -extra] [client] [dashboard]
18:58:30 <SergeyLukjanov> ^^ my current opinion
18:59:06 <SergeyLukjanov> and then we move dashboard to horizon and we'll have only two separately releasing groups
18:59:31 <SergeyLukjanov> looks like we're out of time, let's move to the #savanna and continue discussion
18:59:33 <nadya_> i dont understand what variants we have except the above
18:59:38 <SergeyLukjanov> it'll be better to complete it tpday
18:59:44 <alazarev> and how dashboard and savanna linked in this case? By docs?
19:00:06 <SergeyLukjanov> thank you all guys
19:00:09 <SergeyLukjanov> #endmeeting