14:03:19 <mark-burnett> #startmeeting airship
14:03:20 <openstack> Meeting started Tue Oct 16 14:03:19 2018 UTC and is due to finish in 60 minutes.  The chair is mark-burnett. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:03:21 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:03:23 <mark-burnett> Hey all
14:03:24 <openstack> The meeting name has been set to 'airship'
14:03:32 <mattmceuen> GM!
14:03:38 <aaronsheffield> o/
14:03:39 <seaneagan> o/
14:03:40 <portdirect> w00t
14:04:05 <mark-burnett> The agenda is pretty thin again this week: https://etherpad.openstack.org/p/airship-meeting-2018-10-16
14:04:05 <lamt> o/
14:04:13 <b-str> \o
14:04:59 <hemanth_n> GM
14:05:51 <hogepodge> Hi
14:06:18 <mattmceuen> GM all
14:07:12 <mark-burnett> #topic Wiki
14:07:45 <mark-burnett> mattmceuen: did you add this one?
14:07:47 <mattmceuen> Not sure if Lindsey is here but he got a great start on the wiki
14:07:54 <mattmceuen> Maybe? :)
14:07:59 <mattmceuen> Been a long week
14:08:09 <mattmceuen> Wanted to see if there are any thoughts on a few things:
14:08:33 <mattmceuen> 1) what we can do to improve the content or presentation of the wiki (I know one - logo)
14:09:05 <mattmceuen> 2) any other thoughts on how we can link around to different airship resources to help people get educated fast -- e.g. airshipit.org, gerrit, storyboard etc
14:09:21 <mattmceuen> We have links in there already but I'm interested in feedback
14:10:29 <mattmceuen> One challenge we've had in the past is effectively communicating the different airship community meetings -- hopefully the wiki helps with that
14:10:30 <b-str> Perhaps arrangement based on anticipated audience - already has "contributor" section, but maybe "platform user" section with specific links suited for that?
14:10:31 <evrardjp> o/
14:10:48 <b-str> maybe there are other audiences too
14:11:30 <mattmceuen> I'm thinking that's what the "Try it out" section goes for, but doesn't call out the audience -- maybe we can add a little more content and clarity there
14:11:31 <b-str> Perhaps need to strengthen next steps after "try it out" to be more about "now you really want to use this"
14:11:35 <mattmceuen> ++
14:12:18 <b-str> maybe more on how the releases will be approached rather than just "coming soon"
14:12:30 <b-str> i.e. how do people anticipate our release cycles and etc.
14:12:52 <b-str> Probably needs a "here's what we're looking at as important next"
14:13:02 <b-str> a little bit of roadmapping
14:13:05 <mattmceuen> Agree - I think we just need to flesh that out a bit so we have something to put in there
14:13:20 <b-str> just thoughts...
14:13:34 <mattmceuen> I like the high level roadmapping bit... sort of a carrot on a stick to get people to look in Storyboard
14:13:54 <mattmceuen> Thanks b-str, good feedback, I'll get w/ Lindsey on this
14:14:08 <mattmceuen> That's all from me for this mark-burnett
14:14:20 <mattmceuen> Any other offline feedback welcome on the wiki :)
14:14:23 <mark-burnett> Ok cool
14:14:36 <mark-burnett> #topic Tempest plugin
14:14:46 <mattmceuen> Just a follow on from last week
14:15:02 <mattmceuen> As we decided there's no need to "hold off" on getting the tempest plugin in to openstack infra
14:15:12 <mattmceuen> There's a PS out for that - reviews welcome!
14:15:18 <mattmceuen> https://review.openstack.org/#/c/610175/
14:15:44 <mattmceuen> The intent is to just pull the project as-is (including git history) over to openstack infra and continue it there
14:16:49 <mattmceuen> +1s are valuable, since I made the mistake of submitting that on Friday afternoon, it may have drooped in the review backlog... a +1 (or -1) would give it a bump
14:17:07 <openstackgerrit> Purnendu Ghosh proposed openstack/airship-specs master: Specs for pegleg site manifest generation tool  https://review.openstack.org/605227
14:17:14 <mattmceuen> That's all I got mark-burnett - thanks
14:17:25 <lamt> doesn't tempest plugin usually sit in-tree? or is that project doing some cross airship-projects testing?
14:17:40 <mattmceuen> So it turns out there are several ways to skin that cat
14:17:59 <mattmceuen> And the one that has "won out" is to have a separate repo for a plugin
14:18:09 <lamt> ah
14:18:16 <mattmceuen> There's a cross-project effort to align to that going forward
14:18:48 <mark-burnett> Alright, looks like the last topic that made it in ahead of time:
14:18:52 <roman_g> >> upstream: https://github.com/att-comdev/airship-tempest-plugin.git
14:18:53 <mark-burnett> #topic Spyglass repo
14:19:07 <roman_g> o/
14:19:08 <mattmceuen> thx roman_g
14:19:17 <hemanth_n> We have submitted a blueprint for spyglass - https://review.openstack.org/#/c/605227/
14:19:31 <mattmceuen> oh awesome
14:19:33 <hemanth_n> once the spec is approved, we are looking for process to create new repo airship-spyglass
14:20:06 <mark-burnett> Sounds good to me, I think there is a clear need for a tool like this
14:20:22 <mark-burnett> From my perspective it would be great to have the spec merged first, as creating a repo is usually pretty quick
14:20:32 <mark-burnett> (and non-controversial)
14:20:39 <mattmceuen> +1
14:20:57 <mark-burnett> I will be sure to leave a bit of feedback today on the spec
14:21:33 <hemanth_n> ok thanks... just to know about the process to create repo .. its same as normal openstack project right?
14:21:34 <roman_g> hemanth_n: please, don't ignore comments for your patchset. Address all of them and reply to each of them. There are still issues which have not been changed up on request from Felipe.
14:21:58 <mark-burnett> hemanth_n: once the spec is merged, the core team will help make sure the repo gets created
14:22:00 <hemanth_n> Roman, will be replying to all comments and wil mention Ready for review..
14:22:08 <hemanth_n> ok thanks mark...
14:22:10 <roman_g> ood.
14:22:13 <roman_g> Good.
14:23:14 <roman_g> hemanth_n: to mark PS as not yet ready for review you either set Workflow -1, or add something like [WIP] in title
14:23:25 <hemanth_n> Perfect ..thanks for the tip..
14:24:03 <mark-burnett> Alright, that's it for the list in etherpad
14:24:07 <mark-burnett> #topic Roundtable
14:24:14 <mark-burnett> Any other topics to discuss?
14:24:39 <hemanth_n> one more thing from me on redfish support for bios configuration
14:25:25 <mattmceuen> go for it hemanth_n
14:25:31 <roman_g> mattmceuen , is it really upstream: https://github.com/att-comdev/airship-tempest-plugin.git in https://review.openstack.org/#/c/610175/ ? Wouldn't repo be in git.openstack.org?
14:25:35 <hemanth_n> I would like to maintain the bios settings in site manifests file as a dict and Roman suggested to have it as multi-line string
14:25:59 <hemanth_n> So want to hear others opinion what will be a better approach...
14:26:17 <sthussey> The preference is a YAML mapping anywhere possible
14:26:38 <sthussey> This allows for overriding via deckhand in a granular fashion
14:26:41 <roman_g> Yes. I'm for multiline string, because different vendors have different options for BIOS setup, and I don't want to support mapping between YAML dictionary and vendor-specific options for all vendors.
14:27:06 <mattmceuen> roman_g my understanding of `upstream: https://github.com/att-comdev/airship-tempest-plugin.git` is that that's where the *initial* pull of the code will come from.  You're right that it'll be git.openstack.org after that
14:27:19 <roman_g> mattmceuen: got it. Thank you.
14:27:22 <mark-burnett> If we make it more structured it also allows for easier validation.  It's definitely more expensive when you consider vendor-specific options, but I regret not doing more structured config declarations elswehre
14:27:52 <sthussey> I'd like to focus on just getting the redfish driver merged
14:27:58 <sthussey> BIOS settings are net new
14:28:01 <mark-burnett> That's fair
14:28:36 <mark-burnett> roman_g: IIRC, a follow-on PS eventually occurs to remove that upstream key
14:28:48 <roman_g> mark-burnett: thank you.
14:28:59 <roman_g> now I understand procedure
14:29:06 <mark-burnett> That makes one of us :)
14:29:35 <roman_g> >> overriding via deckhand in a granular fashion
14:29:54 <roman_g> I hope there will be 1 config for one type of baremetal
14:30:27 <roman_g> there wouldn't be overrides per-server
14:30:35 <mark-burnett> roman_g: so Drydock's configuration mechanism actually pre-dates the existence of Deckhand, so it had already implemented some config deduplication features
14:30:53 <sthussey> I would not expect that to be true
14:30:59 <mark-burnett> So you see a BaremetalNode instance that refers to host profiles, etc
14:31:06 <mark-burnett> But you still see a piece of config per server
14:31:23 <sthussey> BIOS settings could absolutely need to be changed in various contexts
14:31:37 <mark-burnett> Which includes ability to specifically override, which is useful for all sorts of operational issues/whatever
14:31:52 <mark-burnett> Right, so no reason to do it differently for bios
14:32:04 <sthussey> The point is you anticipate use-cases you don't predict
14:32:57 <sthussey> One of the worst things I saw in AIC 3.x site definitions was a huge blob of YAML that defined a ton of things
14:33:09 <sthussey> And it couldn't be changed granularly because it was just a large string
14:33:35 <roman_g> git diff would'n satisfy our needs?
14:33:41 <roman_g> *wouldn't
14:33:52 <sthussey> That doesn't allow you to override settings
14:33:59 <roman_g> that's true
14:34:07 <roman_g> What could be overridden?
14:34:19 <sthussey> Any BIOS setting
14:34:24 <roman_g> Per node?
14:34:29 <b-str> is this is a case for more uses of spyglass, to do translation from unstructured to structured bios settings?
14:34:32 <sthussey> Could be in a particular site
14:35:42 <roman_g> All right. I give up =)
14:35:52 <sthussey> Anyway, I don't think this is the correct forum to discuss specs
14:36:01 <sthussey> I think we should keep that discussion in the spec PS to maintain a record
14:36:06 <mark-burnett> Good point
14:36:24 <mark-burnett> ok, any other roundtable topics?
14:36:52 <mattmceuen> not from me
14:37:22 <roman_g> nothing
14:38:42 <mark-burnett> #endmeeting