14:00:08 <nishantkr> #startmeeting airship
14:00:08 <openstack> Meeting started Tue Aug 20 14:00:08 2019 UTC and is due to finish in 60 minutes.  The chair is nishantkr. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:09 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:12 <openstack> The meeting name has been set to 'airship'
14:00:17 <nishantkr> #topic Rollcall
14:00:22 <alexanderhughes> o/
14:00:24 <howell> o/
14:00:27 <CobHead> o/
14:00:29 <nishantkr> Hello everyone!!
14:00:35 <openstackgerrit> Merged airship/deckhand master: Upgrade six to 1.12  https://review.opendev.org/677272
14:00:38 <evgenyl> hi!
14:00:42 <nishantkr> Here is the Agenda for today - https://etherpad.openstack.org/p/airship-meeting-2019-08-20
14:00:43 <ian-pittwood> o/
14:00:45 <mattmceuen> o/
14:00:49 <sthussey> here
14:00:52 <nishantkr> Please add anything you would like to discuss
14:00:58 <jemangs> o/
14:01:01 <nishantkr> let's give it a min before we start
14:01:55 <dwalt> o/
14:02:06 <nishantkr> ok let's go for it !!
14:02:09 <nishantkr> #topic Announcements
14:02:51 <nishantkr> Airship Working committe conducted it's first meeting yesterday. mattmceuen sent out any email yesterday regarding the same but for anyone who might have missed that you could find all the details regarding the meeting here - https://wiki.openstack.org/wiki/Airship/Airship-WC
14:03:07 <nishantkr> some key highlights of that meeting-
14:03:19 <hogepodge> Congratulations to the new WC!
14:03:25 <mattmceuen> ty! :)
14:03:34 <nishantkr> 1) you would be noticing this meeting being hosted by one of the WC members going forward thus sharing the responsibility and workload that has so far been fantastically managed by mattmceuen alone
14:04:23 <nishantkr> 2) A special election would be held after 3 months from the first election held for WC to fill out the fifth seat. Since the 2 member per company quota is already filled up by AT&T and Ericsson, we would be looking for a 5th member  from another company. Please look out for the announcement and news on the election date 3 months (approx) from now
14:05:03 <nishantkr> 3) We have planned to gather feedback from the community in the form of survey and also have a new section "community feedback" in the etherpad used for this meeting. Please provide your feedback in that section and help us improve as a community.
14:05:34 <nishantkr> Please provide your feedback on gathering the feedback as well and let us know if you have any other ideas.
14:06:05 <nishantkr> mattmceuen, dwalt and kskels - Please add if I may have missed something
14:06:33 <mattmceuen> just one more thing on #2 -- we will run the special election plan by the TC to make sure they're good with it, since they own our governance in general
14:07:04 <sthussey> I thought the governance said that WC owned governance?
14:07:33 <mattmceuen> hmm, if so we're done :D  maybe I'm remembering the details wrong, will double check
14:07:45 <openstackgerrit> Dan Crank proposed airship/promenade master: Fixes/updates for webhook-apiserver  https://review.opendev.org/665761
14:07:51 <dwalt> I'd also like to add that the last fifteen minutes are reserved as an open forum for questions -- anyone is welcome to attend the meeting!
14:07:55 <sthussey> https://www.irccloud.com/pastebin/8493LHQF/
14:08:07 <nishantkr> ok thanks for pointing that out mattmceuen and sthussey
14:08:09 <mattmceuen> good catch sthussey!
14:08:23 <nishantkr> thank you dwalt
14:08:39 <nishantkr> ok then moving on
14:08:51 <nishantkr> mattmceuen: you have the next item in the Announcement. please go for it.
14:09:09 <mattmceuen> In case anyone missed it:  https://about.att.com/story/2019/att_dell_opensource5g.html
14:09:45 <mattmceuen> There was a press release from Dell & AT&T around collaborating on 5G technology, and a big part of that was that Dell is going to be getting into Airship development in a big way
14:10:05 <mattmceuen> So that's great to hear - welcome to anyone from Dell who is here or will be joining over the coming weeks!
14:10:18 <mattmceuen> excited for you to be joining us
14:10:34 <mattmceuen> that's all from me nishantkr
14:10:40 <nishantkr> That's exciting news. Thanks for sharing mattmceuen.
14:10:57 <nishantkr> #topic Package management for Airship python projects
14:11:12 <nishantkr> ian-pittwood: go for it !!
14:11:17 <ian-pittwood> Thanks!
14:11:26 <hogepodge> The candidate pool for the upcoming WC election is a bit larger now ;-)
14:11:38 <ian-pittwood> So as you all know, right now we are just using opendev git repos for all of airship
14:11:42 <mattmceuen> +1 hogepodge.  Let's get those commits in!
14:11:47 <ian-pittwood> We aren't doing any packaging that I know of
14:12:44 <ian-pittwood> Recently I've encountered a lot of issues dealing with using only these git repos for our dependencies. Pip doesn't really play well with VCS dependencies it seems. I'm curious how everyone would feel about possibly packaging and uploading our airship projects onto PyPI or some other index
14:12:46 <ian-pittwood> Thoughts?
14:13:16 <pramchan> If we have python package like sushy-tools if we need to call fro go is that via RESTfull calls only or there are other options to call go to python directly?
14:14:12 <ian-pittwood> pramchan: sorry I'm a little confused by that. Are you asking how we'll be calling python from golang in the future? Or something else?
14:14:24 <pramchan> yes
14:14:49 <sthussey> @ian-pittwood i agree w/ pypi
14:14:52 <nishantkr> ian-pittwood: that sounds good to me unless anyone has any other thoughts on it.
14:15:02 <sthussey> but someone will need to set up the plumbing
14:15:12 <sthussey> and more, we will need to adopt some versioning
14:15:17 <pramchan> Let me hold this while we get pypi cleared
14:15:19 <ian-pittwood> pramchan: It would be essentially the same as far as I know. The main difference is that using packages instead of buillding from VCS will make dependency installation easier. There won't be any difference in really how we use it
14:15:45 <ian-pittwood> Yeah who would manage an Airship PyPI account?
14:15:50 <CobHead> Question - you are talking about packaging the minor/major releases of airship and uploading to PyPi, right?
14:16:02 <ian-pittwood> Or would we tag along with OpenStack's account??
14:16:28 <ian-pittwood> Well that's actually a thing I've thought about CobHead. We can do the major/minor releases, but we can also make dev pre-releases
14:16:58 <ian-pittwood> So for every change we make that is merged between releases, we can still install a version of the package with those changes
14:17:11 <ian-pittwood> Thanks to the magic of pbr
14:17:39 <mattmceuen> ian-pittwood: re the pypi account -- management of airship shared infrastructure credentials is one of the things on the WC backlog we didn't get to yesterday - should hopefully have a suggestion next week
14:17:41 <ian-pittwood> So instead of just having v0.1.0, v0.2.0, etc... We can also install v0.1.0dev28
14:18:10 <ian-pittwood> mattmceuen so this is an action item for WC?
14:18:43 <CobHead> I see
14:18:45 <mattmceuen> action item to to figure out, not necessarily to own :)
14:19:03 <ian-pittwood> Haha well I can help if need be. I did some research yesterday to make sure I understood the process
14:19:19 <mattmceuen> account management was a broader thing that sthussey brought up last week
14:19:32 <mattmceuen> ++ thanks!
14:19:37 <nishantkr> yep, i will note the action item on me for now and we can discuss the process on the WC and irc meeting next week.
14:19:41 <sthussey> you'll need to convert some of the modules to pbr
14:19:45 <ian-pittwood> Ok, one more quick question on this
14:20:12 <ian-pittwood> What's up with promenade's dependency management? Why doesn't it use a requirements.txt?
14:20:22 <nishantkr> #action nishantkr Airship python project packaging with pypi
14:21:11 <ian-pittwood> I can foresee it becoming a problem for us when it comes to packaging
14:21:16 <pramchan> #info https://pypi.org/project/python-openstackclient/ is it different from what airship uses?
14:22:20 <nishantkr> ian-pittwood: I think it's more readable in the sense we just use direct dependencies in promenade, hence we have separate requirements file as a best practice maybe?
14:22:55 <alexanderhughes> I think converting to a release management system is going to be a deeper discussion one that might be better suited to the Airship design calls if we can pull some time from Airship2.0 talks.  Might save us some headaches from the lessons we learn now too with 2.0
14:23:06 <ian-pittwood> nishantkr the problem is that's not helpful for other projects attempting to install promenade. As far as I know, pip only searches for requirements.txt
14:23:26 <nishantkr> ideally requirements.txt could have pinned version vs unpinned version package which could help in upgrading those unpinned packages easily
14:24:10 <alexanderhughes> the problem with pinned packages, especially in projects that are consumed by others such as Pegleg (promenade, deckhand, shipyard) is their pins aren't consistent when they are pinned
14:24:27 <ian-pittwood> Libraries should not have hard pins imo
14:24:40 <ian-pittwood> End user apps are the hard pinned applications
14:25:09 <ian-pittwood> And there's tools we can use to help keep packages up to date, we don't have to create our own system for it
14:25:20 <nishantkr> alexanderhughes: yep that's right. i recently had to face a similar issue
14:25:30 <sthussey> all of these tools were built as simple API services
14:25:47 <sthussey> The need to use them as programmatic APIs wasn't really considered
14:25:58 <sthussey> The correct thing is to split the code bases
14:26:07 <nishantkr> ian-pittwood: that's a valid point. let's bring that up in the design call and decide the way forward.
14:26:20 <sthussey> Because not hard pinning has the problem of build variance when building docker images
14:26:54 <ian-pittwood> sthussey that's a problem that pipenv is supposed to solve, but unfortunately it's not ideal for libraries
14:27:28 <sthussey> yeah, I don't think anyone looks to Python for how to solve dependency management
14:27:36 <ian-pittwood> It's a difficult issue. I agree that we can probably discuss it on the design call
14:27:51 <nishantkr> ok sounds good.
14:28:01 <nishantkr> any other thoughts on this topic?
14:28:20 <nishantkr> ok moving on then
14:28:27 <nishantkr> #topic Brief intro to Airship 2.0 scope in Jira
14:28:32 <mattmceuen> Ah that's mine
14:28:40 <nishantkr> please go for it
14:29:43 <mattmceuen> I wanted to give a brief intro to some of the work jezogwza has started doing to scope out Airship 2.0 work in our Jira instance, so we see it coming and see what's most ready to be worked in terms of prioritization and being fleshed out
14:29:59 <mattmceuen> This isn't going to be a deep dive since you can't see my screen :)
14:30:00 <mattmceuen> https://airship.atlassian.net/secure/RapidBoard.jspa
14:30:42 <mattmceuen> The Backlog has the general progression from top to bottom of the scope, roughly cronologically
14:31:20 <mattmceuen> It's split into monthly sprints, with targeted delivery months  in the name -- e.g. 201908 - Bootstrapping
14:32:11 <mattmceuen> Under that are higher level chunks of functionality (e.g. Basic Config + Document Functionality) that are targeted to those sprints
14:32:19 <mattmceuen> and under those are the granular user stories
14:32:52 <mattmceuen> On the right, you see proposed meaningful releases for the scope -- e.g. Airship 2.0 Alpha, Airship 2.0 Beta, Airship 2.0, Post-Airship 2.0
14:33:02 <mattmceuen> and Airship 1.0 :)   we can use this for 1.x scope as well
14:33:30 <mattmceuen> that's really all I wanted to share here -- feel free to take a look and provide feedback to jezogwza, I know he's looking to refine this over time
14:34:13 <nishantkr> yep that sounds a good place to start looking into. thanks for sharing it mattmceuen
14:34:13 <mattmceuen> any questions yet?
14:34:19 <mattmceuen> Sure thing
14:34:24 <mattmceuen> if any - let me know
14:34:30 <pramchan> Good summary
14:35:01 <nishantkr> ok moving on then
14:35:06 <nishantkr> #topic New project proposal: airshipui
14:35:47 <nishantkr> mattmceuen: this is yours. go for it !
14:35:48 <mattmceuen> As you guys are probably aware, there has been a design SIG around adding a user interface for airship
14:36:14 <mattmceuen> There is a request to create a home for this work -- the airship/airshipui project
14:36:29 <sthussey> I assume you mean a graphical interface?
14:36:49 <sthussey> versus the existing command line interface(s)
14:36:49 <mattmceuen> I haven't been in the SIG meetings so I don't have a whole lot of detail to share, anyone else have additional info?
14:36:54 <mattmceuen> yep sthussey
14:37:27 <pramchan> Ui sig meeting what's the link for meeting, I ddi not see any in therpad
14:37:30 <jezogwza> Essentialy its a dashboard (WUI) that will provide functionality that airshipctl exposes, but moe. i.e. YAML friendly functionaity
14:37:54 <jezogwza> The current propoal from SUSE is to use a framework called stratos they developed for cloud foundry
14:37:55 <alexanderhughes> #link https://urldefense.proofpoint.com/v2/url?u=https-3A__etherpad.openstack.org_p_Airship-5FUI&d=DwMF-g&c=LFYZ-o9_HUMeMTSQicvjIg&r=6f0dU7tUT8UoVrYjQwg8cQ&m=MrkJ5xsBj9WB3el-Npgux8hotpubvmCc2_srNjFZwAQ&s=2VDG55yhgCj-LKLU9HXPrc3YAspYx5U1OM15iE_F47s&e=
14:38:02 <jezogwza> We have had a ademo and some explanation about it
14:38:16 <alexanderhughes> #link https://etherpad.openstack.org/p/Airship_UI
14:38:21 <jezogwza> Will be mking a decision on the framework on this Fridya's sig-airship-ui call
14:38:23 <mattmceuen> I +1 this, because a GUI is something that we've received a large volume of interest/desire for over the last year
14:38:32 <mattmceuen> ty jezogwza & alexanderhughes!
14:38:43 <jezogwza> eh framework has a frontend (using Angular and Node.js) and a backend written in g
14:38:44 <jezogwza> go
14:39:15 <jezogwza> Already has some integration with k8s and a poc for integrating with Argo was demoed last week
14:39:33 <pramchan> where is the meeting bridge on that? no link in etherpad above?
14:39:58 <mattmceuen> pramchan: https://wiki.openstack.org/wiki/Airship#AIRSHIP_SIG_-_Special_Interest_Meetings
14:40:18 <pramchan> thanks
14:40:30 <nishantkr> thanks jezogwza and alexanderhughes for sharing the details !
14:40:48 <mattmceuen> Although we don't yet have the full direction ironed out for the project, I think we can vote yea/nay on creation of a project in general
14:40:55 <mattmceuen> Are we good with adding an airshipui?
14:40:59 <alexanderhughes> +1
14:41:03 <jezogwza> +1
14:41:05 <ian-pittwood> +1
14:41:06 <nishantkr> +1
14:41:11 <dwalt> +1
14:41:28 <mattmceuen> \o/
14:41:29 <nishantkr> That sounds like all yay's :)
14:41:35 <mattmceuen> thanks all
14:42:00 <nishantkr> #topic Updating the https://etherpad.openstack.org/p/airship-team-meeting-agenda page
14:42:12 <nishantkr> ian-pittwood: go for it !
14:42:23 <ian-pittwood> Are we still doing that page?
14:42:42 <ian-pittwood> It's still listed on the get in touch page, but it hasn't been updated since March
14:42:59 <mattmceuen> I guess we either need to keep it updated or remove it from the get in touch page
14:43:07 <alexanderhughes> seems like extra effort when it's all available at #link http://eavesdrop.openstack.org/meetings/airship/
14:43:32 <ian-pittwood> Well that's the logs, not the agendas
14:43:38 <alexanderhughes> I'd suggest removing from get in touch page, but, adding to IRC channel or get in touch page the link to the next week's agenda so it's easy to find
14:43:42 <mattmceuen> That is how I'm leaning - but if anyone gets value out of it I don't mind updating either
14:43:45 <openstackgerrit> varagini karthik proposed airship/porthole master: Chart/Dockerfile for Postgresql Utility Container  https://review.opendev.org/675866
14:44:05 <alexanderhughes> well last week's agenda is covered in detail in the meeting log.  each agenda item has its own topic and discussion
14:44:07 <ian-pittwood> alexanderhughes that sounds fine to me
14:44:54 <nishantkr> ok any other sugsestion? do we feel the need to update the page or just remove it?
14:45:10 <alexanderhughes> remove page, but make upcoming agenda easy to find.  and work to get it created in advance
14:45:16 <alexanderhughes> often times it's not created until an hour before
14:45:20 <pramchan> no keep the pages we do use it
14:46:05 <mattmceuen> ok - if you guys use it, I can update the etherpad, just a bit of copy + paste + edit
14:46:07 <alexanderhughes> get in touch is fine to keep, but links to previous agendas should just be replaced with link to previous meetings
14:46:20 <nishantkr> ok if we have folks using it then it may make sense to update it for the time being.
14:46:21 <mattmceuen> ah I see
14:47:10 <nishantkr> #action mattmceuen to update the airship-meeting-agenda page
14:47:31 <nishantkr> any other thoughts on this topic?
14:47:57 <mattmceuen> one sec
14:48:04 <nishantkr> sure
14:48:04 <openstackgerrit> Jagan Mohan Kavva proposed airship/porthole master: Zuul gates setup for Utility Containers  https://review.opendev.org/675798
14:48:31 <mattmceuen> It looks like the Get in Touch section only references the meeting logs (not the etherpad):  https://wiki.openstack.org/wiki/Airship#Get_in_Touch
14:48:54 <mattmceuen> I don't see the reference to the "big list of agendas" etherpad, am I missing it?
14:49:16 <ian-pittwood> Hmm I swore it was somewhere still
14:49:26 <mattmceuen> or did someone update it just now? :)
14:49:35 <ian-pittwood> http://eavesdrop.openstack.org/#Airship_Team_Meeting
14:49:47 <ian-pittwood> It's there I think
14:50:10 <mattmceuen> ah, that's the one
14:50:34 <mattmceuen> Cool.  I'll update it, and will try to do a better job along with WC colleagues on entering the next agenda into that, ahead of time
14:50:49 <mattmceuen> I'm good to move on nishantkr
14:50:50 <nishantkr> thanks mattmceuen.
14:51:04 <nishantkr> ok moving on to our last topic
14:51:07 <nishantkr> #topic AIAB timeout (deafline) on tests is set too low by default for common hardware (i.e. desktops). Should ideally be higher by default
14:51:20 <nishantkr> CobHead: was that added by you?
14:51:21 <CobHead> Hi :)
14:51:23 <CobHead> Yes
14:51:25 <CobHead> So I made it past the hurdle of deploying AIAB wrt the postgresql pod entering a CrashLoopBackoff state - however, the deploy is now failing because of a short deadline, especially during the keystone test (which is set to 300s by default.) It seems to me that the behavior of the deploy is weird. If a deadline is exceeded, one would expect the script to terminate the pod immediately, not wait until the test has completed and the results has been
14:51:25 <CobHead> returned. This also means that the default deadline should be set higher, as most people probably deploy AIAB to play around with, etc. If this deadline is always exceeded, the deploy never finishes. My runs use an average of ~370 seconds on the test, which includes the pod initialization.
14:52:34 <mattmceuen> yeah, those timeouts have evolved over time to be more accurate, but are sensitive to the hardware they're running on, among other potential things
14:53:12 <mattmceuen> CobHead would you be willing to bump that timeout in the manifest to a better value (if no objections from the team)?
14:53:25 <mattmceuen> (I mean push a PS to update it in the repo)
14:53:46 <CobHead> Yes, but if a deadline is exceeded (x) amounts of times - the script should terminate, not continue on for eternity?
14:54:15 <mattmceuen> Couple different things going on there
14:54:33 <mattmceuen> but agree they're separate concerns -- reasonable timeout  value, vs how to handle a timeout
14:55:01 <mattmceuen> For handling the timeout -- keep in mind that the airship in a bottle script isn't intended for prod use; it's a runner for the Shipyard API, which is intended for prod use
14:55:24 <CobHead> I'm aware :)
14:55:26 <mattmceuen> Shipyard retries a few times and then sets the status of the workflow to a Failed state
14:55:26 <CobHead> I tried to increase the deadline by setting setting the variables in /treasuremap/site/aiab/deployment/site/deployment-configuration.yaml - however it seems to me that Genesis is still setting 300 as the default - and I haven't figured out where it gets this default from.
14:56:06 <openstackgerrit> Merged airship/porthole master: Zuul gates setup for Utility Containers  https://review.opendev.org/675798
14:56:12 <roman_g> patch it on the way while it runs :)
14:56:22 <roman_g> Hello everyone. o/
14:56:22 <CobHead> I thought of that :p
14:56:38 <mattmceuen> DId the AIAB script fail-to-fail on the first try only, or was it just waiting for all the retries to occur CobHead?
14:56:48 <nishantkr> CobHead: armada chart deployment should fail if the timeouts have been exceeded and it would go for another retry but yeah we don't really purge the chart or remove the pods before starting another retry.
14:56:50 <mattmceuen> o/ roman_g!
14:56:51 <openstackgerrit> PRATEEK REDDY DODDA proposed airship/porthole master: Chart/Dockerfile for Openstack Utility Container Added Support for rbac  https://review.opendev.org/674670
14:57:23 <mattmceuen> Armada manages that for you (given the appropriate settings)
14:57:24 <CobHead> mattmceuen: It haven't failed, as I usually terminate it when it fails for the 4th of 5th time.
14:57:41 <CobHead> The loop, that is.
14:58:03 <mattmceuen> hmm ok - sounds like that could be improved on the aiab script side then
14:58:25 <mattmceuen> thanks for bringing it up CobHead, I'll take a look
14:58:35 <CobHead> Great - thanks :)
14:58:35 <openstackgerrit> Jagan Mohan Kavva proposed airship/porthole master: Chart/Dockerfile for etcdctl Utility Container  https://review.opendev.org/674680
14:58:46 <nishantkr> yep thanks CobHead