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