14:04:17 <defionscode> #startmeeting hardening-lockdown merger first steps
14:04:17 <zodbot> Meeting started Wed Oct 17 14:04:17 2018 UTC.
14:04:17 <zodbot> This meeting is logged and archived in a public location.
14:04:17 <zodbot> The chair is defionscode. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:04:17 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
14:04:17 <zodbot> The meeting name has been set to 'hardening-lockdown_merger_first_steps'
14:04:49 <defionscode> if you havent used zodbot before here's a cursory intro https://fedoraproject.org/wiki/Zodbot#Meeting_Functions
14:05:50 <defionscode> #commands
14:05:50 <zodbot> Available commands: #accept #accepted #action #agree #agreed #chair #commands #endmeeting #halp #help #idea #info #link #lurk #meetingname #meetingtopic #nick #rejected #restrictlogs #save #startmeeting #topic #unchair #undo #unlurk
14:05:52 <cloudnull> I need to keep things on IRC today however im open to using bluejeans on future meetings. though I do like the logged aspect of IRC
14:06:36 <defionscode> in attendence we have odyssey4me cloudnull defionscode
14:06:45 <cloudnull> o/
14:06:48 <defionscode> shepdelacreme or mnaser are either of you present
14:06:58 <shepdelacreme> yup
14:07:21 <defionscode> ansible-hardening fellas do you guys need/expect anyone else to proceed?
14:07:31 <cloudnull> mnaser may out, I know he's been abroad recently .
14:08:16 <cloudnull> defionscode nope. odyssey4me?
14:08:24 <defionscode> alrighty, lets get the show on the road, I suppose easiest is to tackle the etherpad in order
14:08:56 <odyssey4me> yeah, I dunno - haven't seen any activity from mnaser yet today - he's been travelling a bit lately though
14:09:07 <defionscode> #topic Documentation
14:10:01 <defionscode> Looking over the etherpad, the bigger challenge is multiple repos
14:10:45 <odyssey4me> Does anyone know of a good way to solve the issue yet, or do we need to ask for someone to do so?
14:11:00 <defionscode> given the upcoming stuff with Mazer (new galaxy) are there any objects at a high level in that we'd need each role to live in it's own repository?
14:11:31 <defionscode> odyssey4me: My inclination is to piggy back of what you guys have already done
14:12:04 <odyssey4me> The thinking then is to have each spec in its own repo, and each have their own docs
14:12:06 <odyssey4me> ?
14:12:20 <defionscode> you have the 'hard part' imo complete, it would be a matter of making the docs build process push doc builds to the same place and have a top-level site that can deterministically point to the diff doc content
14:12:23 <odyssey4me> It's a bit of duplication, but that's OK.
14:12:38 <shepdelacreme> multi-repo is a obviously more work when documenting but also I like the idea of moving to mono-repo for the reasons in the etherpad
14:12:52 <defionscode> we can alternatively have a mono repo for doc purposes?
14:12:54 <cloudnull> do we want to consolidate the AH and AL roles into one?
14:13:10 <shepdelacreme> sorry I don't like the idea of mono-repo
14:13:32 <odyssey4me> Well, given the AL repo uses submodules, we could possibly have the docs content in each submodule but publish it from the parent.
14:13:41 <defionscode> cloudnull: I think they _could_ be conslidated at the doc level, the content would _have_ to be split if we're to be availble on galaxy
14:13:57 <defionscode> by content I mean YAML
14:14:27 <odyssey4me> Ideally the doc content should accompany the code, IMO. Otherwise they drift too easily.
14:14:31 <shepdelacreme> consolidating the docs in the AL repo makes sense to me or what odyssey4me said
14:15:06 <defionscode> the only hard-req is that roles must live in unique repos
14:15:21 <shepdelacreme> what does AH use to generate docs now?
14:15:22 <defionscode> so the decision point is do docs live together or separate
14:15:37 <cloudnull> shepdelacreme sphinx
14:15:37 <defionscode> and i'm inclined to agree with odyssey4me, split docs causes drift for version pinning
14:16:06 <shepdelacreme> I think if we can have the doc content in each repo and then also be able to aggregate/publish it from the AL repo that would be nice
14:16:33 <defionscode> that should be possible
14:16:36 <cloudnull> current AH docs https://docs.openstack.org/ansible-hardening/latest - this is all generated and published by zuul
14:16:49 <odyssey4me> shepdelacreme: yep, I think that can work
14:17:24 <odyssey4me> All the doc publishing config is in https://github.com/openstack/ansible-hardening/tree/master/doc
14:17:42 <shepdelacreme> I'm not a fan of working with sphinx lol but the AH docs are quite nice
14:18:00 <defionscode> it's only a pain initially, afterwords it's fine ime
14:18:04 <odyssey4me> the build is executed by https://github.com/openstack/ansible-hardening/blob/master/tox.ini#L33-L41
14:18:50 <defionscode> #idea each repo contains its own role and the docs for that role
14:19:01 <defionscode> odyssey4me: can you do add linkes with #link <url to link>
14:19:13 <defionscode> so it gets properly added to the zodbot minutes
14:19:15 <odyssey4me> We're happy to roll with whatever for doc building, I think. I guess the advantage of using sphinx is that we already have the module which does the heavy lifting converting the yaml to rst: https://github.com/openstack/ansible-hardening/blob/master/doc/source/_exts/metadata-docs-rhel7.py
14:19:23 <cloudnull> ++
14:19:27 <odyssey4me> #link https://github.com/openstack/ansible-hardening/blob/master/doc/source/_exts/metadata-docs-rhel7.py
14:19:35 <odyssey4me> #link https://github.com/openstack/ansible-hardening/blob/master/tox.ini#L33-L41
14:19:41 <odyssey4me> #link https://github.com/openstack/ansible-hardening/tree/master/doc
14:19:47 <odyssey4me> #link https://docs.openstack.org/ansible-hardening/latest
14:20:16 <defionscode> im on board with piggybacking on AH docs system
14:20:18 <shepdelacreme> odyssey4me yes its quite a nice setup and I think it will be easy for us to adopt into the other roles since you guys have done heavy lift with sphinx already
14:20:25 <defionscode> shepdelacreme: you willing to deal with sphinx?
14:20:33 <defionscode> we can mark that part as resolved if so
14:20:38 <shepdelacreme> yup
14:20:54 <defionscode> #accepted use sphinx + AH tooling
14:21:12 <defionscode> ok then next question
14:21:39 <defionscode> #idea one builder that grabs docs from each builder and generates an ansible-lockdown page that can then link to the docs for each respective role
14:21:55 <defionscode> sorry 'from each builder' => 'from each repo'
14:22:10 <defionscode> cloudnull: odyssey4me shepdelacreme any objections there?
14:22:19 <cloudnull> none from me
14:22:22 <odyssey4me> yeah, I think sphinx has a 'book' concept - so each role can have its own 'book'
14:22:43 <defionscode> #idea use sphinx's book concept; each role is a book
14:22:47 <shepdelacreme> nope that makes sense
14:22:47 <odyssey4me> then for convenience we can have some sort of landing page which directs a user to each book
14:22:48 <defionscode> works for me
14:23:01 <defionscode> odyssey4me: exactly my thought
14:23:06 <defionscode> ok great
14:23:14 <odyssey4me> Makes sense to me.
14:23:26 <defionscode> #agreed build process to go through repos, collect docs, and if possible leverage sphinx books
14:23:43 <defionscode> #agreed a singular landing page/portal that then links to each 'book'
14:24:24 <defionscode> who wants to take point on R&D for 'books'?
14:24:45 <defionscode> I'm happy to volunteer to explore unifying the docs build process
14:25:23 <shepdelacreme> I can work on it as well if you want
14:25:24 <defionscode> shepdelacreme and I can handle making AL docs work like the AH docs currently do, pending books idea validation
14:25:30 <defionscode> ok
14:25:46 <cloudnull> ++ I can partner up on that if needed, but im no sphinx expert :)
14:26:15 <cloudnull> ^ on R&D for sphinx books
14:26:21 <defionscode> #action shepdelacreme defionscode cloudnull to work on unifying build process where each repo has a 'book' or at the very least AH-like content
14:26:42 <defionscode> cloudnull: is anyone a sphinx expert? ha
14:26:58 <cloudnull> definitely not :D
14:27:00 <odyssey4me> Me neither, but I'm happy to assist with any research although I'm quite tied up with other work right now.
14:27:12 <defionscode> cloudnull: the bigger need to determine the LOE for AH docs to use books
14:27:34 <defionscode> b/c right now it isn't a book, right? so the book route would be _some_ level of change for your current build  process
14:27:42 <defionscode> as far as docs go
14:28:18 <odyssey4me> Yeah, I'm not too sure about that. We have some pretty good folks in the OpenStack community who can help figure that out though.
14:28:30 <cloudnull> ++
14:29:36 <defionscode> ok so then we can set that on your plate and ping us as your learn/find out more, short term we can proceed under a no-book assumption and then tweak as necessary later, i imagine it wouldn't be to bad to refactor into a book-based workflow
14:29:50 <defionscode> #action cloudnull odyssey4me to R&D book concept
14:30:26 <odyssey4me> I'd recommend popping into #openstack-doc and asking for help there. The folks are very happy to help when they can.
14:30:57 <odyssey4me> Yep, we can pick that up.
14:30:57 <defionscode> #idea visit #openstack-doc for assistance/guidance on sphinx stuff
14:31:28 <defionscode> ok i think we've exhausted this topic, anyone have anything to add/suggest/etc as it pertains to docs?
14:31:56 <odyssey4me> Nothing from me.
14:32:06 <cloudnull> ^
14:32:14 <defionscode> shepdelacreme?
14:32:25 <shepdelacreme> nope
14:32:44 <defionscode> #topic Implementation Style
14:33:28 <defionscode> alrighty, so atm, AH is 'topical' vs sequential by rule
14:33:39 <defionscode> s/rule/rule id/
14:34:05 <defionscode> on the AH side do you guys see any problem with doing it how AL is doing it?
14:34:24 * odyssey4me does not mind.
14:34:29 <defionscode> which would be my preference mainly from a "if an auditor comes" perspective, being able to line things up nicely
14:35:06 <cloudnull> sounds good to me
14:35:17 <odyssey4me> Yeah, that makes sense I think - although it may make the 'extra' non-auditor bits a bit complicated to place.
14:35:22 <cloudnull> wouldn't be a big lift to change it over
14:35:33 * cloudnull i think
14:35:44 <defionscode> sure, we can always place 'other' stuff in a task file and include it
14:36:04 <shepdelacreme> hmm well what is the intention with regards to AH and the AL RHEL7-STIG roles?
14:36:07 <odyssey4me> I'm looking at https://ansiblelockdown.io/ and can't seem to find where there are actually docs?
14:36:09 <defionscode> we do have prelim.yml for example that isnt 'really' a direct implementation as much as it is there to prep the sytem or collect details
14:36:24 <defionscode> odyssey4me: right now it's just a function of README.md in the repos
14:37:06 <defionscode> #link https://github.com/MindPointGroup/RHEL7-STIG
14:37:08 <odyssey4me> Ah OK, I see. So the docs would be largely all new. That's going to be a substantial bdy of work then.
14:37:08 <defionscode> for example
14:37:58 <defionscode> for us on the AL side yes, but shepdelacreme and I can handle doing it for the roles we have, for RHEL7 STIGing yes we will need a follow on meeting to talk about merging logic it's def not 1:1
14:38:06 <cloudnull> shepdelacreme - good question. I'd personally be inclined to merge the two roles and consolidate the efforts given they're largely implementing the same things.
14:38:46 * cloudnull does not care where the code lives, MidePointGroup or OpenStack is all the same to me
14:38:56 <defionscode> cloudnull: i agree, we would just have an extra.yml or something called from main.yml that is conditionally included when someone wants STIG+ more
14:39:06 <cloudnull> ++
14:39:55 <defionscode> lets not get in the weeds of merging logic at the moment, that will be longer effort to be discussed during another session
14:39:55 <odyssey4me> Yep, no concerns from my side.
14:39:56 <shepdelacreme> you have some openstack reqs though...like you tag AH releases to openstack releases, zuul based testing, etc
14:40:06 <shepdelacreme> so we would need to figure out how that plays out as well
14:40:31 <odyssey4me> Well, we'd retire our repo. We no longer tag it anyway - be consume it via SHA.
14:40:43 <cloudnull> ^
14:40:49 <defionscode> ah well in that case
14:40:51 <shepdelacreme> ah ok
14:41:08 <cloudnull> we also pull it in via `git clone` on just about all of our deployments
14:41:12 <defionscode> #idea AH repo to retire and leverage AL SHA to grab specific commit points of AL stuff
14:41:17 <odyssey4me> We can also then have join testing in our integrated buid - zuul can depend on a github PR, so I don't forsee any issues.
14:41:33 <odyssey4me> *joint
14:41:50 <odyssey4me> Apologies, apparently my typing is a bit terrible. :p
14:41:56 <defionscode> c'est la vie
14:42:12 <defionscode> ok so first decision point, i think we have agreement but want to be explictly sure
14:42:13 <cloudnull> if AL is the successor we port content over. I think the biggest thing for us would be multi-distro support
14:42:39 <defionscode> AH to merge into AL, with important element being multi distro support
14:42:40 <shepdelacreme> ok so the reqs on our side would be to make sure functionally the RHEL7-STIG role can do what the current AH role does - ie "extra" tasks, cross platform support, etc
14:42:43 <cloudnull> we have ubuntu, debian, suse, rhel (cent), gentoo (coming soon), etc.
14:43:08 <cloudnull> what shepdelacreme said :)
14:43:53 <defionscode> ok so based on the etherpad im not sure on somoething
14:44:20 <defionscode> for ubuntu, cloudnull odyssey4me do you guys want to keep it as-is or move toward just doing Ubuntu STIG proper?
14:44:28 <cloudnull> defionscode +1 from me but i'd like to have mnaser weigh in given he's the PTL of OpenStack-Ansible
14:44:50 <defionscode> totally
14:45:03 <cloudnull> I think the RHEL stig is more comprehensive
14:45:12 <cloudnull> ^ personal opinion
14:45:28 <defionscode> #action follow up with mnaser on moving ubuntu way from RHEL STIG standards and deving out a Ubuntu STIG proper role
14:45:40 <defionscode> cloudnull: I havent looked but you're probably right
14:46:02 <odyssey4me> defionscode: well, it's hard to really answer that without knowing the differences...
14:46:27 <defionscode> #action explore differences between Ubuntu and RHEL STIGs
14:46:29 <odyssey4me> However, it probably makes better sense to use the standard for the platform - it'd certainly make the audit review easier.
14:46:29 <cloudnull> I'd be more inclined to keep thins as they are and iterate on the role as needed.
14:46:36 <cloudnull> ^
14:47:29 <defionscode> you fellas know your audience better so I'll defer to your judgement, regardless, we'd probably make an Ubuntu STIG role anyway just b/c it does exist as a standard, whether AH users use that or just use the RHEL7 standard would be their choice
14:47:50 <cloudnull> ++
14:47:51 <shepdelacreme> I think we will most likely be developing an Ubuntu STIG role anyway for our own uses...we can still provide ubuntu support in the RHEL STIG and then you can eval the Ubuntu STIG once its built
14:47:59 <defionscode> right
14:48:30 <shepdelacreme> ah...sorry to repeat verbatim what defionscode said lol
14:48:37 <cloudnull> great minds :)
14:49:42 <defionscode> so on the cross-os support, I imagine there is minimal appetite for supporting those same OSes within containers? or am I mistaken?
14:50:16 <defionscode> #action shepdelacreme defionscode to port over cross-os compat to AL
14:50:22 <cloudnull> we support all of those same OS's in and outside of a container.
14:50:31 <defionscode> ah ok
14:50:31 <cloudnull> however our containers are systemd-nspawn and lxc
14:50:48 <odyssey4me> we only run the role on hosts at this time, but it would probably work on machine containers too - but we don't normally execute it that way
14:50:59 <defionscode> #info AH supports OSes as VMs/metal and as systemdnspawn and lxc containers
14:51:11 <odyssey4me> I think we'd be happy for just host support.
14:51:54 <defionscode> #info AH has primary desire for host support
14:51:58 <cloudnull> sadly i have to run to my next meeting. (i know I'm leaving before time sorry about that). however I agree to anything odyssey4me signs me up for :)
14:52:04 <shepdelacreme> I don't think a lot of people apply a role like this to a container for good reasons. I'm good focusing on shoring up host support primarily
14:52:27 <defionscode> shepdelacreme: are you suggesting we nix container support entirely?
14:52:55 <defionscode> cloudnull: thanks for coming, i'll email out meeting notes and propsed times for a next meeting to finish going over etherpad items
14:52:56 <odyssey4me> defionscode: well, I'm thinking that it is a secondary objective - lower priority
14:52:58 <shepdelacreme> I'm fine with continuing on the path we've taken so far
14:52:59 <cloudnull> good first chat, I'm excited to work with everyone on this
14:53:24 <shepdelacreme> but yes what odyssey4me said
14:53:50 <defionscode> odyssey4me: shepdelacreme so in that breadth does that mean we consider a PR/change 'good-to-go' as long as it passes host testing, regardless of container compat?
14:54:02 <defionscode> breadth/breath
14:55:15 <defionscode> #agreed containers as a secondary objective
14:55:24 <shepdelacreme> no I'm fine with what we do now...if a task fails in a container most of the time we just mark it to be skipped since its most likely an issue with some capability or namespace that containers don't have
14:56:22 <shepdelacreme> I'm also good if people work on making container support for the role more comprehensive but for me its secondary. I just use containers to ease testing
14:56:27 <defionscode> shepdelacreme: odyssey4me what about then if we run tests for containers but just for RHEL/centos and for other containerized OSes we say YMMV?
14:56:49 <defionscode> odyssey4me I suppose that will depend on what your current user base would expect/desire
14:57:57 <shepdelacreme> we will need to test the cross platform support from CI somehow...do we do that in AWS or does it make sense to use containers as well?
14:58:21 <defionscode> it depends on the OS
14:58:27 <shepdelacreme> surprisingly Travis is faster with AWS then it is with docker tests
14:58:33 <defionscode> AH is using Zuul but i have never used but maybe it makes it easier?
14:58:49 <shepdelacreme> yeah
14:59:06 <defionscode> lets table testing implementation for the next meeting, we're at the top of the hour
14:59:14 <shepdelacreme> ok
14:59:16 <defionscode> #action add testing to agenda for next meeting
15:00:19 <defionscode> #idea use AWS or containers for cross-platform support? TBD. Maybe zuul helps?
15:00:33 <odyssey4me> I think we can probably have tests run in OpenStack's infrastructure.
15:00:52 <odyssey4me> So if there's an issue with cost/access/whatever, we can run some tests there.
15:01:08 <defionscode> odyssey4me that would be really nice, how does that play with Pull requests?
15:01:20 <defionscode> ie are you able to test PRs automatically when doing it that way?
15:01:33 <odyssey4me> Currently all Ansible OpenStack modules are tested using zuul and openstack-CI. Let me find an example.
15:01:46 <defionscode> cost isnt' too much of a concern, the spend is very low for us
15:02:15 <defionscode> odyssey4me yeah I noticed that part but wasnt sure about pull requests (ie protecting against a PR doing naughty things against the openstack infra, etc)
15:02:33 <odyssey4me> https://github.com/ansible/ansible/pull/40462
15:03:12 <defionscode> #link https://github.com/ansible/ansible/pull/40462
15:03:13 <odyssey4me> oh, every node in openstack-infra testing is a single use VM - it gets thrown away after the test and is untrusted
15:03:21 <defionscode> ah ok perfect
15:03:30 <defionscode> that would be useful for OSes that arent necessarily in AWS
15:03:37 <defionscode> gentoo for example
15:03:57 <defionscode> #idea use openstack infra for testing cross-os compat
15:04:07 <shepdelacreme> yeah...that would be handy to be able to use the openstack infra/zuul
15:04:43 <defionscode> odyssey4me: shepdelacreme the thing to consider is how molecule _might_ play with this
15:05:06 <odyssey4me> It should be pretty straightforward to get that setup. I think that the AL repositories might need to provide access to zuul to get events. we can work that out when the time comes.
15:05:14 <shepdelacreme> they have a openstack driver
15:05:19 <defionscode> ah
15:05:26 <defionscode> didnt realize molecule already had that
15:05:28 <defionscode> nvm then
15:05:44 <odyssey4me> Well, for molecule you'd just run it as you would on whatever VM you have in any other infra.
15:05:54 <defionscode> #idea use openstack molecule drive
15:06:08 <odyssey4me> The openstack driver wouldn't be used - it is there to create instances in openstack... and we wouldn't be doing that.
15:06:18 <shepdelacreme> ah ok
15:06:21 <defionscode> right, in that sense molecule and zuul conflict
15:06:34 <defionscode> if i understand zuul correctly (very superficial understanding atm)
15:06:46 <defionscode> so molecule for local testing?
15:06:54 <defionscode> zuul for 'real' testing?
15:06:57 <odyssey4me> Well, not really - zuul will give you one or many hosts. You run whatever you need on the host.
15:07:21 <defionscode> odyssey4me: sorry I meant as far as molecule-create goes
15:07:37 <odyssey4me> If the molecule tests can be run by hand on a host of your choosing, then the same mechanism would be used in a VM provided by zuul.
15:07:41 <defionscode> you could still run molecule locally on the zuul provisioned hosts I hink
15:07:44 <defionscode> right
15:07:45 <defionscode> ok
15:07:48 <odyssey4me> yep
15:08:42 <defionscode> #idea have a molecule 'local' job that can be ran in hosts spun up by zuul
15:08:48 <shepdelacreme> I think if you wanted to run molecule locally we would just need to use the 'delegated' driver which lets you skip the create/destroy stuff essentially
15:08:56 <defionscode> right
15:09:01 <defionscode> it's possible IIRC
15:09:12 <shepdelacreme> cool
15:09:26 <defionscode> ok we're over-time, we def didnt cover everything but we should certainly have a follow up
15:09:36 <defionscode> any last words before i have zodbot close up the meeting notes?
15:09:38 <defionscode> shepdelacreme: odyssey4me ?
15:09:50 <shepdelacreme> nothing from me
15:09:57 <odyssey4me> nothing from me
15:10:05 <defionscode> ok great
15:10:07 <odyssey4me> good chat - looking forward to working together!
15:10:13 <defionscode> #idea use delegated drive in molecule
15:10:21 <defionscode> likewise!
15:10:25 <shepdelacreme> same here!
15:10:36 <defionscode> #link https://etherpad.openstack.org/p/ansible-hardening-lockdown-convo1
15:10:44 <defionscode> #endmeeting