16:03:27 <kozhukalov> #startmeeting Fuel
16:03:28 <openstack> Meeting started Thu May 14 16:03:27 2015 UTC and is due to finish in 60 minutes.  The chair is kozhukalov. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:03:29 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:03:31 <openstack> The meeting name has been set to 'fuel'
16:03:37 <kozhukalov> #chair kozhukalov
16:03:37 <openstack> Current chairs: kozhukalov
16:03:38 <mihgen> hi
16:03:41 <angdraug> o/
16:03:42 <prmtl> hi
16:03:50 <kozhukalov> agenda is here https://etherpad.openstack.org/p/fuel-weekly-meeting-agenda
16:03:57 <kozhukalov> hey everyone
16:04:05 <kozhukalov> who else is here?
16:04:29 <kozhukalov> 4 people? is it enough?
16:04:59 <rmoe> hi
16:05:05 <mihgen> everyone is working on bugs..
16:05:16 <kozhukalov> mihgen: i hope so
16:05:16 <zigo> hi
16:05:22 <IvanKliuk> hi
16:05:31 <kozhukalov> ok, i've poked some other guys
16:05:38 <kozhukalov> let's start
16:05:44 <mwhahaha> hi
16:05:45 <ogelbukh> kozhukalov: _o/
16:05:59 <kozhukalov> #topic pkgs-version of fuel-library tests on Fuel CI
16:06:35 <kozhukalov> who was that guy who added this topic to agenda?
16:06:49 <barthalion> lol
16:06:53 <alex_didenko> hi
16:06:53 <kozhukalov> aglarendil: around?
16:06:59 <barthalion> aglarendil maybe?
16:08:09 <aglarendil> hi, folks
16:08:14 <salmon_> hi
16:08:14 <aglarendil> we switched CI to using packages
16:08:17 <aglarendil> for library
16:08:24 <aglarendil> all is fine
16:08:31 <aglarendil> except there is an issue with dependent commits
16:08:43 <aglarendil> if you have a chain of commits it will not be correctly checked out
16:08:50 <aglarendil> we are working on the solution right now
16:08:56 <zigo> aglarendil: Do you mean a "git review -r" thing?
16:08:57 <aglarendil> ETA - end of day
16:09:20 <aglarendil> zigo: when we prepare package source we do cherry-pick of the latest commit instead of checkout
16:09:21 <angdraug> zigo: you mean git review -d right?
16:09:34 <zigo> angdraug: no
16:09:35 <zigo> :)
16:09:41 <aglarendil> angdraug: we do not do git-review -d on our slaves
16:10:19 <aglarendil> so far the root cause is known - we will do our best to fix it
16:10:28 <aglarendil> until then, please be very careful with code review
16:10:55 <kozhukalov> aglarendil: do we pack all puppet modules into a single package? or every modules in a separate package?
16:11:54 <aglarendil> kozhukalov: the whole fuel library into one pacakge
16:11:57 <aglarendil> *package
16:12:17 <aglarendil> some binary files are put into separate packages for sake of easier update
16:13:06 <kozhukalov> ok, great, im wondering because otherwise we'd be  forced to test packages compatibility
16:13:44 <kozhukalov> ok, if there are no more q here, then moving on
16:14:00 <kozhukalov> aglarendil: thanks for the info
16:14:13 <kozhukalov> #topic results table on Fuel CI
16:14:18 <bookwar> hi
16:14:26 <bookwar> We've enabled the "pretty messages on Fuel CI", here is the example of the results https://review.openstack.org/#/c/182866/
16:14:32 <bookwar> But there are some comments..
16:14:55 <bookwar> If you send new patchset, results from the previous one are not cleaned from the results table. Thus it happens that table shows results but there is no actual vote from Fuel CI yet, because new set of tests is in progress.
16:15:26 <bookwar> So when you merge stuff, you should check that there is a _vote_ from Fuel CI. Just looking at the table with result is not enough
16:15:34 <kozhukalov> is this message from the patch is going to be pretty fdsjakfklasdjlfjasjdfkljasdlfkljasdkljflajlsdkf ? -)
16:16:14 <bookwar> kozhukalov: ?
16:16:24 <kozhukalov> im kidding
16:16:43 <kozhukalov> about the example patch
16:17:10 <bookwar> i need you to tink about this issue and tell me if it is ok or is it critical and we should revert the change
16:17:15 <bookwar> think*
16:17:39 <mihgen> bookwar: any way to resolve it?
16:17:43 <mihgen> to make UX better?
16:18:06 <mihgen> may be some quick test would create a table or smth
16:18:42 <bookwar> no easy way currently, i am investigating the issue, but there won't be fix available in this or next week
16:19:12 <zigo> bookwar: Could you add a breakout game when we click on the most top-right pixel ?
16:19:16 * zigo hides ...
16:19:42 <angdraug> moving on?
16:19:47 <kozhukalov> yes
16:19:52 <bookwar> ok, so, core reviewers, please take care of the Fuel CI vote, and ket's move on
16:20:12 <kozhukalov> bookwar: thanks
16:20:15 <kozhukalov> #topic networking discussions in Mountain View - short update (mihgen)
16:21:17 <kozhukalov> mihgen: typing?
16:21:44 <mihgen> sorry folks
16:21:57 <mihgen> yeah, we spent some time discussing networking roadmap for 7.0
16:22:20 <mihgen> major thing discussed was support of multi-rack deployments
16:22:58 <mihgen> I can't share many details in here, so we will be getting data in blueprints. Shortly speaking though, there are a few things of interest:
16:23:31 <mihgen> a) our users want not to have floating IPs to be assigned on compute hosts, as it's believed as security problem
16:24:11 <mihgen> or controllers. so that leads to the requirement of having separate set of nodes where floatings would be translated into private using NAT
16:24:42 <kozhukalov> kinda DMZ?
16:24:57 <mihgen> it's not like fully supported by neutron at the moment and further research is needed, especially if we want to have access in HA fashion
16:25:00 <xarses> dedicated l3-agent nodes like in 3.0
16:25:24 <salmon_> mihgen: are there any plans to move network configuration out of nailgun?
16:25:42 <mihgen> salmon_: depends on what exacactly to move
16:25:52 <kozhukalov> salmon_: to neutron for example, right?
16:26:01 <sc68cal> mihgen: when you were in mtn vw did you speak with Neutron SMEs like kevinbenton ?
16:26:09 <mihgen> there is plan that your plugin / role defined would be able to provide metadata what network roles required
16:26:15 <salmon_> kozhukalov: no :)
16:26:25 <mihgen> check out this document:
16:26:27 <mihgen> #link https://docs.google.com/document/d/1QVoexrDF_MS92IZd4jnwPWQDxTAWMzUUrcMyu8VjGF4
16:26:45 <mihgen> this is about flexibility we have to make anyway regardless of multi-rack support
16:27:22 <mihgen> nailgun should be able to reserve N VIP IP addresses, where N is defined by particular role
16:27:23 <salmon_> mihgen: well, all network related stuff. As I remember this futures were discussed before 4.0 but it was hard to refactor nailgun part.
16:27:26 <xarses> sc68cal: I've been talking with kevinbenton about these after we get some kind of direction from the group
16:27:47 <sc68cal> xarses: ok, I can also assist
16:28:10 <mihgen> salmon_: if we move _all_ network related stuff out of nailgun, how would you provide network settings on the UI then?
16:28:46 <mihgen> I believe we still want nailgun to be owner of networking information and help to provide network objects data for partucular roles
16:28:50 <salmon_> mihgen: for UI it doesn't matter to which service it's connecting
16:29:13 <mihgen> salmon_: do you want separate service?
16:29:22 <mihgen> like other python service?
16:29:46 <salmon_> mihgen: yup, which is focused only on network things.
16:30:04 <mihgen> to make it clear, the discussion we had was purely about architecture, and we didn't focus on partucular nailgun/puppet implementation
16:30:08 <kozhukalov> mihgen: probably we can move network stuff into a separate service and nailgun or even UI itself will interact with this service via API
16:30:15 <salmon_> mihgen: ok, I see
16:30:40 <mihgen> salmon_: might be good idea, I'd like to know some more details
16:30:48 <mihgen> so among other things discussed
16:31:15 <salmon_> mihgen: ok, I will send an email
16:31:18 <xarses> salmon_: I'd like to get a list of issues from you. I think after we rebuild nailgun parts for granular network function, and better multiple-cluster-networks support most of the issues with network manager will be resolved
16:31:26 <mihgen> how we would connect different L3 networks between racks, for underlay (mgmt net, other)
16:31:51 <mihgen> and the conclusion was that we better go ahead with ospf of bgp routing protocols to support it
16:32:20 <mihgen> vxlan between racks for underlay doesn't seem to be scalable solution
16:32:40 <mihgen> though for neutron tenants we believe that vxlan is the option
16:33:04 <mihgen> that's pretty much it for high level things
16:33:22 <kozhukalov> mihgen: thanks for this update
16:33:33 <kozhukalov> moving on
16:33:47 <kozhukalov> #topic ruby 2.1 retrospective results https://etherpad.openstack.org/p/fuel-6.1-ruby21-retrospective (angdraug)
16:34:01 <angdraug> we had a retrospective on the Ruby 2.1 problem earlier today:
16:34:03 <angdraug> #link https://bugs.launchpad.net/fuel/+bug/1403088
16:34:03 <openstack> Launchpad bug 1403088 in Fuel for OpenStack 6.1.x "CentOS repository contains ruby conflicts - unable to run yum update plainly" [Critical,Fix released] - Assigned to Artem Silenkov (asilenkov)
16:34:03 <angdraug> the prevention plan:
16:34:03 <angdraug> #link https://etherpad.openstack.org/p/fuel-6.1-ruby21-retrospective
16:34:03 <angdraug> key decisions:
16:34:03 <angdraug> starting in 7.0, we'll stop bypassing packaging pipeline for any reason
16:34:04 <angdraug> packages with the same name and different version (such as ruby 1.8 and 2.1) are not allowed
16:34:06 <angdraug> reference to commits from which package was built in its changelog will be mandatory:
16:34:08 <angdraug> #link https://github.com/stackforge/fuel-specs/blob/master/specs/6.1/separate-mos-from-linux.rst#debian-package-metadata
16:34:11 <angdraug> when a release (6.1) is finalized for GA,
16:34:13 <angdraug> all commits on that release branch in all packages that are not present on the branch for next release (7.0)
16:34:16 <angdraug> are automatically detected and reported
16:34:18 <angdraug> and then manually rebased onto new release branch (rebase form 6.1 onto 7.0)
16:34:20 <angdraug> this will trigger rebuild of all affected packages for new release
16:34:22 <angdraug> we still need to come up with a way to detect deprecated packages such as ruby-mysql
16:34:27 <angdraug> #link https://bugs.launchpad.net/mos/6.1.x/+bug/1415950
16:34:27 <openstack> Launchpad bug 6 in Launchpad itself ""next 10 entries" at bottom of page" [Medium,Invalid] - Assigned to Carlos Perelló Marín (carlos)
16:34:28 <angdraug> dixi
16:34:47 <angdraug> ideas on identifying deprecated (no longer required) packages are welcome :)
16:35:19 <angdraug> questions?
16:36:09 <xarses> does this not address any issues other than the deprecated?
16:36:22 <angdraug> it does
16:36:27 <xarses> so with ruby, we dont allow 1.8 and 2.1
16:36:42 <angdraug> actually, both trusty and centos7 have ruby2.0
16:36:42 <xarses> doe that mean we wont have ruby-1.8 and ruby21-0?
16:37:01 <angdraug> so in 7.0, ruby 2.0 is the only one we're going to have
16:37:52 <kozhukalov> angdraug: thanks
16:38:08 <kozhukalov> is there anything else here? any other q?
16:38:12 <kozhukalov> moving on?
16:38:15 <angdraug> yup
16:38:31 <kozhukalov> #topic fuel-createmirror vs fuel-package-updates
16:39:03 <kozhukalov> actually I added this topic
16:39:09 <angdraug> mattymo: can you sum up the current plan?
16:39:16 <kozhukalov> but I don't know much on this
16:39:23 <kozhukalov> mattymo: around?
16:39:39 <mattymo> I'm sorry, I actually need to leave the office this minute
16:39:41 <kozhukalov> or brain386?
16:39:41 <angdraug> #link https://etherpad.mirantis.net/p/Fuel_mirroring
16:39:57 <mattymo> Please let Vitaly P carry on
16:40:12 <kozhukalov> ok, mattymo we will
16:40:34 <kozhukalov> looks like Vitaly is not here
16:40:52 <angdraug> I pinged him privately, lets move on and try to get back to this later if we have time
16:40:58 <kozhukalov> ok moving on then
16:41:10 <kozhukalov> #topic OS for the Fuel master node in 7.0 (CentOS 7 vs Kilo Keystone et al & Python 2.7) (angdraug)
16:41:16 <angdraug> I added this one
16:41:38 <angdraug> we have a wrinkle in our Linux strategy for 7.0
16:41:54 <angdraug> we use Keystone and other openstack components on the master node
16:42:08 <angdraug> which means that in 7.0 & Kilo, we need Python 2.7 on the master node
16:42:29 <angdraug> which means that leaving CentOS 6.5 on Fuel master node isn't a viable option
16:42:34 <maximov> we can keep old version of keystone
16:42:40 <kozhukalov> are we going to move to Centos 7? or debian?
16:42:40 <maximov> on master node
16:43:07 <angdraug> this means that we'll have to support 3 distros instead of 2:
16:43:11 <rvyalov> angdraug: we use keystone in docker , we can change os in docker to the Ubuntu ?
16:43:12 <mihgen> I would not care about update of keystone on master unless it's totally necessary
16:43:14 <angdraug> 1) ubuntu + kilo
16:43:20 <salmon_> it's not
16:43:21 <barthalion> we can also use centos7 only for keystone container
16:43:22 <angdraug> 2) centos7 + kilo targeted for 7.1
16:43:28 <angdraug> 3) centos6 + juno for master node
16:43:45 <mihgen> don't take that far, angdraug
16:44:07 <mihgen> centos7 + kilo = you'd get keystone kilo on master at that moment
16:44:14 <mihgen> so you can eliminate #3
16:44:23 <salmon_> mihgen: we are building keystone from library manifests. If we update  manifests keystone will update automaticly
16:44:40 <xarses> barthalion: will the keystone client support python 2.6?
16:45:06 <mihgen> in general we have to figure out a way not to depend on chiken - egg problem
16:45:08 <xarses> because now we have both nailgun and fuelclient using the keystone client lib
16:45:18 <mihgen> and being able to always use whatever version of component we wnat
16:45:34 <salmon_> keystone-client supports: py26,py27,py33,py34
16:45:39 <angdraug> right now, mos team's kilo work is blocked until we have a solution
16:46:29 <angdraug> despite what you may think I am not biased to any particular solution, as long as we all agree on one
16:46:51 <barthalion> do we have packaging CI for centos7?
16:46:58 <angdraug> yes
16:47:33 <barthalion> so centos7-based container for keystone makes sense to me, but I'm probably too tired to see serious flaws of this
16:47:38 <mihgen> sounds like we need to identify right folks to discuss this issue, and follow up separately..
16:47:45 <angdraug> mihgen: +1
16:48:03 <mihgen> we need to indentify just an optimal solution here and duscuss overall strategy for similar cases in the future
16:48:17 <mihgen> whom would we need to discuss it?
16:48:45 <angdraug> Mikhail Semenov (MOS Linux) and Dmitry Mescheryakov (MOS)
16:48:48 <mihgen> mos-keystone team (lead), angdraug - you, anyone else?
16:48:56 <xarses> docker people
16:49:28 <mihgen> docker ppl is mattymo first of all here I think, for deployment part
16:49:48 <mihgen> take a note that mattymo is gonna be gone for the design summit next week
16:50:23 <kozhukalov> ok, look like we can move on
16:50:30 <angdraug> brain461 is here now
16:50:31 <mihgen> action item first
16:50:55 <mihgen> maximov: can you take it and organize meeting?
16:51:22 <kozhukalov> brain461: could you please give us some update about merging fuel-createmirror with  fuel-package-updates?
16:51:33 <angdraug> kozhukalov: topic?
16:51:53 <maximov> yes, I will
16:52:17 <kozhukalov> #action angdraug intiates discussion about Centos 7 + kilo on the master node
16:52:32 <brain461> I've added calls to fuel-package-updates script, but it looks like in case of creating a partial mirror script replaces repos in a wrong format
16:52:34 <kozhukalov> #topic fuel-createmirror vs fuel-package-updates
16:52:52 <kozhukalov> brain461> I've added calls to fuel-package-updates script, but it looks like in case of creating a partial mirror script replaces repos in a wrong format
16:53:01 <kozhukalov> just repeating
16:53:31 <brain461> also, in case of partial repo there should be only one repo used instead of base+updates+security - as it combines all of them
16:53:59 <brain461> but script cannot delete repos, just replaces their URIs
16:54:58 <brain461> this needs to be fixed, otherwise we cannot use it for partial repo case (which is the default)
16:55:37 <kozhukalov> brain461:  ok, thanks
16:56:04 <kozhukalov> #action maximov  intiates discussion about Centos 7 + kilo on the master node
16:56:10 <kozhukalov> moving on
16:56:23 <kozhukalov> #topic Dynamically creating rabbitmq exchanges, aka: https://bugs.launchpad.net/fuel/+bug/1445359
16:56:24 <openstack> Launchpad bug 1445359 in Fuel for OpenStack "Nailgun expects exchanges to be setup by puppet" [Medium,Confirmed] - Assigned to Fuel Python Team (fuel-python)
16:56:50 <zigo> Is there anyone working on this?
16:56:58 <zigo> That's a blocker for me ...
16:57:01 <angdraug> not right now I assume
16:57:04 <kozhukalov> looks like no one
16:57:09 <angdraug> everyone is fixing High & Critical bugs for 6.1
16:57:16 <mihgen> wait a sec
16:57:18 <angdraug> once 6.1 is out, we should get back to this
16:57:18 <zigo> Yeah, so I've been waiting for months ...
16:57:24 <zigo> Ok.
16:57:25 <mihgen> I remember this one
16:57:45 <mihgen> you'd find vsharshov to discuss it
16:57:54 <mihgen> we had very weird issue with exchanges before
16:58:16 <angdraug> weird == something we don't understand
16:58:28 <mihgen> which was that nailgun/astute would fail in attempt to create exchange as I remember as it claimed that it was created before with other settings
16:58:30 <angdraug> never a good excuse to not fix something )
16:58:45 <mihgen> it was not really clear who creates it
16:59:03 <mihgen> then there was attempt to create it first in puppet with same settings
16:59:07 <kozhukalov> 1 minutes
16:59:14 <mihgen> probably it's still there from that time
16:59:25 <mihgen> just find vsharshov to find out where we are with this
16:59:34 <angdraug> zigo: irc nick is warpc
16:59:51 <kozhukalov> time
17:00:11 <zigo> ok, will do
17:00:12 <zigo> thanks.
17:00:20 <kozhukalov> there is another topic Fix pfctl bug https://bugs.launchpad.net/fuel/+bug/1454691 (sc68cal)
17:00:20 <openstack> Launchpad bug 1454691 in Fuel for OpenStack "firewall script fails to run multiple times" [Critical,In progress] - Assigned to Serhiy Ovsianikov (sovsianikov)
17:00:31 <kozhukalov> let's discuss this in fuel-dev
17:00:31 * zigo is off now
17:00:40 <kozhukalov> thanks everyone for attending
17:00:48 <kozhukalov> #endmeeting