16:01:44 <kozhukalov> #startmeeting Fuel
16:01:45 <openstack> Meeting started Thu Feb 26 16:01:44 2015 UTC and is due to finish in 60 minutes.  The chair is kozhukalov. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:01:46 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:01:48 <openstack> The meeting name has been set to 'fuel'
16:01:56 <kozhukalov> #chair kozhukalov
16:01:57 <openstack> Current chairs: kozhukalov
16:02:02 <agordeev> hi
16:02:04 <kozhukalov> who is here?
16:02:04 <seeg> \o
16:02:05 <irinapov> hi
16:02:08 <vkramskikh> hi
16:02:36 <kozhukalov> great, at least 5 persons )
16:02:42 <irinapov> yup :)
16:02:55 <kozhukalov> ok, we have little to discuss today
16:02:59 <kozhukalov> let's start
16:03:09 <kozhukalov> #topic Fuel plugins SDK: wiki page and further steps (irinapov)
16:03:27 <irinapov> Please, be informed that I’ve created a wiki page for Fuel Plugins (https://wiki.openstack.org/wiki/Fuel/Plugins). We’ll use it for providing user and dev-side materials.
16:03:42 <irinapov> I’d like you to review the contents and make changes if necessary. On Monday, I’ll send an announcement to openstack-dev ML about the wiki page. As to Fuel Plug-in Guide: since we’re moving to SDK for Fuel Plugins, placed at Mirantis webpage (https://software.mirantis.com/fuel-plugins/) all issues related to plugins should become independent.
16:04:23 <irinapov> I’d also like to note that we have #fuel-plugins channel in Slack - feel free to enter and ask questions - always glad to answer
16:04:26 <kozhukalov> cool, looks like there are lots of info on this page
16:04:51 <irinapov> yup, it'll also have links to the webpage with tutorials and SDK-related topics
16:05:08 <irinapov> so, my request is to review the wiki :)
16:05:11 <kozhukalov> irinapov: slack is private
16:05:35 <kozhukalov> irinapov: are we going to create irc channel as well&
16:05:38 <kozhukalov> irinapov: are we going to create irc channel as well?
16:05:57 <irinapov> I believe, we'll use current IRC channels
16:06:00 <seeg> the wiki says about #fuel-dev -- maybe it's sufficient?
16:07:03 <bookwar> +1, let's start with #fuel-dev
16:07:11 <kozhukalov> irinapov: who do you think is the best person to review?
16:07:38 <irinapov> I believe, Evgeny Li could do this and, sure, the other folks involved into plugin development process
16:08:05 <kozhukalov> he is not around unfortunately
16:08:15 <irinapov> yup, but I can ping him :)
16:08:24 <kozhukalov> irinapov: please ping him personally
16:08:30 <irinapov> np
16:08:42 <kozhukalov> ok, great job
16:08:48 <kozhukalov> thanks
16:08:53 <irinapov> anyway, I'm waiting feedback from any of you! thx
16:08:55 <kozhukalov> any q?
16:09:13 <kozhukalov> if no, let's move on
16:09:31 <kozhukalov> #topic IBP (agordeev)
16:09:45 <agordeev> hi
16:09:52 <agordeev> The implementation of http reconnection for fuel-agent was finished. Waiting on review queue.
16:09:55 <agordeev> #link https://blueprints.launchpad.net/fuel/+spec/ibp-reconnect
16:09:56 <agordeev> #link https://review.openstack.org/#/c/157090/
16:09:59 <agordeev> The implementation of bp/ibp-build-ubuntu-images was started few days ago. ETA is 2d more.
16:10:01 <agordeev> #link https://blueprints.launchpad.net/fuel/+spec/ibp-build-ubuntu-images
16:10:03 <agordeev> The remained bp/ibp-image-checksums hasn't been started yet. ETA of implementation is 2d
16:10:04 <agordeev> #link https://blueprints.launchpad.net/fuel/+spec/ibp-image-checksums
16:10:06 <agordeev> There's a chance that the delivery of BP-s might be delayed and not be in time of FF.
16:10:08 <agordeev> Bugs: few bugs are still around. But there are not critical. Few fixes are still sitting on review.
16:10:10 <agordeev> Backporting 'device busy' fix to classic provisining is paused and its ETA couldn't be property estimated.
16:11:40 <angdraug> what's wrong with the device busy bug?
16:11:45 <kozhukalov> and another point is that we've changed repo_metadata format and deployment the whole flow
16:12:23 <kozhukalov> and we have pre-deployment astute task which gonna pre-configure repos on a slave node
16:12:25 <agordeev> angdraug: it's too hard to bring the changes to preseed/kickstart stuff. It takes a lot of time.
16:13:09 <kozhukalov> so it looks like we need to throw away that stuff in fuel-agent which is about configuring repos (with cloud-init)
16:13:50 <kozhukalov> angdraug: going to deliver this fix at an early date
16:14:01 <agordeev> angdraug: it looks like it might be working fine and fixed, but it doesn't work when you apply it. Debugging capabilities are very limited, especially for preseed
16:14:06 <kozhukalov> angdraug: i mean 'device busy'
16:15:06 <angdraug> thanks, I see
16:15:40 <angdraug> no fundamental problem, just the usual preseed madness...
16:15:41 <kozhukalov> agordeev: and another point is that it looks like we are not able to re-implement image building script in python by FF
16:15:51 <kozhukalov> angdraug: exactly
16:16:14 <kozhukalov> ok, if there is no other q, let's move on
16:16:51 <kozhukalov> #topic Pecan migration (seeg)
16:17:08 <seeg> well, as part of continuing work of meow-nofer and overall acceptance via the mailinglist discussion last 2 days I worked on migrating our API to pecan
16:17:30 <seeg> the biggest issue raised against pecan i think was that the reverse function that we use in tests would be difficult to write
16:17:37 <seeg> well, it turns out it's not that difficult :)
16:17:39 <seeg> https://review.openstack.org/#/c/158661/
16:17:54 <seeg> the Ci tells me that 716 tests pass already, with 130 failing
16:18:29 <seeg> I'm keeping backwards compatibility with our API
16:18:42 <salmon_> awsome :)
16:18:46 <seeg> overall it's not extremely difficult to do
16:18:54 <seeg> just fix tests one by one
16:19:12 <kozhukalov> seeg: great, go ahead
16:19:30 <salmon_> seeg: why did you change version number?
16:19:34 <salmon_> api version
16:19:34 <kozhukalov> seeg: looking forward to see it implemented
16:19:39 <seeg> it was like that, i'll bring it back
16:19:47 <salmon_> ah, ok
16:19:52 <seeg> it doesn't matter with reverse
16:20:00 <seeg> in fact currently neither v1 nor v2 is added to the urls
16:20:11 <seeg> it's very easy, just add one mor controller and name it v1
16:20:27 <seeg> and I'm open to suggestions on improving the api :)
16:20:51 <kozhukalov> seeg: looks like reviewing this patch will be really painful
16:20:56 <seeg> :)
16:21:05 <kozhukalov> i mean + over 3000 lines
16:21:16 <seeg> I thought about creating some wrapper class that would take current handlers and return pecan's controller class
16:21:20 <seeg> most code is just copy-paste anyways
16:21:48 <seeg> something like make_pecan_controller(NodeCollectionHandler)
16:22:01 <seeg> I think it might be done but haven't tried it, and probably there still will be corner cases
16:22:12 <seeg> but for simpler handlers this could be possible, which would reduce amount of code
16:22:41 <seeg> I'm basing on our tests, if all pass I assume API is healthy :)
16:22:49 <kozhukalov> anyway, it is great to see it is going on because webpy is really outdated these days
16:24:05 <kozhukalov> any other q?
16:24:19 <kozhukalov> moving on then
16:24:34 <kozhukalov> #topic Open discussion
16:25:23 <kozhukalov> does anybody have anything?
16:26:09 <xarses> I was hoping to get some updates about the possible package / mirror / caching solution
16:26:24 <xarses> I asked in the ML last week and still haven't had any updates
16:26:48 <barthalion> there is nothing to be said yet, actually
16:27:03 <barthalion> the best solution about caching would be distributed cache
16:27:13 <xarses> so we have no solution, and FF is next week?
16:27:47 <barthalion> but all p2p solutions for apt are either dead or CPU hungry
16:27:53 <xarses> what are we doing to ensure that the packages we need are at least available from the remote repos?
16:28:55 <kozhukalov> xarses: there is bp
16:29:02 <kozhukalov> #link https://blueprints.launchpad.net/fuel/+spec/consume-external-ubuntu
16:29:35 <kozhukalov> it is supposed that user will be able to set a bunch of repos via UI
16:29:48 <kozhukalov> this set of repos is per cluster
16:30:09 <kozhukalov> it is almost ready
16:30:16 <angdraug> that bp spec doesn't specify a script to mirror repos
16:30:38 <kozhukalov> angdraug: yep
16:30:38 <xarses> yes, but its noted as "OPTIONAL: Check that provided repos contain all required packages."
16:31:34 <kozhukalov> we make an assumption that at least of these repos is upstream ubuntu mirror
16:31:39 <xarses> we will have big quality risk if we dont have a) local mirror AND/OR b) check we have all packages
16:31:45 <kozhukalov> with installer image and udeb packages
16:31:49 <barthalion> as kozhukalov says
16:32:50 <barthalion> checking packages availability is overengineering
16:33:08 <barthalion> we want to consume external repo to keep things simple
16:33:19 <kozhukalov> xarses: i think it is more up to a customer
16:33:55 <xarses> barthalion: so you want to start the deployment, and not know if all of the packages can be found, only to find that they are missing when the deployment fails 2 hours later?
16:34:07 <kozhukalov> i mean let's think she understands that broken mirror will likely break deployment
16:34:11 <xarses> kozhukalov: yes, it should, both options should be avail to the customer
16:34:45 <barthalion> 2 hours earlier? it will fail just after ibp
16:35:03 <xarses> ibp packs all of the deps for Ceph?
16:35:09 <xarses> Openstack?
16:36:08 <xarses> my understanding it would be the bare OS like in anaconda or debian-installer
16:36:58 <kozhukalov> when you install ubuntu from upstream you usually get all necessary packages, but if you install from your own broken mirror, then something gonna go wrong, and you'll know about that after a while (it is common situation)
16:38:09 <kozhukalov> xarses: ibp does not install extra packages, just base OS
16:38:36 <kozhukalov> then puppet installs everything else
16:38:57 <xarses> kozhukalov: yes, it will break, and often. but we literally switched to providing everything on the fuel node specifically to avoid problems with fetching packages from remote repos. We must do somthing to ensure we dont regress here
16:39:23 <kozhukalov> we certainly don't have engineering resources to implement repos validation by 6.1
16:41:07 <kozhukalov> are there any other q?
16:41:10 <xarses> We need options then to help limit the impact. I think worse case we could move the make repo code from the iso into the master and allow the user to build and point to their own mirror
16:43:18 <maximov> why we cannot download packages through apt-proxy and failover to official repos in case of failure? sorry for newcomer question
16:43:30 <kozhukalov> as far as I know we are going to deliver kind of script which allows user to make its own mirror from upstream
16:43:59 <barthalion> maximov: we discussed similiar option using squid
16:44:09 <xarses> so next topic, When would we consider applying granular deployment patterns to the rest of the nailgun tasks (specificly provisioning)
16:44:15 <barthalion> maximov: it doesn't solve everything, but is surely way to go
16:44:45 <xarses> by the way, the granular deployments stuff is AWESOME, way to go guys!
16:46:07 <kozhukalov> xarses: can not answer
16:47:12 <xarses> it would be useful to compose custom tasks that could provsion (few)-> deploy(few) -> provsion (remaining) -> deploy (remaining)
16:47:58 <xarses> for cases like if you want to deploy a KVM host, and make VM's for the controllers from it
16:48:14 <kozhukalov> yes, that certainly would be great to use this pattern
16:48:24 <xarses> OK, food for thought
16:48:33 <xarses> thanks
16:48:58 <kozhukalov> thank you guys for attending
16:49:13 <kozhukalov> if there is no other q, then ending
16:49:31 <kozhukalov> #endmeeting