17:00 <gnuoy> #startmeeting openstack-charms-meeting 17:00 <meetingology> Meeting started Wed Jun 8 17:00:48 2016 UTC. The chair is gnuoy. Information about MeetBot at http://wiki.ubuntu.com/meetingology. 17:00 <meetingology> 17:00 <meetingology> Available commands: action commands idea info link nick 17:00 <beisner> o/ 17:00 <gnuoy> #topic Review ACTION points from previous meeting 17:00 <ddellav> o/ 17:01 <gnuoy> #subtopic gnuoy Talk to stub about moving his leadership layer into core 17:01 <tinwood> o/ 17:01 <gnuoy> This is less relevant as I went a different path 17:01 <gnuoy> I ended up gating things like db_sync on leadership down in the layer itself rather than in the top handler 17:02 <gnuoy> I'll close that action 17:02 <gnuoy> #subtopic gnuoy review 16.07 deliverables 17:02 <gnuoy> I'll defer this again until we're closer to the date 17:02 <gnuoy> #subtopic jamespage update on relicensing of charms 17:02 <gnuoy> He is going to contact people outside of Canonical who have contributed to the charms and ask if they are happy if the licensing of the charm moves from GPL v3 to Apache-2.0. This is so that our charms comply with the licensing policy for OpenStack big-tent projects 17:02 <gnuoy> #link http://governance.openstack.org/reference/licensing.html 17:02 <jamespage> ok 17:02 <jamespage> I've sent email to openstack-dev with intent; and emailed contributors outside of canonical directly to ask them to respond on the ML thread 17:03 <gnuoy> excellent, thank you 17:03 <gnuoy> #topic Moving communication Upstream 17:03 <gnuoy> We're currently pushing communication to upstream channels. So, we'll be creating a new openstack-charms IRC channel on freenode and moving email discussions about charm operation and charm development to the OpenStack mailing lists. 17:03 <gnuoy> In addition we'll be pushing to update our documentation, both in the charms and various web pages. 17:04 <jamespage> we should probably move this meeting to an openstack-meeting channel as well? 17:04 <gnuoy> Emails the OpenStack mailing lists should have [charm] at the start of their subject line 17:04 <gnuoy> jamespage, +1 17:04 <jamespage> gnuoy, are you ok to take an action to make that happen? 17:04 <beisner> #link http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 17:04 <gnuoy> #action gnuoy move meeting to openstack-meeting channel 17:04 * meetingology gnuoy move meeting to openstack-meeting channel 17:04 <tinwood> We tend to have most conversations on irc. When do they/should they move to he ML? 17:05 <beisner> jamespage, gnuoy - meeting time slots on the 2 (or 3) openstack-meeting channels is pretty tight. some projects use their own channel, and that can be an ok option i think. 17:05 <gnuoy> tinwood, I don't think we should move conversations to a mailing list 17:05 <jamespage> that's a good question - I think when its something design oriented or significant 17:05 <jamespage> ML 17:05 <jamespage> otherwise general chat still in irc imhp 17:05 <gnuoy> +1 17:05 <tinwood> sounds good 17:05 <gnuoy> beisner, ok, thanks for the heads up 17:05 <beisner> +1 irc for day to day convos 17:05 <jamespage> I proposed a rename of the openvswitch-odl charm - that's probably a good example 17:06 <beisner> indeed 17:06 * gnuoy needs to fiddle with email filters 17:06 <tinwood> So things that have knock on effects, etc. 17:06 <gnuoy> #topic State of Development for next Charm Release 17:07 <gnuoy> Most of the HA code in the OpenStack layers has now landed, so OpenstackCharms built on top of the Openstack Layers should be able to easily enable service HA. Work continues on DNS HA, Barbican and workload status management in the OpenStack layers. anyone, want to add anything? 17:07 <jamespage> how are we with CI progress beisner? 17:08 <beisner> we're now adding a repo-info on the fly just ahead of push and publish to the charmstore 17:08 <beisner> that will allow users / triagers to determine exactly where a cs: revno came from 17:08 <jamespage> \o/ 17:09 <beisner> those files should never live in the charm source repos - only ever in a built/published artifact 17:09 <beisner> example: https://jujucharms.com/tempest/ 17:09 <gnuoy> thanks beisner 17:09 <beisner> next up is injecting the build step into the existing CI, which I plan to have tactically in place this week. 17:09 <gnuoy> tip top 17:09 <thedac> nice 17:10 <beisner> we'll have some things to adjust i'm sure, but the basic commit -> build -> test -> publish flow should be good 17:10 <gnuoy> #topic Release Bugs 17:10 <gnuoy> #link https://goo.gl/HJjORI 17:10 <gnuoy> I haven't gone through them in the last week but will be looking through again tomorrow. If anyone has anytime to look as well that would be great. 17:10 <gnuoy> We're one up on last week I think, so not exactly an avalanche, although I think jamespage has done some work 17:11 <gnuoy> #topic Open Discussion 17:11 <gnuoy> Anyone got anything OpenStack charm related to get off their chests? 17:11 <gnuoy> anyone got anything on their mind? 17:11 <beisner> src dirs are still on my mind 17:12 <gnuoy> in a good way? 17:12 <beisner> ;-) 17:12 <tinwood> Like or dislike 17:12 <beisner> i may have waffled on ya 17:12 <beisner> let's discuss in more detail in day 2 day though. proceeding to support both methods (vanilla layers, and the proposed src charm model) 17:12 <thedac> ha! 17:13 <gnuoy> kk 17:13 <thedac> FWIW I lean toward no src dir 17:13 <tinwood> splitter 17:13 <beisner> i'd like to see us list the distinct benefits of doing it really 17:13 * tinwood is sorry 17:14 <beisner> other than it feels/looks better, naturally :) 17:14 <gnuoy> yes, it does 17:14 <tinwood> I'll add to the design doc on CI some points. 17:14 <gnuoy> feels/looks better, I mean 17:15 <beisner> from a devex perspective, having another method could be confusing 17:15 <beisner> take the cephs 17:15 <beisner> ceph-osd and ceph-mon are to be vanilla layers. buildable as a charm and consumable as a layer. 17:15 <beisner> but the ceph layer would be src charm, with a diff dir structure 17:15 <beisner> ie ceph layer not intended to be reconsumed as a layer 17:16 <tinwood> Should the ceph-osd/ceph-mon be layers AND charms? 17:16 <beisner> that's a good question. the *can* be. should they? 17:16 <tinwood> i.e. another 'thing' that trivally consumes the ceph-osd layer to be the charm. 17:17 <beisner> so charm-layer-ceph-osd with the guts, and a thin wrapper in charm-ceph-osd? 17:17 <tinwood> possibly, although even that feels like a hack. 17:17 <beisner> with the latter being a src charm 17:18 <beisner> i think it's one or the other isn't it? 17:18 <tinwood> yes 17:19 <gnuoy> I don't feel that strongly tbh. I like the src dir because it means that files which are only used to build the charm do not pollute the built charm but *shrug* 17:20 <thedac> My arguments against src dir are 1) We are artificially introducing the concept of "top layer" 2) Theoretical future need to consume "top layer" as a middle layer (cephs good example) 3) The developers of reactive and the first reactive charms don't use a src dir 17:20 <beisner> i agree with that aesthetic benefit entirely 17:20 <thedac> But I am certainly open to debate 17:20 <gnuoy> I think point 2 could be argued both ways tbh 17:21 <thedac> I am just publicly committing to my argument :) 17:21 <gnuoy> If we don't want a top layer to be consuable the src dir is a good way to distinguish it. 17:21 <gnuoy> I find the argument that the src charm is a layer a bit force tbh 17:21 <beisner> it feels a bit like building a thing but then saying: you can't extend or re-use it for some other currently unimagined purpose. 17:22 <thedac> And my point is how can we know for certain now that some point in the future we will not want/have to consume a "top" layer again the cephs are good examples 17:22 <tinwood> I'm not overly attached either way. 17:23 <jamespage> I don't think using the src directory now precludes us from moving a charm to be a layer later... 17:23 <beisner> true, git mv ftw 17:23 <jamespage> at least that way we are making a explicit decision that a charm is now consumable as a layer... 17:24 <thedac> That is the strongest point for src dir. That we are explicitly stating it is NOT supported as a layer 17:24 <gnuoy> jamespage, please review the etiquette guidelines (https://wiki.ubuntu.com/ServerTeam/OpenStackCharmsMeeting) 17:24 <beisner> lolz 17:25 <jamespage> .. 17:25 <jamespage> oops lol 17:25 <beisner> roflcopters 17:25 <thedac> heh 17:25 <gnuoy> Ok, I think we should plough on with the src dir but retain the right to change our minds 17:25 * tinwood lol 17:25 <jamespage> +1 17:26 * thedac falls in line 17:26 <jamespage> can we have a official vote on that? 17:26 <tinwood> how do we vote? 17:26 <gnuoy> we can but I don't know the meeting bot commans 17:26 <gnuoy> * commands 17:26 <jamespage> #vote 17:26 <jamespage> #vote <subject> 17:26 <coreycb> o/ 17:26 <jamespage> https://wiki.ubuntu.com/meetingology 17:26 <gnuoy> #vote Having a src dir in top layer charms 17:26 <meetingology> Please vote on: Having a src dir in top layer charms 17:26 <meetingology> Public votes can be registered by saying +1, +0 or -1 in channel, (for private voting, private message me with 'vote +1/-1/+0 #channelname) 17:27 <jamespage> +1 17:27 <meetingology> +1 received from jamespage 17:27 <icey> +0 17:27 <meetingology> +0 received from icey 17:27 <thedac> +0 17:27 <meetingology> +0 received from thedac 17:27 <gnuoy> #voters all 17:27 <meetingology> Everyone can now vote 17:27 <tinwood> +1 17:27 <meetingology> +1 received from tinwood 17:27 <coreycb> +0 17:27 <meetingology> +0 received from coreycb 17:27 <beisner> yes, happy to pave the ci for both to 'just work' -- i only hold back for the future questions: "you did what?" 17:27 <gnuoy> +1 17:27 <meetingology> +1 received from gnuoy 17:27 <beisner> +0 17:27 <meetingology> +0 received from beisner 17:28 <gnuoy> #votesrequired 3 17:28 <meetingology> votes now need 3 to be passed 17:28 <gnuoy> argh, I think we're done 17:28 <gnuoy> #endvote 17:28 <meetingology> Voting ended on: Having a src dir in top layer charms 17:28 <meetingology> Votes for:3 Votes against:0 Abstentions:4 17:28 <meetingology> Motion carried 17:28 <jamespage> \o/ 17:28 <tinwood> \o/ 17:28 <thedac> :) 17:28 <gnuoy> #topic Announce next meeting date, time and chair 17:28 <gnuoy> jamespage, you#re down for next week, can you managed that, I know its late in the UK? 17:29 <gnuoy> if not you can always swap I guess 17:29 <gnuoy> Date 2016-06-15, same time, same place 17:29 <beisner> comedians here today, jeez! 17:29 <jamespage> I can 17:29 <gnuoy> #endmeeting