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