17:00:31 <hyakuhei> #startmeeting Security
17:00:32 <openstack> Meeting started Thu Oct  8 17:00:31 2015 UTC and is due to finish in 60 minutes.  The chair is hyakuhei. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:33 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:00:35 <openstack> The meeting name has been set to 'security'
17:00:39 <dg_> sup
17:00:41 <hyakuhei> Heyoooo!
17:00:42 <tmcpeak> yo
17:00:42 <tkelsey> o/
17:00:43 <elmiko> o/
17:00:46 <hyakuhei> #chair tmcpeak
17:00:46 <openstack> Current chairs: hyakuhei tmcpeak
17:00:47 <browne> o/
17:00:47 <Michaelxin> Hi
17:00:49 <ccneill> hola
17:00:56 * mhayden stumbles in :)
17:01:05 <tmcpeak> hey mhayden, good to see you
17:01:06 <hyakuhei> Welcome mhayden :D
17:01:17 <bknudson> hi
17:01:19 <Michaelxin> Welcome major
17:01:23 <mhayden> thanks! :)
17:01:27 <yaya> Hey mhayden
17:01:28 <ccneill> lotsa Rackers today
17:01:28 <mvaldes> howdy
17:01:30 <hyakuhei> major is our special guest star this week :)
17:01:30 <yaya> :)
17:01:40 <elmiko> ooh, cool
17:01:46 <hyakuhei> Agenda #link https://etherpad.openstack.org/p/security-20151008-irc
17:01:51 <Michaelxin> +1
17:01:58 <hyakuhei> ^ Was feeling sooper organized this morning :)
17:01:59 <redrobot> o/
17:02:06 <hyakuhei> Hey redrobot
17:02:15 * redrobot waves at hyakuhei
17:02:23 <hyakuhei> Do you have the link for that service authentication using PKI spec thing ?
17:02:46 <tmcpeak> hyakuhei: is there an agenda item for mhayden's stuff?
17:02:49 <redrobot> hyakuhei https://review.openstack.org/#/c/222293/ ?
17:03:05 <hyakuhei> tmcpeak: Yes
17:03:09 <tmcpeak> oh sorry, the end
17:03:11 <tmcpeak> I don't read gud
17:03:11 <hyakuhei> It’s right there on the agenda :P
17:03:19 <hyakuhei> Tis ok, you’re still young.
17:03:26 <tmcpeak> ;)
17:03:29 <hyakuhei> redrobot: that’s the one thanks!
17:03:58 <hyakuhei> ok, lets get the ball rolling with Anchor then
17:04:02 <hyakuhei> #topic Anchor
17:04:16 <hyakuhei> Not much to report, I think we’ve all been working on other things
17:04:32 <hyakuhei> dg_: has been doing some interesting related work thats further down the agenda.
17:04:44 <hyakuhei> The ACME spec is interesting for anyone who cares to look
17:04:55 <hyakuhei> tkelsey: dg_ anything anchor-ish to add?
17:05:08 <tkelsey> not too much, rebased a few patches, thats about i t
17:05:20 <dg_> hyakuhei I dont think so, we bust out the validators, but i think that was last covered in last wweks meeting
17:05:30 <redrobot> hyakuhei +1 on ACME being interesting
17:05:33 <hyakuhei> There’s a few open reviews that need addresssing
17:05:45 <tkelsey> we have looked at pulling some for the validator functionality into a reusable package
17:05:49 <redrobot> hyakuhei any plans for ACME support in Anchor?
17:05:51 <Michaelxin> Did Tim use on metal server to test user cases?
17:06:01 <hyakuhei> redrobot: No immediate ones
17:06:02 <tkelsey> Michaelxin: no not yet ;9
17:06:04 <tkelsey> :(
17:06:09 <tkelsey> been short on time
17:06:17 <dg_> Michaelxin on metal server?
17:06:22 <Michaelxin> Ion worry.
17:06:45 <Michaelxin> yes
17:06:53 <hyakuhei> Though actually, given the dynamic AuthZ nature (validators) of Anchor, it could actually make a lot of sense, depending on the tertiary proof of ownership methods outlined in the ACME standard
17:07:28 <hyakuhei> ok, rolling on to Killick (where ACME will still be relevant)
17:07:33 <hyakuhei> #topic Killick
17:07:39 <dg_> michaelxin got a link? google doesnt have anything much on that
17:07:41 <hyakuhei> spec #link #
17:08:01 <hyakuhei> Stupid etherpad is stupid… link  https://review.openstack.org/#/c/231955/
17:08:10 <hyakuhei> shohel: !!!
17:08:16 <shohel> hi
17:08:42 <dg_> hey shohel
17:08:45 <hyakuhei> Hey, welcome buddy, @everyone shohel is the main guy that drove the Keystone TA work
17:08:49 <Michaelxin> http://www.rackspace.com/en-us/cloud/servers/onmetal
17:08:57 <dg_> thanks michael
17:09:09 <dg_> so Killick
17:09:19 <Michaelxin> Any time
17:09:20 * elmiko waves to shohel
17:09:41 <tmcpeak> welcome back shohel
17:09:58 <hyakuhei> So dg_ please tell us all about killick
17:10:01 <elmiko> hyakuhei: where was the ACME spec?
17:10:08 <elmiko> (sorry for the interruption)
17:10:42 <redrobot> elmiko https://letsencrypt.github.io/acme-spec/
17:10:50 <elmiko> redrobot: thanks!
17:11:49 <dg__> back again, sorry IRC dropped out
17:12:04 <hyakuhei> No worries, we waited for you
17:12:15 <dg__> no worries
17:13:02 <dg__> so we talked about killick briefly a couple of weeks back, the idea is that its a very lgihtweight CA/RA, which can be deployed with minimal infrastructure to build an internal PKI
17:13:18 <dg__> as an alternative to MS ADCS/dogtag/ejbca, but much lighter weight and without any licensing costs
17:13:40 <tmcpeak> no licensing costs is good
17:13:45 <dg__> I've pushed a spec up to the security-specs repo and would appriciate feedback
17:14:08 <dg__> tmcpeak - I dont want to have to tell customers they need a MS windows license to deploy openstack because PKI
17:14:09 <redrobot> dg__ as mentioned last time, I would rather see this work done in Barbican
17:14:20 <tmcpeak> dg__ ++
17:14:25 <hyakuhei> redrobot: why?
17:14:25 <dg__> redrobot feel free to pull in the validation functionality
17:14:36 <dg__> its seperated in anchor
17:14:53 <redrobot> I think validation will be useful to us
17:14:57 <hyakuhei> Validators, which are really “policy” should probably be enforced at the RA
17:15:10 <hyakuhei> redrobot: They’re broken out of Anchor now, you can use them already :)
17:15:12 <Michaelxin> The link to your spec? Please
17:15:14 <redrobot> I'm concerned about adding yet another CA API to OpenStack
17:15:45 <hyakuhei> Big-Tent baby ;)
17:15:57 <elmiko> #link https://review.openstack.org/#/c/231955/
17:16:00 <elmiko> Michaelxin: ^
17:16:11 <dg__> elmiko ty
17:16:29 <Michaelxin> +1
17:16:34 <hyakuhei> Though I do appreciate the concern, now there’s no reason things cant plug into x,y,z like I’d expect Killick to sit behind Barbican and to have a barbican plugin built alongside it as development progresses
17:16:38 <Michaelxin> Ty
17:16:43 <redrobot> hyakuhei sure, there's a huge tent now... but I think it would make it more difficult for projects to add CA support if they have to do so across 3 different APIs
17:16:56 <hyakuhei> Agreed
17:17:45 <dg__> redrobot agreed, but i think theres a very clear distinction for the use-cases
17:17:55 <elmiko> redrobot: is this a situation where castellan, or something similar, could be used to create a useful abstraction? (or is that barbican)
17:18:15 <hyakuhei> Castellan is the abstraction in front of the abstraction that is Barbican…
17:18:18 <hyakuhei> So possibly?
17:18:20 <elmiko> lol
17:18:49 <redrobot> we've gone down that road... I think it would be difficult to provide a one-size-fits-all abstraction on top of a CA
17:18:51 <elmiko> the cert stuff had come up in castellan before, but i think it was a different use case. which is why i mention "or something similar"
17:19:18 <elmiko> redrobot: ack
17:19:25 <hyakuhei> redrobot: last I read (which was some time ago) Barbican still wanted to be the middlman to various certificate authorities?
17:19:35 <redrobot> dg__ so a deployer interested in both Killick and Anchor and Barbican use cases would still have to deploy all 3
17:19:36 <dg__> redrobot anchor is ideally suited for node-node communications, or instance to instance communications, killick is for when you want to have a bit more oversight of whats being issued manually, where you want more functionality than just issuing a self-signed cert with openssl, but without the extra functionality of a barbican CA
17:20:12 <dg__> potentially, depending on the functionality he needed
17:20:16 <redrobot> s/both/all
17:20:20 <mvaldes> is it worthwhile to document how these systems differ, can integrate and where they overlap
17:20:28 <elmiko> mvaldes: +1
17:20:32 <tmcpeak> +1
17:20:46 <tmcpeak> this might get rat-hole-y but I'm interested
17:20:48 <Michaelxin> +1
17:20:52 <elmiko> (even if just on the wiki)
17:20:52 <ccneill> Venn diagrams! :)
17:20:54 <hyakuhei> mvaldes: +1
17:20:58 <dg__> Im unaware of the state of the art with barbican as a PKI, I havent tried to deploy it in 6 months or so, but last time I looked, it didnt seem to be something I could use as an alternative to ADCS
17:21:11 <dg__> mvaldes +1
17:21:12 <hyakuhei> I’ll make some time for it in my summit talk, a slide on what’s available PKI wise today.
17:21:20 <Michaelxin> Anyone is using killick in production?
17:21:24 <hyakuhei> It’s a spec
17:21:28 <hyakuhei> so no :)
17:21:36 <hyakuhei> or “god I hope not..."
17:21:52 <mvaldes> i think ccneill can help with the barbican side of it
17:21:54 <mvaldes> :)
17:21:56 <redrobot> dg__ so barbican is not itself a CA.  And I do believe that having a CA that you can stand up for free is valuable.  The part I don't like is that it having an api that competes with the Barbican API
17:22:10 <redrobot> dg__ I would prefer to see killick as a backend to Barbican
17:22:11 <hyakuhei> So I think it should go both ways
17:22:21 <hyakuhei> Those who only want one type of CA can have it
17:22:33 <hyakuhei> Certainly don’t want a lightweight CA to require Barbican in order to deploy
17:22:36 <hyakuhei> That’s dumb
17:22:38 <ccneill> mvaldes: pretty sure redrobot is the better person to expound on barbican, though I'm happy to help wherever I can
17:22:50 <dg__> redrobot does barbican have a gui I can log into, view the status of a certificate request that has been submitted by a user, and issue or deny the certificate?
17:22:54 <hyakuhei> but where there’s a few different CA use cases, being able to put them behind barbican makes a lot of sense.
17:23:40 <redrobot> dg__ no... again Barbican is currently not a CA, so we are not concerned with Cert Issuance beyond getting a status from the CA
17:24:20 <dg__> so if I want to issue a certificate, I request it from barbican as a user? then barbican passes the request to killick?
17:24:40 <redrobot> dg__ yes, that's the workflow for Public CAs right now.
17:24:51 <redrobot> dg__ dogtag for example.
17:25:17 <dg__> yup
17:25:18 <redrobot> dg__ user interacts with Barbican, Barbican talks to DogTag... DogTag admins do their thing directly with DogTag.
17:25:48 <hyakuhei> Depends if you’re intending this to be an as-a-Service for users of your cloud or more of an under-cloud infrastructure type component I guess.
17:25:51 <dg__> that feels like a load of extra abstraction when all I want to do is to curl a CRL to a url...
17:26:14 <hyakuhei> I think there are use cases for both
17:26:15 <redrobot> dg__ you'll still be curling a CRL to a barbican URL
17:26:28 <dg__> ok cool
17:27:00 <hyakuhei> but if killick has a decent stabilized API I can’t see why it would have to be tightly coupled with Barbican? Though I would certainly encourage people to write a Barbican plugin for it
17:27:13 <mvaldes> hyakuhei: should we set an action item for documentation of barbican, anchor, killick? i can see these questions coming up a lot
17:27:26 <redrobot> hyakuhei my main concern is for projects having to make a decision on whether they need to integrate with Barbican or with Killick
17:27:53 <hyakuhei> My main concerns is making sure they have that option I think
17:27:53 <elmiko> a solid concern
17:28:02 <dg__> redrobot - i see this as more of a anchor or !anchor descision
17:28:16 <hyakuhei> Although, pretty quickly you end up with another Castellan situation I guess.
17:28:24 <redrobot> hyakuhei and if projects start diverging, some integrate with Barbican, some integrate with Killick, then deployment becomes a pain in the rear
17:28:25 <dg__> as otherwise, you just want a traditional certifcate, which means generating a CRL and curling that to an interface somewhere
17:28:25 <hyakuhei> dg__: Is the plan to support Keystone AuthN ?
17:28:28 <dg__> yep
17:28:47 <dg__> I have a place holder in the spec for thinking about auth, as I havent addressed that yet
17:28:54 <hyakuhei> redrobot: Sure does but there’s no way we’d tell DogTag that it has to integrate with Barbican
17:28:55 <tmcpeak> guys this is good stuff but we should probably move on
17:29:00 <hyakuhei> tmcpeak: +1
17:29:05 <tmcpeak> we still have a large agenda and want to make sure to get to mhayden
17:29:07 <hyakuhei> ML or #openstack-security
17:29:16 <mhayden> no worries if i'm left off ;)
17:29:19 <tmcpeak> hyakuhei: +1
17:29:22 <hyakuhei> nonesense.
17:29:32 <redrobot> one last thing:
17:29:52 <redrobot> I would reconsider my opposition to Killick if the API is ACME compliant.
17:30:05 <dg__> redrobot that is the plan, going forwards at least
17:30:08 <hyakuhei> Fair enough :) worth considering
17:30:11 <hyakuhei> Righto
17:30:21 * hyakuhei bumps OpenStack-Ansible-Security
17:30:23 * redrobot will read the spec
17:30:27 <hyakuhei> #topic Ansible-Security
17:30:30 <hyakuhei> #link https://review.openstack.org/#/q/status:open+project:openstack/openstack-ansible-security,n,z
17:30:40 <hyakuhei> mhayden: what’s all this about then ? :P
17:30:48 <tmcpeak> +1
17:30:51 <tmcpeak> this looks interesting
17:31:05 <mhayden> ah yes -- so the general idea is in the spec
17:31:07 <mhayden> let me dig up the link
17:31:30 <mhayden> http://specs.openstack.org/openstack/openstack-ansible-specs/specs/mitaka/security-hardening.html
17:31:35 <mhayden> #link http://specs.openstack.org/openstack/openstack-ansible-specs/specs/mitaka/security-hardening.html
17:31:55 <elmiko> interesting... and cool
17:31:57 <mhayden> the goal is to provide some level of security hardening for the hosts that run an OpenStack infrastructure
17:32:02 <mvaldes> mhayden: good stuff!
17:32:02 <mhayden> and something auditable
17:32:08 <tmcpeak> awesome, and Ansible based?
17:32:14 <mhayden> so we went with the RHEL 6 STIG since it's public domain content
17:32:17 <mhayden> yes, it's ansible
17:32:22 <mhayden> meant to go hand in hand with openstack-ansible
17:32:24 <dg__> good work
17:32:25 <tmcpeak> cool, Ansible seems perfect for this
17:32:40 <mhayden> currently, it's in a WIP state with maybe 80 controls left to assess out of 270-ish total
17:32:41 <Michaelxin> Cool
17:32:47 <bknudson> is there any testing implemented for this?
17:32:53 <mhayden> translating RHEL 6 STIGs into Ubuntu 14.04 is... interesting
17:32:59 <bknudson> as in, something that checks the system after it's deployed
17:32:59 <mhayden> bknudson: the idea is to make a XCCDF for OpenSCAP
17:33:14 <tmcpeak> mhayden: yeah, for sure, I bet that's time consuming
17:33:19 <tmcpeak> have you had any that just don't translate
17:33:20 <tmcpeak> ?
17:33:25 <bknudson> ah, alphabet soup
17:33:25 <mhayden> putting enterprise security around Ubuntu 14.04 is a bit like putting a sweater on a cat -- you know it can be done, but you will get scratched in the process :)
17:33:35 <mhayden> tmcpeak: yes, some don't translate
17:33:45 <mhayden> there are docs for each and every change made
17:33:55 <mhayden> http://openstack-ansible-security.readthedocs.org/en/latest/
17:34:04 <hyakuhei> mhayden: how much of that is 14.04 _specific_ or just dealing with more general Ubuntu idiosyncracies?
17:34:04 <mhayden> (there will be a formal home for those docs soon)
17:34:11 <tmcpeak> this looks like a ton of work
17:34:13 <fungi> i have a feeling there's also some missing coverage when translated to a new platform with different defaults
17:34:19 <hyakuhei> +1
17:34:21 <mhayden> hyakuhei: Ubuntu 14.04 specific for now, because that's what openstack-ansible supports :(
17:34:43 <tmcpeak> mhayden: just two of you working on it?
17:34:44 <mhayden> fungi: very true -- those are tough to catch but the STIG is quite comprehensive
17:35:05 <mhayden> tmcpeak: mainly met at the moment, but i have some help from a coworker occasionally
17:35:12 <mhayden> he's tasked with some other things
17:35:34 <tmcpeak> I really like this idea
17:35:41 <hyakuhei> Very interesting, I don’t have any ansible experience. Not sure what the rest of the team is like.
17:35:48 <mhayden> general process going forward: 1) get all the controls in there, 2) refactor where it makes sense, 3) get some kind of auditing
17:35:49 <tmcpeak> I'm personally interested in helping with this, and I suspect others here might be too
17:35:55 <Michaelxin> My team can help. Major.
17:35:57 <mhayden> one idea is to do ansible-playbook with -C for auditing
17:35:59 <hyakuhei> Well, not a lot of hands-on. I’d like to upskill on it too
17:36:15 <tmcpeak> hyakuhei: Ansible is worth learning for sure
17:36:27 <mhayden> the biggest help i need now is on reviews
17:36:29 <Michaelxin> +1
17:36:33 <mhayden> to ensure i'm meeting the spec of the STIG properly
17:36:40 <mhayden> or documenting the exceptions well enough
17:36:49 <tmcpeak> mhayden: I'll carve a few hours to work on this
17:36:56 <mhayden> i hope to have the remainig controls into the repo by next wed
17:36:59 <tmcpeak> please add me to any reviews that could use help
17:36:59 <yaya> happy to help mhayden
17:37:00 <mhayden> or at least proposed
17:37:06 <mhayden> thanks, everyone!
17:37:12 <hyakuhei> tmcpeak: I have a working knowledge for auditing things but don’t want other people to have to rely on my recipies …
17:37:14 <mhayden> reviews remaining-> https://review.openstack.org/#/q/status:open+project:openstack/openstack-ansible-security,n,z
17:37:21 <tmcpeak> hyakuhei ;)
17:37:23 <bknudson> this is great
17:37:35 <mhayden> there's a push to get OSAD possibly onto Fedora/RHEL/CentOS from what i hear
17:37:39 <mhayden> so that could expand the role a bit
17:37:46 <mhayden> since no stig exists for RHEL/CentOS 7
17:37:48 <hyakuhei> Yeah I think it’s going to be super useful. What project is the repo under at the moment ?
17:38:03 <mhayden> hyakuhei: https://github.com/openstack/openstack-ansible-security
17:38:08 <tmcpeak> mhayden: I will take a crack on these tomorrow morning
17:38:10 <mhayden> it's a child under openstack-ansible
17:38:14 <mhayden> tmcpeak: many thanks!
17:38:26 <tmcpeak> mhayden: thanks for getting this going, and open source
17:38:30 <tmcpeak> this will be really valuable for security
17:38:31 <mhayden> no problem
17:38:38 <browne> very interesting
17:38:40 <mhayden> we tried to do CIS, but that kinda fell apart due to licensing + terms of use :/
17:38:45 <hyakuhei> tmcpeak: This might make another interesting article
17:38:46 <elmiko> tmcpeak: +1
17:38:51 <hyakuhei> mhayden: I meant more in terms of http://governance.openstack.org/reference/projects/index.html
17:38:54 <tmcpeak> hyakuhei: +1
17:39:01 <mhayden> hyakuhei: openstackansible
17:39:05 <hyakuhei> ah sorry I see above it’s under openstack-ansible :)
17:39:10 <bknudson> sorry, no security, need a license for that
17:39:13 <mhayden> that's okay -- i'm typing fast! :)
17:39:35 <mhayden> i sent mail to legal-discuss about CIS and discussed it with CIS directly -- sounds like a no-go
17:39:36 <hyakuhei> So I think we’re all agreed this is exciting stuff
17:39:41 <tmcpeak> this seems fairly labor intensive, but once we have it should be hugely beneficial for everyone
17:39:42 <hyakuhei> :(
17:39:43 <mhayden> awesome
17:39:45 <elmiko> hyakuhei++
17:39:52 <mhayden> well hopefully i can join the meeting next week and report some nifty progress ;)
17:39:57 <mhayden> thank y'all for the time during your meeting
17:40:00 <hyakuhei> I wonder what the matintainence / testing burden wil lbe like
17:40:09 <elmiko> thanks for the intro mhayden =)
17:40:15 <mhayden> de nada :)
17:40:15 <tmcpeak> hyakuhei: I could see setting up automation for testing easily
17:40:37 <tmcpeak> the big thing is going to be absorbing new OS and stigs
17:40:43 <mhayden> tmcpeak: current openstack-ansible PTL has a review in with os-infra for automated testing
17:40:57 <tmcpeak> mhayden: oh awesome, way ahead already then :)
17:41:08 <hyakuhei> cool
17:41:23 <Michaelxin> +1
17:41:24 <mhayden> tmcpeak: odyssey4me gets the credit there ;)
17:41:35 <hyakuhei> Ok, I think we need to press on
17:41:38 <bknudson> I change my vote from this is "great" to this is "awesome"
17:41:43 <mhayden> haha thanks, bknudson
17:41:45 <elmiko> lol, nice bknudson
17:41:48 <hyakuhei> Thank you mhayden - extremely interesting work!
17:41:53 <tmcpeak> lol
17:41:53 <mhayden> you're welcome
17:41:56 <tmcpeak> yeah good stuff
17:42:01 <tmcpeak> looking forward to getting involved in this
17:42:06 <hyakuhei> #topic Bandit
17:42:11 <hyakuhei> #link https://review.openstack.org/#/q/bandit+status:open,n,z
17:42:17 <tmcpeak> tkelsey: roll it
17:42:19 <hyakuhei> tmcpeak tkelsey
17:42:34 <tmcpeak> we're looking to push a new version like… now
17:42:35 <tmcpeak> 0.14.0
17:42:45 <tmcpeak> scrambling to get docs and other outstanding changes and bug fixes
17:42:59 <tmcpeak> once those are done (hopefully tomorrow) I'll run through testing using our new tool
17:43:03 <tmcpeak> then push 0.14.0
17:43:06 <elmiko> nice
17:43:35 <tkelsey> hey
17:43:38 <tkelsey> sorry
17:43:39 <tmcpeak> there he is
17:44:00 <elmiko> tkelsey, coding in the other conference room as usual? ;)
17:44:02 <tkelsey> yeah im pushing on docs to get as muh in for a version we plan to roll tomorrow
17:44:11 <tkelsey> elmiko: lol :)
17:44:52 <hyakuhei> Cool, anything else ?
17:44:53 <tkelsey> we have a lot of stuff building up, so now is a good time to push a new version, we have just been waiting on the docs really
17:45:19 <hyakuhei> (We’ve got a lot of agenda to run through thanks to the spirited Killick debate and the ansible awesomeness)
17:46:00 <hyakuhei> I guess that’s that for Bandit?
17:46:00 <tmcpeak> that should be about it
17:46:02 <tmcpeak> roll it ;)
17:46:04 <hyakuhei> cool :)
17:46:11 <tkelsey> yup thats it
17:46:17 <hyakuhei> #topic OSSN
17:46:20 <hyakuhei> #link https://review.openstack.org/#/q/status:open+project:openstack/security-doc,n,z
17:46:41 <hyakuhei> Not too many left open now (that’s the whole security doc project, wasn’t sure how to filter it)
17:46:59 <browne> OSSN-0057 could use some love
17:47:05 <hyakuhei> In the interests of time I’ll just say please take a look through over coffee and see if anything obviously needs a -/+1
17:47:18 <hyakuhei> #link https://review.openstack.org/#/c/219901/
17:47:25 <elmiko> browne: ack, added to the queue ;)
17:47:33 <hyakuhei> thanks browne  I’ll take a look tomorrow too
17:47:44 <hyakuhei> sicarie: Anything to report on dox?
17:48:10 <hyakuhei> Hmm, I guess not (good time-saving skills!)
17:48:11 <sicarie> We've identified the case studies and the security checklists as our "must-have's" before the Tokyo summit
17:48:15 <sicarie> Sorry, was typing
17:48:26 <sicarie> I think compute is pretty much updated
17:48:27 <hyakuhei> oh cool
17:48:48 <sicarie> And I'll be messing with rst2pdf for the week before the summit, try to get the leaf version out around that time
17:49:01 <hyakuhei> Sounds great!
17:49:02 <hyakuhei> Right guys, I’m going to move to the most important thing next because we need to discuss or at least start to discuss
17:49:07 <hyakuhei> #topic SummitSched
17:49:20 <hyakuhei> Please take a look at #link https://etherpad.openstack.org/p/security-mikata-scheduling
17:50:41 <hyakuhei> Add your name at the bottom of you’re going to be in Tokyo and add a suggestion for fishbowl/worksessions
17:50:59 <hyakuhei> I’ve added would-attend too so you can “vote”
17:51:12 <hyakuhei> basically put your name against anything you think is a good idea
17:51:15 <tmcpeak> I'm tempted to get one of those hokey telepresence robots and terrorize the security fishbowls
17:51:29 <hyakuhei> tmcpeak: excellent contribution :P
17:51:33 <tmcpeak> lol
17:51:36 <fungi> you can always do that whether or not you also attend
17:52:01 <fungi> (might be a novel way to multi-task several sessions simultaneously)
17:52:07 <tmcpeak> +1
17:52:19 <hyakuhei> yeah
17:52:30 <hyakuhei> you don’t have to be going to mark “would attend” next to things :)
17:52:39 <hyakuhei> It’s just a +1 field basically
17:53:11 <bknudson> does this etherpad also include the vmt? there's usually a session for vmt discussion
17:53:13 <hyakuhei> So please, especially if you’re going. Make suggestions, I want to get them into the planner by the end of this week. Where there are obvious choices I’ll make them. Where there aren’t we’ll discuss on the ML prior
17:53:46 <hyakuhei> bknudson: There should definitely be some VMT space there. I’m presuming fishbowl is the preferred option @fungi
17:53:56 <hyakuhei> Although the last session would have fit in a workroom fine
17:54:09 <hyakuhei> I think there are some spare workrooms we can request if required
17:54:17 <michaelxin2> will we have IRC room open for people not in Tokyo?
17:54:17 <bknudson> I hear the workrooms are pretty small this time, 8-10
17:54:29 <hyakuhei> michaelxin2: #openstack-securty?
17:54:38 <tristanC> hyakuhei: bknudson: it seems like vmt might share the room with stable release session
17:54:39 <fungi> hyakuhei: we chatted amongst the vmt and are content to wrap those discussions up in other sessions or punt to the ml
17:55:02 <tristanC> or that :)
17:55:09 <hyakuhei> So long as you’re sure, we’re happy to give time over to VMT activities, they’re pretty critical]
17:55:12 <hyakuhei> hey tristanC  :)
17:55:24 <fungi> a lot of what we've discussed in past vmt summit sessions have been redundant with or closely linked to stable branch management discussions anyway
17:55:54 <fungi> but i could see it also possibly fitting into the "how should the project serve the community" session or something
17:56:10 <hyakuhei> ok great
17:56:40 <elmiko> hyakuhei: i like "Re-entrant policy management for on-cloud applications" good name ;)
17:56:40 <fungi> the vmt has been making pretty steady progress on transparency without needing to hold discussion to the summit anyway
17:56:40 <hyakuhei> We’re running out of time, please do suggest sessions peoples (It’s hard with the asian conferences because a lot fewer devs/cores will be there)
17:56:51 <bknudson> is there any specific vmt work that we could maybe make progress on in a workroom? e.g., docs
17:56:59 <hyakuhei> elmiko: You write the slides, leave the snazzy naming to me ;)
17:57:12 <tmcpeak> lol
17:57:14 <elmiko> lol
17:57:15 <michaelxin2> Do we have flyer for OpenStack Security Group?
17:57:25 <fungi> bknudson: maybe, but most of that we hack on all cycle so i wouldn't want to take up a workroom slot if there's something else worthshilw
17:57:25 <michaelxin2> if yes, we can handle out for some conference here.
17:57:27 <hyakuhei> michaelxin2: Nope, we have a deck though :)
17:57:29 <fungi> er, worthwhile
17:57:35 <hyakuhei> That’s an interesting idea
17:57:38 <hyakuhei> I like that a lot
17:57:40 <tmcpeak> +1
17:57:46 <hyakuhei> We can get them out on the security track
17:58:01 <tmcpeak> great idea
17:58:03 <hyakuhei> Anyone got a pet graphic designer?
17:58:09 <hyakuhei> ML discussion I guess
17:58:23 <hyakuhei> Lets wrap before the hard stop so the next guys can start on time
17:58:31 <tmcpeak> ok, good stuff today
17:58:37 <hyakuhei> Thank you everyone, especially VMT folks and mhayden
17:58:40 <hyakuhei> #endmeeting