15:00:34 <ian-pittwood> #startmeeting airship
15:00:35 <openstack> Meeting started Tue Feb 18 15:00:34 2020 UTC and is due to finish in 60 minutes.  The chair is ian-pittwood. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:36 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:38 <openstack> The meeting name has been set to 'airship'
15:00:54 <ian-pittwood> There we go, still learning the ropes. Hello, everyone!
15:01:26 <ian-pittwood> #topic rollcall
15:01:33 <mattmceuen> o/
15:01:43 <mattmceuen> GM ian-pittwood!
15:01:45 <ian-pittwood> Here's today's agenda https://etherpad.openstack.org/p/airship-meeting-2020-02-18
15:01:51 <dwalt> o/
15:02:06 <aaronsheffield> o/
15:02:11 <ian-pittwood> Looks pretty empty minus the review requests so please feel free to add anything for discussion today!
15:02:13 <michael-beaver> o/
15:02:38 <ian-pittwood> I'll wait a couple minutes and then we'll start
15:03:12 <souradage> o/
15:03:35 <nishantkr> o/
15:03:47 <alexanderhughes> o/
15:04:30 <ian-pittwood> Alright, let's get things started.
15:04:33 <ian-pittwood> #topic Reminder: core team nominations
15:04:34 <roman_g> o/
15:04:45 <ian-pittwood> Looks like this one is from mattmceuen
15:04:48 <jamesgu> o/
15:05:00 <mattmceuen> Hey, not a big one:
15:05:25 <mattmceuen> Just an occasional reminder around our core reviewer nomination process
15:06:00 <mattmceuen> We have a number of different corners of the airship community working on different things -- not exactly 1:1 with projects, but there are definitely different teams doing different things
15:06:44 <mattmceuen> an important responsibility of the core reviewers on a project to be aware of the status/health of the core reviewer team they're a part of
15:07:13 <mattmceuen> if the team doesn't have enough cores -- then please keep your eye out for potential cores and help groom them to readiness
15:07:43 <mattmceuen> if there's someone qualified and ready -- any member of that project's core team can nominate them on the mailing list
15:08:30 <ian-pittwood> What are the official rules again on voting for that? Do all the cores specific to that project need to approve or is it a certain percentage of cores?
15:08:32 <mattmceuen> if a core member has "moved on" and is no longer active in the community -- then there are some friendly conventions around proposing de-core-reviewering
15:09:41 <mattmceuen> I just double-checked our governance, and don't see anything formal written down (that's what I thought)
15:10:03 <mattmceuen> the convention is that there's a one-week period after the core nomination goes out (by an existing core)
15:10:13 <mattmceuen> and then at the end of the week, +1s / -1s are tallied up
15:11:01 <mattmceuen> the only other thing I have is a reminder of my personal guidelines for core reviewer selection -- two checkboxes in my mind:
15:11:39 <mattmceuen> 1. a history of meaningful reviews in the project (meaningful meaning of course, textual feedback that's helpful, as opposed to flyby +1s/-1s on the other end)
15:12:09 <mattmceuen> 2. meaningful, quality, non-trivial contributions to that project.  This person will help steer the project, so it's important they have a strong understanding of it!
15:12:54 <mattmceuen> There's no set number of cores for a team -- active projects benefit from a bit more; mature projects don't necessarily need as many
15:13:15 <mattmceuen> That's all I had on this - any questions/thoughts?
15:13:45 <roman_g> stackalitycs provides stats on voting, but lacks stats on comments
15:14:15 <roman_g> Stas if I'm not mistaken submitted a patch to count comments with +0 vote
15:14:23 <roman_g> Not yet merged, afaik.
15:14:33 <roman_g> Or me.. I don't remember )
15:14:37 <mattmceuen> Oh that's interesting - hadn't seen that one
15:14:38 <mattmceuen> :)
15:14:40 <ian-pittwood> I think the comments are a little too subjective for that kind of tracking, but I'm not opposed to more statistics
15:14:50 <roman_g> Anyway. Good way to see who is doing reviews at all.
15:14:55 <ian-pittwood> That's true
15:15:02 <pramchan> Does this refer to Airship 1.0 , 2.0, metal3.io, Ironic all or some select ones?
15:15:10 <roman_g> And then filter those who do meaningful reviews
15:15:14 <mattmceuen> The most important reason for the "current cores" on a project to nominate "new cores" is that they're the team that's already very familiar with someone's work
15:15:33 <roman_g> pramchan: Airship 1.0, 2.0
15:15:43 <pramchan> OK thx
15:15:45 <mattmceuen> so at that granularity, if you have to look them up in stackalytics, it's probably just to validate your existing gut check
15:16:01 <roman_g> True.
15:16:17 <ian-pittwood> Any further questions/comments for mattmceuen?
15:16:37 <pramchan> Is there any link to Treasuremap 2.0?
15:16:54 <pramchan> Are all docs submitted there in for 2.0?
15:17:17 <mattmceuen> https://opendev.org/airship/treasuremap/src/branch/v2
15:17:24 <pramchan> Thanks
15:17:53 <ian-pittwood> Alright we're going to move back into announcements since I see something there now
15:17:56 <mattmceuen> The goal is to get YAML manifests into the v2 branch of treasuremap (although we're cutting our teeth on the airshipctl project in that area)
15:18:03 <ian-pittwood> #topic 16GB RAM and 32GB RAM flavors are available for Airship 2.0 initiative (as of now only for jobs in airshipctl repo)
15:18:16 <mattmceuen> For documentation proper, it should be targeted to the airship/docs project for both 1.0 and 2.0 docs
15:18:30 <mattmceuen> (as a rule of thumb at least)
15:18:34 <ian-pittwood> mattmceuen this one is yours
15:18:45 <roman_g> mine.
15:18:50 <roman_g> it's just an announcement
15:18:57 <ian-pittwood> oh my gosh you're the same color on my etherpad
15:18:59 <ian-pittwood> my bad
15:19:11 <ian-pittwood> #link https://opendev.org/airship/airshipctl/src/branch/master/zuul.d/nodesets.yaml#L18-L44
15:19:20 <mattmceuen> hahaha that confused the heck out of me -- was like, it looks like I added it but sure don't remember
15:19:32 <ian-pittwood> Take it away roman_g
15:20:26 <roman_g> Well, just an announcement that we can now use this two new flavors and a new nodeset consisting of 1x32GB + 3x16GB RAM VMs. Hardware virtualization is enabled.
15:20:39 <portdirect> roman_g: are these only for airship jobs atm?
15:20:39 <mattmceuen> that's awesome
15:20:46 <roman_g> Kostiantyn Kalynovsky is informed (he is primary user, atm).
15:20:47 <portdirect> Or projects that ask nicely?
15:21:36 <roman_g> portdirect: no technical restriction to be used in other projects. But other projects don't really know this flavors exist.
15:21:47 <roman_g> portdirect: want to utilize for OSH? ;)
15:22:20 <portdirect> Yes
15:23:02 <roman_g> portdirect: technically you can. Ericsson agreed to share resources for all projects.
15:23:08 <mattmceuen> but you set yourself up portdirect, still need to ask nicely :p
15:23:19 <roman_g> I.e. practically you can, as well.
15:24:32 <ian-pittwood> Any more discussion on this announcement?
15:25:00 <roman_g> portdirect: also, running some other jos on this new nodesets would provide with early feedback in case something fails on provider's side
15:26:09 <ian-pittwood> Alright seems like we're good to move forward.
15:26:11 <mattmceuen> thanks for working with infra team to get us this, roman_g
15:26:20 <ian-pittwood> Yeah thank you
15:26:31 <ian-pittwood> #topic Lots of issues to peruse in https://github.com/airshipit/airshipctl/issues
15:26:37 <roman_g> You are most welcome.
15:26:42 <ian-pittwood> Now back to mattmceuen
15:26:59 <mattmceuen> oh yeah - this is even quicker
15:27:04 <ian-pittwood> #link https://github.com/airshipit/airshipctl/issues
15:27:37 <mattmceuen> as has been brought up a few times, dwalt, howell, Rodolfo, many other folks have been defining more scope in our github issue backlog
15:27:48 <mattmceuen> so just wanted to add a reminder so interested folks could take a look
15:27:54 <mattmceuen> that's all ian-pittwood
15:28:12 <ian-pittwood> Alright, cool.
15:28:28 <ian-pittwood> Nothing more on the agenda so let's move on to roundtable
15:28:32 <ian-pittwood> #topic roundtable
15:29:38 <dwalt> I have an item. With regards to Zuul jobs, do we have a preference for ansible modules or shell commands?
15:30:10 <ian-pittwood> The one benefit I think with shell commands is that they're generally usable for devs locally too
15:30:10 <alexanderhughes> Just a quick note about reviews request coming up. Airship development isn’t limited to just airshipctl. There’s plenty of metal3 issues I added to help get Prakash’s team more eyes on their patches
15:30:49 <dwalt> ian-pitwood: these aren't shell scripts, just in-line shell commands
15:31:01 <mattmceuen> Good call alexanderhughes, can you please drop a link to that backlog too?  Is it metal3 or some airship tracking backlog?
15:31:06 <dwalt> they are embedded since we are taking the approach that devs should be able to run our playbooks locally
15:31:34 <ian-pittwood> Do we have a couple examples dwalt? For the less Zuul savvy among us (me)
15:31:38 <pramchan> so you want me to add those #PRs to tomorrows meeting?
15:31:38 <dwalt> This particular playbook just publishes the airshipctl image to quay, so it wouldn't be used by developers. I'm mostly speaking about the most general case
15:32:31 <mattmceuen> One thing to factor in is, a lot of the ansible playbooks themselves are being designed for use on a dev machine, I believe, right?
15:32:32 <roman_g> dwalt: as long as we use it only for zuul - it doesn't matter. Once we try to reuse those playbooks for deployment & management (e.g. Ansible Tower or alternatives), then it makes sense to use native modules, as it usually provides with better idempotency.
15:32:38 <alexanderhughes> pramchan: they’re in today’s agenda. We can also discuss tomorrow if needed. In mean time can you link the backlog you’re working out of? Is it from old JIRA board or in github issues etc
15:32:58 <pramchan> OK like https://github.com/metal3-io/metal3-docs/pull/60
15:32:59 <roman_g> dwalt: in your particular pathc set - it's fine to use shell commands.
15:33:10 <roman_g> *patch set
15:33:21 <ian-pittwood> pramchan: I'll link all the review requests after this
15:33:46 <dwalt> portdirect: was your comment in reference to all playbooks, or just within the playbook I wrote?
15:34:20 <pramchan> I need some education on Jira to github transition, is it what Airship Blog shows or any other link I can use to undertsnad that?
15:35:09 <portdirect> dwalt: just that one, as I've not looked extensively through others
15:35:26 <portdirect> But in general it's best to stick to one approach or the other
15:35:54 <mattmceuen> for airshipctl in particular -- since it's already a straightforward CLI, I wonder if adding wrapper shell scripts would be overkill?
15:36:09 <portdirect> No
15:36:22 <mattmceuen> testing often goes in the shell scripts; that's valuable stuff we want to retain on one place or another
15:36:27 <portdirect> As it makes it much easier to consume outside of the playbook
15:36:45 <ian-pittwood> pramchan: most of the projects are just switching to GitHub Issues. for airshipctl the link is https://github.com/airshipit/airshipctl/issues
15:37:05 <ian-pittwood> most issues that looked active should be ported over already
15:37:39 <roman_g> https://review.opendev.org/#/c/707478/ patch set in question, shell vs. ansible native module
15:37:47 <mattmceuen> pramchan:  here's an intro guide to github issues in general: https://guides.github.com/features/issues/
15:37:58 <alexanderhughes> pramchan: we can discuss more at flight plan tomorrow, but for now all that’s been migrated is airshipctl linked in the blog. If there’s items getting worked out of JIRA still we need to discuss tomorrow and make sure they get migrated as well as story requirements may have changed.
15:38:26 <pramchan> So do  I need to add all Jira issues which I deal in to trasfer to link above?
15:39:05 <ian-pittwood> Personally, I'm fine with working through what's left in Jira and just not making any new issues in there
15:39:06 <pramchan> OK thaks appreciate that
15:39:16 <ian-pittwood> But I think it's something to bring up in flight plan as alexanderhughes said
15:39:28 <mattmceuen> ok I think we got off track
15:39:37 <mattmceuen> back to scripts vs ansibles:
15:39:48 <dwalt> Sorry, stepped away for a second. I can translate to the shell wrapper if that's appropriate for image publishing. This seems like a specialized procedure that we don't want devs to run, though
15:40:22 <dwalt> Another approach: it looks like the airship-images repo job has merged. We could genericize that and use it in airshipctl
15:40:23 <mattmceuen> I guess first thing, yeah Pete just to make sure I understand the context:  are you thinking in terms of e.g. tagging images for downstream build/consume?
15:40:30 <mattmceuen> portdirect^
15:40:33 <pramchan> Does Script iclude golang too or you just refer to shell?
15:40:42 <mattmceuen> just shell vs ansible
15:40:47 <portdirect> Oh man, you guys hate on the guy in a car ;)
15:40:48 <pramchan> ok
15:40:51 <mattmceuen> lol
15:41:02 <portdirect> But yes
15:41:08 <mattmceuen> that makes sense
15:41:16 <portdirect> We are installing multiple packages
15:41:26 <portdirect> Just to write out a tiny config file
15:41:31 <portdirect> Either template it
15:41:41 <portdirect> Or use docker cli to generate it
15:41:52 <portdirect> Or if you want to use docker module
15:41:59 <portdirect> Use that everywhere
15:42:23 <portdirect> Either is fine, its just a mix atm that gives us the worst of both worlds
15:42:23 <roman_g> which config file?
15:42:31 <portdirect> Docker auth file
15:42:35 <roman_g> ah
15:43:30 <portdirect> Make sense?
15:43:59 <roman_g> kinda. yes. for me.
15:44:03 <dwalt> Yep. Thanks for the explanation portdirect
15:44:06 <roman_g> Thanks.
15:44:07 <mattmceuen> sounds good to me
15:44:13 <ian-pittwood> Alright, anything else for roundtable?
15:44:16 <dwalt> Unless anyone is strongly opposed, Ill give the docker module a try for this specialized job
15:44:37 <ian-pittwood> +1
15:44:40 <roman_g> +1 to this
15:45:28 <ian-pittwood> #topic reviews
15:45:42 <ian-pittwood> #link https://review.opendev.org/#/c/690870
15:45:51 <ian-pittwood> #link https://github.com/digambar15/metal3-docs/commit/023b6eb772d20162bf0712e6debd27dcf92325fb
15:45:56 <ian-pittwood> #link https://github.com/metal3-io/metal3-docs/pull/64
15:46:01 <ian-pittwood> #link https://github.com/metal3-io/metal3-docs/pull/60
15:46:05 <ian-pittwood> #link https://github.com/metal3-io/metal3-docs/pull/63
15:46:13 <ian-pittwood> #link https://github.com/metal3-io/metal3-docs/pull/66
15:46:17 <openstackgerrit> Sirajudeen proposed airship/airshipctl master: [#22-WIP] - use table test for set context tests  https://review.opendev.org/707768
15:46:20 <ian-pittwood> #link https://github.com/metal3-io/baremetal-operator/pull/407
15:46:26 <ian-pittwood> #link https://github.com/metal3-io/baremetal-operator/issues/351
15:46:31 <ian-pittwood> #link https://github.com/metal3-io/baremetal-operator/pull/292
15:46:44 <ian-pittwood> Alright I believe that's the list
15:47:10 <ian-pittwood> There's further details in the agenda for each of these links
15:47:43 <ian-pittwood> Does anyone have any other review requests or any last minute topics?
15:49:20 <ian-pittwood> Ok, well with that I think we're all done here. Thanks for your time, everyone!
15:49:27 <ian-pittwood> #endmeeting