14:00:20 #startmeeting airship 14:00:21 Meeting started Tue Aug 27 14:00:20 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:22 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:00:26 The meeting name has been set to 'airship' 14:00:27 #topic Rollcall 14:00:32 o/ 14:00:35 o/ 14:00:35 o/ 14:00:38 |o/ 14:00:39 o/ 14:00:41 o/ 14:00:41 ty for sharing agenda alexanderhughes 14:00:45 o/ 14:00:50 Alexander Hughes hello! meeting kicking off in a few minutes, agenda here https://etherpad.openstack.org/p/airship-meeting-2019-08-27 14:00:51 o/ 14:00:55 here 14:00:58 GM/GE all! 14:01:12 yw :) 14:01:19 we'll get going in just a minute 14:01:33 feel free to add any more topics to discuss to this week's agenda 14:01:33 What time is it over there? 14:01:45 o/ 14:01:49 9am here in Saint Louis! How about you CobHead? 14:01:59 o/ 14:02:35 4pm in Norway 14:03:37 thanks all for joining, and away we go: 14:03:50 #topic Airship YouTube playlist 14:03:55 go for it alexanderhughes 14:04:12 Just a quick announcement, Chris and the rest of the awesome folks at OSF have set us up a playlist on their youtube channel 14:04:19 #link https://www.youtube.com/playlist?list=PLKqaoAnDyfgp8YjZbzjVrmZBJR9thV27y 14:04:39 these are a collection of interviews/presentations etc. regarding Airship. if you have more content you'd like to see added please shoot me a message 14:04:41 Sunny and the rest of the marketing team deserve most of the credit. 14:04:56 that is awesome 14:05:02 Nice :) 14:05:08 yes, huge thanks to Sunny for her hard work on the media channels 14:05:29 ty both for spearheading that (and Sunny for doing the hard work!! :) 14:05:30 It became a valuable exercise for all of the projects so thank you for the suggestion. 14:05:38 nice 14:06:28 hopefully we get a few more on there after the Shanghai summit as well 14:06:48 Any presentations due for the summit? 14:07:04 May be worthwhile to have someone demo some of the projects there 14:07:12 ++++ sthussey 14:07:13 rather than having only presentations and interviews 14:07:30 Demos are always nice 14:07:57 absolutely, there's a lot more we can do with this. I'd love to see more content on the channel, making it a one stop shop for anyone curious about airship and use cases, how certain things work etc 14:07:58 alexanderhughes, were you already prepping a Shanghai presentation list or did I make that up? 14:08:32 #link https://www.airshipit.org/blog/airship-at-the-open-infrastructure-summit-shanghai-in-november.html 14:08:39 there's a list of Airship presentations on the blog 14:09:04 o/ 14:09:17 ah, ty for sharing that 14:09:51 Alright, I think we can move on unless anything else on this topic? 14:10:00 nope :) 14:10:16 #topic Airship GUI Project Name 14:10:27 So last week we agreed to create a new project 14:10:38 But we didn't figure out anything awesome to call it 14:10:45 I sent out an email on the ML to remedy that 14:11:10 Details in that email - please read it and plan to share your opinions on the best names in next week's IRC meeting 14:11:19 That's all on that topic unless any questions 14:12:26 #topic New Project Proposal: airship/isogen 14:12:56 Dmitry: the floor is yours, can you please give us an overview of the plan for this project? 14:13:07 Thanks 14:13:25 I know discussion has been going on in the Bootstrap SIG, so folks who are not regulars may need to be caught up just a bit 14:14:11 Basically as a part of airshipctl development we need Live CD iso to bootstrap ephemeral k8s cluster 14:14:42 this cluster is going ot be used for new (Target) cluster deployment using metal3 14:15:01 ephemeral cluster get destroyed then 14:15:38 so to build an LiveCD/LiveUSB image it was decided to use container with set of scripts 14:16:04 so there is a question: where to keep Dockerfile and scripts 14:16:50 we also decided to create separate repo for all such image builders (e.g for Debian SuSe etc) 14:17:11 Makes sense to me. So this new project will not contain the airshipctl module for generating the iso; that code would live in the airshipctl project, right? 14:17:12 o/ 14:17:15 it turned out that we may need more the one type of images 14:17:18 o/ jemangs 14:17:43 I support to have another repo, but for all images/Dockerfiles all together, which would be supplementary to the airshipctl. 14:17:45 so may be isogen is not good name for that repo 14:18:11 airshipctl-images? 14:18:26 +1 roman_g 14:18:35 youe ,ean not using quay.io? 14:18:38 Wouldn't it make more sense to keep it all time builders in the same repo? If the project ends up with builders for 6 distros, it might be difficult to keep track of them all? 14:18:57 similar to openstack-helm-images 14:19:46 CobHead: there's overhead involved in project creation/maintenance, so if it doesn't get out of hand I like starting with a single repo. Agree roman_g openstack-helm-images is some good prior art there 14:20:07 can we not add these standard specified images to quay.io 14:20:12 CobHead: yes, that's what I would like to have - one repo for all images related to the airshipctl 14:20:26 pramchan: yep we can store build images in quay.io, agree 14:20:32 pramchan: they would be published there, but we discuss where to host sources 14:20:34 we just need a project for the unbuilt images 14:20:52 OK that makes sense 14:21:22 for that we can create patches under tools and add those sources 14:21:22 A question for a later date is whether or not the Airship project team should be responsible for all the builders, or if some should be sourced out to the community? 14:22:34 we need to maintain at-least two builds to ensure variety 14:23:40 CobHead: agree and I would frame it up straw-man style this way, an airship-images project would be only for image sources that need to be created or built by the airship team (potentially forked from a project) only when necessary, and would not take image build responsibility away from other projects that are a more natural fit (e.g. deckhand would continue to build its own image) 14:23:43 Agree? 14:24:12 Sounds good. 14:24:17 +1 14:24:47 we could welcome other container images as long as they have high quality code, well covered by CI tests, and there would be someone willing to support them 14:24:52 +1 14:25:05 _integrated_ CI tests 14:25:11 Agree roman_g 14:25:46 do we like the airship-images convention? Or do we want to come up with something more creative? 14:25:54 (in terms of project name I mean) 14:26:03 Keep it nice and simple 14:26:20 +1 14:26:24 airship-images or airshipctl-images? 14:26:24 +1 14:26:25 descriptive is nice. there's no question what airship-images is 14:26:49 why wouldn't this go into airshipctl if this is only to support code being added there? 14:26:49 airship-images as ui will also use it 14:26:52 airship-images +1 14:27:06 +1 to airship-images 14:27:12 I'd go for airship-images roman_g, I think it makes sense for other non-cli images we may need in the future 14:27:43 looks majority is airship-imaged go for it 14:27:58 airship-images typo 14:28:05 I think you are right pramchan, I will sip coffee for 30s in case anyone comes up with a counterpoint 14:28:21 +1 sounds good to me 14:28:26 welcome to colambian cofee!!! 14:28:36 sthussey: we were discussing on bootstrap call, that there are high chances that we would have more airshipctl modules implemented as containers. 14:28:47 right 14:29:10 sthussey: so I see reasons to keep it with airshipctl 14:29:11 modules as containers - I like it :) 14:29:13 Is the code in the airshipctl module going to be coupled with the container contents? 14:29:13 and not only airshipctl i guess ... 14:29:33 nope the airshipctl module code will live in airshipctl I believe 14:29:40 for isogen, etc 14:29:47 coupled as in co-dependent 14:29:52 where etc = built-in modules 14:29:54 I think given the trends it's a no brainer and best practice by definition will be use Docker conatainer or some container that fits your needs 14:30:21 a change in module code requires a change in the container build - or vice versa 14:30:44 sthussey: line 65 and onwards https://etherpad.openstack.org/p/Airship_bootstrap 14:30:48 what do you think dukov in terms of coupling? Do you expect a stable interface? 14:32:01 really just an ecosystem difference. OSF projects seem to shy away from a repo having more than a single artifact produced from it 14:32:14 probably not super stable. but intention was to use Depends-On: xxx for cross-repo CI checks 14:32:27 and to use cross-CI Zuul jobs 14:32:34 mattmceuen: well the idea is to define a contract of communication between container and airshipctl which means any image that implements interface can be used 14:32:39 *cross-repo CI Zuul jobs 14:33:11 that being said we still need a place where to keep couple default ISO builder container 14:33:30 *containers 14:33:30 makes sense dukov, it would have to be pretty stable or else it would wreak some havoc 14:34:15 just seems odd to me that images built for this and the airshipui are considered coupled enough to be in the same repo, but putting this in the same repo as airshipctl isn't. anyway, carry-on. 14:34:24 technically we can use airshipctl for that but eventually it will create a mess 14:35:03 airshipui - I think container build code would live in-tree with application code, but I haven't been tied into those convos and aren't an authority 14:35:53 Ok, I think we can move on unless anything else on this topic: 14:36:14 sthussey: are you for separating supplementary images into one additional repo, or are you for keeping supplementary images (e.g. isogen) inside airshipctl? 14:36:47 so what is the conclusion? are we going to create separate repo ? 14:37:19 I was just bringing up a viewpoint. It sounds like the folks working on it are for this generic images repo 14:37:39 I tend to avoid repo sprawl 14:37:45 but airship is probably long past that point 14:38:23 Yep I think we still have consensus for airship-images (unless anyone de-consensizes). Appreciate probing the pros/cons of this sthussey 14:38:31 Agree on repo sprawl 100% 14:38:56 I was leaning toward bundling this into airshipctl till learning more from dukov 14:39:12 thanks for bringing this up and filling us in on progress dukov! 14:39:58 mattmceuen: you are welcome! I'll update CR accordingly then 14:40:18 if we run into unanticipated issues we can always move it out later 14:40:27 Perfect ty - then feel free to add that on to the agenda review list as well so we can put +1s on it 14:40:42 #topic Has anyone been able to roll AIAB in the recent weeks 14:40:52 CobHead I take it you're hitting some issues :( 14:40:54 Yes, I can't for the life of me get past shipyard trying to build Armada. It's stuck there until it finally fails. Then it moves on to try submitting Horizon, but that inevitably fails too. Anyone else in here experienced this? 14:41:26 I initially suspected a timeout, so I tried bumping it, but to no avail. 14:41:36 And just to clarify this is Treasuremap single-node AIAB, right? 14:41:41 Yes. 14:42:03 That's what I thought - yeah, I tried a couple times a week and a half or so ago with two successes 14:42:15 We need to figure out your RC 14:42:36 Remind me, are you running in a local VM or in a public cloud or? 14:42:48 Local VM - however I've tried public cloud aswell. 14:42:56 same behavior? 14:43:13 Actually, it's different. Can't get past PostgreSQL in the cloud. 14:43:21 Locally it stops at Armada build. 14:43:53 Well it oughta be working fine in both places. Which one do you want to fix first 14:44:02 There feels like there are some caveats here, and I'd like to resolve them on the top, so people who are unfamiliar with the project don't hit a dead end when they want to try AIAB. 14:44:23 I'd like to fix local first. 14:44:25 Agree, may be some hidden assumption we need to ferret out 14:44:35 Ok - would you be free to power through this in the IRC channel after the meeting? 14:44:37 does AIAB stand for Airship in a Box ? or is it Airskiff my ignorance please clarify? 14:44:47 Airship in a Box ;) 14:44:48 Close pramchan :) Bottle 14:44:57 ok 14:45:00 mattmceuen: Absolutely. Can start deployment now. 14:45:01 again with the nautical theme 14:45:54 After we have gone through the changes for review, there is another thing I'd like to take up. 14:46:08 Is it then etcd dependency that is fainling in local VM similar to PostgresSQL in cloud for AIAB? 14:46:29 At this point, I have not a single clue. 14:46:42 Can we not track the failure or error code? 14:46:49 Since we only have a few mins left, let's save the troubleshooting for post-call -- but please stay tuned pramchan I want to get this fixed 14:46:57 #topic Requests for Review 14:47:04 These are copied from last week's; confirm whether more review is needed before meeting: 14:47:04 https://review.opendev.org/#/c/671575/ - Shipyard (one more +2 is needed)rt dependencies) 14:47:04 https://review.opendev.org/#/c/675440 (add airskiff suse cite and ci gate) 14:47:04 https://review.opendev.org/#/c/672688/ (Tungsten Fabric support in Treasuremap) 14:47:04 https://review.opendev.org/#/c/678311/ Airskiff dep fix in Treasuremap 14:47:05 https://review.opendev.org/#/c/671575/ Shipyard 14:47:05 https://review.opendev.org/#/c/677980/ Bump ucp keystone timeour 14:47:06 https://review.opendev.org/#/c/674409/ - shellcheck linting (this one - for divingbell) - need to evaluate if it's usefull to be implemented to other charts we host under airship/*. 14:47:06 https://review.opendev.org/#/c/678618/ - airship/armada - Fix: Armada Exceptions docs rendering on RTD 14:47:19 Let's please get some eyeballs on these today, team 14:47:34 Another thing, mattmceuen - which everyone should hear. 14:47:38 Or read, for that matter.. 14:47:46 Yes please CobHead, go for it 14:48:07 #topic Roundtable 14:48:19 https://review.opendev.org/#/c/672540/ Take a look at this commit. This commit removed the package dependencies for Airskiff, since they are being handled in OSH - but the OSH package install script is never handled by the airskiff script(s) 14:48:40 ahh 14:48:48 So essentially, if you deploy Airskiff using the steps described in the docs - you will halt when Armada is built 14:48:55 Since that requires make. 14:48:57 Make is never installed. 14:49:04 Likewise with the Python client for Openstack 14:49:10 Since python-pip is never installed. 14:49:14 https://review.opendev.org/#/c/678302/ 14:49:20 I've made some amends in that commit. 14:49:24 Yep - I hit the Python / pip issue yesterday 14:49:59 But please - if there are dependencies removed - please also remove them at the gate. Zuul has no issues with this as those packages are listed in the gate. 14:50:19 But not in the script - so the CI succeeds, while the developer fails. 14:50:26 Yeah 14:50:47 Good catch, thanks for fixing that 14:50:50 https://review.opendev.org/#/c/678311/ I think this should help with this. 14:51:18 Gate Ubuntu image has a lot of stuff pre-installed, this is the reason it does not fail. 14:51:30 Including make, I presume. 14:52:05 I think evgenyl's patch should be merged instead of mine, as it addresses both pip and the other dependencies. 14:52:07 I 14:52:11 I will abandon mine ;) 14:52:35 ok :) great minds are thinking alike 14:53:22 That was what I had to bring up :) 14:53:58 I think we hit everything in the agenda, anything esle you'd like to discuss today team? 14:54:26 I will be on vacation tomorrow through next Thursday, so don't expect much out of me :D 14:54:51 Can i ask a question on baremetal? 14:54:56 sure pramchan 14:55:25 sthussey: you wanted to review https://review.opendev.org/#/c/674409/ - shellcheck linting. I would appreciate a lot your opinion. 14:55:34 Thank you. 14:56:03 I am trying to find a directory where I can submit the code, shall I call it baremetal as a new folder to start coding for Redfish boot for testing vBMS? 14:56:18 vBMC 14:56:47 start anywhere, and we will find a right place :) 14:57:08 pramchan: this code will be the Redfish equivalent of vBMC, right? 14:57:17 cool thx will do 14:57:54 airship/airshipctl/tools/ <- probably somewhere here 14:57:56 partly yes will push to cmd later once I can test it 14:58:14 as it would be part of gates, I think 14:58:16 yes tools is where I will put the vBMC 14:58:21 Agree with roman_g, get it out somewhere public and we can figure it out. You can always make changes in a new github repo and then we can import it later when we know where it should go - we have done that many times 14:58:38 that's awesome 14:58:53 thanks and I will try get it out the base by week end 14:59:11 perfect - drop us a note in the IRC channel when its ready for a look! 14:59:25 OK 14:59:29 ok I think we're out of time - great meeting all, appreciate your time & discussion 14:59:34 have a good week! 14:59:43 #endmeeting