17:00:11 <gnuoy> #startmeeting charms
17:00:12 <openstack> Meeting started Mon Aug 22 17:00:11 2016 UTC and is due to finish in 60 minutes.  The chair is gnuoy. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:13 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:00:15 <openstack> The meeting name has been set to 'charms'
17:00:17 <thedac> o/
17:00:18 <beisner> o/
17:00:33 <gnuoy> Hi all, I'll just pause a minute for any straglers
17:00:45 <tinwood> Hi!
17:00:50 <gnuoy> \o
17:01:19 <cargonza> o/
17:01:25 <wolsen> o/
17:01:29 <gnuoy> #topic Review ACTION points from previous meeting
17:01:32 <jamespage> o/
17:01:43 <gnuoy> #subtopic Mascot
17:02:00 <tinwood> jamespage, do you have details on this yet?
17:02:06 <gnuoy> I don't think it was actually an action but did something happen after the last vote?
17:02:15 <jamespage> I emailed Heidi but have not heard back -
17:02:20 <gnuoy> kk
17:02:21 <jamespage> orangutang was the first choice
17:02:25 <jamespage> just chased
17:02:32 <gnuoy> #subtopic beisner Nominate thedac for charms-release group
17:02:38 <gnuoy> did that happen?
17:02:47 <jamespage> gnuoy, no I think we where waiting on your vote?
17:02:55 <gnuoy> orly
17:02:57 <beisner> sent to ml, received some +1s there.
17:03:08 <thedac> thanks, beisner
17:03:13 <gnuoy> I'll dig it out and +lots
17:03:32 <gnuoy> #topic State of Development for next Charm Release
17:03:38 <jamespage> gnuoy, added thedac to -release
17:03:44 <gnuoy> jamespage, thanks
17:03:49 <thedac> thank you
17:04:04 <wolsen> well earned thedac
17:04:05 <tinwood> yay
17:04:19 <gnuoy> Anyone got anything they'd like to highlight as a feature targetted for 16.10?
17:04:29 <beisner> woot thanks all, welcome thedac  ;-)
17:04:42 <jamespage> no technically but I want to have a bit of a focus on our dev guide
17:04:53 <gnuoy> defo
17:04:54 <jamespage> I'll take an action to include the openstack-on-lxd README as a section
17:05:08 <gnuoy> #action jamespage  include the openstack-on-lxd README as a section in dev guide
17:05:13 <beisner> prob worth getting nova serial-console feature dev on someone's list
17:05:15 <jamespage> beisner, are you still ok to contrib the amulet bits and pieces? I think generally documenting our CI there is OK
17:05:19 <jamespage> beisner, ah yes
17:05:36 <beisner> jamespage, yes i have an outstanding to-do to update the test section of the charm-guide, still plan to tackle that.
17:05:49 <gnuoy> The SDN cookie cutter charms *will* be ready for 16.10
17:06:05 <tinwood> once we know what shape they will be.
17:06:10 <gnuoy> ha! yes
17:06:21 <beisner> orangutan, naturally
17:06:29 <gnuoy> ok, anyone got anymore...
17:06:42 <gnuoy> #topic High Priority Bugs
17:06:56 <gnuoy> Any horrible bugs worth noting?
17:07:05 * jamespage thinks
17:07:14 <gnuoy> thedac, am I right in thinking there is some rabbit work still needs doing?
17:07:15 <thedac> glance-simplestreams-sync needs xenial updte
17:07:22 <jamespage> I had a juju 2.-0 trip hazard
17:07:29 * gnuoy wonders whether to mention mongo
17:07:38 <jamespage> https://bugs.launchpad.net/juju-core/+bug/1615601
17:07:38 <openstack> Launchpad bug 1615601 in juju-core "2.0 beta 14 + openstack: generated hostnames exceed 255 byte limit" [High,Triaged]
17:07:41 <thedac> gnuoy: possibly more stability testing for rabbit, yes
17:07:54 <jamespage> gnuoy, thedac: yeah we need to rip out all of the hosts management changes I made
17:08:04 <jamespage> I feel I should do that and clean up my own mess
17:08:08 <gnuoy> jamespage, it reminds me of the ol' directory-too-long back in pyjuju days
17:08:20 <wolsen> has anyone tested l3-ha for neutron gateway in the recent past?
17:08:21 <jamespage> oh for sockets
17:08:23 <jamespage> yah lol
17:08:28 <thedac> :)
17:08:32 <beisner> glance-simplestreams-sync is worth a separate and more detailed convo imho.  when we last discussed i/p, we thought it might be good to deprecate it and add actions to the glance charm.
17:08:39 <gnuoy> wolsen, yes, it's part of our release testibng
17:08:57 <thedac> beisner: actions are an interesting idea
17:08:57 <wolsen> gnuoy: great
17:09:00 <gnuoy> beisner, yes, that was where we left it
17:09:03 <jamespage> beisner, agreed - we need todo that this week or it will not happen - I'll schedule a slot and we can discuss in #openstack-cahrms
17:09:16 <beisner> as g-s-s-s-s-s-s is currently not in ci, i think we should either knock it into shape, or work the necessary bits into the glance charm
17:09:25 <jamespage> second for me
17:09:41 <gnuoy> wolsen, I spoke to thedac and we're going to dig at it too
17:09:41 <jamespage> gnuoy, can you action me to organize a follow up for that pls?
17:09:46 <beisner> cool
17:09:48 <wolsen> gnuoy, stellar
17:09:48 <jamespage> (g-ss-s)
17:09:59 * jamespage waves a bbaqar
17:10:02 <jamespage> welcome!
17:10:12 <gnuoy> #action jamespage Discuss future of g-ss-s charm
17:10:13 <wolsen> gnuoy: I'd be more than happy to help as I'd like to understand if I did something wrong
17:10:27 <gnuoy> wolsen, sur, will keep you updated
17:10:43 <bbaqar> jamespage: thanks :)
17:10:49 <gnuoy> ok, moving on....
17:10:57 <gnuoy> #topic requirements files in charms
17:11:24 <gnuoy> So, there was some talk of doing a global requirements thingy, is that right?
17:11:25 <beisner> hi.  so osci is currently tripping over a dep of a dep of a dep of a req in charm-tools
17:11:39 <beisner> https://github.com/juju/charm-tools/issues/246
17:11:56 <beisner> which is fix-committed in charm-tools master, but will not resolve our issue until/if charm-tools cuts a new pypi release
17:12:24 <beisner> that underlying issue is solvable in another way though, which is to require setuptools version == that of xenial
17:12:30 <tinwood> if it's in a venv, why's it failing?  is it using system packages?
17:13:02 <beisner> no, it's setuptools 2.2 in a venv on trusty vs setuptools 25.2.0 in venvs on xenial.
17:13:36 <jamespage> beisner, is this just effecting UOSCI testing? is OpenStack verification ok?
17:13:38 <beisner> if we use the later setuptools, problem solved.
17:13:56 <beisner> jamespage, openstack verification is ok, as they're now building venvs on xenial hosts.
17:14:00 <tinwood> I think it is using site-packages.  However, it may need to.
17:14:37 <beisner> on the topic of xenial, we will need jenkins-slave to overcome this https://bugs.launchpad.net/charms/+source/jenkins-slave/+bug/1543380
17:14:38 <openstack> Launchpad bug 1543380 in jenkins (Ubuntu) "jenkins-slave on Xenial: Unable to connect to Upstart: Failed to connect to socket " [Undecided,Confirmed]
17:14:52 <beisner> back to the nature of the topic, and my question:
17:15:13 <beisner> requirements.txt and test-requirements.txt across os-charms are not unified
17:15:15 <beisner> but should be imho
17:15:37 <beisner> i've added links to upstream requirements-update code, which may be usable for this, albeit overkill for what i'd like to do.
17:16:08 <beisner> which is maintain requirements in our release-tools repo, along with the necessary script to push that into the os charm repos.
17:16:18 <gnuoy> sorry, where have you added those links?
17:16:27 <beisner> oh sorry, in the etherpad
17:16:30 <beisner> https://etherpad.openstack.org/p/openstack-charms-weekly-meeting-20160822
17:16:52 <gnuoy> #link https://github.com/openstack/requirements
17:16:59 <gnuoy> #link http://docs.openstack.org/developer/requirements/#enforcement-in-projects
17:17:06 <beisner> jamespage, without charm-tools passing, we won't get amulet tests because it's bail on first fail in the pipeline
17:17:24 <jamespage> beisner, yeah
17:18:14 <beisner> so, fact:  charm-tools in a venv on a trusty host now fails by default until pypi pkg is revved up;   qq:  do we pressure there and wait it out, or start modding charm reqs?
17:18:44 <jamespage> beisner, hmm
17:19:09 <beisner> it does bring the desire to have global reqs swiftly to the front burner, if that's the direction we want to go.
17:19:23 <jamespage> my main problem is that even if we go for an approach that means we have consistent requirements.txt and test-requirements.txt we can still get hit by transient dependency issues
17:19:57 <beisner> yeah, in this case the dependency chain looks like:  cryptography->secretstorage->keyring->launchpadlib->charm-tools
17:19:58 <jamespage> I think its a step forward, but we should probably follow our peer projects and start to use pip constraints to pin/fix versions as required
17:20:22 <beisner> where the breakage was at charm-tools, but on a launchpadlib dep, when secretstorage revved up.
17:20:32 <beisner> i'm not sure anything can solve that
17:20:44 <jamespage> the constraints are sourced from upper-constraints.txt in global-requirements - if we take that approach, then we can fix a transient break in a central way, rather than having to raise 30 reviews
17:21:00 <beisner> yes that is good
17:21:17 <gnuoy> ok, I think we're agreed on the central requirements approach
17:21:23 <jamespage> agreed +1
17:21:26 <beisner> but if you take this breakage, we would have to pin 4 layers deepo
17:21:29 <beisner> deep, even
17:21:35 <gnuoy> beisner, but in one place
17:21:39 <tinwood> I'm not sure I understand it.
17:21:42 <jamespage> beisner, we can generate a constraints file
17:21:55 <beisner> cryptography->secretstorage->keyring->launchpadlib->charm-tools
17:22:07 <jamespage> based on a known good baseline, and then refresh and re-test on a regular basis
17:22:11 <beisner> ^ secretstorage revved up, breaking charm-tools.  we already pin charm-tools.
17:22:52 <jamespage> beisner, I think constraints covers everything in the venv
17:22:52 <jamespage> https://github.com/openstack/requirements/blob/master/upper-constraints.txt
17:23:06 <jamespage> not just the expressed dependencies in requirements.txt
17:23:26 <beisner> right, i don't disagree there at all.  ok, so who's going to take that on?
17:23:52 <beisner> seems like a non-trivial undertaking
17:24:02 <jamespage> I don't think its that bad
17:24:10 <jamespage> we have a good template to copy imho
17:24:42 <jamespage> I know everyone is super busy
17:24:54 <beisner> i would like to get there (use openstack/requirements as a model).  i would also like to unblock your gate tactically.
17:25:07 <jamespage> beisner, quickest way to gate being unblocked is to release charm-tools right?
17:25:11 <beisner> yes
17:25:19 <jamespage> lemme go kick the tyres there then
17:25:35 <beisner> fyi, queried in #juju first thing this am
17:25:38 <beisner> worth a re-ping
17:26:18 <jamespage> beisner, ok
17:26:22 <gnuoy> ok, so publish fixed charm-tools RSN and global requirements soon too
17:26:30 <jamespage> gnuoy, agreed
17:26:36 <gnuoy> kk
17:26:42 <gnuoy> #topic Barcelona Design Summit: Fishbowls, Workrooms and Contributor meetups.
17:26:48 <gnuoy> jamespage, your topic I believe
17:27:05 <jamespage> oh yeah - so  we need to decide on what to request for the design summit in terms of slots etc...
17:27:15 <gnuoy> jamespage, whats the deadline?
17:27:20 <jamespage> 31st
17:27:27 <gnuoy> ack
17:27:31 <jamespage> fishbowls are fixed advertised content - I was going to suggest
17:27:53 <jamespage> 1) retry of 16.07 and 16.10 charm releases - identify pain points and potential ways forward
17:27:58 <jamespage> retro
17:28:16 <jamespage> 2) 16.10 planning and high level objective setting
17:28:35 <jamespage> and then request a workroom for an afternoon (3 slots)
17:28:49 <jamespage> with a contributor meeting on the friday pm if we can get one
17:28:53 <jamespage> does that sound ok?
17:28:59 <gnuoy> sounds good to me
17:29:02 <thedac> sounds good
17:29:03 <tinwood> Sounds excellent.
17:29:26 <jamespage> okwill request tommorow
17:29:42 <gnuoy> #action jamespage request  Barcelona Design Summit slots
17:29:53 <gnuoy> we're pretty much out of time
17:30:07 <gnuoy> anyone got anything else burning?
17:30:16 <thedac> no
17:30:18 <tinwood> nope
17:30:24 <jamespage> no
17:30:26 <gnuoy> same time, same place in 2 weeks then
17:30:32 <gnuoy> #endmeeting