16:00:03 <xarses> #startmeeting fuel
16:00:03 <xarses> #chair xarses
16:00:03 <xarses> Todays Agenda:
16:00:03 <xarses> #link https://etherpad.openstack.org/p/fuel-weekly-meeting-agenda
16:00:03 <xarses> Who's here?
16:00:07 <mwhahaha> hi
16:00:08 <openstack> Meeting started Thu Aug 11 16:00:03 2016 UTC and is due to finish in 60 minutes.  The chair is xarses. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:10 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:13 <openstack> The meeting name has been set to 'fuel'
16:00:14 <openstack> Current chairs: xarses
16:00:17 <vkramskikh> hi
16:00:38 <romcheg> o/
16:01:06 <akscram> hi
16:01:22 <gkibardin> hi
16:01:49 <kozhukalov> hi
16:02:11 <xarses> alright, lets get started
16:02:16 <xarses> #topic Deprecation of the old Fuel client (romcheg)
16:02:22 <romcheg> Hi everyone
16:02:26 <ajafo> hi
16:02:37 <ashtokolov> hi
16:03:08 <romcheg> We managed to merge all required patches to master and trying to backport everything to stable/mitaka
16:03:16 <romcheg> #link https://review.openstack.org/#/q/status:open+project:openstack/python-fuelclient+branch:stable/mitaka+topic:deprecate_old_cli
16:03:50 <xarses> fantastic
16:03:52 <romcheg> Those are the patches that we still need to backport, so I would like to ask core reviewers to take a look
16:03:57 <kozhukalov> nice, but does this pkg job finally work?
16:04:09 <romcheg> kozhukalov: it does not work yet
16:04:14 <romcheg> but how is that related? :)
16:04:37 <kozhukalov> it is not, just asking
16:04:44 <akscram> Will old fuel client command be available?
16:04:50 <akscram> *commands
16:05:03 <romcheg> We also have one patch to merge to master
16:05:29 <romcheg> that patch will actually delete old fuel client, but I would like to get a +1 from our QA team on it
16:05:31 <romcheg> #link When I said we merged all required patches I kind
16:05:38 <romcheg> whoops
16:05:47 <romcheg> #link https://review.openstack.org/#/c/353734/
16:06:10 <romcheg> akscram: no, we remove old fuel client from the repository
16:06:20 <romcheg> Old commands are going to be installable from PyPi
16:06:29 <mwhahaha> that doesn't seem like a proper deprecation
16:06:47 <romcheg> mwhahaha: we had a deprecation warning for about 3 releases
16:06:58 <akscram> Yeah, it's a complete replacement.
16:07:03 <mwhahaha> ok well you should also formally announce on the ML
16:07:05 <romcheg> it is complete replacement
16:07:16 <mwhahaha> then remove :)
16:07:18 <romcheg> mwhahaha: that's a good idea
16:07:38 <romcheg> I will also prepare a spec with a table
16:07:52 <mwhahaha> yes please make sure there is a proper docs on new vs old commands
16:07:53 <xarses> #action romcheg to annouunce fuel2 promotion and old fuel CLI removal on ML
16:07:57 <romcheg> so people won't have problems migrating to the new CLI
16:08:31 <xarses> moving on then?
16:08:42 <romcheg> +1 if nobody has more questions
16:09:06 <xarses> #topic Introduction of the CCP team. Q\A if needed (kproskurin)
16:09:59 <xarses> they aren't here, so moving on
16:10:09 <xarses> #topic CSV output for deployment hostory handlers status (dguryanov)
16:10:09 <ajafo> we are
16:10:14 <dguryanov2> Hi!
16:10:29 <dguryanov2> Just wanted to ask to review https://review.openstack.org/#/c/346957/
16:10:45 <dguryanov2> This patch is about splitting @content decorator
16:11:03 <ajafo> as you probably saw we started work related to spec https://review.openstack.org/#/c/331139/
16:11:07 <dguryanov2> Could someone, please, help?
16:11:10 <xarses> ajafo: we'll come back, are you going to lead the topic?
16:12:04 <xarses> dguryanov2: what's the problem? Just need more reviewers?
16:12:04 <ajafo> xarses: ok we can back to it later  if kproskurin will join he will lead it if not I can introduce little
16:12:24 <dguryanov2> xarses: Yes
16:13:12 <xarses> dguryanov2: ok, anything else then?
16:13:33 <dguryanov2> No, that's all
16:13:39 <xarses> thanks
16:13:42 <xarses> #topic Repo based BTV (without ISO) (kozhukalov)
16:14:16 <kozhukalov> i just want everyone to be informed that we are now next to run get green bvt without iso
16:14:24 <xarses> \o/
16:14:30 <kozhukalov> maybe today it will be green
16:15:07 <kozhukalov> once it is ready we then will reimplement fuel-ci deployment tests and our main bvt and swarm on master
16:15:21 <kozhukalov> that was a long story
16:15:30 <kozhukalov> but finally ...
16:15:43 <xarses> ya, do we see improvement in test time already with this?
16:15:43 <kozhukalov> ok, that is it on this topic
16:16:05 <kozhukalov> no, test itself takes the same time
16:16:14 <kozhukalov> but we don't need to build iso
16:16:14 <xarses> ok
16:16:15 <xarses> fantastic to hear, I know this has been one of your missions, it's good to see it done
16:16:35 <kozhukalov> not done, but almost
16:17:01 <kozhukalov> moving on, then
16:17:11 <xarses> #topic Upgrades: needs merge for backports to stable/8.0
16:17:25 <akscram> We have two backports to stable/8.0 to enable cloud upgrade from 7.0 to 8.0 in the fuel-web codebase:
16:17:27 <akscram> https://review.openstack.org/353876
16:17:29 <akscram> https://review.openstack.org/342686/
16:18:07 <akscram> They are ready to be merged.
16:18:42 <xarses> akscram: we just need cores to review?
16:19:07 <akscram> Yes, some of them already have +2.
16:19:50 <kozhukalov> yes, we have a lot of patches on review, please core reviewers help
16:20:07 <kozhukalov> review is more important than even writing new code
16:20:29 <xarses> +1
16:20:43 <xarses> #topic The cluster_upgrade extension was extracted from the fuel-web codebase.
16:20:55 <akscram> I want to notice that we extracted the cluster_upgrade extension from the Nailgun codebase and now it lives in a separate repository.
16:21:02 <akscram> #link https://github.com/openstack/fuel-nailgun-extension-cluster-upgrade
16:21:51 <xarses> akscram: I didn't see a message to the ML, did you send one?
16:21:54 <akscram> Okay, I think that I need to write in ML about that.
16:22:10 <xarses> please do
16:22:26 <xarses> #action akscram to send ML about moving cluster_upgrade extension
16:22:50 <xarses> #topic mcollective configuration on slaves https://bugs.launchpad.net/fuel/+bug/1585671
16:22:52 <openstack> Launchpad bug 1585671 in Fuel for OpenStack "Multiple points of mcollective configuration on nodes" [Medium,Confirmed] - Assigned to Georgy Kibardin (gkibardin)
16:22:58 <gkibardin> 
16:22:59 <gkibardin> Upon first boot mcollective on slaves is configured by cloud-init (host, port etc.) and by the nailgun agent when node identity is written. This may happen in any order. These caused several problem fixed in bounds of https://bugs.launchpad.net/fuel/+bug/1455489. Currently we rely on hostname to figure that the provisioning is over and prevent nailgun agent from messing with mcollective. This solution is quite hacky and we need to make
16:22:59 <gkibardin> a better fix. We need a single point of mcollective configuration.
16:22:59 <openstack> Launchpad bug 1455489 in Fuel for OpenStack "Nodes stuck in "provisioning" state despite successful reboot into newly installed OS" [High,Fix committed] - Assigned to Georgy Kibardin (gkibardin)
16:23:11 <gkibardin> 
16:23:11 <gkibardin> I'm inclined not to use cloud init for mcollective configuration. It configures things in quite a strange way: it mounts an image of a file system and read configs from it. Probably there are use cases where this makes sense, but for our particular one this looks overcomplicated. In a bootstrap we initially have properly configured mcollective without all this black magic.
16:23:27 <gkibardin> P.S. There is also one more thing that bothers me: we have two slave-master communication channels: HTTP for nailgun agent and a message queue for  mcollective. Why do we need both of them?
16:24:16 <kozhukalov> for cloud-init it is standard way to get user data
16:24:27 <kozhukalov> from a separate partition
16:24:42 <kozhukalov> nothing bad in such an approach
16:24:47 <gkibardin> kozukalov: yes, I understand this
16:24:59 <gkibardin> but it looks overcomplicated for our use case
16:25:14 <mwhahaha> in the bootstreap, the nailgun agent configures mcollective yes?
16:25:24 <gkibardin> yes
16:25:37 <mwhahaha> so i guess the proposal would be to let it do it post provisioning as well?
16:26:07 <gkibardin> mwhahaha: it is an option
16:26:28 <kozhukalov> ok, anyway using cloud-init for the image is optional from fuel-agent point of view
16:26:52 <mwhahaha> to be consistent I would think we should use the same method for both. I'm not a fan of the cloud-init configuration for mcollective
16:27:30 <gkibardin> yes, the consistency is a problem here, it is better to use one method even it is not good enough
16:27:30 <kozhukalov> then let's maybe think of using ansible instead
16:27:40 <mwhahaha> we need the mcollective configuration for astute by the way as it doesn't leverage the nailgun agent for execution
16:27:49 <gkibardin> or puppet, for the consistency reasons
16:28:10 <mwhahaha> the nailgun agent makes sense as it will essentially autoregister the node
16:28:19 <mwhahaha> i disagree with ansible for this
16:29:00 <mwhahaha> puppet might be useful after the fact as well but i think if we're using nailgun agent as our means for registering a node to the fuel master, it should also handle the mcollective configuration for now
16:29:09 <kozhukalov> let's write dows all options and compare their cons and pros in ML
16:29:26 <gkibardin> ok
16:29:28 <kozhukalov> gkibardin: could you please write ML on this?
16:29:32 <gkibardin> sure
16:29:40 <gkibardin> thanks everybody, lets move on
16:29:55 <xarses> #action gkibardin to follow up on ML about mcollective config issues
16:30:11 <xarses> #topic Renaming the fuel 'release' construct https://review.openstack.org/#/c/351569/1..2/specs/10.0/release-as-a-plugin.rst (xarses)
16:30:24 <xarses> We've been discussing in the release-as-a-plugin spec
16:30:24 <xarses> #link https://review.openstack.org/#/c/351569/1..2/specs/10.0/release-as-a-plugin.rst
16:30:24 <xarses> It's come up that we need to rename the 'release' fixture to something less confusing.
16:30:24 <xarses> Because I can write "
16:30:24 <xarses> In the next release we will release a feature that will allow releases to be released separate of other releases"
16:30:26 <xarses> Current proposals are 'bundle' and 'stack' I lean towards stack as heat uses similar term to describe about the same thing so it would be good to share the terminology
16:30:59 <kozhukalov> ))))
16:31:32 <kozhukalov> yeah bundle sounds more appropriate
16:32:23 <kozhukalov> but how much would it cost for us to change this model Release into Bundle
16:32:35 <kozhukalov> it is going to change also UX
16:32:55 <kozhukalov> as we have commands in CLI like "fuel release"
16:33:01 <xarses> we'd have to rename it all over the place
16:33:34 <kozhukalov> should we also rename database table?
16:33:49 <xarses> we could call them 'release bundles' when we talk about them, which could remove the need to rename them
16:34:32 <xarses> but it will confuse new contributors
16:35:02 <xarses> but ya, less pain then renaming all the things
16:35:53 <ikutukov> Yes, release should be renamed. But "plugin" also not correct term now
16:36:00 <kozhukalov> how is it going to affect upgrades?
16:36:18 <ikutukov> Because we having by fact "plugin-release" and "plugin-plugin"
16:37:05 <xarses> Ok, I propose this then, we can call them 'release bundles' for now in documentation, and deal with possible name migration to just 'bundle' in a different spec
16:37:22 <ikutukov> second case is tautology
16:37:34 <kozhukalov> it is really difficult to choose variable names for majority of software developers
16:37:54 <ikutukov> What about "plugins"?
16:38:02 <xarses> ikutukov: so we would call them fuel-bundle-'name'
16:38:14 <xarses> a plugin is for a bundle
16:38:23 <xarses> *a specific bundle
16:38:30 <ikutukov> OK
16:38:48 <xarses> on that note, so from there, we also need to consider if we should rename fuel-library since it's going to be it's own thing it doesn't make sense to have it be 'the fuel library' any longer
16:39:04 <ikutukov> lets rename FPB to FBB as well)
16:40:03 <xarses> 'fuel-bundle-default' for example
16:40:05 <ikutukov> Another question, will we allow to have bundle and release bundle in one bundle?
16:40:41 <xarses> you mean a 'plugin' and a release bundle?
16:40:44 <kozhukalov> yeah moving code here and there makes fuel project a leading project in openstack by the number of changed lines of code
16:41:29 <xarses> kozhukalov: maybe we squash those commits out of stackalytics
16:42:13 <kozhukalov> dubious
16:42:22 <akscram> I need to read this proposal to understand an impact on upgrades.
16:42:39 <kozhukalov> yes, please do
16:43:19 <xarses> akscram: from the internals side, you should see any change, the label for the 'release' would still be mitaka-9.0 and newton-10.0
16:43:25 <kozhukalov> renaming is usually very painful and we should do this only if potential adv. are much bigger
16:43:51 <xarses> should/shouldn't
16:43:52 <ikutukov> what about bundle metadata file structure, we should make smth like {"releases": [{RELEASE DEF}, ...], "plugins": [{OLD STYLE RELEASE DEF}, ...]}
16:43:59 <ikutukov> ?
16:44:29 <xarses> ikutukov: plugins to bundles are still expected
16:44:55 <ikutukov> Yes, what about declaration format?
16:45:07 <xarses> ya, comment on the specs, there are two
16:45:25 <xarses> #link https://review.openstack.org/#/c/346143
16:45:34 <xarses> #link https://review.openstack.org/#/c/351569
16:45:44 <xarses> ok, lets move on.
16:46:01 <xarses> #topic Introduction of the CCP team. Q\A if needed (kproskurin).
16:46:26 <kproskurin> Hello
16:46:32 <xarses> #action xarses will update spec regarding release naming and summarize on ML
16:46:33 <xarses> hi
16:46:48 <kproskurin> We'd like to introduce out team and our project - CCP. Our goal is to create a contarenized OS running on top of k8s.
16:46:55 <kproskurin> This initiative described in this spec:
16:46:59 <kproskurin> #link https://review.openstack.org/#/c/331139/
16:47:07 <kproskurin> We already in upstream, under fuel umbrella: openstack/fuel-ccp*. Everyone is welcome to contribute to this repos.
16:47:19 <kproskurin> We wrote a simple python CLI, which can be found in openstack/fuel-ccp repo, which fetch, build and deploy OS for us. Some documentation avalible in the same repo(not much right now).
16:47:19 <kproskurin> We already able to deploy basic OS in containers(mariadb, RBMQ, keystone, horizon, glance, nova, ovs, neutron) and everything seems to work, but a lot of work still ahead.
16:47:19 <kproskurin> Olso, we're joined 3rd party CI, which build some docker images for testing purposes:
16:47:23 <kproskurin> #link https://wiki.openstack.org/wiki/ThirdPartySystems/Fuel_CCP_CI
16:47:32 <kproskurin> We're in the middle of creating vagrant  dev env in openstack/fuel-ccp-installer, so really soon you could try to play with it and we're going to create a user friendly documentation describing how  to create a dev env and deploy OS using CCP cli on top of it in the following week.
16:47:32 <kproskurin> If you've any question we can answer now (or if I'll don't know answer bring it on next meeting)
16:48:45 <kozhukalov> what is the plan for integrating your work with Fuel?
16:49:30 <kproskurin> It's not 100% clear yet. But it's somewhere in the roadmap, but not very soon, iirc.
16:49:59 <kproskurin> But plan is to enable CCP deploy via Fuel
16:50:24 <kproskurin> iirc it will be a separate reference architecture
16:50:26 <kozhukalov> do you plan to use Fuel WEB UI?
16:50:41 <kozhukalov> wen deploying Openstack over K8s?
16:51:02 <kozhukalov> are there any preliminary public docs, discussions?
16:51:11 <kproskurin> Probably, but yet again, it's a bit early to make such assumptions, we're in very early state of development and we want to stabilize our own code before thinking about integrations
16:51:33 <kozhukalov> I would say you guys need to promote ccp initiative more intensively
16:51:51 <kproskurin> We were a bit in a stealth mode
16:51:53 <kproskurin> :-)
16:52:04 <xarses> yes, but don't stay that way
16:52:19 <xarses> people are very interested in what you are working on
16:52:38 <kozhukalov> yes, and this must be fixed asap (i mean switch to public mode)
16:52:45 <kproskurin> Sure, it's been few weeks from the point of first stabilisation of our code, we wasnt ready before to promote our self
16:53:06 <kproskurin> Well, Kolla project aware what we exist
16:53:16 <kozhukalov> i hope you guys will take part in our weekly meetings regularly
16:53:31 <ajafo> yes we will take a part regulary
16:53:39 <kproskurin> We will
16:53:54 <kozhukalov> everyone is aware, but no one knows exactly what are your plans
16:54:01 <kproskurin> Thats true
16:54:34 <kozhukalov> ok, nice, we are looking forward to see any progress on this topic
16:54:38 <kozhukalov> thanks
16:54:38 <kproskurin> Its a bit hard to explain but we wanted to be in a "working state" before promote ourselfs
16:55:10 <kproskurin> Sure, I hope really soon we'll able to provide a simple way to use our work via vagrant
16:55:15 <gkibardin> Will promotion part include some sort of roadmap?
16:55:20 <kproskurin> I hope it's 1-2 week from now
16:55:30 <kproskurin> Yes, I think so
16:55:45 <ajafo> yes, we wanted to prepare project to be ready to contribution by others so we had to prepare repos ci and it take some time
16:55:48 <kproskurin> We have a roadmap for like half of the year ahead but something always change
16:56:59 <ajafo> now all of it has basic functionality so it's time for improvements and next steps like our presence here
16:57:15 <gkibardin> thanks, I would play with the dev env as soon as it is available.
16:57:47 <kproskurin> Sure, we will promote ready-to-use env and docs here and in the mailing list, I suppose
16:58:06 <xarses> anything else, we have 2 min
16:58:56 <kozhukalov> once again please help with reviews
16:59:08 <tmcpeak> o/
16:59:21 <xarses> #endmeeting