17:02:01 <thedac> #startmeeting charms
17:02:01 <openstack> Meeting started Mon Mar  6 17:02:01 2017 UTC and is due to finish in 60 minutes.  The chair is thedac. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:02:02 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:02:05 <openstack> The meeting name has been set to 'charms'
17:02:13 <thedac> Welcome everyone.
17:02:23 <jamespage> o/
17:02:24 <vds> o/
17:02:29 <thedac> Appologies for canceling our previous meeting as we were in the middle of release week
17:02:44 <thedac> We'll jump right in
17:02:49 <thedac> #topic Review ACTION points from previous meeting
17:02:50 <jamespage> awesome-o
17:03:13 <thedac> Copied over some out of date previous actions.
17:03:19 * thedac jamespage    talk py27 retirement with tc as ptl
17:03:43 <thedac> jamespage: any word or can that be closed out?
17:04:01 <jamespage> I've still not really broached that subject; however I do feel the requirement for py27 is broadly not applicable in our use case
17:04:10 <jamespage> I don't think we need to continue to track it specifically
17:04:20 <thedac> OK
17:04:28 * thedac cholcombe    close out bugs against ceph-fs
17:04:35 <thedac> cholcombe: any status ^^
17:04:37 <jamespage> done
17:04:41 <jamespage> we released it :-)
17:04:48 <thedac> \o/
17:04:54 <wolsen> \o/
17:05:00 <thedac> #topic State of Development for next Charm Release
17:05:01 <cholcombe> :D
17:05:06 <thedac> 17.02 is out the door
17:05:14 <jamespage> congrats all
17:05:28 <jamespage> it was nice todo the release with most people in the same room for a change!
17:05:34 <thedac> agreed
17:06:09 <thedac> We do have some follow up work regarding ocata amulet tests. That work is in progress
17:06:27 <icey> woot
17:06:37 <thedac> Any other items for State of Development
17:07:12 <thedac> going once?
17:07:19 <thedac> Moving on
17:07:23 <jamespage> +1
17:07:23 <thedac> #topic Discussion: service discovery vs modeling
17:08:03 <thedac> jamespage: wolsen niedbalski I believe you are all on for this ^^^
17:08:04 <jamespage> oh strait into the interesting stuff this evening!
17:08:12 <wolsen> thedac indeed
17:08:29 <jamespage> ok so the context for this is charms that need to enable features based on knowledge of whats been deployed as part of the cloud
17:08:46 <jamespage> specific examples - enabling notifications for ceilometer when ceilometer is deployed
17:08:56 <jamespage> enabling designate notifcations when designate is deployed
17:09:13 <jamespage> ceilometer knowing to use the radosgw support when the object-storage is radosgw
17:09:49 <jamespage> we've seen a few approaches proposed for this - niedbalski - thanks for your proposal for cinder btw
17:10:16 <jamespage> niedbalski's approach involves quering the service catalog during charm hook execution to determine which services are enabled or not.
17:11:09 <jamespage> I have a few reservations about that approach as its a little point in time - ceilometer might get added to the deployment after the initial deployment, but notifications might not get turned on correctly taking this approach
17:11:23 <cholcombe> i was thinking the same thing
17:11:41 <jamespage> so we have to model this by using relations and relation data in some fashion
17:12:15 <jamespage> that's my take at least - this may mean adding a 'requires:ceilometer-service' relation to service that need to optionally enable notifications of this type
17:12:44 <jamespage> then the charm categorically knows there is something in the deployment providing ceilometer, so notifications can be enabled
17:12:57 <jamespage> that's fairly coarse in application
17:13:04 <jamespage> its either there or not
17:13:28 <jamespage> we have other finer grained requirements - I really don't like the way we have to turn on dashboard features using config for example
17:13:39 <jamespage> that should just be part of service discovery of some description
17:13:55 <jamespage> anyone else have any opinions here?
17:14:00 <thedac> I agree relations is the only way we can manage the race conditions during deploy time. We could do actions post-deploy but that is not an elegant solution.
17:14:12 * jamespage shivers a litte
17:14:15 <jamespage> agreed thedac
17:14:44 <jamespage> this is a great example of a 'smart' charm use-case
17:15:05 <thedac> With relations the charms can then set workload status if a service is not avaialable. Informing the end user
17:15:20 <jamespage> where juju deploy openstack actually deploys a charm, which then deploys the rest of openstack and knows what's been deployed and can toggle config flags
17:15:32 <jamespage> but that's a bit of a pipe dream right now
17:15:37 <thedac> :)
17:16:06 <cholcombe> consul is specifically built for this use case
17:16:09 <jamespage> thedac: I did also have a crazy idea about a general capability to register services and features
17:16:10 <cholcombe> and i believe it's charmed?
17:16:23 <jamespage> cholcombe: what might that add? I'm not familiar with consul
17:16:44 <cholcombe> charms would have to talk to consul to register themselves and what they provide
17:16:50 <cholcombe> i'm not entirely sure it adds anything
17:17:08 <thedac> How would that be different than the keystone catalog?
17:17:16 <jamespage> thedac: I was just thinking that
17:17:22 * jamespage ponders this
17:17:31 <cholcombe> it's prob not any different so long as keystone can handle scaling up and taking the load of lots of clients asking it for things
17:17:57 <jamespage> if API endpoints provided features as well as the service type, the keystone charm could have a relation where it echos out a consolidated set of service discovery information to any charm that wants to consume it
17:18:34 <cholcombe> as long as it's reliable i don't see any reason not to use it :)
17:18:42 <jamespage> cholcombe: thedac: does that make some sort of sense?
17:18:56 <cholcombe> yeah i believe so
17:19:00 <niedbalski> jamespage, agreed, that'd solve my case.
17:19:10 <cholcombe> i'm a radosgw i provide x, y and z
17:19:23 <thedac> yeah, that might work. The consuming charm can wait until the service it needs shows up.
17:19:57 <jamespage> schema might look like
17:20:26 <jamespage> type: metering
17:20:43 <jamespage> hmm not sure we'll get to this right now
17:21:04 <jamespage> thedac: can you action me to draft an initial proposal?
17:21:20 <jamespage> unless someone else would like to take a first pass?
17:21:30 <thedac> #action jamespage Draft initial proposal for service discovery
17:21:33 <jamespage> happy to standback from this one if someone else wants to take point
17:22:43 <thedac> Shall we move on then? Any more discussion for this meeting on this topic?
17:23:16 <thedac> Ok, moving on
17:23:17 <niedbalski> the suggested approach looks fine to me
17:23:30 <thedac> great
17:23:39 <thedac> #topic High Priority Bugs
17:23:51 <thedac> #link https://bugs.launchpad.net/openstack-charms
17:24:17 * jamespage waves
17:24:20 <jamespage> high level stats
17:24:25 <jamespage> 1 critical bug open still
17:24:32 <jamespage> 59 high priority ones
17:24:54 <jamespage> https://bugs.launchpad.net/charm-hacluster/+bug/1478980
17:24:54 <openstack> Launchpad bug 1478980 in OpenStack hacluster charm "If the principle updates a resource parameter of an already configured resource hacluster ignores it" [Critical,In progress] - Assigned to Liam Young (gnuoy)
17:24:57 <jamespage> is the high priority one
17:25:25 <thedac> ok
17:25:27 <jamespage> and a bit of a tricky one to solve methings
17:25:39 <jamespage> high/critical priority one
17:26:00 <thedac> I would also like to highlight jamespage's great work consolidating all charms under one project so that bugs are now easier to find and create.
17:26:19 <jamespage> ta - it should make things much easier to track
17:26:44 <thedac> That is an understatement
17:26:46 <thedac> Any other high priority bugs to highlight?
17:27:04 * jamespage is glad his migration script dtrt :-)
17:27:16 <thedac> Moving on
17:27:24 <thedac> #topic Openstack Events
17:27:49 <thedac> We just came from the ptg
17:27:57 <thedac> #link https://etherpad.openstack.org/p/openstack-charms-ptg-pike
17:28:07 <thedac> Any upcoming events to highlight?
17:28:40 <jamespage> ops meetup next week - I won't be attending but I think some folk are going along
17:29:05 <jamespage> ...
17:29:14 <jamespage> (that was for gnuoy)
17:29:25 <thedac> ODS in Boston in May
17:29:30 <thedac> #link https://www.openstack.org/summit/boston-2017/
17:30:02 <cargonza> Boston DevOps Meetup during ODS Boston in May also... still planning...
17:30:48 <thedac> Any other events?
17:31:06 <thedac> #topic Open Discussion
17:31:19 <thedac> Open discussion time. Does anyone have anything to bring up?
17:31:37 <jamespage> not this week
17:31:59 <thedac> Going once?
17:32:06 <wolsen> not from me
17:32:13 <wolsen> well
17:32:26 <wolsen> does this - https://etherpad.openstack.org/p/openstack-charms-ptg-pike capture the discussions at the PTG adequately
17:32:37 <wolsen> any additional comments on it for those of us that didn't attend
17:33:18 <thedac> I think it gives the highlights and the actions that came out of the discussion. Feel free to ping me on any points of interest
17:33:25 <wolsen> thedac ack
17:33:42 <thedac> ok closing out
17:33:45 <thedac> #endmeeting