17:04:28 <thinrichs> #startmeeting CongressTeamMeeting
17:04:29 <openstack> Meeting started Tue May 20 17:04:28 2014 UTC and is due to finish in 60 minutes.  The chair is thinrichs. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:04:31 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:04:33 <openstack> The meeting name has been set to 'congressteammeeting'
17:04:44 <pballand> Hi skn_ !
17:04:53 <thinrichs> Glad to see people from the summit joining us!
17:04:53 <skn_> Hi Peter and Tim
17:05:24 <sarob> I'm here
17:05:26 <pballand> I heard from Rajdeep that he had a conflict and can’t meet this week
17:05:28 <pballand> Hi sarob !
17:05:39 <sarob> pballand: hey
17:05:52 <pballand> kudva also sends his regrets for this meeting
17:06:02 <skn_> Hi peter, did you send out the group mail to share everyone’s id?
17:06:23 <pballand> I have not yet - I was waiting for one more reply, but will send out after this meeting
17:06:43 <thinrichs> I think we're all still recovering from the summit.
17:06:49 <skn_> OK, great.
17:06:56 <skn_> True
17:07:10 <sarob> thinrichs: almost recovered
17:07:36 <thinrichs> sarob,skn: :)
17:07:38 <sarob> thinrichs: Friday did me in
17:07:53 <skn_> Who’s sarob?
17:07:59 <thinrichs> sarob: It was action packed for me too.
17:08:01 <sarob> Me
17:08:16 <sarob> Sean roberts yahoo devant
17:08:25 <skn_> Oh, ok, got it.
17:08:35 <thinrichs> Let's quickly go over action items from last week.
17:08:40 <skn_> Sorry Sean, didn’t know your IRC id
17:08:49 <sarob> Np ;)
17:09:09 <thinrichs> rajdeep was productive: he moved the datasources dir and wrote some unit tests.
17:09:19 <thinrichs> Here are his unit tests from the data drivers.
17:09:21 <thinrichs> https://review.openstack.org/#/c/94123/
17:10:08 <thinrichs> The unit tests basically have some JSON objects and run the translator code on them to get the tables that Congress uses.
17:10:33 <thinrichs> Let us know if any of you have comments, and we'll make sure rajdeep gets them.
17:10:59 <pballand> I had 2 action items from the conference:
17:11:20 <pballand> 1 - email the list of participants who wanted to share contact info
17:11:36 <pballand> 2 - set up a blueprint process similar to nova-spec
17:11:53 <pballand> on 1, I am going to send out the list after the meeting
17:11:54 <sarob> #link  https://etherpad.openstack.org/p/juno-congress
17:12:02 <pballand> sarob: thanks
17:12:22 <pballand> for 2: I wanted to propose placing the blueprints in the same tree as the source for now
17:12:25 <sarob> Yup
17:12:33 <skn_> Thanks for the etherpad
17:12:44 <skn_> Yes
17:12:47 <pballand> considerations: we are a very small project, so managing multiple projets seems overkill
17:12:56 <sarob> The spec process nova and other are following
17:13:12 <pballand> on the other side, confusing specs and src may be confusing
17:13:13 <pballand> thoughts?
17:13:21 <sarob> Hey keep the specs as a separate repo
17:13:31 <sarob> Spell chk is killing me
17:13:49 <sarob> #link https://github.com/openstack/nova-specs
17:14:17 <pballand> sarob: any particular reason (other than following what nova does)?
17:14:17 <sarob> I guess it's to keep the rst and running of tox
17:14:26 <sarob> As simple as possible
17:15:02 <sarob> I can ask Michael still why extra repo
17:15:04 <pballand> sarob: so we would have stackforge/congress and stackforge/congress-spec ?
17:15:16 <sarob> I assumed was to limit pollution
17:15:27 <sarob> Yup
17:15:32 <sarob> My understanding
17:15:34 <pballand> I would appreciate that - I’d prefer to keep the specs together (in a specs subidr)
17:16:00 <sarob> Start with subdir is easy to move later
17:16:00 <skn_> I thought it would be a subdir
17:16:06 <skn_> Yeah
17:16:17 <sarob> In case there's some higher reasoning
17:16:28 <pballand> agreed, we can always break out to new repo later
17:16:31 <pballand> will create subdir
17:16:57 <pballand> #action pballand to create subdir for specs in stackforge/congress
17:17:05 <pballand> that’s it for me
17:17:11 <sarob> Subdir for Juno as well
17:17:31 <pballand> sarob: yes
17:17:34 <sarob> The templates and format is straightforward
17:17:39 <sarob> Are
17:17:48 <thinrichs> We should also put someone in charge of writing a first blueprint.
17:18:14 * sarob hand up, at least to help
17:18:18 <skn_> Didn’t we discuss that we’ll likely have multiple blueprints?
17:18:21 <thinrichs> I can take that on unless someone else feels strongly.
17:18:40 <skn_> I can help out Tim
17:18:40 <thinrichs> skn_: We'll definitely have multiple blueprints.  But the first is often the hardest.
17:19:07 <sarob> The spec process should make few blueprints
17:19:09 <skn_> And what do we want to focus on for the 1st one?
17:19:31 <thinrichs> I'm going to need to read through that spec process.
17:19:31 <sarob> Reason nova started for quality verses quantity they have had
17:19:43 <thinrichs> Before I can figure out what the first blueprint should be.
17:20:13 <sarob> Can we discuss Juno user stories?
17:20:20 <sarob> From the summit session
17:20:30 <thinrichs> So let's make sure all 3 of us peruse nova-spec to see what's going on and then we'll be in touch over email to work out blueprint details.
17:20:32 <skn_> I thinks we should
17:20:49 <thinrichs> #action thinrichs, sarob, skn_ will work on a nova-spec-like blueprint
17:21:00 <thinrichs> sarob, skn_: Definitely
17:21:30 <sarob> User stories brought up
17:21:42 <sarob> Trusted pool
17:21:52 <sarob> Evacuation
17:21:58 <sarob> Upgrade
17:22:22 <sarob> Workload migration
17:22:50 <pballand> proposal: let’s classify stories by openstack components they include
17:22:54 <sarob> Fine grained attributes
17:23:06 <sarob> Smart
17:23:29 <skn_> Agree with pballand
17:23:39 <sarob> Trusted pool will prob get intel people involved
17:23:56 <sarob> And evacuation
17:24:23 <sarob> Upgrade will have broad interest
17:24:40 <sarob> Those three are my favs
17:24:44 <pballand> If I recall correctly, we agreed at the summit that the stories go on the wiki
17:25:01 <skn_> Let’s put them on the wiki first
17:25:24 <sarob> Roger
17:25:50 <thinrichs> Those 3 sound good to me too.
17:26:10 <pballand> lets start with trusted pool:
17:26:30 <pballand> it definitely involves nova, and a way to tak hypervisors
17:26:33 <pballand> s/tak/tag
17:26:51 <skn_> for geotagging, etc
17:26:55 <sarob> Start with that
17:26:59 <pballand> question: how are hypervisors identified as trusted, and are any other components involved?
17:27:07 <thinrichs> Are we hoping to have demos for each of the 3, or just tell the story around them?
17:27:21 <sarob> For Juno?
17:27:29 <thinrichs> sarob: yes, Juno.
17:27:30 <skn_> TXT-based technology is Intel spoke about
17:27:38 <sarob> skn_: yup
17:27:51 <skn_> Something like vTPM too
17:28:02 <sarob> skn_: when we have the spec up, I'll point the intel people
17:28:04 <pballand> can you help me understand how the TXT data gets to congress?
17:28:06 <sarob> To it
17:28:13 <pballand> (from nova?)
17:28:28 <sarob> pballand: filter
17:28:43 <sarob> Sep service monitoring txt
17:29:03 <skn_> we should have one use case for a network security service (e.g. vuln scanning, DLP, etc)
17:29:11 <pballand> I’d like each story to include at least two components
17:29:18 <pballand> (data-source plugins in Congress-speak)
17:29:26 <sarob> Prob want API ext to front txt data
17:29:35 <sarob> Nova API ext
17:30:09 <skn_> Why do we want API extn?
17:30:13 <sarob> IDS could get symantec involved
17:30:23 <sarob> More
17:30:40 <skn_> why not just data source
17:30:41 <pballand> sarob: in that case, it sounds like the story just includes one component...
17:30:45 <thinrichs> Any reason we can't integrate with the txt service directly?
17:30:48 <thinrichs> skn_: agreed
17:31:08 <sarob> thinrichs: could do that
17:31:18 <thinrichs> Generally speaking we don't want to be extending existing services to make our use case.
17:31:20 <sarob> thinrichs: makes it specific to intel
17:31:39 <sarob> Guess plugin could hold the flexibility
17:31:40 <thinrichs> Or is the extension to the API already in existence?
17:31:49 <sarob> Don't think so
17:31:57 <sarob> Haven't checked
17:32:04 * sarob blush
17:32:19 <skn_> I think we’ll need to take a fresh look at what the updated TXT interfaces are
17:32:22 <thinrichs> sarob: part of what people seem to like is that we can use whatever services they have *without* changing services
17:32:30 <thinrichs> And the system is designed to make that easy.
17:32:35 <skn_> Yes
17:32:58 <skn_> thinrichs: yes, that’s why data source is thw way to go
17:33:04 <sarob> So have the flexibility in the congress plugins rather the projects
17:33:13 <thinrichs> sarob: Yes.
17:33:21 <sarob> Okey dokey
17:33:55 <pballand> sarob: Could you add this to the wiki?
17:34:37 <pballand> skn_: can you describe the story you had in mind for intrusion detection?
17:34:58 <sarob> pballand: which?
17:35:05 <sarob> Trusted pool
17:35:10 <skn_> It would be like IDS service puts out data sources
17:35:11 <pballand> yes
17:35:23 <skn_> related to security issues
17:35:33 <sarob> #action sarob add trusted pool user story to wiki
17:36:03 <skn_> stuffs that are monitored and if there is something bad happening, we may need to take actions
17:36:24 <skn_> intrusion might need to quarantine a VM, or a L2 segment, etc
17:36:34 <pballand> skn_: this makes sense, but it would be great to nail down a specific integration, with nova or neutron, for example
17:36:49 <skn_> Agreed, I can work on this use case
17:37:32 <sarob> skn_: just nova network might be the best use case to start
17:37:43 <thinrichs> Great.  Someone dropped into pballand's office.
17:37:48 <skn_> ok
17:37:57 <thinrichs> Or use the Neutron network as well.  We already have a driver for that.
17:37:58 <sarob> skn_: since very few running neutron
17:38:10 <thinrichs> Or Nova Neutron.  Whatever works.
17:38:14 <skn_> I think both nova and neutron
17:38:26 <thinrichs> I don't know if we have the Nova network stuff integrated.  rajdeep knows but couldn't make it.
17:38:26 <skn_> networks, I meant
17:38:32 <pballand> sorry, back
17:38:54 <sarob> Just thinking about real world use case
17:39:15 <sarob> Neutron will not be as interesting at this moment
17:39:26 <sarob> After Juno prob more
17:39:29 <pballand> how about a scheduler hint based on IDS?
17:39:40 <pballand> (nova scheduler)
17:39:51 <skn_> Like stop this VM?
17:40:20 <pballand> actually, it’d be simpler if we can keep it as a monitoring case for now
17:40:30 <sarob> Greylist
17:40:50 <skn_> I think nova network should be simple
17:40:55 <skn_> we can start with that
17:41:02 <skn_> quarantining a host
17:41:07 <skn_> I mean a VM
17:41:09 <thinrichs> Are there Nova API calls we could execute that would be a reasonable response to IDS?
17:41:12 <sarob> White and grey would be easier than black for Juno
17:41:23 <sarob> For IDS
17:41:24 <thinrichs> e.g. is there a quarantine API call, a black-list API call, etc.?
17:41:29 <pballand> sarob: can you help me understand what you mean by gray-list?
17:42:00 <sarob> These VMs may have issues, ops should look at these
17:42:08 <pballand> (all of these ideas make sense, but I don’t know how to map that in to existing constructs in Nova)
17:42:18 <sarob> Black would be automagically kill these
17:42:40 <sarob> More harder
17:42:46 <pballand> My trouble with graylist (as defined) is that it only involves the IDS (no cross-component integration)
17:43:19 <thinrichs> So both monitoring (for gray-list) and enforcement (black-list).  Right?
17:43:23 <skn_> Yes, I want the IDS to integrate with another component
17:43:28 <sarob> Simple start is good
17:43:31 <sarob> No?
17:43:34 <pballand> I like the simpler “monitoring” use case, but would like to integrate it with another data source
17:43:55 <skn_> like scheduler data source?
17:44:00 <skn_> or the nova net?
17:44:02 <pballand> e.g. if IDS flags host AND nova says host <something> then flag
17:44:28 <pballand> maybe nova-net says connected to intranet?
17:44:40 <sarob> Could knock bad actor off lbaas
17:44:52 <sarob> Or close ports
17:45:05 <sarob> Rather than kill vm
17:45:28 <pballand> if we are doing enforcement, turning off the VM is easiest to impelment (as a first-delivered feature)
17:45:40 <sarob> Agreed
17:45:49 <pballand> or disconnect-network
17:45:51 <sarob> But to include another project
17:46:02 <sarob> Was my comment
17:46:27 <pballand> my thought is that we may want to keep enforcement out for the immediate term
17:46:33 <skn_> pballand: Yes, for turning off VMs
17:46:36 <sarob> Agreed
17:46:44 <thinrichs> I think we should be able to get rudimentary actions/enforcement in place for Juno.
17:46:50 <skn_> I think, thats what we can have as the first use case
17:46:58 <skn_> easier to demo too
17:46:58 <pballand> thinrichs: in that case, I have no objections to the story
17:47:25 <thinrichs> Monitoring is a good first use case, for sure.  But I think actions/enforcement is reasonable in 6 months.
17:47:37 <thinrichs> For POC, of course.
17:47:38 <skn_> thinrichs: agreed
17:47:48 <sarob> So IDS and nova services only to start for trusted pool user story
17:48:18 <pballand> I was thinking this was a separate story
17:48:24 <skn_> Yeah, me too
17:48:28 <skn_> lets keep them separate
17:48:31 <sarob> Okay
17:48:33 <skn_> trusted pool and IDS
17:48:42 <sarob> Ah right
17:48:47 <pballand> (trusted pool is nova + intel intetration, IDS is security + nova integration)
17:48:49 <sarob> Conflated
17:48:53 <pballand> skn_: can you pick an enforcement action, and add the story to the wiki?
17:49:05 <skn_> I can work on the IDS user story
17:49:18 <skn_> I can do that pballand
17:49:39 <pballand> #action skn_ to add IDS user story to wiki
17:49:39 <skn_> The IDS story with monitoring and enforcement action
17:50:04 <sarob> #action skn_ The IDS story with monitoring and enforcement action
17:50:08 <pballand> do we want to keep going with evacuation or upgrade use cases?
17:50:21 <pballand> (10 minutes left)
17:50:23 <skn_> Hey guys, I need to run, but I’ll work on the user story and likely share with you folks as I proceed
17:50:38 <pballand> thanks skn_ !
17:50:42 <skn_> Today I’m hosting a talk on OpenDaylight, so
17:50:49 <pballand> I wanted to mention that we are trying to do the meeting every week now
17:50:56 <sarob> Excellent
17:50:58 <skn_> Yes, I’ll join every week
17:51:13 <skn_> But only today I’ll run before time
17:51:19 <skn_> sorry about that
17:51:32 <thinrichs> No problem.  Thanks for joining!
17:51:42 <skn_> Bye pb, tim and sean
17:51:58 <thinrichs> Another action item we discussed at the summit was talking with Nova and Neutron folks.
17:52:06 <sarob> Bye
17:52:14 <thinrichs> skn_: bye
17:52:20 <thinrichs> We have contacts with Neutron, but who should we talk to in Nova?
17:52:26 <sarob> I spoke with still
17:52:32 <sarob> Nova ptl
17:52:46 <sarob> He is ready when we are
17:53:03 <sarob> I suggest getting both in the same meet to start
17:53:21 <sarob> Kyle, mark, micheal
17:53:42 <sarob> Bush
17:53:46 <sarob> Arrg
17:53:49 <sarob> Vish
17:54:13 <pballand> sarob: Do you think we should have a separate meeting just for this, or do in IRC?
17:54:29 <sarob> I'm good with irc
17:54:30 <pballand> (not clear to me how to do this most efficiently)
17:54:55 <sarob> I think those guys will prefer irc too
17:55:07 <sarob> Documented
17:55:12 <thinrichs> Would you suggest inviting them to this IRC or setting up a separate time?
17:55:14 <sarob> History
17:55:26 <sarob> Vish is PDT
17:55:33 <sarob> Mark est
17:55:40 <sarob> Kyle cst
17:55:53 <sarob> Micheal aus
17:56:08 <sarob> I can ask Micheal
17:56:13 <sarob> He is the extreme
17:56:36 <thinrichs> What are we trying to do in this meeting?  Tough to convey vision over IRC.
17:57:00 <thinrichs> Maybe we should chat on the phone about what we're trying to do here and logistics?
17:57:10 <sarob> I'd think discuss policy strategy
17:57:16 <sarob> Sure
17:57:34 <sarob> Details should be irc though
17:57:34 <thinrichs> Policy strategy across OS, yes?
17:57:47 <sarob> And ODL
17:58:00 <sarob> Kyle can represent that side
17:58:08 <thinrichs> Agreed--the phone conv just for higher-bandwidth clarification on stuff already discussed.
17:58:33 <sarob> Once we get going, bosh
17:58:58 <sarob> Joshua can front that side
17:59:04 <sarob> But later
17:59:50 <sarob> Me discuss time with still right?
18:00:00 <pballand> sounds great
18:00:10 <pballand> unfortunately we’re out of time this week
18:00:33 <sarob> #action sarob get time for stategy call with nova ptl
18:00:43 <sarob> Roger next week
18:00:44 <pballand> thanks everyone for joining!
18:00:51 <sarob> :)
18:00:51 <thinrichs> #endmeeting