15:00:14 <mattmceuen> #startmeeting airship
15:00:15 <openstack> Meeting started Tue Nov 12 15:00:14 2019 UTC and is due to finish in 60 minutes.  The chair is mattmceuen. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:16 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:19 <openstack> The meeting name has been set to 'airship'
15:00:21 <mattmceuen> #topic Rollcall
15:00:32 <dwalt> o/
15:00:34 <mattmceuen> Good morning/evening everyone!
15:00:45 <mattmceuen> We'll give it a couple minutes for folks to join us
15:00:47 <dwalt> gm!
15:00:50 <michael-beaver> o/
15:01:08 <mattmceuen> Here's our agenda for today, please add any items you'd like to discuss as a team: https://etherpad.openstack.org/p/airship-meeting-2019-11-12
15:01:48 <mattmceuen> also, please add your name to the Attendees list
15:02:38 <pramchan> #info pramchan
15:03:26 <mattmceuen> Alright - let's get started
15:03:48 <mattmceuen> #topic Daylight Savings / Meeting Times
15:04:15 <mattmceuen> We had a slight bit of confusion around meeting times, because we have a couple of contradictory times:
15:04:37 <mattmceuen> The wiki says "14:00 UTC", but the invite is still 9am US Central Time
15:04:47 <Romik> o/
15:04:48 <pramchan> welcome to global adjustments
15:04:54 <mattmceuen> So with daylight savings coming to an end in the US -- oops :)
15:04:54 <pramchan> 0/
15:05:04 <mattmceuen> pramchan:  I can barely keep up with DST in my own country
15:05:25 <mattmceuen> So I think we should pick one of the two times going forward, and correct the other one
15:05:39 <mattmceuen> It seems like most folks showed up to this current time spot; should we continue with this time?
15:05:50 <pramchan> +1
15:06:02 <santku123> Hi Kanwar
15:06:05 <cps1408> +2
15:06:06 <alexanderhughes> yes, but all the wiki times should be updated, SIGs included
15:06:33 <mattmceuen> Agree alexanderhughes -- I'll take this as an action (circling back with the meeting owners just to confirm first)
15:06:36 <alexanderhughes> and maybe add a note that it changes with DST in the future
15:06:38 <dddpak> +3
15:07:00 <mattmceuen> #action mattmceuen to fix meeting times in wikis to account for DST
15:07:29 <mattmceuen> Thanks all and sorry for any confusion this time.
15:07:31 <mattmceuen> Next up:
15:07:34 <michael-beaver> Will that be for all meetings or just IRC?
15:07:49 <mattmceuen> IRC for sure, all other meetings "probably"
15:08:02 <pramchan> where do we add topics - link?
15:08:16 <alexanderhughes> https://etherpad.openstack.org/p/airship-meeting-2019-11-12
15:08:18 <mattmceuen> I'll try to make sure the invites are correct, in any case (i.e. any changes should get sent out)
15:08:43 <pramchan> santuku123 can you add your topic in etherpad above
15:08:53 <alexanderhughes> propose we send this out to mailing list regardless of changes
15:09:00 <alexanderhughes> just for anyone not here today (still in Shanghai for example)
15:09:18 <mattmceuen> ++
15:09:19 <uzumaki> Guys, aren't we using the DST time for all meetings? Sorry, joined in late
15:09:53 <mattmceuen> uzumaki:  we'll probably adjust all meeting times by 1 hour GMT to account for DST
15:09:55 <alexanderhughes> we had meetings marked as eastern daylight time, and X UTC.  but when DST ended those two numbers no longer matched.  by default people in states just came to the DST meeting cause that's what their calendars updated to
15:10:00 <mattmceuen> But I just need to check with other meeting owners first
15:10:24 <uzumaki> mattmceuen, thanks!
15:10:37 <mattmceuen> sure thing - time zone math is the worst kind
15:10:49 <mattmceuen> #topic PTG / Summit update
15:11:05 <uzumaki> ikr? had to spend a long time coverting all those times to accommodate for DST, made a little table
15:11:28 <mattmceuen> Sorry to put folks on the spot -- but I'd love it if anyone who was at the PTG / Summit could give a couple highlights to catch us up!
15:11:35 <alexanderhughes> sure
15:11:40 <alexanderhughes> we captured PTG notes here https://etherpad.openstack.org/p/shanghai-ptg-airship
15:11:59 <alexanderhughes> couple highlights for 2.0 - we're trying to solve challenges with third party CI, reaching out to a few folks to help us out
15:12:37 <alexanderhughes> had a few questions that need to go back to design calls, raid configuration and the like.  met a few companies looking to adopt Airship
15:13:00 <pramchan> Highlights - 1. Airship 1.0 is difficult to install (Seaworthy - DT)
15:13:04 <openstackgerrit> diwakar thyagaraj proposed airship/porthole master: Add Gate jobs to check docker default apparmor profile  for openstack-utility Containers.  https://review.opendev.org/693748
15:13:38 <hiregoudar> Adoption of airship by companies are very encouraging. Can you pl. let us know who are they and any expectations from them
15:14:11 <pramchan> Highlight 2 - Two strawman proposals were made - one for RAID and ended in requiring flags to be added for MVP hardware Profile
15:14:13 <mattmceuen> alexhughes:  that's awesome to hear - I'll catch up on those notes, looks like you all covered a lot of ground!
15:14:18 <mattmceuen> which is great
15:15:07 <mattmceuen> pramchan:  will the RAID thing need to be coordinated with the Cluster API?  Or only within Airship?
15:16:01 <pramchan> Highlight 3 - metal3.io use of hardware Profile - Kanwar to help in define v1alph2 or v1beta1? for kind: BaremetalHost
15:16:27 <mattmceuen> that's great to hear
15:16:32 <pramchan> https://github.com/metal3-io/baremetal-operator/blob/master/docs/api.md
15:17:12 <mattmceuen> thanks for catching us up, guys
15:18:01 <pramchan> Highlight 4: Lab (thirdparty CI) suggestions and follow ups for lab resources with Ericson/Intel/Troilo
15:18:04 <alexanderhughes> Nippon Telegraph and Telephone was at the PTG for onboarding.  no specific requirements communicated.  still in evaluation period of Airship and doing some research to compare to StarlingX
15:19:25 <pramchan> Nishant, kasper and team did a great job to present Airship community at Summit as well PTG
15:19:27 <alexanderhughes> second company Jan-Erik was working with, have to get with him for details when he returns
15:19:44 <mattmceuen> Also, I haven't seen any of the recordings yet -- if anyone has any favorites (including the project update :) it would be good if we could get a list of recommendations.  Let's add them here:
15:19:46 <mattmceuen> https://etherpad.openstack.org/p/airship-shanghai-recommended-talks
15:19:56 <alexanderhughes> project update was not recorded
15:20:08 <mattmceuen> oh darn
15:20:09 <alexanderhughes> the others will be uploaded in ~1 week according to OSF due to restrictions in China with YouTube
15:20:18 <mattmceuen> ok, got it
15:20:38 <pramchan> Jan-Erik has sent his questions in airship discuss list
15:21:51 <pramchan> Sure we can revisit  at kubecon to summarize and reord if needed
15:22:24 <mattmceuen> Good work team, sounds like it was a very productive time
15:22:50 <mattmceuen> pramchan: that's a great segueway
15:22:55 <mattmceuen> #topic Reminder: KubeCon mini-PTG on Monday
15:23:28 <roman_g> Who is going there to KubeCon?
15:23:29 <mattmceuen> We will continue some of these discussions from the PTG at KubeCon on Monday afternoon next week
15:23:33 <mattmceuen> details here:  https://etherpad.openstack.org/p/airship-kubecon-san-diego
15:23:37 <roman_g> OK
15:23:43 <openstackgerrit> Rahul Khiyani proposed airship/porthole master: Adjust code to project conventions  https://review.opendev.org/691400
15:23:50 <mattmceuen> I will be -- anyone who will be there please add your name to the etherpad^
15:24:07 <roman_g> Sadly can't.
15:24:27 <mattmceuen> We will endeavor to take good notes roman_g
15:24:37 <mattmceuen> My priority this week is catching up on the PTG notes :)
15:25:17 <mattmceuen> Any questions/discussion around KubeCon?
15:25:46 <mattmceuen> ok moving on:
15:25:56 <mattmceuen> #topic If interested in A2.0 bare metal provisioning, watch 11/6 recording
15:26:02 <roman_g> I guess list of talks w/ Airship is somewhere on their website
15:26:26 <mattmceuen> Alan mentioned yesterday that there was some very good discussion around bare metal provisioning in last week's boostrapping SIG call
15:26:50 <mattmceuen> And that it would be a good one to watch the recording of if you'd like to up up to speed on where that's going
15:27:08 <mattmceuen> The recording is linked from roman_g's agenda page:  https://etherpad.openstack.org/p/Airship_bootstrap
15:27:28 <pramchan> Can we move to  adding flag remote action type (Air-82/88)
15:27:48 <mattmceuen> let's give it a minute first
15:28:16 <pramchan> ok
15:28:17 <mattmceuen> any other discussion before we move on?
15:28:35 <mattmceuen> ok!
15:28:38 <mattmceuen> #topic adding flag remote action type (Air-82/88)
15:28:40 <mattmceuen> take it away pramchan
15:28:43 <pramchan> I have note watched it yet as was at PTG will go through it today
15:29:43 <pramchan> Topic - adding falg remote action type
15:29:47 <pramchan> ./airshipctl bootstrap remotedirect --eph-node-id 643e3744-7857-4cf3-995d-e73be2a950a7 --iso-path "http://10.118.135.28/bionicpup64-8.0-uefi.iso" --remote-action-type "ForceOff" --remote-url http://10.118.135.27:8000
15:30:31 <pramchan> default can be reboot, but we need remote-action-type to support other commands
15:30:48 <pramchan> Santosh can you explain?
15:30:52 <santku123> Yes
15:31:39 <pramchan> Why you need this flag?
15:31:40 <santku123> we have /airshipctl bootstrap remotedirect  with no action fflag set performs remote which
15:31:54 <santku123> reboot
15:32:05 <pramchan> ok continue
15:32:25 <pramchan> what else you need to do besides reboot?
15:32:49 <pramchan> can you list other actions?
15:33:02 <mattmceuen> I haven't been really active in the bootstrap conversation, but can you catch me up:  I understand how "bootstrap remotedirect" would remotely boot the iso, but I'm not clear why you would run airshipctl to ForceOff or to Reboot
15:33:02 <santku123> where in we have action type like "ForceOn",GracefullStart,GracefullShutdown,NMI
15:33:34 <santku123> "On",
15:33:58 <santku123> these are the different actions we can perfrom on BMC
15:34:14 <pramchan> Is it terminology issue or is it simply not required?
15:34:26 <mattmceuen> santku123:  would those flags be "passthrough" to the BMC, or would airship additionally do something (like with the ISO etc)
15:35:02 <santku123> it performs action on the BMC
15:35:30 <pramchan> basically does nothing to image per say and is pass through to BMC
15:35:58 <roman_g> That's would be a good discussion topic for the call we will have tomorrow. We would need to support forceoff, reboot, on, and may be something else. We need to be a bit flexible. Why? - because this functionality would be reused for sequenced reboots while preparing bare-metal node for the deployment, and those programmable steps (defined in e.g. yaml format) would be used to update different firmware
15:36:04 <roman_g> (BIOS/iDRAC/RAID array/etc.) on servers and may be run some hardware (HDD/SSD counts, etc.) and connectivity tests (Ethernet/FC/etc.).
15:36:12 <mattmceuen> will those actions fit into the airship bootstrapping workflow?  Or are they just nice to have, utility functionality?
15:36:40 <santku123> if we dont have this we can't test other actions supported
15:37:21 <mattmceuen> Are there any existing utilities that already perform those actions?
15:37:27 <mattmceuen> (for testing purposes I mean)
15:37:28 <roman_g> actions need to be passtrough, but they are rarely changed (defined in Red Fish specs), and airshipctl bootstrap could validate if it thinks that the action syntaxically is correct.
15:38:11 <mattmceuen> My only concern is adding commands to airshipctl only for the sake of testing, which wouldn't be used for provisioning, if that functionality already exists in other commands
15:38:33 <mattmceuen> I might be missing context though
15:38:41 <pramchan> As suggested lets bring to bootsrap SIG call tomorrow and redefine the specs
15:38:50 <mattmceuen> yep that sounds like a plan
15:38:59 <roman_g> mattmceuen: no, doesn't exist yet. And designers want to have a single binary to commant whole fleet.
15:39:06 <mattmceuen> Thanks for bringing this up pramchan / santku123
15:39:17 <santku123> ok
15:39:19 <mattmceuen> gotcha - ok roman_g if that's the direction that's fine with me
15:39:44 <mattmceuen> anything else on this topic?
15:39:56 <santku123> i have on error
15:40:06 <pramchan> Zuul stuff
15:40:07 <santku123> is it fine some expert suggest
15:40:15 <howell> santku123: I've seen your error, it doesn't seem related to your PS
15:40:19 <santku123> the reason
15:40:21 <howell> I'm looking into it this morning
15:40:27 <pramchan> Is there anything Deepak wants to discuss on Zuul Pipeline?
15:40:28 <mattmceuen> yeah, let's transition into Roundtable and discuss that error
15:40:32 <mattmceuen> #topic Roundtable
15:40:37 <mattmceuen> and zuul stuff
15:40:38 <dddpak> yes
15:40:44 <pramchan> go ahead
15:40:50 <santku123> howell: thank you
15:41:00 <dddpak> so far getting up vbmc vm in zuul
15:41:16 <dddpak> I had problems in choosing ip/netmask/gateway/dns
15:41:17 <dddpak> ntp
15:41:19 <dddpak> for backend
15:41:29 <dddpak> if that can be helped
15:41:54 <mattmceuen> We can try!  what was the problem?
15:42:24 <dddpak> john williams wrote a script to start redfish and vbmc_node in separate vms
15:42:36 <dddpak> redfish vms is scripted with station ip details like
15:42:37 <dddpak> ip
15:42:39 <roman_g> dddpak: you can't choose. You will have to bring up VM and then DNAT ports from VM to the nested VM.
15:43:01 <dddpak> ok
15:43:19 <roman_g> IP details of running VM in openstack infra you can get from ansible variables
15:43:27 <roman_g> as usual
15:43:35 <dddpak> as an alternate, I will be trying running sushy-tools with localhost
15:43:42 <dddpak> instead of any ip
15:43:57 <roman_g> that's actually not a bad idea, as long as it all fits to one VM
15:44:19 <dddpak> so far zuul tells it fits
15:44:24 <roman_g> yep
15:44:42 <dddpak> having virsh network issue, will be fixing by tomorrow before re-submit
15:44:58 <dddpak> thats all from me
15:45:00 <dddpak> for now
15:45:08 <mattmceuen> thanks dddpak, roman_g
15:45:23 <pramchan> ok so you going localhost approach
15:45:40 <dddpak> I think that is most sensible for now
15:46:02 <dddpak> and small footprint to be a test
15:46:09 <pramchan> ok tryy it out and submit the patch
15:46:14 <dddpak> usre
15:46:15 <dddpak> sure
15:46:29 <mattmceuen> For review requests -- we had a long list at our last meeting, and a lot of them are successfully reviewed/merged now
15:46:37 <mattmceuen> but we have a number left too:
15:46:42 <mattmceuen> https://review.opendev.org/#/c/679563 - airshipctl  Generate cloud init settings
15:46:43 <mattmceuen> https://review.opendev.org/#/c/682050 - airship/images  Initial debian based iso builder
15:46:43 <mattmceuen> HTK uplifts and new K8s entrypoint image
15:46:58 <pramchan> any other  issues like node definitions in metal3.io for RAID team?
15:47:29 <uzumaki> need to review a bit more on the PTG stuff that happened pramchan, will have something in the bootstrap meeting tomorrow
15:47:32 <pramchan> raschid?
15:48:07 <pramchan> OK lets differ bootstrap and RAID/BIOS issues fro tomorrws SIG call
15:48:15 <mattmceuen> ok sounds good
15:48:40 <pramchan> sure uzumaki
15:48:49 <pramchan> Anything you want to discuss now?
15:49:03 <uzumaki> Not at the tim
15:49:08 <pramchan> ok
15:50:10 <mattmceuen> Any other roundtable discussion or feedback?
15:50:28 <pramchan> can move to next possibly any code reviews requests?
15:51:02 <mattmceuen> I tried to paste them up above, did it not paste?
15:51:19 <mattmceuen> Let me try as a snippet...
15:51:22 <mattmceuen> https://www.irccloud.com/pastebin/04QGf6J2/
15:51:37 <pramchan> OK  I missed that - it did indeed
15:51:55 <mattmceuen> Ok cool, my IRC client has been acting wierd so it could have been me :)
15:52:02 <mattmceuen> any additional review requests?
15:53:36 <mattmceuen> Alright, then I think we can end the meeting -- thanks everyone for the discussion today!
15:53:41 <mattmceuen> Appreciate your time
15:53:45 <mattmceuen> #endmeeting