14:00:17 <dwalt> #startmeeting airship
14:00:20 <openstack> Meeting started Tue Oct 22 14:00:17 2019 UTC and is due to finish in 60 minutes.  The chair is dwalt. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:21 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:22 <dwalt> #topic rollcall
14:00:24 <openstack> The meeting name has been set to 'airship'
14:00:35 <dwalt> welcome everyone! Here is today's agenda: https://etherpad.openstack.org/p/airship-meeting-2019-10-22
14:01:00 <dwalt> we'll give it five minutes for everyone to join, as I see the etherpad is shifting around a bit
14:01:00 <nishantkr> o/
14:01:04 <seaneagan> o/
14:01:26 <uzumaki> o/
14:01:30 <portdirect> o/
14:01:31 <raschid> o/
14:01:38 <aaronsheffield> o/
14:01:59 <alexanderhughes> o/
14:02:01 <ian-pittwood> o/
14:04:53 <jtwill98> meeting
14:05:14 <dwalt> hi jtwill98! Yep, you're in the right place :)
14:05:17 <dwalt> let's get started
14:05:21 <dwalt> #topic KubeCon
14:05:44 <dwalt> If you haven't heard, we are planning to have a "mini" PTG at KubeCon
14:06:23 <dwalt> For that PTG, we have an etherpad. Please feel free to add your name as an attendee if you plan to join. And any topics you'd like to discuss
14:06:23 <dwalt> https://etherpad.openstack.org/p/airship-kubecon-san-diego
14:06:41 <kirandivekar> This is 18th Nov, right?
14:07:00 <dwalt> Right now it's planned for Monday, 12:30-6:30. But we'll start around 1
14:07:03 <howell> o/
14:07:13 <dwalt> kirandivekar: I think that's the date
14:07:19 <dwalt> welcome howell
14:07:40 <dwalt> also it's Cobalt room 501 at the Hilton. Any questions?
14:08:12 <dwalt> fantastic.
14:08:13 <dwalt> #topic Project confirmation
14:08:36 <dwalt> Right now Airship is being pitched for official project confirmation!
14:09:04 <dwalt> The OSF board will vote after the meeting. The outcome can go one of three ways:
14:09:47 <dwalt> Airship will either be confirmed as a result of the meeting, delayed for more discussion, or not confirmed at this time
14:10:09 <dwalt> We hope to have more updates soon
14:10:16 <dwalt> anything on the confirmation?
14:10:41 <alexanderhughes> board meeting is ~2 hours, community update to be sent out with status of confirmation among other topics target end of week/early next week
14:11:21 <dwalt> ty alexanderhughes
14:11:26 <dwalt> #topic Recommend to use Ironic for Redfish support in metal3-io for RAID/BIOS config
14:11:44 <dwalt> revisiting this item from last week. Can someone speak to this one?
14:11:52 <dwalt> uzumaki: I believe that's your color
14:11:52 <uzumaki> This is me, something we discussed last time
14:13:18 <dddpak> yes
14:13:46 <dwalt> Looks like we lost uzumaki
14:13:54 <uzumaki> sorry about that
14:14:00 <dwalt> ah welcome back :)
14:14:21 <uzumaki> so, the thing we talked about last week, should we use metal3->ironic->redfish or metal3->redfish
14:14:30 <uzumaki> first, are there any developments on this?
14:15:16 <dddpak> pramchan worked on this, I guess
14:15:28 <shubham_kaushal> since i am new to airship, I am curious will there be any metal3 version recommended to use?
14:17:05 <dwalt> howell, did any of the metal^3 stuff get merged from last week?
14:17:25 <howell> none of it is merged yet. I'm making it a priority to review today
14:18:05 <nishantkr> uzumaki we have plans to integrate ironic with metal3 and redfish, currently i see the work is ongoing in the airshipctl project to implement the bootstrap command with redfish
14:18:10 <dwalt> ty howell. Unfortunately, mattmceuen couldn't make it today since he is at the confirmation. I'll check with him later and see if he has any updates about the ericsson work he mentioned last week
14:18:43 <nishantkr> shubham_kaushal I don't think we have yet decided on any particular metal3 version to use
14:19:10 <shubham_kaushal> thanks nishantkr!
14:19:28 <AshuKumar> Project specification :  version for GoLang and k8s we are planning to use
14:19:35 <uzumaki> alright, since ironic supports redfish as well, wouldn't it become redundant to implement redfish separately for airshipctl ?
14:20:33 <uzumaki> dwalt, let me know what he says!
14:20:53 <nishantkr> uzumaki That command is for the initial bootstrap of the cluster i.e. bootstrapping your first node
14:21:44 <openstackgerrit> Merged airship/docs master: Add YAML and CRD conventions  https://review.opendev.org/689006
14:21:51 <jtwill98> I think there a lot of experience to learn from in the ironic community, I'm not sure metal^3 has experienced some of the glitches.  I know ironic supports more than just redfish because redfish didn't cover all the hardware config options.
14:22:44 <portdirect> the intent is to make use of that as much as possible
14:22:55 <uzumaki> portdirect, that would be good!
14:22:55 <dwalt> I am not familiar with the details, but if there is an ironic implementation, we should pursue that
14:22:58 <jtwill98> I think redfish is catching up but there may still be some outliers items.
14:23:03 <dwalt> so as to not write multiple drivers
14:23:13 <portdirect> as nishantkr has pointed out, the primary/only use of refish in airshipctl will be to help boostrap the 1st node
14:23:24 <portdirect> so simply, iso mount, and power
14:23:40 <portdirect> after then, we should be making use of metal3/ironic for all actions
14:24:22 <GarimaM44> I am facing issue while deploying Airskiff. The page "https://airship-treasuremap.readthedocs.io/en/latest/airskiff.html" mentions about a script "./tools/deployment/common/005-deploy-k8s.sh" which is missing from the github repository.
14:25:14 <uzumaki> portdirect, as long as we can reuse things in airshipctl, would be easier than reimplementing
14:25:15 <dwalt> hey GarimaM44 -- we're having a meeting right now. Happy to help afterwards :)
14:25:18 <jtwill98> We've been able to Uefi mount nested VMs with the sushy-tools emulator.  We're hoping to have something working with baremetal Dell servers.
14:27:25 <nishantkr> Ashukumar In terms of k8s version we are always trying to use/upgrade to the latest version available, so as of now it would be 1.16
14:29:06 <AshuKumar> nishantkr Thanks. And about GoLang,  1.13 is latest stable version. so it will be good to go with 1.13
14:29:14 <jtwill98> Ironic does offer a lot with regards to discovering node inventory, which will also be nice when it come to validating actual hardware node inventories against node documentation
14:31:00 <rajat143> As we are talking about versions is there any ironic specific version we will be using. Have anybody tried ironic standalone deployment on ubuntu 18.04. Any suggestions.
14:31:21 <portdirect> raschid: the version of ironic is dictated by metal3 support
14:32:05 <portdirect> im using stein on 18.04 in my home lab standalone, but not sure what metal3 is targetting atm, i would have thought master?
14:35:06 <dwalt> at a quick glance, I can't find any specific information. But I imagine portdirect is right
14:35:36 <portdirect> master: https://github.com/metal3-io/ironic-image/blob/master/Dockerfile#L4
14:35:57 <portdirect> oh sorry - train
14:36:20 <dwalt> thanks portdirect
14:36:46 <dwalt> I think we touched on all of the versions questions. Was there anything we missed on this?
14:36:57 <rajat143> Thanks portdirect
14:37:06 <uzumaki> i think this is it
14:37:21 <dwalt> great. And I will update you later on the ericsson stuff uzumaki
14:37:30 <uzumaki> great
14:37:30 <dwalt> #topic Additional Airship cross-project standards [romang, mattmceuen]
14:37:40 <dwalt> hey roman_g: are you out there today?
14:37:48 <dwalt> I assume we are just looking for reviews on these items:
14:38:33 <dwalt> #link https://review.opendev.org/#/c/685049/
14:38:33 <dwalt> #link https://review.opendev.org/#/c/685038/
14:38:33 <dwalt> #link https://review.opendev.org/#/c/689006/
14:38:46 <dwalt> feel free to add any details roman_g
14:39:30 <dwalt> actually, it appears he's not in the channel list. I'll post these with the other review patches later
14:39:40 <dwalt> #topic Ussuri/Shanghai PTG agenda:
14:39:52 <dwalt> #link https://etherpad.openstack.org/p/airship-ptg-ussuri
14:40:37 <dwalt> the etherpad for the upcoming ussuri PTG is live! We'd like to add discussion points and onboarding items to it
14:41:16 <dwalt> We plan to start with and emphasize onboarding in the first portion of the PTG if we have an influx of contributors
14:41:49 <openstackgerrit> Roman Gorshunov proposed airship/docs master: Add container image and Dockerfile conventions  https://review.opendev.org/685038
14:42:10 <dwalt> If we have fewer, we will emphasize the discussion points in the etherpad. We'll also review these items at KubeCon
14:42:45 <dwalt> Any on the upcoming PTG?
14:43:12 <dwalt> #topic Proposal: add new metadata field "peglegStoragePolicy" to documents
14:43:18 <dwalt> alexanderhughes ian-pitwood
14:43:21 <dwalt> floor is yours
14:43:29 <ian-pittwood> hello
14:43:48 <ian-pittwood> so as I understand it we have multiple components trying to use metadata.storagePolicy
14:44:07 <ian-pittwood> Alex wishes to make a separate field in metadata just for pegleg in order to avoid some potential confusion
14:44:52 <ian-pittwood> That way it's clear cut on whether pegleg needs to encrypt a document or not
14:45:18 <dwalt> To be clear, Pegleg is not storing any documents, right?
14:46:10 <uzumaki> I think so, storage is deckhand
14:46:25 <ian-pittwood> No, but it is doing some document management as far as encryption, linting, etc...
14:46:31 <ian-pittwood> storage should be deckhand though, right
14:47:15 <openstackgerrit> Ahmad Mahmoudi proposed airship/shipyard master: (airflow) - Apache airflow uplift to 1.10.4  https://review.opendev.org/689015
14:48:30 <dwalt> So we currently only encrypt documents when the storagePolicy is encrypted? And the Pegleg team wants to add a new field to toggle that behavior for Pegleg?
14:49:21 <ian-pittwood> Yes, the new field would be to indicate whether that data should be encrypted or not by pegleg
14:51:09 <ian-pittwood> And leave storagePolicy for deckhand and barbican
14:51:19 <dwalt> What issues are we having using the same field?
14:51:50 <alexanderhughes> deckhand and barbican both currently use metadata.storagePolicy, the idea is to separate encryption from the multiple services.  pegleg encryption will allow encryption of documents stored in source control.  operators may be having separate ideas on encryption within deckhand or barbican - barbican in particular is a major pain point
14:51:50 <dwalt> Personally, I wouldn't be opposed to adding one if it was appropriately named. But I am not sure I understand the need yet
14:52:44 <alexanderhughes> our current behavior is to encrypt when storagePolicy:encrypted, and when decrypted force it back to cleartext.  but Pegleg shouldn't be manipulating documents.  by adding metadata.PeglegStoragePolicy we would allow operators to choose what encryption(s) are used and when without pegleg modifying documents.  to ensure backwards compatability the default value of this new field would be "cleartext"
14:54:02 <dwalt> I agree
14:54:09 <nishantkr> To me that sounds a valid need and i think we ran into this issue during password rotation
14:54:25 <dwalt> If this allows us to get around the manipulation of documents, that's an easy one
14:55:22 <dwalt> My only suggestion is that the name "PeglegStoragePolicy" is not entirely accurate. As Deckhand owns that field, and it actually stores documents
14:55:41 <dwalt> Something like "PeglegEncryptionPolicy" would be more accurate
14:55:50 <alexanderhughes> peglegEncryption:<true|false> default false ?
14:56:11 <ian-pittwood> I like that
14:56:15 <dwalt> works for me
14:56:30 <alexanderhughes> thanks, I'll take this item and propose a patch soon
14:56:43 <dwalt> sounds good. Thanks for the discussion alexanderhughes
14:57:16 <dwalt> #topic     Leverage Zuul for Unit Tests - Deepak (https://airship.atlassian.net/browse/AIR-61) (copied from announcements)
14:57:28 <dwalt> we are cutting it close, but all yours dddpak
14:57:38 <dwalt> or we can visit this on the next meeting
14:57:49 <dddpak> yes
14:58:06 <dddpak> Approach 1: https://opendev.org/openstack/openstack-helm-infra
14:58:26 <dddpak> we are trying openstack-helm-infra zuul.d
14:58:44 <dddpak> to push for getting ubuntu VM up
14:58:48 <dwalt> do you have a patch?
14:58:52 <dddpak> not yet
14:59:15 <dddpak> but the question is, since we are using zuul3
14:59:44 <dddpak> Can we bringup local node for testing purposes using openstack gerrit as usual??
15:00:18 <dwalt> like a third-party node? I'm not sure that is possible
15:00:27 <dddpak> or may be local CI??
15:00:54 <dddpak> I thought that was possible with zuul3
15:01:06 <dddpak> would be very useful to test patch before submit
15:01:15 <dwalt> dddpak: Sorry, I'm not sure I'm following, and we are out of time. Can we revisit this during the next meeting or in the main channel?
15:01:21 <dddpak> ok
15:01:25 <dwalt> ty
15:01:30 <dwalt> last thing: reviews please!
15:01:32 <dwalt> #topic reviews
15:01:39 <dwalt> #link https://review.opendev.org/#/c/676700/ - Spec: Introduce isogen subcommand for airshipctl
15:01:39 <dwalt> #link https://review.opendev.org/#/c/675851/ - Airshipctl: Add logic to isogen subcommand
15:01:39 <dwalt> #link https://review.opendev.org/#/c/679563/ - Airshipctl: Generate cloud init settings
15:01:39 <dwalt> #link https://review.opendev.org/#/c/685049/ airship/docs Add Ansible code formatting documentation
15:01:39 <dwalt> #link https://review.opendev.org/#/c/682050/ - Airship Images: Initial debian based iso builder
15:01:40 <dwalt> #link https://review.opendev.org/#/c/682354/ - Airship Images: Add basic CI jobs
15:01:40 <dwalt> #link https://review.opendev.org/#/c/686389/ - vBMC emulator environment setup document
15:01:41 <dwalt> #link https://review.opendev.org/#/c/689526/ - Governance update to clarify responsibilities of TC/WC in event of a dispute
15:01:41 <dwalt> #link https://review.opendev.org/#/c/685049/
15:01:42 <dwalt> #link https://review.opendev.org/#/c/685038/
15:01:42 <dwalt> #link https://review.opendev.org/#/c/689006/
15:01:49 <dwalt> thanks for coming everyone. Have a good day!
15:01:54 <dwalt> #endmeeting