16:00:16 <kozhukalov> #startmeeting Fuel
16:00:17 <openstack> Meeting started Thu Feb 19 16:00:16 2015 UTC and is due to finish in 60 minutes.  The chair is kozhukalov. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:18 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:21 <openstack> The meeting name has been set to 'fuel'
16:00:25 <kozhukalov> #chair kozhukalov
16:00:27 <sambork> hi
16:00:29 <openstack> Current chairs: kozhukalov
16:00:33 <kozhukalov> agenda as usual
16:00:35 <agordeev> hi
16:00:42 <kozhukalov> #link https://etherpad.openstack.org/p/fuel-weekly-meeting-agenda
16:01:13 <kozhukalov> looks like we have just a couple of topics to discuss
16:01:23 <kozhukalov> #topic Dims needs Project Ideas, Mentors for GSoC 2015
16:01:38 <mihgen> hi folks
16:02:02 <kozhukalov> who was that guys who added this topic to agenda?
16:02:14 <mihgen> frankly I don't know who put this topic, but we should have someone who was going to operations meetup
16:03:13 <kozhukalov> operations meetup? what is it?
16:03:41 <mihgen> well community is getting people who are interested and working on operations story for openstack
16:04:10 <mihgen> I'll need to dig it in my gmail,but anyway - it's pretty important for us to participate there if possible
16:04:23 <mihgen> the thing is that Fuel has to support operations anyway
16:04:34 <mihgen> and the more is done in openstack itself, the easier life is in Fuel
16:05:09 <mihgen> with some real experience, we clearly need to share it - and get knowledge what has to be done in fuel
16:05:19 <IvanKliuk> hi
16:05:37 <mihgen> I don't see xarses here, he would certainly share some more details
16:05:51 <mihgen> I know someone was going there from US office.
16:06:02 <mihgen> so if we don't have people to discuss this topic further, let's move on
16:06:09 <meow-nofer__> hi everyone
16:06:22 <kozhukalov> maybe aedo?
16:07:32 <kozhukalov> ok, if no one has additional details
16:07:46 <kozhukalov> we definitely can not cover this topic
16:08:16 <kozhukalov> let's skip it and dig a little bit deeper after meeting
16:08:21 <kozhukalov> moving on
16:08:43 <kozhukalov> ohh, great, xarses
16:09:06 <kozhukalov> could you please share some details about openstack operations meetup?
16:09:29 <kozhukalov> as far as we know someone from US office was going to participate
16:10:06 <xarses> that is news to me, but I would not be supprised if someone went
16:10:24 <xarses> its in Philadelphia, PA
16:10:54 <kozhukalov> ok, if there are no details, let's move on
16:11:10 <xarses> sorry, thats about all I have
16:11:24 <kozhukalov> #topic IBP (agordeev)
16:11:27 <agordeev> hi
16:11:40 <agordeev> IBP status.
16:11:41 <agordeev> The implementation of http reconnection for fuel-agent was started
16:11:43 <agordeev> link https://blueprints.launchpad.net/fuel/+spec/ibp-reconnect
16:11:45 <agordeev> ETA 1d
16:11:47 <agordeev> Regarding the rest 2 BPs, i think there's enough time to get them implemented before FF.
16:11:49 <agordeev> Bugs: few high priority fixes are still on a review
16:11:51 <agordeev> link https://review.openstack.org/155703
16:11:53 <agordeev> link https://review.openstack.org/155782
16:11:55 <agordeev> link https://review.openstack.org/156185
16:11:57 <agordeev> Meanwhile, backporting 'device busy' fix to classic provisining is still in progress and couldn't be property estimated.
16:11:59 <agordeev> A lot of customer-found bugs were fixed for last two weeks
16:12:28 <dpyzhov> agordeev: let’s pause backport of ‘device busy’ fix
16:12:44 <dpyzhov> who is working on it?
16:13:03 <agordeev> dpyzhov: kozhukalov was working on it for the last time
16:13:10 <kozhukalov> dpyzhov: nobody
16:13:37 <dpyzhov> ok, great, it’s on hold =)
16:13:40 <ikalnitsky> agordeev: could you please first implement blueprint ibp-build-ubuntu-images and then others?
16:13:42 <kozhukalov> i'm doing preparation for 'way to clouds' confrerence
16:14:33 <agordeev> ikalnitsky: ok, i'll finish reconnect for today, then will start build-ubuntu-images.
16:15:05 <kozhukalov> ok, any other q about this topic?
16:15:12 <ikalnitsky> agordeev: sounds cool. thank you. i just want to make sure that we did manage it asap. you know, your blueprint is required for mine
16:15:14 <agordeev> ikalnitsky: i've tried the script. And it's not working, it needs additional time to investigate
16:15:59 <kozhukalov> ok, moving on
16:15:59 <ikalnitsky> agordeev: ok, no problem. i just want you to make right priorities. :)
16:16:05 <kozhukalov> consume-external-ubuntu (ikalnitsky)
16:16:13 <kozhukalov> #topic consume-external-ubuntu (ikalnitsky)
16:16:25 <ikalnitsky> ok, guys!
16:16:25 <ikalnitsky> we had a hot discussion this week and previous one about feature design.
16:16:25 <ikalnitsky> it looks like we agreed on implementation details, so please see the spec if you're interested in
16:16:26 <ikalnitsky> #link https://review.openstack.org/#/c/154973/
16:16:26 <ikalnitsky> the first patch (nailgun part) for this blueprint on review, though it requires rebasing and some fixes
16:16:26 <ikalnitsky> #link https://review.openstack.org/#/c/156147/
16:16:26 <ikalnitsky> ui team has start their working today as well as devops team.
16:16:27 <ikalnitsky> from qa side, it looks like they don't require a lot of work - just few changes in system tests.
16:16:27 <ikalnitsky> next steps - fix nailgun patchset, prepare patch to astute
16:16:27 <ikalnitsky> that's all for now
16:16:38 <ikalnitsky> questions? :)
16:16:59 <xarses> thanks for paste =)
16:17:29 <dpyzhov> ikalnitsky: great
16:18:13 <kozhukalov> are UI guys going to be in time for FF with this custom handler for repos?
16:18:37 <ikalnitsky> kozhukalov: i think so.
16:18:42 <ikalnitsky> vkramskikh: are you around?
16:18:48 <vkramskikh> yep, there should be no difficulties
16:19:05 <mihgen> ikalnitsky: I'm worried about CI infra being ready for the change
16:19:05 <kozhukalov> great
16:19:15 <mihgen> for all tests we run, Fuel CI, system tests, etc.
16:19:18 <xarses> how are we dealing with the package fetching?
16:19:20 <mihgen> did you talk to QA guys?
16:19:36 <ikalnitsky> mihgen: yes, i did.
16:19:50 <mihgen> Also, I don't know about squid/other type of proxy for packages, who is working on that one?
16:20:04 <xarses> ikalnitsky: how are we dealing with the package fetching?
16:20:05 <ikalnitsky> from qa side - there should not be difficulties. all job should be performed by devops. i mean, prepare mirrors and so on.
16:20:14 <mihgen> I agree with xarses that it's risky, we had issues before
16:20:23 <xarses> a LOT of issues before
16:20:28 <ikalnitsky> mihgen: squid/proxy is a part of holser spec. i think we need ask him.
16:20:29 <mihgen> teran: who is working on jobs? mirrors, etc. ?
16:20:52 <mihgen> we need to ensure it starts to run next week, I don't think it's viable to wait before FF
16:21:16 <ikalnitsky> mihgen: Mateusz Matuszkowiak and Pawel Brzozowski are assigned to mu blueprint
16:21:39 <xarses> We also need a better mirror system than squid
16:21:40 <ikalnitsky> mihgen: agreed. i ask them to start it asap and don't wait ff.
16:21:51 <mihgen> ok. ikalnitsky, you as a feature lead, please ensure that it's being addressed by devops guys in time
16:22:04 <ikalnitsky> they learn the spec and i've gave them answers
16:22:24 <mihgen> thank you. I know from past experience, these things don't go fast. We should be doing infra in advance. Following TDD where possible ;)
16:22:39 <mihgen> holser: ping
16:23:02 <mihgen> following up on xarses question about squid, if holser is here, I'd like to hear some answers on this
16:23:04 <ikalnitsky> mihgen: i order to get fully working feature, others blueprint have to be complete.. and they have to be complete in time too
16:23:17 <mihgen> ikalnitsky: what dependant bps do you have?
16:23:26 <xarses> ikalnitsky: please ensure that we can easily modify the repos with out download/upload custom yaml so we could code internal mirrors if needed
16:23:31 <ikalnitsky> i mean such blueprints like trusty support, ibp images, separate linux packages from mos
16:24:04 <mihgen> ikalnitsky: well I don't know, but I think your code should be independent from ubuntu version
16:24:20 <xarses> i would hope it is
16:24:20 <ikalnitsky> my code is independent, yes.
16:24:37 <xarses> cool
16:24:38 <mihgen> Also I'd like to learn more about ibp here - you should not depend on this one too, I think
16:25:11 <mihgen> I'd like to have a meeting about split repos tomorrow with osci / vparakhin, I'll send you an invite
16:25:21 <ikalnitsky> mihgen: currently, ibp images are building when we're building our iso. now, there should be a script to build them on master node.
16:25:53 <mihgen> correct. but your code should be independent here as well I think, is not it?
16:26:10 <ikalnitsky> yep, from my side, the code is independent
16:26:29 <mihgen> the other way perhaps - ibp code would be dependent on yours
16:26:55 <mihgen> ok let's talk about split repos tomorrow and about deps between all this interrelated ubuntu stories
16:27:01 <ikalnitsky> ok
16:27:05 <mihgen> I've sent you an invite
16:27:11 <mihgen> ikalnitsky: thx for update
16:27:15 <mihgen> let's move on
16:27:39 <kozhukalov> there are no more topics to discuss
16:27:49 <kozhukalov> #topic open discussion
16:28:32 <kozhukalov> does anybody have something?
16:28:46 <mihgen> any news about virtual routers?
16:28:50 <mihgen> + dns/ntp
16:29:10 <mihgen> #link https://blueprints.launchpad.net/fuel/+spec/virtual-router-for-env-nodes
16:29:18 <mihgen> #link https://blueprints.launchpad.net/fuel/+spec/external-dns-ntp-support
16:30:13 <mihgen> looks like no one is here for this to give an update :(
16:30:34 <kozhukalov> yep
16:30:37 <mihgen> what about building images on master node for IBP - did we cover this one?
16:30:53 <mihgen> (sorry I had to leave this room for 10min and could miss it )
16:30:53 <kozhukalov> agordeev: is going to work on that
16:31:11 <mihgen> just want to know how long would it take, what's the current status
16:31:18 <kozhukalov> but he did not start
16:31:32 <kozhukalov> it gonna take several days i think
16:31:33 <agordeev> mihgen: current status. It needs about 1w at least
16:31:39 <mihgen> I"m pretty worried as we need to think a lot about possible failures there
16:32:18 <mihgen> so it can fail on any step, and if, for instance, there is something mounted - and we can't build image anymore - that would worst thing ever
16:32:26 <mihgen> as user will stuck with building an image
16:32:56 <agordeev> mihgen: for now, it only fail on jenkins slave if there was an interruption.
16:32:58 <mihgen> (mounted - I know such issue from 'make iso')
16:33:15 <mihgen> would not it fail in the same way on fuel master node?
16:33:19 <kozhukalov> i think we need to deal with that on the task level (i mean task should have kind of timeout)
16:33:21 <seeg> I got some task on virtual routers but it seems to be related to https://blueprints.launchpad.net/fuel/+spec/refactor-l23-linux-bridges
16:34:10 <mihgen> seeg: hmm as I understand it's baseground for virtual routers, yes
16:34:45 <mihgen> kozhukalov: we need to think about cleanup thoroughly
16:34:50 <seeg> but i'm just gathering info about it still, it's news from today for me :)
16:34:50 <kozhukalov> mihgen: yes, here we need to be accurate (when mounting/umounting loop devices)
16:35:03 <mihgen> if task fails, we have to ensure that nothing left from previous run before we try again
16:35:25 <kozhukalov> mihgen: sure
16:35:27 <mihgen> Also, what about python code for it in nailgun
16:35:34 <mihgen> it's gonna be task running when?
16:36:01 <mihgen> who would trigger it, how UX is changed because of it? is it in design spec somewhere to take a look? who will implement nailgun's part/
16:36:03 <agordeev> mihgen: it's going to be an asynchronous task executed by astute in mcollective container
16:36:04 <kozhukalov> it gonna be task which is supposed to be run just before provision task
16:36:36 <xarses> kozhukalov: does it allways have to run?
16:36:37 <kozhukalov> mihgen: it is all up to ikalnitsky's patch
16:37:03 <kozhukalov> xarses: we decided to build images once per cluster
16:37:05 <mihgen> ikalnitsky: so you will be implementing it?
16:37:19 <mihgen> per cluster or release?
16:37:20 <ikalnitsky> mihgen: i'll implement sending the task. that's all
16:37:25 <xarses> kozhukalov: what If i want to rebuild it?
16:37:27 <ikalnitsky> mihgen: per cluster.
16:37:37 <ikalnitsky> mihgen: cluster may have different set of repos
16:38:04 <kozhukalov> xarses: and yes we'll run this task every time before provision, but this task is to be trivial if images is built already (i mean task will do nothing)
16:38:10 <mihgen> interesting. ikalnitsky - please share spec link, I want to learn more about it
16:38:34 <xarses> kozhukalov: but what If i want it to be rebuilt because the package delta is hight?
16:38:34 <ikalnitsky> mihgen: https://review.openstack.org/#/c/154973/
16:39:02 <kozhukalov> xarses: at the moment it gonna be impossible
16:39:10 <kozhukalov> xarses: but it is not a problem
16:39:26 <kozhukalov> xarses: because we deal with basic images not goldev
16:39:30 <kozhukalov> xarses: because we deal with basic images not golden
16:39:49 <mihgen> ikalnitsky: as I left comment before, let's have backdoor - user should be able to just rm -f image
16:39:59 <kozhukalov> and those images are to be possible to upgrade during deployment
16:40:01 <mihgen> and nailgun will see it's removed in order to rebuild it
16:40:07 <xarses> mihgen: +1
16:40:13 <ikalnitsky> mihgen: yes, it'll be rebuild
16:40:23 <ikalnitsky> our task will be something like microservice
16:40:41 <ikalnitsky> it will check whether image is exist or not
16:40:49 <ikalnitsky> if not - it will build
16:41:04 <mihgen> ok thanks guys
16:41:04 <kozhukalov> and how is it going to look like (rm image) from UI point of view?
16:41:27 <mihgen> kozhukalov: not from UI for now, let's be simple here
16:41:40 <mihgen> ssh to master, and do "rm -f"
16:41:53 <kozhukalov> ahh, yes, if user rm image it gonna be rebuilt
16:41:57 <mihgen> not sure if it's gonna be ever needed (and we should aim for it)
16:42:13 <mihgen> but just backdoor is always good
16:42:39 <mihgen> ok thx folks
16:42:40 <xarses> ikalnitsky: kozhukalov will this task be visible  / editable in the task graph like the fuel-library ones?
16:43:02 <mihgen> vkramskikh: around?
16:43:02 <kozhukalov> xarses: yes
16:43:16 <xarses> cool
16:43:27 <kozhukalov> xarses: it should be a separate task
16:43:31 <xarses> I like the new task graph engine
16:43:40 <xarses> it looks lovely guys
16:43:44 <xarses> <side node>
16:43:47 <xarses> <side note>
16:44:11 <kozhukalov> ok, if there are no other q, let's finish
16:44:23 <mihgen> well I had question to UI
16:45:00 <mihgen> is vkramskikh here? where are we with network verification before deployment
16:45:21 <seeg> yeah, well i'm implementing that too :)
16:45:31 <seeg> i have python code for that, the UI is done by MorAle
16:45:40 <seeg> i just have to fight some tests
16:45:46 <mihgen> seeg: oh cool!
16:45:57 <mihgen> did you plan to show demo of UX for it?
16:45:58 <xarses> Are we going to be able to do anything to make the results more readable?
16:46:00 <seeg> there are strange race conditions i presume, concerned with fake_tasks i think
16:46:12 <mihgen> I would love to take a quick look, fake UI is ok
16:46:22 <seeg> yeah, sure, we can make a demo
16:46:29 <mihgen> xarses: I don't think in this release :(((
16:46:41 <mihgen> but I certainly would enforce it for the next release
16:47:01 <xarses> =/ It's terribly hard to read at times, and I know what it's doing
16:47:19 <mihgen> xarses: btw dude we really need your reply in openstack-dev about openrc / how we gonna deal with service user, as we need it for stats collection as well
16:47:28 <xarses> yes
16:47:50 <mihgen> xarses: if it's easy to fix… let's just explain how, may be we can get someone to make a change…
16:48:01 <mihgen> I'm not sure if it's easy..
16:48:23 <xarses> mihgen: I will add it to my backlog to look over more
16:48:46 <mihgen> #link https://wiki.openstack.org/wiki/Fuel/6.1_Release_Schedule
16:48:57 <mihgen> to remind everyone ^^^  - 2 weeks before FF
16:49:08 <mihgen> let's merge code faster ;)
16:49:35 <mihgen> if we see we are not fitting schedule - let's raise it as earlier as possible, so we can decide what to do
16:50:25 <mihgen> also, as we know, core reviewers will be busy right before FF - so give patches for review as early as possible
16:51:02 <kozhukalov> ending?
16:51:20 <mihgen> I think so
16:51:25 <kozhukalov> thanx everyone for partisipation
16:51:31 <mihgen> thanks guys
16:51:38 <kozhukalov> #endmeeting