15:00:03 <EmilienM> #startmeeting puppet-openstack
15:00:04 <openstack> Meeting started Tue Aug 16 15:00:03 2016 UTC and is due to finish in 60 minutes.  The chair is EmilienM. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:06 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:08 <openstack> The meeting name has been set to 'puppet_openstack'
15:00:09 <EmilienM> #topic https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20160816
15:00:11 <xarses> o/
15:00:13 <EmilienM> o/
15:00:13 <iurygregory> o/
15:00:15 <chem> o/
15:00:25 <EmilienM> err
15:00:32 <EmilienM> #link https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20160816
15:00:44 <EmilienM> #topic Puppet Application module proposal
15:00:57 <xarses> I wanted to socialize my proposal to add a puppet application orchestrator module.
15:00:57 <xarses> #link http://lists.openstack.org/pipermail/openstack-dev/2016-August/101670.html
15:01:05 <xarses> My goal is to create generic "applications" that wrap the different openstack services so that we can leverage the new orchestration components in puppet
15:01:13 <EmilienM> beside socialize, do you have code handy?
15:01:17 <xarses> I just saw your reply a few min ago EmilienM
15:01:32 <xarses> nothing that works directly with openstack yet, I wanted to start here
15:01:44 <EmilienM> I'm wondering about several things
15:02:08 <xarses> There is a complicated wordpress example that might show some insight
15:02:08 <chem> this is based on the new PE orchestrator feature, which has no hope of becoming FOSS as far as I understand
15:02:14 <EmilienM> app orchestration can work with full open source puppet ?
15:02:20 <chem> is that correct ?
15:02:29 <EmilienM> maybe _ody or Hunner are around?
15:02:42 <xarses> Yes, it can work with FOSS pupppet, it requires a deployer
15:02:51 <xarses> a component which is only ready for use in PE
15:03:06 <chem> when I've been to the puppet camp in paris the answer was very blurry
15:03:12 <_ody> I be walkinf
15:03:14 <xarses> ri is working on making one
15:03:21 <xarses> #link https://github.com/ripienaar/mcollective-choria
15:03:27 <chem> like "maybe", later and only part of it ?
15:04:06 <xarses> besides the deployer, all of the language bindings are already in FOSS puppet
15:04:19 <xarses> but that is puppet 4.4
15:04:26 <_ody> It's not a maybe, it's happening.
15:04:26 <chem> yes but useless without the client tool, no ?
15:04:31 <EmilienM> we barely make our CI working with puppet 4 :-)
15:05:13 <EmilienM> xarses: do you have an example of workflow that would be in this module?
15:05:19 <chem> os mcollective-choria would be the FOSS version of the PE tooling ?
15:05:25 <EmilienM> I would like to understand if it's a stackforge/puppet-openstack bis
15:05:42 <_ody> There are multiple community implementations of the deployer and we are ramping up the development on another.
15:06:55 <EmilienM> _ody: any link?
15:07:10 <xarses> EmilienM: the model would be that we define some generic relationships in a 'application' this maps relations between amqp & db to the primary serivce, and then the service would relate to it's load balancer
15:07:27 <EmilienM> what load balancer?
15:07:38 <EmilienM> my point is that it's being opinionated
15:07:51 <_ody> Not on hand. Choria is one and there is another but they are both mcollective based.
15:08:31 <EmilienM> ok so we would have to add a new external dependency to our forge (and CI) ?
15:08:49 * beagles sort of lurks
15:09:02 <xarses> we'd create the relationships, and define some common components and applications to provide some generic components for other people to consume
15:09:20 <_ody> And multinode ci too. Kinda a requirement for this.
15:09:38 <xarses> for example, this is a really bare application definition
15:09:46 <chem> I would very much like to be able to use the orchestrator, It's a killer feature, but the future of the foss version supported by puppet is very very unclear.
15:09:47 <xarses> of me playing with it so far
15:09:50 <xarses> #link https://github.com/xarses/paoos/blob/master/manifests/init.pp
15:10:27 <EmilienM> ah so you have a PoC ;-)
15:10:38 <xarses> uh, thats just pumbing testing so far
15:10:56 <iurygregory> but can be a PoC =)
15:11:00 <xarses> I can put more meat into it if thats the what you'd like to see
15:11:05 <EmilienM> _ody: we already have multinode CI, with Fuel and TripleO.
15:11:25 <xarses> here is a complicated wordpress example
15:11:28 <xarses> #link https://github.com/puppetlabs/puppetlabs-wordpress_app
15:11:29 <EmilienM> I agree with chem though, some insights from puppetlabs would be great on this side
15:12:16 <EmilienM> I'm still concerned about a puppet-openstack bis module
15:12:35 <EmilienM> too opinionated to be used in production by our community and not maintained enough
15:13:01 <EmilienM> but I like the idea of multinode thing
15:13:09 <EmilienM> couldn't we add something within our modules?
15:13:21 <xarses> It would make them require puppet4
15:13:23 <EmilienM> some optional classes (apps?) to deploy a component?
15:13:31 <EmilienM> not if you don't use the class in your catalog
15:13:34 <iurygregory> murano apps make sense?
15:13:50 <_ody> PAO applications are less opinionated then your old standard composite module because the architecture is not static.
15:13:53 <EmilienM> iurygregory: I'm not sure it's in this context.
15:14:09 <iurygregory> EmilienM, ok ^^
15:14:13 <EmilienM> _ody: s/your/our/
15:14:24 <_ody> Yeah
15:14:33 <_ody> On phone
15:14:39 <EmilienM> it was created by puppetlabs ;-)
15:14:57 <_ody> Typo, seriously.
15:15:01 <EmilienM> cool np
15:15:22 <EmilienM> before creating a new repo I would like to see a more concrete PoC
15:15:28 <xarses> So it seems people are interested, should I continue on my own?
15:15:51 <EmilienM> also, I would like some vision on roadmap around orchestration
15:15:56 <EmilienM> chem's question has not been answered
15:15:57 <xarses> Ok, does anyone want to participate with me before then?
15:16:09 <xarses> which?
15:16:24 <_ody> I'd like to see a more robust poc being coded in the open where the community can watch progress and learn.
15:16:29 <xarses> oh, the future foss vision from puppet(labs)?
15:16:43 <chem> yes, because without the official client tooling (included only in PE) you have to rely on third party plugin (mcollectived based) .  So we should choose one third party plugin and then support it as well to make sure that everything is working.  how that would work in the CI ?
15:16:45 <EmilienM> specially orchestrator
15:17:12 <EmilienM> in CI and also for our community, it sounds like a critical choice
15:17:31 <_ody> I'll get product to weigh in from puppet. I've actually been talking with them a lot on the subject lately.
15:17:54 <EmilienM> please use the ML's thread
15:18:07 <_ody> Kk
15:19:00 <EmilienM> the idea of doing multi node orchestration is really exciting! though we might want to not repeat the same mistakes as we did
15:19:19 <xarses> I'd like to not also, that's why I wanted to raise this early in the process
15:19:28 <EmilienM> great
15:20:19 <EmilienM> if you really want an incubator OpenStack repo, we can create it but I think it's not the priority #1
15:20:55 <EmilienM> if there is > 1 person actually interested by it, then an incubator repo would be useful
15:21:04 <EmilienM> else, do it on your github now
15:21:22 <_ody> I'd like to collaborate.  Been doing this for my internal OpenStack too.
15:21:25 <EmilienM> maybe can you provide an example with a keystone server
15:21:43 <chem> and explain how to deploy it with foss tooling :)
15:22:09 <_ody> We've also been using OpenStack as our base application internally for orchestrator feature improvement and bug discovery.
15:22:13 <EmilienM> one thing we might not want is to engage upstream efforts for something that is not fully open source
15:23:48 <EmilienM> if puppetlabs wants people to use orchestration and OpenStack to develop puppet modules that support it, make it FOSS
15:23:58 <EmilienM> our community is working hard to make everything in the open
15:24:14 <EmilienM> I don't know why it would be a single direction effort
15:24:40 <EmilienM> and choosing a third party plugin that we are not sure about is definitly not a direction we would take
15:25:46 <EmilienM> unless we have more vision on this area, I'm not sure we'll work on this topic
15:26:06 <_ody> I also don't want something intended to be open source, be code in the dark then "presented" to the community accept.
15:26:23 <_ody> That's why I asked for further PoC to be open
15:27:01 <EmilienM> _ody: xarses's effort is cool, what is not cool is that we're looking for third party plugins to replace something not open source
15:27:26 <EmilienM> so either puppetlabs provides a vision on orchestrator tooling that we can officially use
15:27:54 <EmilienM> or we will have to pick one and pray it will work for us
15:28:24 <EmilienM> I'll follow up on the mailing list about that
15:28:36 <EmilienM> do we have more questions / comments about #topic ?
15:29:06 <_ody> I'll follow up on mailing list.  Just want to get feedback on how we can keep people involved during the PoC process.
15:29:12 <xarses> ok, so next steps, come back with a more fruitful PoC and reconvene on the topic.
15:29:57 <xarses> thanks
15:30:20 <EmilienM> good
15:30:27 <EmilienM> #topic open discussion
15:30:35 <EmilienM> do we have outstanding reviews / bugs this week?
15:30:52 <EmilienM> I have an FYI: we finally got stable/hammer CI working again on puppet-ceph, heh!
15:30:59 <iurygregory> great
15:31:10 <chem> we have the puppet 4.6 related bugs
15:31:11 <iurygregory> i've put the trove authtoken patch
15:31:40 <chem> https://review.openstack.org/#/c/354872/ for instance
15:32:05 <EmilienM> I reported https://bugs.launchpad.net/netbook-remix/+bug/355609
15:32:05 <openstack> Launchpad bug 355609 in Ubuntu Netbook Remix "Interface responds slowly + display error in interface" [Undecided,Incomplete]
15:32:09 <EmilienM> err wrong link
15:33:00 <EmilienM> but puppet 4.6 unit tests jobs are failing
15:33:04 <EmilienM> https://review.openstack.org/#/c/355617/ and https://review.openstack.org/#/c/355609/
15:33:28 <EmilienM> I hate asking but it would be great to have a bit of support from puppetlabs sometimes
15:33:47 <chem> I didn't have time to fill the bug upstream, yet, will do today.
15:34:12 <EmilienM> chem: thanks for your time, hopefully we can get an eye on it quickly
15:34:36 <iurygregory> https://bugs.launchpad.net/puppet-nova/+bug/1613329
15:34:36 <openstack> Launchpad bug 1613329 in puppet-nova "puppet 4.6.0 unit tests are broken" [Medium,New] - Assigned to Emilien Macchi (emilienm)
15:34:43 <EmilienM> ah, thanks
15:34:49 <iurygregory> np
15:35:04 <EmilienM> I had to do https://review.openstack.org/#/c/355609/3/manifests/db.pp to fix unit tests
15:35:18 <EmilienM> might something with rspec, I'll dig into it later this week
15:36:01 <EmilienM> anything else for this week ? I'll let meeting open 30s in case
15:36:21 <EmilienM> Hunner: something to say about puppet 4.6?
15:36:29 <iurygregory> https://review.openstack.org/#/c/346685/10/manifests/keystone/authtoken.pp Lines 280-282
15:37:26 <EmilienM> ok, hunner mentioned on #puppet-openstack that puppet 4.6 is broken
15:37:28 <EmilienM> great !
15:37:29 <Hunner> o/
15:37:31 <EmilienM> ah
15:37:36 <iurygregory> if any core have option, the authtoken class should handle other configurations besides keystone_authtoken section?
15:37:46 <EmilienM> iurygregory: will look at it
15:37:52 <chem> ditoo
15:37:53 <Hunner> I'll have more details on 4.6.0 brokenness in a bit
15:37:58 <iurygregory> EmilienM, tks :D
15:38:14 <chem> Hunner: so no need for a bug report ?
15:38:18 <EmilienM> Hunner: please use openstack-dev ML with [puppet] tag, would be awesome
15:38:32 <EmilienM> chem: please report the bug anyway, it will still help for history & tracking
15:38:54 <chem> ack, I'll do it short then :)
15:38:56 <EmilienM> I'm about to close the meeting
15:39:01 <EmilienM> thanks everyone
15:39:06 <EmilienM> #endmeeting