14:01:29 <mattmceuen> #startmeeting airship
14:01:31 <openstack> Meeting started Tue Nov 27 14:01:29 2018 UTC and is due to finish in 60 minutes.  The chair is mattmceuen. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:01:32 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:01:35 <openstack> The meeting name has been set to 'airship'
14:01:39 <aaronsheffield> o/
14:01:43 <mattmceuen> #topic rollcall
14:01:59 <mattmceuen> Hi all gm!
14:02:06 <portdirect> o/
14:02:12 <sthussey> https://etherpad.openstack.org/p/airship-meeting-2018-11-27
14:02:35 <georgk> hi
14:03:23 <mattmceuen> I will be your topic swapper this morning
14:03:39 <mattmceuen> Please go ahead and add anything you'd like to discuss into the agenda for today
14:04:11 <mattmceuen> I was out last week and haven't caught up on last week's logs -- did we retro on the summit or anything?
14:08:34 <mattmceuen> Ok let's get this party started
14:08:45 <mattmceuen> #topic Summit notes
14:08:57 <mattmceuen> So there was a summit a couple weeks ago!
14:09:05 <mattmceuen> Lot of interest in Airship there
14:09:43 <mattmceuen> There were some talks -- anyone have the youtube links handy by chance?
14:10:25 <sthussey> They are in the etherpad under announcements
14:11:28 <mattmceuen> wunderbar ty sthussey
14:12:10 <mattmceuen> I'm looking for the deckhand talk and am not finding that?
14:12:13 <mark-burnett> Hopefully the non-keynotes get added to youtube too
14:12:20 <mark-burnett> They don't appear to be uploaded yet
14:12:41 <mattmceuen> Ok, weird - they're ususally uploaded fast
14:12:51 <mark-burnett> Well, it was a holiday, etc.
14:12:56 <mattmceuen> I'll look into that, the deckhand one should be a valuable reference I think for new folks
14:13:12 <mattmceuen> Yeah but "fast" meaning "in an hour from the time of the talk" :)
14:13:24 <mark-burnett> Hmm
14:13:32 <mattmceuen> I'll track it down
14:14:00 <mattmceuen> another good thing from the summit:
14:14:06 <portdirect> I didn't notice any filming notices now I think of it, wonder if that has anything to do with it.
14:14:14 <mattmceuen> hmm
14:14:47 <mattmceuen> We had great discussions with other project teams in several forum sessions
14:14:55 <mattmceuen> Ironic, Infra, other container teams
14:15:30 <mattmceuen> If anyone would like to catch up, there are good notes in here:
14:15:33 <mattmceuen> https://etherpad.openstack.org/p/BER-airship-qa
14:15:34 <mattmceuen> https://etherpad.openstack.org/p/BER-airship-bare-metal
14:15:34 <mattmceuen> https://etherpad.openstack.org/p/BER-container-security
14:15:59 <mattmceuen> Again, I am not fully caught up myself :)  but planning on grepping through this for next steps / action items this week
14:17:01 <mattmceuen> In addition we had a very well attended developer onboarding session with a great crowd (hopefully some of you are out there today :) )
14:17:25 <mattmceuen> Please feel free to ask questions or otherwise get involved in this chat room - welcome
14:17:32 <b-str> indeed!
14:17:59 <mattmceuen> Any other highlights / questions / etc around the summit folks?
14:18:10 <evrardjp> none
14:18:51 <mattmceuen> Alrighty
14:19:08 <mattmceuen> #topic Ideas for treasuremap deployment
14:19:38 <mattmceuen> I'm working on a couple POCs of tensorflow-related sites
14:19:46 <mattmceuen> Hope to have something to share next week
14:20:09 <mattmceuen> there are a lot of good ideas in the etherpad
14:20:28 <mattmceuen> So one of the questions that came up at the summit - and a very valid one - was
14:20:37 <mattmceuen> "how is airship different from the other openstack installers"
14:20:49 <mattmceuen> because there are several excellent openstack installers
14:21:31 <sthussey> Airship is in fact not an OpenStack installer?
14:21:38 <mattmceuen> So proving that airship is not just for openstack, but can be configured to drive arbitrary helm-based workloads, will help put oomph behind the tagline that it's not just for openstack
14:21:47 <evrardjp> sthussey: that's a valid answer :p
14:22:02 <mattmceuen> Exactly - just have to demo that a bit :)
14:22:28 <evrardjp> well that's what I meant with my comment -- proper PR (public relations, not pull request) help there.
14:22:36 <mattmceuen> ++
14:22:42 <sthussey> https://github.com/helm/charts/tree/master/stable
14:22:49 <sthussey> Pretty much anything there should be fodder
14:22:57 <mattmceuen> agree
14:23:07 <roman_g> Another 2 questions "how is airship-promenade different from the other k8s installers?" and "how is airship different from starling-x?"
14:23:23 <roman_g> (from what I've been asked)
14:23:32 <mattmceuen> Ideas from the etherpad:
14:23:32 <mattmceuen> gitlab
14:23:32 <mattmceuen> jenkins/artifactory
14:23:32 <mattmceuen> zuul
14:23:32 <mattmceuen> hadoop
14:23:32 <mattmceuen> LMA applications
14:23:32 <mattmceuen> end-user apps
14:23:33 <mattmceuen> tensorflow/kubeflow - "impressive"
14:23:33 <mattmceuen> wordpress
14:23:49 <roman_g> o/
14:23:50 <sthussey> Honestly, I'm not sure why we should attempt to differentiate Airship
14:24:20 <sthussey> Just explain what Airship does. Decide to use it on its merits, compare it yourself other alternatives.
14:24:56 <mattmceuen> Good ones roman_g
14:25:10 <mattmceuen> Yep, and code is worth a million words
14:25:36 <mattmceuen> If anyone is interested in helping define manifests for any of those things above that would be awesome
14:25:56 <mattmceuen> as examples and proofs-of-concept for operators to start from
14:26:00 <sthussey> I believe we already have Jenkins
14:26:07 <mattmceuen> do we have that in treasuremap yet?
14:26:17 <b-str> In terms of differentiators (but probably not totally unique) is the declarative definition of the site and workload.
14:26:28 <sthussey> I
14:26:37 <sthussey> I'm not sure it will go in treasuremap
14:26:38 <roman_g> Questions are asked by users, they will not be reading the code. Product (hopefully) is not supposed to be used only by developers, but by wider audience.
14:26:46 <sthussey> Treasuremap was defined as showing how Airship can deploy OSH
14:27:08 <mattmceuen> Yeah I agree... it would be good to have some library of examples somewhere too
14:27:53 <mattmceuen> This probably dovetails into the "service layers" idea too, where operators can pick from a library of configs and build their own infra adventure from premade parts
14:28:14 <mattmceuen> examples are nice, but reusable code is better
14:28:42 <b-str> I think service layers gets us to a "recommended pattern" perhaps too.
14:29:37 <roman_g> 1st most popular question is "Where is the GUI for the Airship? Do you may be have screenshots?". (partial answer is already added into airship-in-a-bottle repo)
14:30:08 <mattmceuen> lol roman_g
14:30:52 <mattmceuen> We have some new developers that just joined the Pegleg dev team -- maybe after some more ramp up they'd be able to help with service layers
14:30:53 <roman_g> mattmceuen: having at least graphical representation of other software deployed and managed with Airship would be a nice to have
14:31:04 <roman_g> not necessarily a repo with yaml code
14:31:07 <mattmceuen> If anyone is interested in collaborating with them on that please let us know
14:31:18 <roman_g> which eventually will become outdated/unsupported
14:32:22 <mattmceuen> roman_g y'know I wonder if helm itself has a good GUI chart out there or some such... might be a good thing to create some airship config for.  Would then demo two things at once (gui and arbirary chart deployment)
14:34:22 <roman_g> https://github.com/helm/monocular - on a screenshot looks like a generic application catalog.
14:35:15 <roman_g> not sure that it would be suitable
14:36:35 <mattmceuen> Looks like that's oriented more around discovering helm charts that can be deployed, rather than showing what's already deployed
14:36:46 <mattmceuen> But I'll take a look @ it - thx roman_g
14:36:59 <mattmceuen> alrighty, any other thoughts on this topic before we move on?  I have a couple action items for myself
14:37:41 <mattmceuen> #topic Airship Releases
14:37:51 <mattmceuen> I think we mentioned this before but
14:38:01 <mattmceuen> https://github.com/openstack/airship-treasuremap/releases
14:39:01 <mattmceuen> We are now tagging periodic releases of Treasuremap to signify stable builds of the Airship Release Candidate
14:39:21 <mattmceuen> We have one so far, and I think we'll probably have a new one soon
14:39:55 <mattmceuen> #topic Roundtable
14:39:56 <sthussey> Are these considered Airship releases?
14:40:03 <mattmceuen> oops sorry sthussey
14:40:17 <mattmceuen> They are considered 1.0 Release Candidates
14:40:42 <mattmceuen> So basically yes, but more along the lines of "stable, usable in production if you know what you're doing, pre-releases"
14:40:46 <sthussey> Okay. I didn't recall any community discussion on releasing or the release process
14:41:05 <sthussey> And we don't seem to have release notes to go with them
14:41:23 <mattmceuen> A lot of it was in the bi weekly airship / osf sync
14:41:37 <mattmceuen> will make sure that's tied into this forum better in the future
14:41:53 <portdirect> does someone take minutes at those?
14:42:02 <portdirect> simply linking to them would prob help
14:44:08 <mattmceuen> good catch portdirect
14:44:14 <mattmceuen> there is a gdoc
14:44:21 <mattmceuen> we can link that in
14:45:17 <mattmceuen> Any other discussion today, all?
14:45:30 <evrardjp> none
14:46:00 <b-str> Added an item to the etherpad about needing to assemble some release notes for 1.0
14:46:51 <b-str> More an action item/TODO I guess
14:47:04 <roman_g> can we utilize openstack reno for release notes? https://docs.openstack.org/reno/latest/
14:47:27 <sthussey> I believe we have a resource to do technical writing
14:47:44 <mark-burnett> Well, I think for 1.0 release notes you need to have something more thorough and general
14:47:44 <sthussey> We can speak with him about how he prefers to author release notes
14:48:03 <mark-burnett> Automated release notes are mediocre in my experience
14:48:45 <roman_g> they are manual. just the formatting is automated
14:48:59 <mattmceuen> I have no strong feelings around release notes beyond we should have them, we should make our lives as devs as easy as possible, and we shouldn't go overboard
14:49:27 <sthussey> I think we should review the overall software development ecosystem
14:49:37 <mattmceuen> ++
14:50:24 <mattmceuen> Is anyone passionate about release notes, such that they could find good examples out there / counterexamples and give us a readout in one of the upcoming meetings?
14:50:41 <mattmceuen> I should have phrased it "passionate about bragging on the awesome work we're doing" :)
14:51:37 <sthussey> Any tooling should be chosen based on best practice in the full open source development ecosystem
14:52:21 <evrardjp> reno is a very nice tool
14:52:50 <evrardjp> it makes it very easy to use, and therefore quickly gets out of the way to focus on your activities of dev.
14:52:51 <b-str> There's a video at the link above should be a nice intro for those that don't have any background with it.
14:53:07 <b-str> I know I'll be watching that video
14:53:30 <mattmceuen> Are there any solid alternatives to reno to consider, aside from hand-authoring?
14:53:38 <sthussey> I can take a look at other large successful projects
14:53:44 <mattmceuen> e.g. do other open source communities solve this problem differently?
14:53:44 <sthussey> And see how they are handled
14:53:53 <mattmceuen> awesome - thanks sthussey
14:53:55 <b-str> Anyway, just added the item because it's something we need to track through to completion for the 1.0 release.
14:54:04 <mattmceuen> yup
14:54:06 <evrardjp> sthussey: that's fair to see if those tools are matching the needs. Keep in mind this kind of reseach was also done by OpenStack group, so re-using kinda makes sense, but the times have changed, so feedback to OpenStack can also be useful
14:54:31 <sthussey> Then it should be an easy decision
14:55:02 <portdirect> and if not, we can feed back to the reno developers why not.
14:55:03 <evrardjp> Ansible, for example, decided to not use reno at some point, IIRC.
14:55:18 <mattmceuen> excellent, good point evrardjp.  In addition it's not just "the tool" but also "how you use it" -- I know any tooling for this stuff could be used well or poorly
14:56:18 <evrardjp> portdirect: reno's devs have been receptive in the past for different needs than openstack
14:56:29 <b-str> ok, I think we should probably have a "roadmap to 1.0" that includes this and other items needed too... make it super obvious.
14:56:51 <evrardjp> I recall different versioning schemes were used in a project, and reno was adapted to support it.
14:58:05 <mattmceuen> Any final thoughts before we wrap up, team?
14:58:18 <evrardjp> none
14:58:31 <mattmceuen> Good meeting - thank you all, & have a great week.
14:58:33 <mattmceuen> #endmeeting