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