16:01:15 <kozhukalov> #startmeeting Fuel
16:01:15 <openstack> Meeting started Thu Jan 15 16:01:15 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:16 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:01:18 <openstack> The meeting name has been set to 'fuel'
16:01:22 <salmon_> hi
16:01:23 <evgeniyl__> hi
16:01:25 <kozhukalov> #chair kozhukalov
16:01:26 <akasatkin> hi
16:01:26 <openstack> Current chairs: kozhukalov
16:01:26 <mihgen> hi guys
16:01:26 <mkwiek> hi
16:01:26 <romcheg> o/
16:01:27 <prmtl> hey
16:01:28 <agordeev> hi
16:01:28 <ikalnits_> o/
16:01:31 <IvanKliuk> hi
16:01:34 <kozhukalov> hi everyone
16:01:45 <kozhukalov> today we have a lot of stuff to discuss
16:01:48 <kozhukalov> let's start
16:01:57 <seeg> hi
16:02:08 <kozhukalov> #topic fuel-client (new project) core rights to restructure (tzn)
16:02:22 <docaedo> hey
16:02:23 <tzn> Hi
16:02:29 <kozhukalov> agenda as usual
16:02:37 <kozhukalov> #link https://etherpad.openstack.org/p/fuel-weekly-meeting-agenda
16:02:44 <kozhukalov> tzn: hi
16:02:46 <tzn> So we’ve separated fuel-client from main fuel-web repo
16:03:22 <tzn> As a quick decision we’ve assigned romcheg and dpyzhov core rights
16:03:38 <romcheg> For technical reasons mostly
16:03:52 <tzn> As we now have separate group for this repo (as other OSt ptojects) we need to set initial list of cores there
16:03:58 <mihgen> tzn: so my opinion is that we have to follow openstack guidelines unless we really to tweak those
16:04:00 <kozhukalov> ok, i think all fuel-web core reviewers could help to review this stuff as well
16:04:15 <tzn> Those guidelines say nothing about starting projec
16:04:34 <mihgen> tzn: ok why don't we discuss it publicly then?
16:04:38 <tzn> After we set up initial list, we should stick to OSt rules
16:04:42 <mihgen> I think it's common openstack problem too
16:04:52 <tzn> I propose adding all python experts from fuel-web to that group
16:05:06 <tzn> We are just doing this :)
16:05:09 <mihgen> when like part of nova-compute is being splitted into separate repo, who becomes cores there?
16:05:20 <tzn> I have no idea
16:05:21 <mihgen> tzn: it's not mailing list
16:05:37 <mihgen> we need to discuss it in openstack-dev ML and see what other people think
16:05:44 <kozhukalov> tzn: +1 to adding all fuel-web core reviewers
16:05:48 <tzn> I don;t really want to spend to much time here, it;s very clear for me, that we need current fuel-web guys to be cores
16:06:00 <mihgen> tzn: to start - yes
16:06:09 <tzn> After that - we use elections, like OSt
16:06:10 <mihgen> but I think we should be removing guys from cores too
16:06:16 <tzn> Sure
16:06:16 <mihgen> if they stop contributing
16:06:19 <tzn> I’m all for that
16:06:25 <mihgen> contributing  / reviewing
16:06:25 <romcheg> So the only problem in adding all python guys we'll have to remove some of them later
16:06:34 <tzn> Exactly
16:06:39 <mihgen> romcheg: tzn Fine with me.
16:06:46 <tzn> OSt only counts reviews, not contributions
16:07:09 <tzn> Ok, do we need to state it clearly here who gets rights, or is it enough to send email to ost-dev?
16:07:26 <kozhukalov> what is to be done by 6.1 about fuel-client? any plans?
16:07:35 <tzn> I think I will just send email and we’ll do lazy consensus
16:07:42 <tzn> you have full spec
16:07:59 <mihgen> tzn: yep, pls send email
16:08:17 <romcheg> kozhukalov: There is a spec for refactoring planned to 6.1 https://blueprints.launchpad.net/fuel/+spec/re-thinking-fuel-client
16:08:22 <tzn> kozhukalov: full rewrite
16:08:30 <kozhukalov> romcheg: thanks
16:08:31 <tzn> ok, any other questions?
16:08:44 <kozhukalov> no q from my side
16:08:45 <romcheg> I have one
16:08:47 <tzn> romcheg: thax, you were quicker
16:09:35 <romcheg> So to let some guys land required patches to ISO we allowed to merge them to the old folder in fuel-web project
16:10:04 <romcheg> However after they've landed there I'd like to get that to python-fuelclient
16:10:26 <ikalnitsky_> romcheg afaik, they won't merged yet. any eta when we can build fuelclient from new repo?
16:10:51 <romcheg> ikalnitsky_: Mon-Tue
16:10:58 <tzn> we’d like it to be ready nearly next week, it’s a blocker now
16:11:22 <mihgen> why can't we propose it into old and new repo then for now?
16:11:23 <romcheg> tzn: Not a blocker but just a question of how to pull merged patches to new repo
16:12:08 <romcheg> mihgen: We could simply cherry-pick them and +A with the link to the original review
16:12:13 <mihgen> patch owner should propose it into old and new place then
16:12:27 <tzn> can romcheg take a look after we have ci/cd ready and move required stuff?
16:12:35 <mihgen> romcheg: cherry-pick unlikely to work if you have separate directories
16:13:05 <kozhukalov> why can't we just switch our ci to using forked client and if it works, then we'll propose changes to new repo only?
16:13:17 <romcheg> mihgen: Right it's a manual cherry pick
16:13:19 <tzn> you can move patchests from subdirectory
16:13:19 <tzn> we should only take care to create separate patches for /fuelclient
16:13:30 <tzn> And not combined with other folders
16:13:47 <tzn> +1
16:14:36 <mihgen> ok do we consider topic closed?
16:14:40 <romcheg> +1
16:14:42 <ikalnitsky_> +1
16:14:44 <tzn> yes, rest on ost-dev
16:14:44 <kozhukalov> ok, let's move this discussion to ML, because right now we have a lot of other stuff
16:14:47 <tzn> +1
16:14:51 <tzn> that’s right
16:15:08 <kozhukalov> #topic 200 nodes support (salmon_)
16:15:11 <salmon_> hi
16:15:12 <salmon_> Heere is the blueprint https://review.openstack.org/#/c/146900/
16:15:12 <salmon_> #link https://review.openstack.org/#/c/146900/
16:15:12 <salmon_> Please review. In summary, what will be done: for nailgun: more tests and improvements if needed. Deploy changes will go to background. For astute: provision in chunks, allowing to fail some nodes during provisioning. Speedup network verification.
16:15:12 <salmon_> Any questions? :)
16:16:09 <mihgen> I'd love to see a change in the UI workflow for net-verify, so when you click deploy without net-verify passed you should get a warning
16:16:16 <mihgen> but that's for vkramskikh I think to do
16:16:24 <salmon_> yup, good idea
16:16:36 <mihgen> salmon_: another thing is CI
16:16:46 <mihgen> there was a discussion for scale tests
16:16:46 <vkramskikh> i'll sent an email into openstack-dev about this soon
16:16:48 <mihgen> for nailgun
16:16:51 <mihgen> vkramskikh: thx
16:17:00 <salmon_> mihgen: testa are in CI, not useful yet
16:17:06 <salmon_> *tests
16:17:11 <mihgen> salmon_: why not yet?
16:17:14 <mihgen> not finished?
16:17:18 <salmon_> mihgen: results are hard to read
16:17:37 <mihgen> oh ok.. any plans to impove? introduce even gating may be?
16:17:58 <salmon_> mihgen: yeah, we want to add some charts
16:18:08 <mihgen> ok cool
16:18:09 <salmon_> to show how performance changes
16:18:29 <salmon_> not sure if in this relese, we don't have resource fot it :(
16:18:32 <mihgen> then we should check it periodically
16:18:36 <salmon_> yup
16:18:59 <mihgen> ok cool thanks
16:18:59 <tzn> gating is also good idea
16:19:04 <tzn> at least for dramatic changes
16:19:09 <tzn> one more thing here
16:19:13 <tzn> very important
16:19:24 <mihgen> tzn: we should consider threasholds yes, but may be not necessarily for 6.1
16:19:29 <tzn> we assume that image based provisioning is not going to make into 6.1
16:19:43 <mihgen> in ideal world I'd see whether email or even -1 in patch if it degrades
16:19:44 <tzn> all stuff is planned with this assumption
16:20:01 <mihgen> not at the point when it's already late (2 days before release.. )
16:20:05 <tzn> if we introduce it late, scope will change and we will not deliver
16:20:38 <tzn> because it will completele change were optimisations should be made
16:20:41 <tzn> so just to let you know
16:20:59 <tzn> and I’m not against IBP of course
16:21:13 <mihgen> introduce what, sorry?
16:21:20 <kozhukalov> tzn: actually we agreed that ibp will be one of the provisioning options apart from classic one
16:21:21 <mihgen> what assumption?
16:21:33 <tzn> „we assume that image based provisioning is not going to make into 6.1"
16:21:42 <tzn> at least as a default option
16:21:42 <mihgen> ibp == image-based provisioning for those who doesn't know
16:22:31 <mihgen> tzn: if we can't start working on it right away now
16:22:49 <mihgen> but if we can - why can't we certify it on 200 nodes?
16:22:57 <kozhukalov> tzn: you are right ibp is not to be a default option for 6.1, just an option
16:23:01 <tzn> salmon_:
16:23:11 <tzn> I think there is no time
16:23:15 <tzn> it will be double work
16:23:27 <tzn> we only really have 1 person working on it
16:23:36 <mihgen> just on option is also fine with me. Then we would just say in release notes that we didn't certify it for scale
16:23:46 <kozhukalov> tzn: and another person from fuel agent side
16:23:51 <salmon_> mihgen: testing on 200 nodes takes a lot of time, if it will be introduced at the end of release cycle we will not be able to test it and optimize if something is slow
16:24:10 <kozhukalov> agordeev: is to work on ibp during 6.1
16:24:11 <barthalion> hi, sorry for being late
16:24:15 <mihgen> salmon_: it can be introduced now, as far as I know from kozhukalov
16:24:35 <mihgen> so guys I think you'd need to sync between 200 nodes team & ibp team
16:25:07 <kozhukalov> mihgen: you are right, we will
16:25:11 <salmon_> yup
16:25:16 <kozhukalov> let's move on
16:25:30 <kozhukalov> any other q here?
16:25:33 <mihgen> tzn: did you see holser anywhere? I'd like to hear ubuntu14.04 status..
16:25:42 <mihgen> kozhukalov: not for this topic
16:25:47 <tzn> he had maintenance until 3 in the morning
16:26:00 <kozhukalov> #topic fuel-stats. current state, future feature plans (akislitsky)
16:26:02 <mihgen> thx salmon_ for information about scale
16:26:05 <tzn> besides, it’s not in the agenda, so sorry
16:26:06 <salmon_> np
16:26:11 <akislitsky> We have discussed structure of statistics CSV report with Ronen. Now we are moving implementation of the CSV exporter prototype into http handler for fetching CSV report from statistics web UI. It will be done this week. Also we have got part of requirements for OpenStack workload statistics from Ronen. At the beginning of next week we are going to get the rest requirements for OpenStack workload statistics from Nathan,
16:26:11 <akislitsky> when he will come to Moscow office. Workload statistics requires different storing strategy. We'll discuss architecture design and create spec on the workload statistics. We are planning to start implementation next week as soon as we will have requirements and draft of architecture design. Development will be split on short cycles. In the end of each cycle we will show results to the our feature consumer from the PM t
16:26:12 <akislitsky> eam.
16:27:20 <mihgen> akislitsky: thx for update
16:27:27 <dpyzhov> Looks like we have new requirements
16:27:36 <mihgen> akislitsky: I have a question about community version
16:27:41 <dpyzhov> And we can have more work for extra developer
16:27:47 <mihgen> that's more for devops perhaps
16:27:51 <mihgen> teran_: ^^^
16:27:54 <dpyzhov> will know better after meeting with Nathan
16:28:06 <mihgen> so if it's feairly simple to deploy, I'd love to see it finally implemented
16:28:34 <dpyzhov> I’m talking about openstack workloads statistics
16:28:36 <mihgen> stats.fuel-infra.org or what's that gonna be
16:28:50 <mihgen> dpyzhov: yeah let's wait for him
16:29:21 <teran_> mihgen: it's currently in progress, anyway we'll get all the data while it's not worken when it will get up
16:30:02 <nurla> what about improvements that we've planned at last year to perfomance?
16:30:14 <mihgen> teran_: any ETA?
16:30:28 <mihgen> nurla: performance of what?
16:30:30 <teran_> mihgen: 1-2 weeks
16:30:35 <mihgen> teran_: cool, thx
16:30:41 <nurla> collector of statistic
16:30:50 <mihgen> do we see any issues with it?
16:31:03 <mihgen> or predict that it's not gonna handle scale
16:31:18 <teran_> mihgen: it's pretty slow, but currently we need to recheck test results
16:31:24 <mihgen> I just don't wonna us to make it super perfect if it's good enough for our purposes
16:31:29 <nurla> yep, Tema provided results to Igor
16:31:39 <teran_> nurla: we will discuss how it's going with Artem
16:31:50 <nurla> okay, thank you
16:32:29 <kozhukalov> if there are no other q, let's move on then
16:32:43 <kozhukalov> thanks akislitsky
16:32:44 <mihgen> teran_: nurla guys let's get results
16:32:47 <mihgen> by next week
16:32:56 <mihgen> I hear about this for 2-3 months :(
16:32:57 <teran_> mihgen: ll
16:33:01 <teran_> mihgen: лл
16:33:05 <teran_> mihgen: kk
16:33:06 <mihgen> it sounds to me that we are infinitely working on int
16:33:14 <teran_> mihgen: the same stuff :(
16:33:30 <mihgen> thx, let's move on
16:33:34 <kozhukalov> #topic docker upgrade to 1.4.1 (ikalnitsky)
16:33:40 <ikalnitsky_> Ok, guys, I have managed to update docker (0.10 -> 1.4.1) on master node.
16:33:40 <ikalnitsky_> There are only two patches that we need:
16:33:40 <ikalnitsky_> https://review.openstack.org/#/c/121559/ is the fix to manifests
16:33:40 <ikalnitsky_> https://review.openstack.org/#/c/146885/ is the fix to fuel_upgrade
16:33:40 <ikalnitsky_> I built an ISO with new docker/patches and it successfully passed our BVT tests.
16:33:40 <ikalnitsky_> I also prepared an upgrade tarball with new docker/patches and the upgrade was done successfully too.
16:33:42 <ikalnitsky_> I think, we can ask QA to verify both ISO and an upgrade tarball.
16:33:42 <ikalnitsky_> There's one thing I want to notice - we can't build Docker package automatically, we should do it manually (and we did). The reason is that our OBS is flying over CentOS 6.4 when for building docker we require at least 6.5.
16:33:42 <ikalnitsky_> That's all.
16:34:32 <mihgen> ikalnitsky_: thx
16:34:39 <barthalion> can't we just upgrade obs to 6.5?
16:34:46 <mihgen> sounds like great progress
16:35:00 <mihgen> mattymo: did you have a chance to review docker work?
16:35:02 <ikalnitsky_> barthalion i think you should ask rvyalov or dburmistrov
16:35:22 <mihgen> barthalion: they want to get rid of it at all :)
16:35:25 <ikalnitsky_> barthalion afaik, upgrading obs to 6.5 will requires to rebuild all packages
16:35:38 <barthalion> obs must be really fishy piece of software
16:35:51 <mattymo> mihgen, I wrote a good portion of it myself, so yes. We've been in close contact
16:36:12 <mihgen> mattymo: ok great
16:36:39 <mihgen> rvyalov: docker thing should be in roadmap for osci to fix later
16:36:43 <mattymo> We do need to note that we can't release 6.1 with new docker unless we get a clean build on OSCI
16:36:50 <mihgen> we should not just forget it
16:36:53 <mattymo> but we can use the unclean package for now
16:36:57 <rvyalov> barthalion: yes, now we discuss this problem
16:37:24 <mihgen> thx guys let's move on
16:37:47 <kozhukalov> #topic downloadable ubuntu release (ikalnitsky)
16:37:54 <ikalnitsky_> me again :)
16:37:59 <kozhukalov> yea
16:38:05 <kozhukalov> yep
16:38:08 <ikalnitsky_> Actually, there's nothing to be said. I've registered a blueprint
16:38:08 <ikalnitsky_> #link https://blueprints.launchpad.net/fuel/+spec/downloadable-ubuntu-release
16:38:08 <ikalnitsky_> and now I'm on my way to writing a spec. I hope I'll publiosh it tomorrow.
16:38:08 <ikalnitsky_> For those who have no clue: by some reason, we can't redistribute Ubuntu package and call it "Ubuntu". So we have decided to transform it into "optional" release, which could be easily added by cloud operator. The workflow will be: download official ubuntu iso and upload it to fuel.
16:38:08 <ikalnitsky_> Besides, I've done some investigation with ubuntu iso internals and it looks like there's no challenge to extract repos and installer.
16:38:08 <ikalnitsky_> I thought to test these "extracted" repos on the env, but in order to get a clear test I was needed in separate repos. Unfortunately, the man who are doing this will be available next week.
16:39:13 <ikalnitsky_> questions?
16:39:15 <mihgen> ok good
16:39:25 <mihgen> we need design review
16:39:31 <mihgen> did you start it?
16:40:13 <kozhukalov> we also need to separate ubuntu repo from openstack repo on a master node to make this feature working
16:40:16 <mihgen> ikalnitsky_: I mean design spec?
16:40:35 <ikalnitsky_> yeah, i started, but it doesn't ready
16:40:48 <ikalnitsky_> i'll try to publish it on review tomorrow
16:40:55 <mihgen> pls attach it to blueprint
16:41:01 <mihgen> so we can easily find it and review
16:41:11 <kozhukalov> moving on?
16:41:15 <ikalnitsky_> yep, sure
16:41:15 <mihgen> kozhukalov: yeah
16:41:17 <mihgen> thx ikalnitsky_
16:41:54 <kozhukalov> #topic image based provisioning (agordeev)
16:42:03 <agordeev> hi
16:42:20 <agordeev> A lot of bug are still here. Few of their fixes deserve to be backported to 6.0
16:42:22 <agordeev> Most noticable are:
16:42:24 <agordeev> New high priority bug appeared and was fixed lightning fast ->  https://bugs.launchpad.net/fuel/+bug/1410471
16:42:26 <agordeev> Medium, but hard to reproduce bug was finally fixed https://bugs.launchpad.net/fuel/+bug/1394599
16:42:28 <agordeev> Still a 5 or 6 of bug fixes are ready for review (progress on all of them was blocked due to 6.0 releasing ) - most were snippets related. Especially mellanox
16:42:30 <agordeev> and there is one meduim bug. https://bugs.launchpad.net/fuel/+bug/1398643 which's still unclear how is better to fix it.
16:42:32 <agordeev> Otherwise, no other bug news.
16:42:34 <agordeev> According to the latest news and announcements, for the 6.1 I'll be dedicated for bringing true production readyness to IBP by any means.
16:42:36 <agordeev> That's all.
16:43:42 <kozhukalov> agordeev: yes we all hope to get really reliable feature by 6.1
16:43:55 <mihgen> yes please :)
16:44:09 <kozhukalov> thanx agordeev
16:44:23 <kozhukalov> if there are no other q let's move on
16:44:41 <kozhukalov> #topic fuel system tests refactoring (IvanKliuk)
16:44:44 <IvanKliuk> Hi!
16:44:48 <IvanKliuk> The first aim of Fuel system tests refactoring is to extract certain methods are related to the test environment creation and logically have to be a part of fuel-devops project. These methods live in fuel-main.fuelweb_test.EnvironmentModel and being moved into fuel-devops.devops.models.Environment class. Right now the most of methods have been moved into fuel-devops repo and I'm working on decoupling them from other parts of fuel
16:45:41 <IvanKliuk> That's all for now.
16:45:52 <ikalnitsky_> IvanKliuk: nice. the patches are merged or only on review?
16:46:05 <kozhukalov> do you have a spec for this feature?
16:46:13 <mihgen> IvanKliuk: very good, we really need this help for QA team
16:46:34 <IvanKliuk> As I said before, I'll push all the intermediate changes to github for convenience.
16:46:39 <nurla> ikalnitsky_ kozhukalov it is my responsibility to prepare specs for it :)
16:46:43 <IvanKliuk> kozhukalov: no, I don't
16:47:00 <kozhukalov> nurla: great
16:47:05 <kozhukalov> thanks
16:47:11 <mihgen> thx, let's move on
16:47:15 <nurla> I will prepare at next week
16:47:30 <kozhukalov> #topic advanced-networking (akasatkin)
16:47:35 <akasatkin> hi
16:47:39 <akasatkin> spec: https://review.openstack.org/#/c/115340/
16:47:39 <akasatkin> Just a few tasks within adv-networking feature can be delivered to FF.
16:47:39 <akasatkin> These two are mandatory as they exert influence on other projects/features:
16:47:46 <akasatkin> 1. Provide an ability to use mixture of different L23 providers within one
16:47:46 <akasatkin> environment.
16:47:46 <akasatkin> 2. Use network schema for Nova-Network as it is done for Neutron now.
16:47:52 <akasatkin> These changes affect nailgun and library.
16:47:53 <akasatkin> Most of other tasks will be postponed due to lack of time.
16:47:53 <akasatkin> Best effort solution may include:
16:48:01 <akasatkin> 1. Separate public and floating for Neutron.
16:48:01 <akasatkin> 2. Networking API refactoring (introduce DSL in there).
16:48:01 <akasatkin> 3. It will be not mandatory to map all networks to interfaces on every node.
16:48:01 <akasatkin> 4. Network role is separated from network.
16:48:01 <akasatkin> 5. Networks can be arbitrary created/deleted by user.
16:48:08 <akasatkin> Complete list of tasks is in spec.
16:48:08 <akasatkin> Seems that some of the tasks will be solved in API only (no GUI support)
16:48:08 <akasatkin> Most of the work is to be done in nailgun.
16:48:08 <akasatkin> And I'm the only nailgun developer on the feature.
16:48:15 <akasatkin> One of the problems is support of old API (new API is introduced).
16:48:15 <akasatkin> It will take time as DB structure and relations are to be changed significantly.
16:48:15 <akasatkin> So, most of changes may be postponed.
16:49:35 <mihgen> akasatkin: yeah we need you for other things, may be patching
16:49:52 <mihgen> looks like for now we will have to postpond most of the work related to advanced networking
16:50:10 <mihgen> and concentrate on the essential blueprints for 6.1
16:50:22 <akasatkin> if no other python devs will be involved - yes
16:50:49 <kozhukalov> ok, looks like no q here
16:50:53 <kozhukalov> moving on
16:50:54 <mihgen> thx akasatkin . let's move on
16:51:08 <kozhukalov> #topic community project update (teran)
16:51:20 <teran_> We’re going to run landing page for fuel community project by next week.
16:51:20 <teran_> I should become the central endpoint to navigate within our stuff like CI, bugtracker, docs and so on.
16:51:21 <teran_> There also will be available the link for community releases & latest nightly builds, so don’t miss it ;)
16:51:23 <teran_> That’s all.
16:51:57 <mihgen> I -> It, I hope )
16:52:20 <mihgen> thx teran_ , guys - it's gonna be really great page
16:52:22 <teran_> mihgen: yeah :)
16:52:40 <tzn> can’t wait to see it
16:52:41 <mihgen> teran_:  I'm looking forward for it, dreaming about it for a long time already
16:52:50 <nurla> =)
16:52:58 <mihgen> teran_: what about community ISO builds?
16:53:08 <mihgen> https://fuel-jenkins.mirantis.com/
16:53:16 <mihgen> I don't see 6.1 there :(
16:53:59 <teran_> mihgen: it will appear with this release, but we can turn it on quicker manualy for now
16:54:06 <mihgen> any plans to fix it? we need users in the community being able to easily consume daily builds
16:54:13 <mihgen> teran_: we need it badly
16:54:30 <mihgen> we can't wait 2-3 more weeks before you implement something excellent
16:54:37 <teran_> mihgen: it's already fixed, so fix will appear there with community landing page
16:54:45 <mihgen> so if it's possible to spend an hour or two  - please do it
16:54:54 <teran_> mihgen: for now I'll fix it manually there today
16:55:00 <kozhukalov> 5 mins and one more  topic
16:55:01 <mihgen> great thx
16:55:12 <mihgen> we will monitoring for this probably
16:55:22 <kozhukalov> #topic New features for plugins (adanin)
16:55:22 <mihgen> so next time we fix it quickly
16:55:30 <adanin> Hi
16:55:32 <adanin> 1. The Empty Role will be introduced (the code is on review). Fuel just deploy CentOS/Ubuntu on this node and run pre- and post-deploy plugins' hooks. No extra network setup or Puppet run occurs on such node.
16:55:32 <adanin> #link http://osdir.com/ml/openstack-dev/2015-01/msg00819.html
16:55:33 <adanin> 2. We are going to add a new task for Fuel plugins. A plugin will be able to reboot node and wait until it become available again. It allows plugins to update a kernel, for example. There is no link to this task still.
16:55:48 <adanin> that’s all.
16:56:14 <mkwiek> Wasn't it supposed to be called generic role?
16:56:32 <adanin> Maybe.
16:56:40 <mihgen> I
16:56:55 <adanin> We can discuss it in the mail thread I mentioned above.
16:56:58 <mihgen> I'm not sure about generic role…
16:57:16 <evgeniyl__> I'm not sure about generic role too
16:57:24 <mihgen> this is actually hack for now
16:57:28 <mkwiek> ok, sure, it's mentioned in the email thread anyway
16:57:39 <mihgen> before we get new roles definition in plugins
16:57:51 <mihgen> so the least confusing name is preferrable for now
16:58:07 <mihgen> yeah let's come up with ideas in ML
16:58:28 <kozhukalov> ok, guys, looks like we are done
16:58:39 <mihgen> thanks guys
16:58:40 <kozhukalov> we don't have time anymore
16:58:46 <kozhukalov> thanx everyone
16:58:51 <kozhukalov> great meeting
16:58:52 <mihgen> we have many work ahead of us, let's do it!
16:58:55 <kozhukalov> closing
16:59:01 <nurla> bye-bye)
16:59:06 <evkonst> bye
16:59:07 <tzn> thx
16:59:11 <kozhukalov> #endmeeting