=== JanC is now known as Guest74845
=== JanC_ is now known as JanC
=== sarnold is now known as sarnold_
=== Guest47242 is now known as med_
[16:59] <thedac> o/
[17:00] <gnuoy> o/
[17:00] <jamespage> o/
[17:00] <icey> op/
[17:00] <cargonza> o/
[17:00] <gnuoy> tinwood, beisner, coreycb, ddellav today?
[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> Available commands: action commands idea info link nick
=== meetingology changed the topic of #ubuntu-meeting to: Ubuntu Meeting Grounds: Please leave swords by the door | Calendar/Scheduled meetings: http://fridge.ubuntu.com/calendars | Logs: https://wiki.ubuntu.com/MeetingLogs | Meetingology documentation: https://wiki.ubuntu.com/meetingology | openstack-charms-meeting | Current topic:
[17:00] <beisner> o/
[17:00] <gnuoy> #topic Review ACTION points from previous meeting
[17:00] <ddellav> o/
=== meetingology changed the topic of #ubuntu-meeting to: Ubuntu Meeting Grounds: Please leave swords by the door | Calendar/Scheduled meetings: http://fridge.ubuntu.com/calendars | Logs: https://wiki.ubuntu.com/MeetingLogs | Meetingology documentation: https://wiki.ubuntu.com/meetingology | openstack-charms-meeting | Current topic: Review ACTION points from previous meeting
[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
=== meetingology changed the topic of #ubuntu-meeting to: Ubuntu Meeting Grounds: Please leave swords by the door | Calendar/Scheduled meetings: http://fridge.ubuntu.com/calendars | Logs: https://wiki.ubuntu.com/MeetingLogs | Meetingology documentation: https://wiki.ubuntu.com/meetingology | openstack-charms-meeting | Current 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> ACTION: 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
=== meetingology changed the topic of #ubuntu-meeting to: Ubuntu Meeting Grounds: Please leave swords by the door | Calendar/Scheduled meetings: http://fridge.ubuntu.com/calendars | Logs: https://wiki.ubuntu.com/MeetingLogs | Meetingology documentation: https://wiki.ubuntu.com/meetingology | openstack-charms-meeting | Current 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
=== meetingology changed the topic of #ubuntu-meeting to: Ubuntu Meeting Grounds: Please leave swords by the door | Calendar/Scheduled meetings: http://fridge.ubuntu.com/calendars | Logs: https://wiki.ubuntu.com/MeetingLogs | Meetingology documentation: https://wiki.ubuntu.com/meetingology | openstack-charms-meeting | Current 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?
=== meetingology changed the topic of #ubuntu-meeting to: Ubuntu Meeting Grounds: Please leave swords by the door | Calendar/Scheduled meetings: http://fridge.ubuntu.com/calendars | Logs: https://wiki.ubuntu.com/MeetingLogs | Meetingology documentation: https://wiki.ubuntu.com/meetingology | openstack-charms-meeting | Current topic: Open Discussion
[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
=== meetingology changed the topic of #ubuntu-meeting to: Ubuntu Meeting Grounds: Please leave swords by the door | Calendar/Scheduled meetings: http://fridge.ubuntu.com/calendars | Logs: https://wiki.ubuntu.com/MeetingLogs | Meetingology documentation: https://wiki.ubuntu.com/meetingology | openstack-charms-meeting | Current 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
=== meetingology changed the topic of #ubuntu-meeting to: Ubuntu Meeting Grounds: Please leave swords by the door | Calendar/Scheduled meetings: http://fridge.ubuntu.com/calendars | Logs: https://wiki.ubuntu.com/MeetingLogs | Meetingology documentation: https://wiki.ubuntu.com/meetingology
[17:29] <meetingology> Meeting ended Wed Jun  8 17:29:24 2016 UTC.
[17:29] <meetingology> Minutes:        http://ubottu.com/meetingology/logs/ubuntu-meeting/2016/ubuntu-meeting.2016-06-08-17.00.moin.txt
[17:29] <beisner> thx gnuoy & thx all
[17:29] <coreycb> thanks gnuoy
[17:29] <icey> thanks!
[17:29] <thedac> thanks gnuoy
[17:29] <gnuoy> np
[17:30] <tinwood> thanks gnuoy
[17:30] <jamespage> thanks gnuoy
[17:30] <jamespage> ttfn
=== lifeless_ is now known as lifeless