16:00:29 <mattmceuen> #startmeeting airship
16:00:34 <openstack> Meeting started Tue Apr 23 16:00:29 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:35 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:39 <mattmceuen> #topic Rollcall
16:00:39 <openstack> The meeting name has been set to 'airship'
16:00:51 <mattmceuen> Hello, everyone - welcome
16:00:53 <aaronsheffield> o/
16:00:56 <mattmceuen> https://etherpad.openstack.org/p/airship-meeting-2019-04-23
16:00:57 <evgenyl> Hello!
16:00:58 <arunkant> o/
16:01:01 <mattmceuen> ^ agenda above
16:01:06 <AlexanderHughes> o/
16:01:10 <dwalt> hi all o/
16:01:20 <mattmceuen> We have a full agenda today so I'll try to keep us on the tracks :)
16:01:50 <mattmceuen> #topic No meeting next week
16:01:58 <mattmceuen> I think this is self explanatory :)
16:02:13 <mattmceuen> due to the summit
16:02:17 <michael-beaver> o/ GM
16:02:23 <mattmceuen> #topic Update on gerrit migration
16:02:52 <mattmceuen> We have our shiny new opendev infrastructure up and running now thanks to the hard work of the openstack infra team
16:03:00 <mattmceuen> To make sure everyone's aware of the changes:
16:03:07 <mattmceuen> https://opendev.org/airship/
16:03:22 <sthussey> opendev infra team*
16:03:25 <mattmceuen> ^ this is our git repository now, and it has https redirects set up
16:03:34 <mattmceuen> TY Scott
16:03:52 <mattmceuen> Note that previously we'd had an openstack git repo, which mirrored out to github
16:04:05 <mattmceuen> Now we are using the gitea open source project to host both functions
16:04:17 <mattmceuen> So if the link above looks like github - that's intentional
16:04:35 <mattmceuen> Notice also we are in the /airship project namespace rather than /openstack now
16:04:53 <mattmceuen> And therefore the project names themselves have lost the 'airship-' prefix
16:05:03 <mattmceuen> e.g. https://opendev.org/airship/promenade
16:05:07 <mattmceuen> So that's great
16:05:24 <mattmceuen> Similarly, our gerrit is now https://review.opendev.org/
16:05:41 <mattmceuen> All patchsets from the old gerrit have been migrated over
16:06:10 <mattmceuen> dwalt points out that:     gerritbot no longer posting new changes in IRC https://review.opendev.org/654470
16:06:23 <dwalt> woops -- forgot to remove that, sorry
16:06:32 <dwalt> that has merged since yesterday :)
16:06:33 <mattmceuen> However that appears to be merged so I think we're good :)  thanks dwalt
16:06:38 <dwalt> np!
16:06:54 <mattmceuen> There are a couple more items related to the migration, but they have their own topics later in the agend
16:07:06 <mattmceuen> any questions / thoughts on the migration?
16:07:57 <michael-beaver> airship/in-a-bottle probably needs to be changed right?
16:07:58 <hogepodge> yes
16:08:12 <mattmceuen> Yep sthussey has an item for that michael-beaver
16:08:20 <michael-beaver> Oh sorry I missed that
16:08:29 <hogepodge> For the airship-in-a-bottle rename, the infra team has asked that you follow this procedure. https://docs.openstack.org/infra/manual/creators.html#project-renames
16:08:30 <mattmceuen> Let's hold off on that one till later, there are two parts to it
16:08:52 <mattmceuen> Yup I chatted with clarkb this a.m. and he got me set up with the needful steps - I'm planning to get them in this week
16:09:47 <mattmceuen> It'll probably take a week or two to get the update made, but I think that's probably fine thanks to
16:09:47 <mattmceuen> 1) https:// redirects
16:09:47 <mattmceuen> 2) let's just make sure the wiki and airshipit.org point to the correct place and keep those things up to date
16:09:48 <kaspars__> airship-in-a-bottle I think is really close with new airsloop type to be migrated to treasuremap.. just a thought
16:10:01 <mattmceuen> lol that's the other 1/2 of sthussey's agenda item
16:10:12 <mattmceuen> We have effectively moved the item - let's finish it up
16:10:29 <mattmceuen> Do we want to keep airship-in-a-bottle as a separate project?
16:10:57 <mattmceuen> It's two different things -- a site definition (a couple of 'em) and some easy-to-use demo deployment tooling
16:11:36 <evgenyl> I think Dimitrious started doing some work on that, but I'm not sure if he is here.
16:11:47 <dwalt> I can't think of any benefits to maintaining it as a separate project. In fact, it seems like it diverges further from treasuremap every week.
16:11:55 <michael-beaver> ++
16:12:02 <kaspars__> https://review.opendev.org/#/c/654548/
16:12:05 <sthussey> So we'll need to determine path forward
16:12:38 <sthussey> That repo was originally built as an integration repo, which we still need
16:12:58 <kaspars__> I also think having it in the same repo would simplify things
16:13:05 <sthussey> There is documentation there that is now likely stale
16:13:12 <kaspars__> I feel that all that treasuremap is is basically integration..
16:13:37 <mattmceuen> If we want to move the aiab deployment tooling into treasuremap, we can put it in `/tools/deployment/airship-in-a-bottle`
16:13:40 <dwalt> Along a similar vein, moving repositories would also be a good opportunity to clean-up the multinode "gate" and make it more visible
16:13:40 <mattmceuen> or some such
16:14:06 <sthussey> The site definitions and tooling going to treasuremap is fine
16:14:07 <evgenyl> We will also need to move multinode deployment.
16:14:09 <dwalt> I like that idea mattmceuen
16:14:25 <mattmceuen> kaspars__, are you targeting the existing multinode virtualized testing using the sloop type, or something else?
16:14:25 <sthussey> The developer documentation can move, but that changes the intent of treasuremap
16:15:35 <kaspars__> sloop may be too slim for gate-multinode - so I'm not 100% sure
16:15:50 <mattmceuen> Ok.  So we have a few things we'll need to figure out
16:15:55 <kaspars__> definitely we can have AIAB to use sloop
16:16:03 <kaspars__> that would fit perfect
16:16:47 <kaspars__> "A sloop (from Dutch sloep, in turn from French chaloupe) is a sailing boat with a single mast and a fore-and-aft rig. A sloop has only one head-sail; if a vessel has two or more head-sails, the term cutter is used, and its mast may be set further aft than on a sloop. "
16:16:51 <kaspars__> for people that wonder..
16:17:31 <mattmceuen> 1) figure how to best migrate gate-multinode tooling/site def into treasuremap
16:17:31 <mattmceuen> 2) do the work of moving aiab into treasuremap
16:17:31 <mattmceuen> 3) determine what we want to do with documentation (consolidate somewhere please)
16:17:31 <mattmceuen> 4) retire aiab project
16:18:09 <mattmceuen> We should hold off on #4 (retire aiab project) until after it's fully migrated into treasuremap
16:18:41 <mattmceuen> With that in mind - I think I'll still go forward with requesting the project rename back to airship/airship-in-a-bottle for the migration period
16:19:35 <evgenyl> Yes, it will take some time to get the migration finished, so it may be a good idea to rename it.
16:19:36 <mattmceuen> I've added another agenda item for doc consolidation
16:19:44 <mattmceuen> Not sure if we'll be able to round it out today
16:20:01 <mattmceuen> Cool.  Are we good with that general approach, all?
16:20:01 <sthussey> As part of some improvements on build pipelines, we'll be updating the Airship coding standard doc there
16:20:36 <michael-beaver> I'm already working on creating multinode developer documentation, I wouldn't mind also taking on moving the multinode setup into treasuremap. Not sure if we wanted to wait until after the summit or not to do that though
16:20:52 <mattmceuen> Good question
16:21:00 <mattmceuen> Let's see how the week goes michael-beaver
16:21:06 <sthussey> First step to that is merging all the in-flight CS
16:21:15 <mattmceuen> yes good point
16:21:56 <michael-beaver> Sorry just reconnected and that just went through
16:21:58 <mattmceuen> also thanks for volunteering for that michael-beaver -- evgenyl maybe you guys can sort some of that out in the chat room since it'll be a couple weeks till the next team meeting
16:22:12 <mattmceuen> Ok!  Moving on:
16:22:16 <mattmceuen> #topic Mutli-OS image support
16:22:23 <mattmceuen> I think this one is yours sthussey
16:22:33 <mattmceuen> https://review.opendev.org/643106
16:23:10 <sthussey> yes
16:23:21 <sthussey> so we have a spec out there to support Multi-OS based docker images
16:23:36 <sthussey> I propose an amendment there to support some build pipeline rationalization
16:24:03 <sthussey> basically what I propose is moving all the multi-OS stuff to an airship-base image that each airship component would build from
16:24:49 <sthussey> airship-base would be built from your OS-base of choice and include a helper script that basically allows the Airship components to install OS packages without having any idea what OS base is beneath them
16:24:56 <sthussey> I looked at bindep, it doesn't seem to achieve this
16:25:49 <sthussey> airship-base would also include steps to allow someone to customize where the image build is sourcing external dependencies such as Python packages or OS packages
16:26:13 <mattmceuen> gotcha
16:27:10 <mattmceuen> Sounds reasonable to me.   I am not an image build SME, hogepodge or portdirect, does that sound like a good plan to you too?
16:27:44 <mattmceuen> I know you guys have done a lot to facilitate complex image builds in loci as well
16:28:03 <hogepodge> The more you can abstract those layers the better
16:28:21 <mattmceuen> roman_g, arunkant, jamesgu__ -- sound good from your perspective too?
16:28:26 <hogepodge> things always sneak in, as every packaging system treats common things differently.
16:28:29 <openstackgerrit> Merged airship/deckhand master: CI: Update OSH relative paths for OpenDev  https://review.opendev.org/654604
16:28:42 <arunkant> sthussey: Right now, each airship project has image build support. How's base image different from what we have in Dockerfile FROM ?
16:29:16 <sthussey> It isn't
16:29:23 <sthussey> but deckhand is missing that
16:29:24 <hogepodge> httpd is a prime example, the abstraction layer needs to provide interfaces for configuring things like httpd/apache that have totally different installation and management layouts
16:30:09 <sthussey> I'm not really worried about a general solution
16:30:25 <sthussey> As far as I know none of Airship does any of that today
16:30:31 <arunkant> yes and package names are different in distro . So not sure what base image will have additionally other than what we have in FROM
16:31:07 <sthussey> the point of the helper script
16:31:27 <sthussey> We'll define some meta-packages that airship components can request, the helper script will sort out what underlying OS packages will fulfill that
16:31:33 <hogepodge> I guess I'm saying it's a good idea, and it works best if you have the discipline to always push those abstractions to the base rather than build in OS specific stuff in the higher level components
16:32:15 <mattmceuen> I like this idea, but am concerned that it would hold up the multi-os work.  Can we plan for a migration path toward that?
16:32:45 <sthussey> I prefer this path to implement the multi-os work
16:32:55 <sthussey> because now the multi-os work impacts a single image, not 8
16:34:23 <sthussey> If it isn't a candidate for upstream, that's fine. We can implement it locally downstream.
16:34:38 <arunkant> Right now we have distro specific docker file (in proposed reviews) and it abstracts the distro details ( package names, expected path, permission etc) in single place.
16:35:22 <mattmceuen> arunkant, I know work has been progressing on the multi-os implementation.  How "close" do you feel that work is
16:35:32 <arunkant> May be I am not following what value add helper script are adding..
16:35:56 <mattmceuen> I think a spec will help to clarify - could we get some details down in a spec sthussey?
16:36:10 <arunkant> mattmceuen: We are waiting for spec update and approval and reviews are already following that spec recommendation
16:36:13 <mattmceuen> I guess it would be an alternative or patch on top of the current spec
16:36:54 <sthussey> I can do a CS on the current spec
16:37:49 <mattmceuen> Yes arunkant - since you've already done the work there, I would propose we
16:37:49 <mattmceuen> 1) go ahead with the current plan, with multiple dockerfiles
16:37:49 <mattmceuen> 2) work through the details of sthussey's idea in a spec
16:37:49 <mattmceuen> 3) refactor all multi-os support for the outcome of #2 after that
16:38:16 <mattmceuen> Mainly, I just don't want to hold up work in progress for a new approach if we can migrate to that new approach after it's fleshed out
16:38:26 <arunkant> sounds like a plan +1 .
16:38:40 <mattmceuen> Are you ok with that sthussey?
16:38:58 <sthussey> Yeah, we can do it downstream in the meantime. Move it upstream if desired.
16:39:33 <arunkant> mattmceun: Any idea when update on spec can be made as there are some update needed based on comments
16:40:10 <mattmceuen> Alright, sounds like a plan.  Could also do it in att-comdev or some such as a "POC" for the approach as could be incorporated into airship proper
16:40:23 <arunkant> mattmceuen: If roman_g is not available, I can make the update in spec
16:40:54 <mattmceuen> ah right - that update
16:41:13 <mattmceuen> roman_g are you ok with arunkant pushing an update to the patchset?
16:41:38 <mattmceuen> It's a small change and he has it well sorted out
16:42:25 <mattmceuen> let's keep going - roman_g may be afk.  We'll confirm with him when he's back.
16:42:42 <mattmceuen> #topic Google Season of Docs
16:43:17 <mattmceuen> Just an FYI that some of the ideas from the team for Google Season of Docs have been fleshed out here: https://wiki.openstack.org/wiki/Airship/2019-SoD
16:43:59 <mattmceuen> hogepodge and I have been working the details out and Airship should be on the application list before the 3pm central deadline :)
16:44:01 <hogepodge> I'm filling out the application for it right now
16:44:21 <mattmceuen> nice!  Thanks hogepodge, let me know if there's anything I can do to help
16:44:38 <mattmceuen> #topic Now that we have OpenDev, do we additionally still want github mirroring?
16:44:59 <evgenyl> Yes, I really like using hotkeys on GitHub...
16:45:04 <mattmceuen> So - github mirroring is now turned off, so I think our github mirrors will quickly become stale
16:45:04 <evgenyl> Gitea does not have any https://github.com/go-gitea/gitea/issues/5796
16:45:48 <mattmceuen> If we really want to maintain github mirroring, I think I saw that there's a request process we can go through
16:46:04 <mattmceuen> Me personally, I'm ok with just opendev.   But understand others may care more
16:46:10 <dwalt> I would like to see GitHub mirroring for the additional visibility
16:46:11 <kaspars__> for now, I've been quite OK with looking at the code there.. so no strong view from me
16:46:13 <evgenyl> Also I like to run searches for all repos in the organization, which does not seem to be available for gitea.
16:46:56 <mattmceuen> #action mattmceuen figure out process for requesting github mirroring
16:47:22 <mattmceuen> There will probably be things we need to figure out, e.g. since airship is not part of the openstack namespace anymore we might need to live in a new home on github - will see
16:47:29 <evgenyl> But we should make sure that we don't use github links in the docs :)
16:47:36 <dwalt> ++
16:47:37 <mattmceuen> ++
16:47:42 <ian-pittwood> +1
16:47:54 <mattmceuen> ok, trucking along:
16:47:59 <mattmceuen> #topic New project creation request:  spyglass plugin for XLS
16:48:16 <mattmceuen> AlexanderHughes I think this is yours
16:48:24 <ian-pittwood> This one is me actually I think
16:48:33 <mattmceuen> oops!  sorry ian-pittwood
16:48:48 <mattmceuen> Last week we'd discussed splitting out spyglass plugins into their own projects
16:49:09 <mattmceuen> But we didn't officially agree on the 1st plugin project name, and I think it would be good to nail down a convention
16:49:15 <ian-pittwood> I'm working on separating out the plugins from Spyglass as there was a proprietary plugin that made it's way in there. I was thinking we could make a new plugin for the open source plugin
16:49:34 <mattmceuen> airship/spyglass-plugin-tugboat   <- ian's proposal
16:49:34 <ian-pittwood> Yeah there's the spreadsheet plugin currently called Tugboat
16:49:45 <sthussey> why would this go in an individual repo?
16:49:58 <sthussey> You could split the plugin out of the python package w/o proliferating repos
16:50:12 <ian-pittwood> That seemed to be the direction we decided on last week, but I am open to other ideas
16:51:09 <sthussey> Okay, I probably missed that.
16:51:20 <sthussey> this project does love to grow the repo count
16:51:40 <mattmceuen> I'm not quite as concerned about project proliferation as I used to be, now that we have an /airship namespace.  Split out plugin projects was where some of the openstack projects have landed after going back and forth
16:51:48 <mattmceuen> But I don't have a really strong opinion either
16:52:11 <ian-pittwood> Creating a plugin repo just sort of matched some other repos I looked at
16:52:31 <ian-pittwood> But there were also others that kept plugins all within the same repo so either way
16:52:32 <openstackgerrit> Kaspars Skels proposed airship/maas master: Support for MAAS URL overrides  https://review.opendev.org/653853
16:52:45 <ian-pittwood> I would just need to adjust my course a little bit depending on what we decide is best
16:52:47 <sthussey> I'm a mono-repo proponent which isn't popular in openstack
16:53:20 <openstackgerrit> Lev Morgan proposed airship/pegleg master: Added cleartext option to passphrase generation  https://review.opendev.org/645017
16:53:25 <ian-pittwood> With Spyglass, it's likely that end users would create their own plugins for data extraction
16:53:37 <sthussey> but wasn't aware this was already litigated
16:53:39 <ian-pittwood> That's why I thought that maybe it would be a good idea to keep them all separate
16:53:47 <sthussey> so I'll just remove my opinion from the conversation
16:54:36 <mattmceuen> so tugboat is an xls-based plugin, right ian - are there other generic kinds of plugins that are expected?
16:55:16 <mattmceuen> In any case, we need to be able to support external plugins, whether or not the "default" plugin is bundled with spyglass project itself
16:55:23 <ian-pittwood> I imagine more would be made down the road. Input data could come from anywhere
16:55:28 <ian-pittwood> Exactly
16:56:02 <mattmceuen> ian-pittwood - if you're doing the work, what approach do you prefer :)
16:56:17 <openstackgerrit> Arijit Bose proposed airship/in-a-bottle master: [site update] update software  https://review.opendev.org/655197
16:56:23 <ian-pittwood> I guess for now I would try separate repos then
16:56:31 <mattmceuen> ok
16:56:43 <mattmceuen> for airship/spyglass-plugin-tugboat
16:56:52 <mattmceuen> My only concern is that it's not obvious that it's an xls plugin
16:57:05 <mattmceuen> what about airship/spyglass-plugin-xls?
16:57:14 <ian-pittwood> A name change isn't that big a deal for me
16:57:18 <ian-pittwood> Sure, that works
16:57:29 <mattmceuen> For an example plugin, I think it's important to make it clear what it's doing is all
16:58:05 <mattmceuen> Cool - then we'll go forward with submitting that project creation request unless anyone objects
16:58:27 <mattmceuen> ian-pittwood:  if you can put in the request and then add me as a reviewer that would be awesome :)
16:58:58 <ian-pittwood> Sure, thank you
16:59:00 <mattmceuen> #topic Roundtable
16:59:01 <hogepodge> can I jump in for the last couple of minutes for some summit questions?
16:59:10 <mattmceuen> #topic hogepodge roundtable
16:59:13 <mattmceuen> go for it!
16:59:29 <hogepodge> I need to get a list of names of folks who will be at the board meeting and joint leadership meeting representing airship
16:59:55 <mattmceuen> board meeting:  Matt McEuen, Kaspars Skels, Jay Ahn
17:00:04 <mattmceuen> are the ones I'm aware of
17:00:09 <hogepodge> Also, if you're a non-ATT person who wants to be identified as a leader for Airship within your company I also need your name so we can identify you on your badge.
17:00:47 <mattmceuen> Kaspars is the leader from Ericsson, Jay is the leader from SKT
17:01:12 <mattmceuen> Joint Leadership Meeting - sorry, when is that one?  Diff from the board update?
17:01:52 <mattmceuen> we're out of time but can continue here in the room if that's ok hogepodge
17:01:55 <jamesgu__> hogepodge... what is the joint ledership meeting?   From suse side, Dirk Mueller and/or myself can attend?
17:02:24 <mattmceuen> Sorry we ran out, all - will copy the remaining agenda items to the next agenda
17:02:35 <mattmceuen> #endmeeting