14:00:12 <mattmceuen> #startmeeting airship
14:00:13 <openstack> Meeting started Tue Sep 17 14:00:12 2019 UTC and is due to finish in 60 minutes.  The chair is mattmceuen. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:14 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:15 <mattmceuen> #topic Rollcall
14:00:17 <openstack> The meeting name has been set to 'airship'
14:00:19 <mattmceuen> o/ everyone!
14:00:22 <nishantkr> o/
14:00:24 <ian-pittwood> o/
14:00:26 <aaronsheffield> o/
14:00:28 <DanCrank> o/
14:00:36 <howell> o/
14:00:42 <mattmceuen> Let's give it a couple minutes; I know the design call was stretching over so folks may trickle in
14:01:06 <mattmceuen> Here's the agenda for today, feel free to add anything you'd like to discuss (or any patchsets needing review): https://etherpad.openstack.org/p/airship-meeting-2019-09-17
14:01:15 <michael-beaver> o/ GM
14:01:49 <alexanderhughes> o/
14:02:07 <mattmceuen> Ok, let's get started:
14:02:11 <mattmceuen> #topic Email on ML: participation at Kubecon and MWC?
14:02:26 <mattmceuen> Just wanted to call this out for the email-challenged folks like myself :)
14:02:52 <khiyani> GM
14:03:05 <mattmceuen> At the last airship TC meeting there was discussion around potentially making some airship gatherings at either the upcoming Kubecon or the Mobile World Congress in the spring
14:03:43 <mattmceuen> To help with that - the email was sent out to try to gauge potential participation; if you have an idea that you might or might not be able/interested in attending those - please reply on the mailing list
14:04:15 <mattmceuen> That's all I wanted to bring up for that as it's already out on the ML for discussion.  Any other questions though?
14:04:31 <alexanderhughes> a poll might be an easier way to aggregate results.  break it down into a few categories: interested, going, not interested etc.
14:05:29 <mattmceuen> Yeah maybe so
14:06:02 <mattmceuen> However was also interested in "soft" answers and Q&A
14:06:36 <mattmceuen> So far I don't think we've gotten any responses so if we still don't after another day or so I'll try again with a poll :D
14:06:54 <alexanderhughes> that's fair.  I think over the next few WC/TC meetings we should aim to identify more events and what we plan to accomplish at each given X participation
14:07:03 <mattmceuen> yeah agree
14:07:19 <mattmceuen> Ok, moving on to the next topic:
14:07:27 <mattmceuen> #topic Adding porthole utility containers to AIAB
14:07:41 <mattmceuen> This was to expand on a discussion we'd had maybe 3-4 weeks ago
14:08:00 <khiyani> Matt our team has been working on implementing utility-container in airship/treasuremap we have got few comments on that
14:08:23 <mattmceuen> In adding the new porthole project (containerized, helm chart-ized ops utility containers for airship), we were interested in adding support for them to e.g. airship in a bottle
14:08:28 <openstackgerrit> Merged airship/spyglass master: Implement intermediary file validation  https://review.opendev.org/678642
14:08:32 <khiyani> https://review.opendev.org/#/c/680482/
14:08:33 <mattmceuen> o/ khiyani
14:08:50 <sthussey> I don't know what constitutes AIAB now
14:09:00 <jemangs> o/
14:09:09 <mattmceuen> A concern was raised in that changeset -- AIAB is already "big", so we should be wary of making it substantially "bigger"
14:09:15 <michael-beaver> Should mostly be the aiab site under treasure map as far as I know
14:10:00 <mattmceuen> sthussey: the proposal before was to add the porthole chart(s) to the treasuremap aiab site proper
14:10:32 <sthussey> okay, I've only asked it be omitted from the airship-in-a-bottle multinode site
14:10:55 <mattmceuen> First question to khiyani, if you know, is how much overhead a porthole chart might add from a memory perspective?  (note: different utility containers are captured in different porthole helm charts)
14:11:32 <khiyani> I am not sure how much RAM does it consume
14:12:23 <khiyani> how can we know how much RAM does it consumes ?
14:12:54 <sthussey> top
14:13:22 <mattmceuen> One option I put in the agenda would be to include just one example porthole chart in the aiab site, and then devs can just add in (or uncomment) others if they want to deploy them
14:13:56 <mattmceuen> an alternative would be to have a second aiab-ish site that includes porthole charts, but omit them from the general aiab
14:14:01 <mattmceuen> thoughts/opinions?
14:14:29 <nishantkr> I like the first approach
14:14:58 <michael-beaver> I think prefer the first idea as we don't need to be adding even more sites for this IMO
14:15:04 <roman_g> If there is a need to constantly test porthole, then create a pipeline which would clone treasuremap and add porthole utilities to it and run tests. Please, don't add utilities to the site which was supposed to be able to fit onto a developer's laptop (20GB RAM).
14:16:26 <Kavva> I do not think it will take much RAM as these component level utility containers is used to check the state of various services running within the component pods.
14:16:27 <mattmceuen> if we can find one porthole utility that is both small (to roman_g's laptop point) as well as general-purpose (i.e. generally useful, like etcdctl or something), and enable that by default -- would that be a good compromise?
14:16:47 <roman_g> Shouldn't be a problem to add chart on demand in gates.
14:17:02 <roman_g> Also consider disk space usage. Same problem.
14:17:12 <roman_g> Not talking about CPU cycles.
14:17:17 <roman_g> Yet.
14:17:18 <mattmceuen> roman_g in addition to testability, a second goal of aiab inclusion is to "advertise" these things -- help raise awareness
14:17:21 <nishantkr> apart from testing we would also like developers to make use of it, so there should be an option for including the utitliy
14:18:00 <sthussey> why not just include a couple different chart manifests and docs on telling shipyard which to use?
14:18:19 <sthussey> no reason you can't define all the YAML for deploying all the charts in the site so developers can use them
14:18:22 <michael-beaver> ^I think I like that idea a lot
14:18:48 <michael-beaver> Leave the default aiab manifest as the slimmest it can be and create other ones for different use cases
14:19:39 <mattmceuen> so you're saying sthussey, make e.g. a full-site-porthole.yaml manifest which lives side by side with the full-site.yaml manifest, and then make it clear to devs (etc) how to deploy it using aiab?  That sounds good to me
14:19:47 <roman_g> Advertising is a good thing, I agree. Provide good docs, videos on youtube, presentations. But if our users are being told that they now need 30-40GB RAM to test very basic Airship (with all features) - who would be intrested in that so much to find resources, unless one works for an enterprise?
14:20:09 <roman_g> +40GB HDD
14:20:25 <roman_g> People use SSD's now, and 40GB is a lot.
14:20:56 <michael-beaver> We could even enhance the airship-in-a-bottle script to take in a parameter for which full-site.yaml they want
14:21:17 <roman_g> Sounds a lot better :)
14:21:27 <michael-beaver> I do agree though roman, the requirements are already becoming prohibitive for entry level testers
14:21:57 <openstackgerrit> Trung Thai proposed airship/porthole master: Initial commit of mysqlclient-utility container.  https://review.opendev.org/674881
14:22:08 <mattmceuen> khiyani:  does this sound good to you?  1) don't change full-site.yaml or bootstrap.yaml   2)   add a full-site-porthole.yaml that includes all the utility containers , 3) document in the AIAB readme something like "to deploy with porthole utility containers <link> make this configuration change..." ?
14:22:58 <khiyani> sounds good to me
14:23:14 <mattmceuen> note:  this is the one line config that would need to be changed:  https://opendev.org/airship/treasuremap/src/branch/master/site/aiab/deployment/deployment-configuration.yaml#L38
14:23:29 <mattmceuen> the value corresponds to the document name (not the filename) of the armada manifest you want to deploy
14:23:32 <mattmceuen> awesome
14:23:54 <mattmceuen> I think we have a path forward -- anything additional on this topic, team?
14:23:57 <thyagaraj> looks good matt
14:24:24 <mattmceuen> cool - moving on!
14:24:27 <mattmceuen> #topic Deckhand support for python 2.7
14:24:36 <khiyani> Thanks Matt
14:24:36 <mattmceuen> nishantkr this is yours, go for it
14:25:16 <nishantkr> I happened to look into deckhand code a bit yesterday and i see it has zuul jobs running for python2.7 and some other documentation related to that, i was wondering do we still need those and the reasoning for supporting python2.7 in deckhand as I don't see it supporting in any other Airship repo?
14:25:23 <openstackgerrit> Trung Thai proposed airship/porthole master: Initial commit of mysqlclient-utility container.  https://review.opendev.org/674881
14:25:47 <mattmceuen> I personally have no qualms with deprecating py2.7 in deckhand
14:25:50 <nishantkr> If not needed, i can make a change to remove those
14:26:48 <ian-pittwood> py27 is close to being unsupported so I doubt we'll need to keep it
14:27:03 <roman_g> nishantkr: https://review.opendev.org/#/c/677552/ I failed to cleanly remove it.
14:27:18 <roman_g> Probably something else is needed
14:27:41 <nishantkr> oh ok, i will take a look at that, thanks roman_g
14:27:42 <roman_g> Ian: I'm not sure, pegleg broke randomly as well. I have to take the afternoon off though so I'll look at it tomorrow if it's still broken for you
14:28:11 <roman_g> running recheck just out of curiosity
14:28:57 <mattmceuen> sounds good - thank you guys
14:29:08 <openstackgerrit> Roman Gorshunov proposed airship/deckhand master: Remove Python 2.x support  https://review.opendev.org/677552
14:29:23 <mattmceuen> #topic Review Requests
14:29:38 <mattmceuen> I have carried over three patches from last week:
14:29:38 <mattmceuen> https://review.opendev.org/#/c/676700/ - Spec: Introduce isogen subcommand for airshipctl
14:29:38 <mattmceuen> https://review.opendev.org/#/c/676121/ - Airshipctl: Add isogen subcommand for bootstrap
14:29:38 <mattmceuen> https://review.opendev.org/#/c/675851/ - Airshipctl: Add logic to isogen subcommand
14:29:49 <mattmceuen> They got good review and I believe are ready for some more
14:30:16 <mattmceuen> any additional requests team?
14:30:43 <roman_g> mattmceuen: outreachy. I gonna cancel request, I guess.
14:30:52 <roman_g> No funding.
14:31:02 <cjain> Creating airship folder under https://github.com/openstack/rpm-packaging for airship rpm packaging
14:31:59 <openstackgerrit> Trung Thai proposed airship/porthole master: Initial commit of mysqlclient-utility container.  https://review.opendev.org/674881
14:32:00 <roman_g> cjain: we are not really part of OpenStack software
14:32:11 <roman_g> we are in OpenStack foundation
14:33:52 <roman_g> kskels: Hi Kaspars. Need your magical access to github.com/airshipit SSH key. Please, update PS in airship/images with encrypted SSH key when you have time. Thank you!
14:34:05 <roman_g> That's to enable sync.
14:34:34 <kskels> yes, and I should share that key somehow
14:34:43 <Kavva> @Matt I made changes to include etcdctl-utility container in Treasuremap. But when i deploy Treasuremap i do not see etcdctl-utility deployed. Could you please go through this ps https://review.opendev.org/#/c/680482/ and let me me know what i am missing.
14:34:48 <kskels> I know we discussed this - did we come up with a conclusion where to store these kinda  things
14:35:12 <roman_g> kskels: That's problem of technical committee, they wanted to decide how to keep keys to services we use.
14:35:20 <mattmceuen> Kavva:  sure thing
14:35:41 <mattmceuen> roman_g:  that's too bad on the funding side re: outreachy.  Thanks for pursuing it
14:36:01 <roman_g> mattmceuen: I read it as your aqgreement on cancelling it. :)
14:36:06 <roman_g> *agreement
14:36:11 <mattmceuen> I consent :)
14:36:19 <roman_g> :tumbs_up:
14:36:26 <roman_g> *thumbs
14:36:41 <cjain> we want to create rpm-packages for airship components and openstack-rpm-packaging suggested to create airship folder under https://github.com/openstack/rpm-packaging
14:37:04 <mattmceuen> sorry cjain: I don't think we have the experts in this IRC channel for that one
14:37:15 <sthussey> airship components are deployed as OCI images
14:37:30 <mattmceuen> oh I misread, please disregard my comment cjain
14:38:01 <roman_g> cjain: in addition to the fact that airship is not a part of OpenStack, software we develop is supposed to be packaged into containers only. Not into RPM's.
14:38:33 <mattmceuen> cjain: can you help describe what you're trying to accomplish through rpm packaging, maybe we can help?
14:40:24 <mattmceuen> kskels: "did we come up with a conclusion on where to store credentials":  the suggestion was to look into what openstack-infra is doing today
14:40:43 <cjain> In order to build containers we first need to create RPM spec for packaging
14:40:52 <mattmceuen> as they have some mature practices around shepherding credentials, encrypting them, avoiding the bus factor, etc
14:41:26 <mattmceuen> cjain:  ok.  What can we do to help?
14:43:00 <kskels> fyi: perhaps completely off but we also have SUSE based images for most things now, especially openstackhelm parts - perhaps something that might be of interest. They build images using Dockerfiles as here https://github.com/airshipit/deckhand/blob/master/images/deckhand/Dockerfile.opensuse_15
14:43:47 <mattmceuen> I don't have any experience with RPM packaging (I personally don't have much interest in it either) but if it's helpful for others, I wouldn't get in the way
14:44:27 <cjain> So I wanted to discuss if it is the right approach to create airship folder under https://github.com/openstack/rpm-packagi
14:44:30 <mattmceuen> cjain:  I recommend you take a look at what SUSE have done first^ to see whether you really need rpm packaging
14:45:13 <roman_g> cjain: who is interested in developing RPM specs?
14:46:16 <openstackgerrit> Trung Thai proposed airship/porthole master: Initial commit of mysqlclient-utility container.  https://review.opendev.org/674881
14:46:46 <cjain> In SUSE we create rpm packages for components and build them in OBS+IBS
14:47:13 <mattmceuen> ok
14:47:57 <cjain> And then we use that to build container images
14:47:58 <mattmceuen> I really don't have much experience with RPM building conventions (containerized or otherwise) so unfortunately I don't have a really good answer for you
14:48:20 <mattmceuen> I don't have any concerns personally with https://github.com/openstack/rpm-packaging, if you are familiar/comfortable with that
14:48:26 <cjain> Sure thanks
14:48:39 <mattmceuen> and the rpm-packaging team doesn't mind hosting airship RPM stuff alongside "openstack proper"
14:48:45 <jamesgu> so SUSE will create the rpm spec :-(. The proposal from the rpm pgk team is to add the airship folder inthe openstack/rpm-package project. So cjain is bringing this to attention, as fyi
14:49:11 <mattmceuen> makes sense to me now, I was a little slow on the uptake jamesgu :)
14:49:14 <roman_g> mattmceuen: one more thing: we have utilities containers in porthole repo, and supplementary images in images repo. Hope it's OK.
14:49:41 <roman_g> cjain, jamesgu: oh, thanks. So it wouldn't be just empty folder :)
14:50:07 <jamesgu> right roman_g. not idea as you pointed out airship is not openstack proper (yet)
14:50:14 <kskels> so likely openstack parts are good under /openstack, for airship components if RPMs used, likely you need opendev.org/airship/rpm-packages
14:50:16 <kskels> ?
14:50:48 <jamesgu> kskels: the airship/rpm-packages is not the route they want to take yet
14:51:12 <cjain> it will be https://github.com/openstack/rpm-packaging/airship
14:51:35 <kskels> hm - that's somewhat strange to me as those 2 projects are pretty independednt - openstack-helm/airship
14:51:36 <roman_g> jamesgu: I wanted to say that Airship is not a component of OpenStack, as in this openstack/rpm-packaging repo I see OpenStack components only.
14:51:55 <kskels> exactly
14:52:17 <kskels> I feel if you want to package say Deckhand - it really doesn't belong there..
14:52:45 <jamesgu> I'd tend to agree with you roman_g and kskels. cjain, what are the reasons that rpm team is proposing to add a folder?
14:53:51 <cjain> It seems openstack-rpm-packaging already discussed this topic and they suggested to airship folder next to openstack folder under https://github.com/openstack/rpm-packaging
14:54:41 <mattmceuen> I have no problem with creating an airship/rpm-packaging project, as long as folks were willing to support it
14:54:59 <Kavva> @Matt Thanks.
14:55:08 <mattmceuen> The benefit I see of of the openstack/rpm-packaging project is that it exists, has a team, and has all the CI plumbing in place
14:56:07 <roman_g> I'm fine with whatever contributers are comfortable to work with. Could be https://github.com/openstack/rpm-packaging/airship.
14:56:15 <roman_g> *contributors
14:56:22 <mattmceuen> Pasting the full review request in, since a few have been added:
14:56:22 <mattmceuen> https://review.opendev.org/#/c/676700/ - Spec: Introduce isogen subcommand for airshipctl
14:56:22 <mattmceuen> https://review.opendev.org/#/c/676121/ - Airshipctl: Add isogen subcommand for bootstrap
14:56:22 <mattmceuen> https://review.opendev.org/#/c/675851/ - Airshipctl: Add logic to isogen subcommand
14:56:22 <mattmceuen> https://review.opendev.org/#/c/677944/ - Project Config: New project request: airship/images
14:56:22 <cjain> roman_g yes
14:56:23 <mattmceuen> https://review.opendev.org/#/c/678106/ - airskiff suse site
14:56:23 <mattmceuen> https://review.opendev.org/#/c/678109/ - Armada metric output for genesis
14:56:24 <mattmceuen> https://review.opendev.org/#/c/657879/ - Run haproxy pod with the nobody user
14:56:24 <mattmceuen> https://review.opendev.org/#/c/657671/ - maas-ingress and maas-ingress-errors pods with non-root user
14:56:39 <kskels> I would vote for Matt's "I have no problem with creating an airship/rpm-packaging project, as long as folks were willing to support it"
14:57:06 <mattmceuen> Sorry cjain, I feel like we have come back and put the question back in your lap :)  I think we could go either way and it depends in part in what you & your team were willing to do and support
14:57:32 <mattmceuen> jamesgu do you have a strong opinion?  Or want to think about it first?
14:57:51 <jamesgu> mattmceuen: that sounds like a good answer
14:58:11 <jamesgu> I don't have strong opinion
14:58:20 <mattmceuen> we are unanimous then :D
14:58:43 <cjain> jamesgu mattmceuen Sure thanks
14:58:46 <mattmceuen> That's the agenda, folks - any other topics anyone would like to bring up in our 2 remaining minutes?
14:58:53 <mattmceuen> sure thing cjain, thanks for bringing it up
14:59:22 <mattmceuen> in that case:  thanks all for joining, and have a great week!
14:59:27 <mattmceuen> #endmeeting