16:08:46 <mihgen> #startmeeting fuel
16:08:47 <openstack> Meeting started Thu May 29 16:08:46 2014 UTC and is due to finish in 60 minutes.  The chair is mihgen. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:08:48 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:08:50 <openstack> The meeting name has been set to 'fuel'
16:09:08 <mihgen> hi folks
16:09:19 <mihgen> I'll run it if we don't have vkozhulalov...
16:09:39 <mihgen> I'm not an expert in meet bots, trying first time now, looks like I don't have other choice)
16:09:48 <mihgen> unless someone wants to help me with it :)
16:09:56 <mihgen> #topic announcements
16:10:30 <mihgen> My congratulations on Fuel 5.0 release
16:10:50 <mihgen> I've pushed out tags, so you can make an ISO 5.0 easily referring to tags
16:11:45 <mihgen> Design week has started. The goal for 5.1 release is to finish items which left unfinished after 5.0
16:11:58 <mihgen> Those include patching of openstack as the most important one
16:12:01 <mattymo> mihgen, I found vkozhukalov
16:12:20 <mihgen> vkozhukalov: how can I pass meeting driving to you?
16:12:32 <mihgen> vkozhukalov: I'm not an expert with meeting bots
16:12:45 <openstack> vkozhukalov: Error: Can't start another meeting, one is in progress.  Use #endmeeting first.
16:13:43 <vkozhukalov> mihgen: I am also not an expert
16:13:53 <mihgen> another import thing to finish, at least to make it available via CLI, is ability to deploy single env with multiple L2 networks
16:14:32 <mihgen> for large envs it is really network requirement. We started an effort as several bug fixes
16:14:53 <mihgen> I believe there is rmoe patch somewhere which has to be finished
16:15:28 <mihgen> Starting from 5.0, we are supporting upgrades. So for every change we do now, we have to care about compatibility and upgradability
16:16:00 <mihgen> 5.1 will be out as both ISO and package which can be applied to 5.0 to make it 5.1
16:16:35 <mihgen> For the design, we have created fuel-specs repo
16:16:50 <mihgen> so please let's move all the design docs we've started somewhere else to fuel-specs
16:17:08 <vkozhukalov> mihgen: there is first spec review request
16:17:22 <mihgen> It becomes the only acceptable format for official design tracking, and we are following best practices of other openstack projects in this
16:17:28 <mihgen> vkozhukalov: great, please share a link
16:17:39 <vkozhukalov> #link http://docs-draft.openstack.org/75/95575/17/check/gate-fuel-specs-docs/3499e53/doc/build/html/specs/5.1/image-based-os-provisioning.html
16:18:03 <vkozhukalov> #link https://review.openstack.org/#/c/95575/
16:18:08 <mihgen> Folks, another important thing are bugs. We've been very busy making 5.0, and left many bugs in master unsolved.
16:18:26 <mihgen> I'd like to attract your attention. We really need to squash many Criticals and High bugs there
16:18:37 <vkozhukalov> infra automatically puts spec in docs draft so as to make convenient to read
16:18:42 <mihgen> vkozhukalov: cool, thanks, that's great
16:18:58 <mihgen> vkozhukalov: do you know if after merging we will get it somewhere published too?
16:19:38 <mihgen> Any questions for 5.1 / overall before we proceed with agenda? https://etherpad.openstack.org/p/fuel-weekly-meeting-agenda
16:20:22 <mihgen> please put '?' if you trying to break me and ask anything
16:20:34 <mihgen> looks like no questions at the moment, so let's move on
16:20:45 <vkozhukalov> mihgen: i dont know exactly but it looks like after merging infra will publish spec into docs (not docs draft)
16:20:54 <mihgen> #topic design status and 5.1 targeted blueprints for fuel-library sub-project
16:21:01 <mihgen> aglarendil: your turn :)
16:21:27 <aglarendil> hi all
16:21:36 <aglarendil> #link https://etherpad.openstack.org/p/fuel-library-5.1-design-session
16:21:45 <mihgen> vkozhukalov: that would be awesome!
16:21:59 <aglarendil> here you can find all the fuel library related blueprints
16:22:16 <aglarendil> that we are going to implement in 5.1 release
16:22:25 <aglarendil> many of them are only partialy related
16:22:44 <aglarendil> some of them, e.g. hyper-v support can be postponed if
16:22:51 <aglarendil> we do not have sufficient
16:23:10 <aglarendil> resource
16:23:26 <aglarendil> feel free to add any blueprints to this list
16:23:38 <aglarendil> if you think we missed something
16:23:52 <salmon_> https://blueprints.launchpad.net/fuel/+spec/fuel-deploy-on-softlayer this one can be removed
16:24:06 <aglarendil> does anyone have any questions or suggestions ?
16:24:06 <mihgen> That's huge amount of things. Overall strategy is to address the following areas in a first order:
16:24:12 <aglarendil> salmon_: thank you, I'll do it
16:24:35 <mihgen> 1) patching & upgrades of openstack
16:24:50 <mihgen> 2) overall stability, reliability and HA
16:24:50 <aglarendil> mihgen: some of these things are almost ready
16:25:03 <aglarendil> mihgen: we need to complete some additional steps
16:25:07 <mihgen> 3) scalability and certification for large amount of nodes
16:25:14 <aglarendil> mihgen: HA and resilience are our first priority
16:25:20 <mihgen> aglarendil: that's cool
16:25:31 <aglarendil> mihgen: xenolog is working on rabbitmq pacemaker script that will
16:25:36 <aglarendil> mihgen: make it unbreakable
16:25:46 <mihgen> another important thing 4) community activities, such as puppet-openstack sync
16:25:57 <aglarendil> mihgen: holser is working on galera script along with zynzel
16:26:02 <mihgen> cool
16:26:22 <aglarendil> mihgen: we had some really cool meetings on Juno summit
16:26:28 <aglarendil> mihgen: and we are heading towards merging all the upstream puppet manifests
16:26:36 <aglarendil> mihgen: into our master
16:26:48 <aglarendil> mihgen: thus it will be easy for us to attach FUEL CI to puppet-openstack stackforge
16:26:54 <aglarendil> mihgen: repos
16:27:05 <salmon_> for scalability I would like propose https://blueprints.launchpad.net/fuel/+spec/fuel-1k and invite everyone to discussion
16:27:06 <aglarendil> mihgen: guys from puppet-openstack are really yearning for this
16:27:07 <mihgen> I"m looking forward to see Fuel CI working against puppet-openstack
16:27:37 <aglarendil> salmon_: yep, but this is more naligun and Ironic part
16:27:38 <mihgen> salmon_: cool. I'm not sure though that we want to track it as one bp
16:27:52 <mihgen> we may want to make it for every component which we have
16:28:11 <aglarendil> salmon_: we've already moved to puppet-masterless installation thus deployment is similart for 1k nodes
16:28:28 <mihgen> but it can be a virtual blueprint though, with many things which it depends on
16:28:47 <salmon_> mihgen: yeah, exactly
16:29:01 <mihgen> aglarendil: not provisioning though, and not sure if MC is Ok with it too.
16:29:36 <mihgen> aglarendil: ok, how is the design phase going on?
16:29:39 <aglarendil> mihgen: yep, but it is stateless and is easily scalable
16:29:54 <aglarendil> mihgen: we are still organizing some things
16:30:11 <aglarendil> mihgen: also I would like to mention that design period is ending on next Friday
16:30:19 <aglarendil> so everyone is welcome to participate
16:30:22 <mattymo> distributed base OS deployment is a bit of a limit. too much concurrency will reduce effectiveness
16:30:47 <aglarendil> aforemnetioned document will be the base for our discussion
16:30:57 <mattymo> it would be really awesome if we could see some replicated ironic agents to get closer to a 1-to-100 ratio for concurrent deployment
16:31:03 <mihgen> for every design doc it is mandatory to have QA expert to approve it before it can be merged, I expect nurla to paying attention to it
16:31:05 <aglarendil> mattymo: AFAIK this is what going to be addressed in Ironic
16:31:20 <mattymo> it is, but we need to decide how it will fit inside Fuel's architecture
16:31:21 <aglarendil> vkozhukalov: can you comment on this ?
16:31:44 <mihgen> there is a topic for that in agenda
16:31:54 <mihgen> should I change a topic now then?
16:32:03 <mihgen> or aglarendil you want to continue?
16:32:10 <mihgen> and we will get back to vkozhukalov a bit later
16:32:18 <vkozhukalov> aglarendil: will tell about it a bit later
16:32:43 <aglarendil> I am done
16:32:58 <mihgen> aglarendil: thanks!
16:33:04 <mihgen> #topic Openstack Patching status
16:33:15 <akasatkin> Hi all
16:33:22 <mihgen> akasatkin: long waited feature :)
16:33:29 <akasatkin> Status: Nailgun: tests to be added, under review, testing on VM is in progress. UI: need testing on VM, under review. Library: merged. Scripts for preparing patch on master node: not ready (must be reworked after upgrade stuff is merged).
16:33:45 <akasatkin> A kind of problem: no actual patch example. I just copy existing puppets and repos to imitate patching process. Do we have a technology to assemble patch?
16:34:20 <mihgen> aglarendil: we really need dilyin to organize this stuff, or someone else
16:34:40 <aglarendil> we'll work on it
16:34:44 <mihgen> do we have a list of possible patches definitions in design docs somewhere?
16:34:56 <mihgen> akasatkin: did you try to run it all through, I mean all integrated?
16:35:07 <aglarendil> akasatkin: contact dilyin - he will help you
16:35:09 <mihgen> does it work anyhow?
16:35:40 <akasatkin> Not yet. I run nailgun for now.
16:35:46 <mihgen> akasatkin: do I understand right, that you've not tried to use package of newer version or something like it?
16:36:02 <mihgen> akasatkin: ok, let's push hard to run it integrated
16:36:07 <akasatkin> It seems to be ok. I'll add UI tomorrow.
16:36:17 <mihgen> sooner we do, the sooner we can discover issues
16:36:31 <mihgen> I'm more worried about nailgun - fuel lib integration
16:36:41 <mihgen> than about UI - nailgun, which seems to me pretty simple
16:37:06 <akasatkin> It should be
16:37:21 <mihgen> akasatkin: vkramskikh I have another question on all our network refactorings which we were designing about 2 months ago
16:37:39 <mihgen> where are we with this, will we have any resources to make it at least partly done in 5.1?
16:37:42 <vkramskikh> we are going to discuss all the stuff tomorrow
16:37:57 <akasatkin> we have a meeting tomorrow
16:37:59 <vkramskikh> it seems there are some contradictions
16:38:04 <akasatkin> on networking in 5.1
16:38:07 <mihgen> I think this largely intersects with pluggable architecture, which we want to deliver in pretty good shape in 6.0
16:38:14 <vkramskikh> so we are going to clarify all the stuff
16:38:47 <mihgen> vkramskikh: cool. Please take a look at this from pluggability perspective and make sure AndreyDanin participates...
16:39:00 <akasatkin> yep
16:39:02 <angdraug> vkramskikh: can you provide an agenda for the meeting tomorrow?
16:39:17 <mihgen> I suspect some plugins will want to build networks programmatically, and now we have just hardcoded amount ..
16:39:21 <akasatkin> I'll provide it little later
16:39:32 <akasatkin> angdraug
16:39:39 <mihgen> ok thanks akasatkin
16:39:43 <mihgen> anything else?
16:39:48 <mihgen> can I move on?
16:39:54 <akasatkin> that's it
16:40:00 <mihgen> thanks
16:40:01 <mihgen> #topic Declarative wizard status
16:40:06 <vkramskikh> hello
16:40:25 <vkramskikh> i just want to announce that long-awaited feature was merged 1 hour ago
16:40:28 <vkramskikh> https://review.openstack.org/#/c/71478/
16:40:45 <vkozhukalov> #link https://review.openstack.org/#/c/71478/
16:40:47 <mihgen> vkramskikh: 59 patch sets) are you kidding?)))
16:40:52 <vkramskikh> we made our wizard declarative, it is now configurable by modifying the config
16:40:59 <vkramskikh> yet, that was not easy
16:41:10 <mihgen> vkramskikh: that's amazing
16:41:20 <vkramskikh> https://review.openstack.org/#/c/71478/59/nailgun/static/js/wizard.json that's how the config looks like
16:41:20 <mihgen> vkramskikh: how about documentation for it?
16:41:36 <mihgen> and pluggability support?
16:41:44 <vkramskikh> it is really plugin-friendly and options can be added to the wizard without any JS code
16:42:01 <vkramskikh> we are going to document it, no documentation yet
16:42:07 <mihgen> cool, can I add a new plugin description in separate json though?
16:42:20 <vkozhukalov> looks frightening
16:42:44 <vkramskikh> yes, that how we going to do this. add a separate json file which needs to be merged with the main config
16:43:28 <mihgen> vkramskikh: excellent. One of the ideas is that plugin should be delivered as separate package, so modification of existing files is not a viable option
16:43:48 <vkramskikh> yes, this approach will be supported
16:44:08 <mihgen> great! really nice to see it.
16:44:32 <mihgen> vkramskikh: any more updates?
16:44:37 <vkramskikh> nope
16:44:48 <mihgen> vkramskikh: ok, good, thanks
16:44:58 <mihgen> #topic Image based provisioning
16:45:17 <vkozhukalov> the situation here is not very good
16:45:33 <vkozhukalov> ironic guys rejected partitioning at all
16:45:42 <mihgen> vkozhukalov: doesn't sound good
16:45:43 <vkozhukalov> it one of our major features
16:46:11 <vkozhukalov> besides, they try to be very limited in their scope
16:46:17 <mihgen> I strongly believe that flexible partitioning schemas is very important, especially for small private clouds
16:46:22 <vkozhukalov> in order to integrate with nova
16:46:22 <xarses> do we just own partitioning ourselves then?
16:46:36 <mihgen> be limited in scope may be not that bad idea though =)
16:46:56 <vkozhukalov> our suggestion for now is to address our partitioning issues
16:47:00 <mihgen> vkozhukalov: so we still need ironic and partitioning to fix our problems with cobbler
16:47:03 <vkozhukalov> without use of ironic
16:47:18 <vkozhukalov> there is a spec review request
16:47:19 <mihgen> vkozhukalov: ok, do we still need ironic itself?
16:47:20 <mattymo> I proposed to vkozhukalov that we ship with a small root and read metadata to extend to the rest of the disk according to a scheme
16:47:48 <vkozhukalov> #link https://review.openstack.org/#/c/95575
16:47:51 <mihgen> mattymo: that may work too, details are important though
16:47:52 <mattymo> it's not as beautiful as a really well thought out solution
16:48:12 <mattymo> I can go into better detail because this was a solution for encrypted laptops in a previous life
16:48:32 <vkozhukalov> my suggestion is to postpone ironic integration for a while
16:48:50 <vkozhukalov> and implement at last image based provisioning
16:49:01 <mattymo> vkozhukalov, what will transport the images?
16:49:05 <xarses> vkozhukalov: I think we would need to work around the issue, deploying at larger scale, images are important
16:49:09 <vkozhukalov> then once it work will think of ironic
16:49:30 <vkozhukalov> mattymo: we will just download them via http
16:49:45 <vkozhukalov> mattymo: it is scalable enough
16:49:54 <mihgen> vkozhukalov: details are needed, really. Please start conversation in mailing list - I would like to see all of us engaged into the discussion.
16:50:12 <angdraug> what about bittorrent? that remained an abandoned experiment?
16:50:13 <mihgen> or we can read https://review.openstack.org/#/c/95575/17/specs/5.1/image-based-os-provisioning.rst and provide comments there
16:50:24 <vkozhukalov> mattymo: if we really need something like torrent we can implement that also
16:50:25 <mihgen> depends on what's gonna be easier
16:51:00 <mihgen> torrent would be awesome to have I believe, that's the kind of innovation I always wanted, frankly
16:51:14 <vkozhukalov> mihgen: is review request not an appropriate place to have a discussion?
16:51:17 <mihgen> especially if it's that easy and solves scalability as far as I see
16:51:24 <mihgen> vkozhukalov: it is appropriate
16:51:32 <mihgen> depends on topics of discussion
16:51:52 <mihgen> I think review request is rather for details
16:52:04 <mihgen> and overall ideas rather needs to be discussed in ML
16:52:16 <vkozhukalov> mihgen: ok
16:52:25 <mihgen> it's just about conveniency to me, so I don't push for anything here.
16:52:41 <mihgen> ok, thanks vkozhukalov .
16:52:47 <mihgen> should we move on?
16:52:57 <vkozhukalov> mihgen: it is not a problem at all to implement torrent as well, it is rather a problem to contribute all that stuff
16:53:23 <mihgen> ok, I see, we would need to run this through your review or ML then
16:53:40 <mihgen> #topic Open Discussions
16:53:52 <mihgen> Folks, feel free to ask questions
16:54:17 <salmon_> I would like to talk about https://review.openstack.org/#/c/96429/
16:54:38 <mihgen> I'd like to express one more thing about planning for releases - to be successful in 6.0 with pluggable architecture, we really need to start now
16:54:44 <salmon_> some fuel folks suggesting that using basic http auth will be ok. For me it's not enough. First of all, it looks ugly. Secondly we still have to implement handlers for password change. And if in the future we will need something more advanced we will have to rewrite it from scratch.
16:54:54 <mihgen> same applies to upgrade of openstack
16:55:16 <vkramskikh> do we want to protect nailgun API or just the UI?
16:55:37 <mihgen> Ideally both..
16:56:09 <salmon_> all proposed sollutions protects ui and api
16:56:28 <mihgen> salmon_: if you feel that you can dedicate all your time to make it properly in 5.1, then it's cool to have implemented in ideal way
16:56:39 <xarses> We have to protect both, since we can deploy os to hardware, this is an attact vector
16:57:17 <mihgen> Folks actually can we start with simple prototype may be? to lower the risk of missing a 5.1 date?
16:57:20 <xarses> right now some one could just hit cobbler api and replace images and create many infected nodes
16:57:30 <salmon_> mihgen: I have enough resources to do it
16:57:31 <mihgen> that's true about cobbler
16:58:00 <mihgen> salmon_: I'm all for it then, however let's put clearly phases into design doc
16:58:05 <mihgen> when we can ask for what part
16:58:18 <mihgen> so we could identify earlier if we are becoming late
16:58:26 <mihgen> to have some backup plan
16:58:50 <salmon_> mihgen: ok, so can we forst agree on min requirments?
16:58:54 <salmon_> *fitsy
16:58:57 <salmon_> *first
16:59:02 <mihgen> what do you think, can we split a work onto few pieces?
16:59:10 <salmon_> sure we can
16:59:12 <mihgen> salmon_: yep, I think so.
16:59:15 <xarses> api must be protected, too because you could just download passwords from fuel
16:59:31 <mihgen> salmon_: please engage other to help you with review
16:59:35 <mihgen> folks 1 min left
16:59:45 <mihgen> any more questions?
16:59:53 <xarses> Two things from me. 1)We need to stop having meetings and posting results with out sending meeting invites out (especially on ML)
17:00:00 <salmon_> mihgen: I'm trying but not to many people are commenting
17:00:09 <xarses> 2) I propose we consider Testing MOS/Fuel on OpenStack https://gist.github.com/xarses/9d9cae6acea7d9f22509
17:00:38 <mihgen> thanks xarses, will consider this. We can also move to #fuel-dev if there is anything left.
17:00:52 <mihgen> I'm closing the meeting, thanks everyone, and my congrats again on 5.0 !
17:00:59 <mihgen> #endmeeting