16:00:13 <mattmceuen> #startmeeting airship
16:00:18 <mattmceuen> #topic Rollcall
16:00:19 <openstack> Meeting started Tue Mar 26 16:00:13 2019 UTC and is due to finish in 60 minutes.  The chair is mattmceuen. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:20 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:22 <openstack> The meeting name has been set to 'airship'
16:00:23 <mattmceuen> Hey GM everybody
16:00:31 <dwalt> o/ GM!
16:00:35 <michael-beaver> o/ GM
16:00:36 <mattmceuen> Here's our agenda for today: https://etherpad.openstack.org/p/airship-meeting-2019-03-26
16:00:41 <Nishant_> o/
16:00:53 <mattmceuen> please add anythingthing you'd like to discuss, as we wait for folks to join
16:00:56 <evgenyl> Hi everyone!
16:02:17 <mattmceuen> Alright, let's get started
16:02:25 <mattmceuen> #topic Chart document naming and labelling conventions
16:02:50 <levmorgan> o/
16:03:14 <mattmceuen> deckhand allows us to have multiple layers (global, type, site) of documents, and is very flexible in how you approach naming and labelling docs
16:03:35 <openstackgerrit> Luna Das proposed openstack/airship-promenade master: Add init container to load custom apparmor profile for kube-proxy  https://review.openstack.org/647749
16:03:52 <mattmceuen> I think it would be good to come up with a *convention* for how we approach parent-child document naming and labelling, and then apply that convention across treasuremap
16:04:03 <mattmceuen> as we have a few different conventions that have grown organically
16:04:32 <mattmceuen> First point:  what should the documents themselves be named
16:05:03 <mattmceuen> If we have a document `foo` defined at the global level, I've seen it named either `foo` or `foo-global`
16:06:07 <mattmceuen> I'd suggest we just call it `foo` and then
16:06:07 <mattmceuen> 1) use labels to designate it as global
16:06:07 <mattmceuen> 2) when re replace at a child level, just retain the same name e.g. `foo`
16:06:07 <mattmceuen> 3) when we layer without replacement at a child level, give the result a derivitive name
16:06:39 <mattmceuen> This convention would keep the focus in the "name" on the intent of the content, rather than "where it comes from"
16:06:47 <mattmceuen> What do y'all think
16:07:06 <dwalt> When using labels to designate the document as global, are we talking about appending global to the document name label, or adding a separate label?
16:07:11 <dwalt> Currently, I think we do the former
16:07:14 <evgenyl> Hmm, e.g. if I have `keystone` what would be a name for the override? `keystone-seaworthy`?
16:07:41 <mattmceuen> dwalt:  yep, we could give it a label of `name: foo-global` which seems to be the most common convention
16:07:56 <mattmceuen> evgenyl:  yep I think something like that makes sense
16:08:08 <mattmceuen> `keystone-<type or site name>`
16:08:24 * dwalt Does anyone like the idea of moving that convention to something like:
16:08:53 <dwalt> Sorry for emote
16:08:58 <dwalt> labels:
16:08:58 <dwalt> name: keystone
16:08:58 <dwalt> layer: global
16:09:10 <dwalt> That way, the name label is consistent with the document name
16:09:31 <mattmceuen> that is indeed Point #2 to figure out!  I don't have strong opinions but have seen both ways :)
16:09:59 <dwalt> Sorry for skipping ahead :)
16:10:31 <mattmceuen> No worries, I'm hoping that means we're just aligned on #1; speak now or forever hold your peace on doc names just being `foo` or `keystone` etc
16:10:39 <Nishant_> I like #1 i.e.  global: keystone-global;  type: keystone-type;  site: keystone-site
16:10:53 <dwalt> ++
16:14:26 <mattmceuen> I am leaning toward that too
16:15:21 <evgenyl> Is the suggestion to have `name: keystone-global` label for globals and use different postfixes for different layers?
16:15:40 <Nishant_> Yes, that's what I understand
16:15:51 <evgenyl> And without having `name: keystone` labels at all?
16:16:40 <evgenyl> I like it because it is so much easier to grep and understand what the child exactly overrides :)
16:17:43 <mattmceuen> Agree
16:17:52 <mattmceuen> May require revisiting when we implement service layers
16:17:55 <openstackgerrit> Luna Das proposed openstack/airship-promenade master: Add init container to load custom apparmor profile for kube-proxy  https://review.openstack.org/647749
16:18:02 * mattmceuen mythical service layers
16:18:25 <mattmceuen> Ok awesome -- I think we're ready for Point #3 to sort out
16:18:54 <mattmceuen> Should our default position be to insert labels into documents, so that there is always a hook there for documents to override them at the type or site level?
16:19:12 <mattmceuen> Or, should we only add labels into a document if and when we decide it should be overridden?
16:20:22 <evgenyl> I would consider always adding the labels for the documents, it may help to reduce the amount of forks.
16:20:31 <Nishant_> With this I am leaning towards the former
16:20:40 <dwalt> I personally like always having them available to reduce the amounts of extra commits/work when adding new site documents
16:20:40 <mattmceuen> My opinion is - let's define labels at the global / type level in general.  Otherwise, as more folks use treasuremap as a reference for their own sites, we'd be restricting the ways they could extend things
16:20:48 <mattmceuen> I think we all agree!
16:20:57 <michaelbeaver> ++
16:21:06 <mattmceuen> I think we can leave them out at the site level, since they wouldn't be used for anything
16:21:30 <evgenyl> ++ only for globals and types
16:21:46 <mattmceuen> Those are all the convention-y things I wanted to sort out; am I forgetting any other things we should sort out while we're discussing this?
16:22:20 <dwalt> I think we hit it all
16:22:30 <mattmceuen> dwalt had put together a user story for this:  https://storyboard.openstack.org/#!/story/2004354
16:22:57 <mattmceuen> dwalt could you please summarize the results of this discussion in that story?  Then we could update the treasuremap peggles accordingly as part of that story
16:23:34 <dwalt> #action dwalt update treasuremap labels convention story
16:23:36 <dwalt> will do!
16:23:38 <mattmceuen> thanks!
16:23:45 <mattmceuen> alright, moving on:
16:23:52 <mattmceuen> #topic Season of Docs
16:24:14 <mattmceuen> last week, roman_g had brought up that google has a new "season of docs" program that takes after their "summer of code" program
16:24:19 <mattmceuen> I looked into this a bit
16:24:52 <mattmceuen> It's a way for a technical doc writer to get extra experience for their resume while also helping an open source project
16:25:28 <mattmceuen> OSS organizations that are interested have to apply by April 23rd, and then there's a selection process for both orgs and for individual writers
16:25:47 <mattmceuen> Then the program itself takes place in the Fall IIRC
16:26:01 <mattmceuen> I think this is a great idea, and there's no harm in trying for it
16:26:07 <evgenyl> Docs is always something that we need help with :)
16:26:30 <mattmceuen> For our application, we'd need a selection of potential projects for the technical document writer to do - we can't wait till the Fall to come up with work :)
16:26:46 <mattmceuen> And I think compelling projects would give a better chance of being selected
16:27:01 <mattmceuen> So, keeping in mind that this will be in the Fall (i.e. post-1.0)
16:27:20 <mattmceuen> Let's brainstorm some ideas for document authoring
16:27:48 <evgenyl> We need more user-facing docs, and better organization/referencing of all the projects that we use.
16:27:57 <dwalt> I think we need more integration diagrams
16:28:18 <dwalt> especially in the individual components. For example, how Armada uses tiller
16:29:15 <mattmceuen> Oh my - know what, we're going to be moving toward the k8s cluster API in the future, which would require user-facing docs and diagrams
16:29:30 <mattmceuen> Would be great to be ahead of the curve from a documentation perspective on that, rather than behind the curve
16:29:46 <mattmceuen> and I bet things related to the k8s cluster API would be favorable to google :)
16:31:07 <mattmceuen> evgenyl and kaspars are planning on creating some new "getting started" stripped down reference yamls for bare metal.  I bet a good guide walking people through that would be valuable?
16:31:22 <evgenyl> mattmceuen: Do you want to have some generic k8s cluster api docs? Or something airship related?
16:31:49 <mattmceuen> def something airship related -- i.e. how airship will integrate with cluster api, how to configure it, etc
16:32:11 <mattmceuen> side note - if anyone wants to discuss airship-cluster api integration, come to Rodolfo's call on Thursday :)
16:32:54 <mattmceuen> I will take some notes based on the above, in the agenda
16:33:08 <dwalt> Sorry if it has already been said, but how long does the program last?
16:33:13 <mattmceuen> Let's think about this some more, and then revisit next week, since we have a little runway
16:33:24 <mattmceuen> https://developers.google.com/season-of-docs/docs/timeline
16:33:50 <mattmceuen> the actual meat of the program is Sept 2 - Nov 22
16:34:22 <dwalt> cool, just wanted to understand how much time there is for ramping-up. Thx mattmceuen
16:34:40 <mattmceuen> hey hogepodge - will want to sync up with you on this at some point too; it looks to me like it would be most appropriate for the Foundation to formally submit the application, so we should make sure there are no gotchas with that
16:35:24 <mattmceuen> Anything else on the doc front to discuss?
16:35:58 <mattmceuen> dwalt, michael-beaver, and I divvied up a lot of the dev guide user story tasks; I've been looking for some time to get started on that
16:36:03 <mattmceuen> #topic roundtable
16:36:35 <evgenyl> Just a small announcement, we got fixed AIAB https://review.openstack.org/#/c/644634/
16:36:53 <dwalt> mattmceuen: thanks! I've made some good progress, just holding off for the template before I push
16:36:55 <evgenyl> So gates should be green now, unless there are some problems with the infra (which have a lot recently)
16:37:32 <dwalt> evgenyl: that's great!
16:37:43 <evgenyl> So before merging something to AIAB, check the comments if there are failures related to AIAB deployment.
16:38:06 <evgenyl> And multinode gate is still failing, so we need help from somebody to take a look into that.
16:38:11 <dwalt> evgenyl: will do. Is there anything we can do to have the results published near Zuul? Or does it need to be a gate
16:38:31 <dwalt> I have seen other third party CIs do so on other OpenStack projects, not sure if it's feasible
16:39:11 <mattmceuen> evgenyl:  that's awesome!  thanks for your work on getting AIAB back up and running :)
16:40:11 <evgenyl> dwalt: We can definitely look into that, any help would be appreciated, there are quite a few problems with Jenkins stability :(
16:41:19 <openstackgerrit> Ahmad Mahmoudi proposed openstack/airship-maas master: [FIX] - Fixed maas-rack reschedule issue  https://review.openstack.org/642174
16:41:20 <evgenyl> That is it from me for roundtable.
16:41:22 <dwalt> evgenyl: I'll look into it. Would it be better to leave it toggle-able in the meantime?
16:41:42 <mattmceuen> It would be great if we could get the results published in a non-voting way back up to the green/red CI section at the top of the PS.  Hopefully that isn't a big effort, but I haven't done it before
16:42:30 <dwalt> #action dwalt explore publishing AT&T CI results in PS tables
16:42:37 <mattmceuen> ty dwalt
16:42:40 <dwalt> sure thing
16:42:48 <mattmceuen> any other roundtable topics to discuss today?
16:43:06 <mattmceuen> In that case - great meeting, thanks everyone for joining
16:43:12 <mattmceuen> Have a great week.
16:43:15 <mattmceuen> #endmeeting