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