17:00:50 <pballand> #startmeeting CongressTeamMeeting
17:00:51 <openstack> Meeting started Tue Jul  8 17:00:50 2014 UTC and is due to finish in 60 minutes.  The chair is pballand. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:53 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:00:55 <openstack> The meeting name has been set to 'congressteammeeting'
17:00:58 <sarob> Morning
17:01:01 <pballand> hello, anyone around today?
17:01:06 <banix> hi
17:01:28 <thinrichs> Hi all
17:01:49 <arosen> Hi
17:01:56 <rajdeep> hi
17:02:29 <pballand> I have a couple of general items on the agenda this morning, then time for status updates and open discussion
17:02:38 <rajdeep> ok
17:03:14 <pballand> the bulk of changes needed for end-to-end execution of policy through the proposed API model are in
17:04:00 <pballand> now we are moving on to filling in the gaps to make the system easier to use, as well as get ready for incubation
17:04:29 <pballand> one place we are planning to tighten up around is code reviews
17:04:54 <pballand> we are going to require 2 +2s from core reviewers before submission
17:05:45 <pballand> and also be more strict about bug and spec linkages
17:05:59 <pballand> thanks to all who have been calling this out in the reviews
17:06:10 <pballand> please continue to do so - it will really help as the project starts to scale
17:06:37 <pballand> another thing we need to get more formal about is having an actual PTL
17:06:48 <pballand> so far, thinrichs and I have been sharing the responsibility
17:07:09 <pballand> ultimately we need to have an election before inclubation, but we may want to do that on the formal cycle - thoughts?
17:07:39 <sarob> Will you need to increase the number of core reviewers
17:07:59 <sarob> As the review activity is going up
17:08:13 <pballand> option 1: have election soon, and ever 6 months thereafter, option2: nominate interim PTL and hold elections at next cycle
17:08:40 <pballand> sarob: good point - that is another thing we should discuss
17:09:07 <sarob> Good idea to keep quality up
17:09:23 <banix> sarob: +1
17:09:31 <thinrichs> I’d be happy if pballand was interim PTL.
17:09:49 <banix> wrt PTL either options sound good
17:10:17 <rajdeep> +1 for pballand as PTL
17:10:28 <pballand> thanks thinrichs - I’d be happy to hold the capacity for now
17:10:28 <sarob> Pballand as intern is a good plan
17:10:31 <arosen> I'm +1 as well
17:10:36 <banix> pballand:  are you running for PTL? :)
17:10:43 <banix> pballand: +1
17:10:52 <pballand> sounds like we have quorum - any opposed?
17:11:10 <pballand> great, thanks guys
17:11:27 <pballand> we’ll bring this back up in a couple months during the ‘normal’ election cycle
17:11:54 <pballand> #action pballand will try to step up his game as interim PTL
17:12:12 <thinrichs> :)
17:12:31 <sarob> Roger that game stepper
17:12:32 <pballand> as sarob mentioned, we could benefit from having more core reviewers as well
17:13:09 <pballand> I propose we get suggestions over the ML, and discuss there
17:13:26 <sarob> Sounds good
17:13:28 <pballand> s/suggestions/nominations/
17:14:05 <rajdeep> how do you define a ML?
17:14:21 <pballand> rajdeep: Mailing LIst - use [Congress] in the subject
17:14:26 <pballand> (openstack-dev)
17:14:35 <banix> openstack-dev with [congress]
17:14:58 <banix> [Congress] that is
17:14:58 <pballand> another housekeeping item - the J-02 milestone closes July 24
17:15:02 <rajdeep> ah
17:15:21 <pballand> we haven’t been tracking milestones thus-far, but that is one thing I am gong to push for going forward
17:15:37 <pballand> does tthat sound reasonable?
17:15:46 <sarob> +1
17:15:50 <thinrichs> +1
17:15:54 <pballand> great
17:15:55 <banix> with the launchpad project account in place, sounds good
17:16:21 <skn_> Are we voting for something? Sorry, joined late
17:16:43 <pballand> hi skn_ : glad you could make it
17:16:51 <rajdeep> or we should have sprints
17:16:57 <sarob> And al the work goes to
17:17:02 <sarob> Skn_
17:17:04 <skn_> Hi Peter
17:17:04 <banix> skn_: yup, you missed it. you have to buy lunch for everybody
17:17:14 <sarob> Kidding !
17:17:16 <pballand> you missed your chance to disagree bout me as interim PTL ;)
17:17:27 <skn_> banix: hehe, I’d be glad to when we meet next time :)
17:17:44 <pballand> I don’t expect to do full status updates every meeting, but I think it will be good until we get in the spec/bug/code-review rhythm
17:17:59 <pballand> my front-burner item is getting gate tests re-enabled
17:18:10 <pballand> (https://bugs.launchpad.net/congress/+bug/1339193)
17:18:11 <banix> pballand: and having an agenda on the meeting page will be also helpful
17:18:22 <arosen> pballand:  i agree. I have a few points to bring up there if we want to talk about them now.
17:18:31 <pballand> banix: yes - I’ll include that in _stepping-up-my-game_
17:18:40 <banix> pballand: :)
17:19:02 <arosen> pballand: ah your launchpad bug sums up the issue i was going to talk about :)
17:19:15 <pballand> I’m also working on API validation - spec has been submitted
17:19:27 <pballand> arosen: you have been busy - mind giving an update?
17:19:31 <arosen> Sure
17:19:50 <arosen> so I guess lets start with the tests since you just linked that bug
17:19:55 <arosen> I want to start sorting out is getting the unit tests to run in the gate. Right now they are not running because how the tox.ini isn't telling them to run.
17:20:03 <arosen> I've been able to get the tests to run with help of thinrichs though. It requires running:
17:20:12 <arosen> java -jar /tmp/congress/thirdparty/antlr-3.5-complete.jar /tmp/congress/congress/policy/Congress.g
17:20:12 <arosen> which generates two Files:
17:20:12 <arosen> congress/policy/CongressLexer.py
17:20:12 <arosen> congress/policy/CongressParser.py
17:20:18 <pballand> yes - I have the code almost ready for that
17:20:19 <arosen> I'm not sure if we're going to be able to generate these files on the fly like this in the gate (one of the other openstack projects do this i believe) but I'm going to start looking into this. In the meantime it might be easiest to check these two python files into the repo and add some pep8 excude for their directory as they aren't outputted in a pep8 compliant way. Thoughts?
17:20:36 <arosen> pballand:  how are you solving this issue?
17:21:02 <banix> arosen: sounds reasonable
17:21:02 <pballand> arosen: I added a setup.py hook in policy/, and added the files to MANIFEST.in
17:21:28 <pballand> they now exist in my .tox dir, but still have a couple import issues to fix (which may be addressed by one of your patches that include congress.*)
17:21:48 <arosen> Does it generate the .py files on the fly or do we check the content of those in the MANIFEST.in file?
17:22:09 <pballand> on the fly (as part of setup.py)
17:22:26 <pballand> will still need to exclude the files from pep8, but won’t need to check in static versions
17:22:34 <thinrichs> One thing to think about is that those files change *very* infrequently, and generating them requires having Java installed.
17:22:53 <arosen> I wonder if we can get java added to the gate test runners for this. I'm not sure if it has that today?
17:22:58 <thinrichs> It might be nice if the run-of-the-mill user doesn’t need to have Java installed if they’re just going to run congress.
17:23:01 <banix> any reason for wanting them generated dynamically?
17:23:24 <thinrichs> So checking them into the repo might be good.
17:23:26 <thinrichs> Thoughts?
17:23:32 <arosen> banix: this way we don't need to worry about the code getting out of sync. A bug could slip in unless we run make and check in the changed files.
17:23:34 <pballand> confusion if someone forgets to check in updated files?
17:23:37 <thinrichs> banix: those files are the lexer/parser generated from a BNF.
17:23:56 <thinrichs> pballand: agreed, but it happens once a year.
17:24:07 <pballand> I’m okay with checking them in (even after figuring out how to generate them)
17:24:07 <banix> i see.
17:24:23 <arosen> pballand:  well it sounds like you got this converted so I think we can recircle here when you post your patch.
17:24:34 <arosen> In other news on my end:
17:24:37 <thinrichs> pballand: I think the only real benefit is if people will be unhappy having java installed
17:25:14 <pballand> thinrichs:
17:25:15 <arosen> I've been digging into the congress source tree. I got a few patches up that integrate oslo.config and olso-incubator, these patches are still WIPish but feel free to take a look. I wanted to get this work out of the way for the keystone integration.
17:25:21 <pballand> agreed - lets debate on code review
17:25:29 <arosen> +1
17:25:45 <arosen> I also have made some good progress on the python-congressclient which can now look up a congress endpoint from keystone and then issue requests into congress. I started the launchpad page http://launchpad.net/python-congressclient for tracking of issues there (which is what the other openstack projects do with their clients).
17:25:53 <sarob> +1
17:25:59 <pballand> arosen: awesome!
17:26:20 <rajdeep> this is great!
17:26:31 <pballand> cloudtoad: you around?
17:26:47 <arosen> I've also made a few big changes that change import paths so it might be useful to merge these first or rebase on ton of mine just to avoid conflicts but not a big deal eitherway.
17:27:00 <arosen> s/ton/top
17:27:30 <rajdeep> arosen: will congress have dependency on keystone?
17:27:38 <pballand> thanks for fixing up the imports - I’ve been doing it wrong all this time :)
17:27:57 <arosen> rajdeep:  it will have a dependency on the python-keystoneclient as the other projects do for the middleware.
17:28:12 <arosen> rajdeep:  though we'll make sure you can use congress without keystone if one chooses to.
17:28:22 <banix> arosen: at what stage is openstackclient work? do you know?
17:29:33 <arosen> banix: I've been playing around with the python-openstackclient a good bit, devstack actually uses this client directly when setting up openstack now.
17:29:49 <arosen> banix:  here's my patch that leverages the python-openstackclient: https://review.openstack.org/#/c/104375/
17:30:27 <banix> arosen: great. will review.
17:30:44 <arosen> So basically the way we integrate with the openstackclient is in setup.cfg we set an entry point of: openstack.cli.extension and the openstackclient will pick up our bindings.  https://review.openstack.org/#/c/104375/1/setup.cfg
17:31:11 <arosen> this way we don't have to implement shell.py which handles the env vars the openstack uses
17:31:17 <arosen> OS_USERNAME etc
17:31:27 <banix> makes sense
17:31:36 <arosen> saves us a lot of code duplication :)
17:32:21 <skn_> arosen: how far have you progressed on this?
17:32:59 <arosen> skn_:  I got the the congressclient integrated with keystone so we can look up the congress endpoint then issue a post datasource command to congress
17:33:24 <banix> Are there plans (or should we plan?) to integrate with Horizon on top of the cli?
17:33:39 <skn_> arosen: thats great
17:33:39 <arosen> but right now congress isn't able to handle the request because the extra headers we pass in for the keystone integration. So I'm working on getting the keystone integration working in congress before i continue on it.
17:34:15 <arosen> banix:  yea i think we should eventually do that. The python-congressclient will provide bindings that horizon can use.
17:34:25 <rajdeep> arosen other clients create models for the resources on the client side
17:34:35 <rajdeep> are we also planning to create those
17:34:56 <arosen> rajdeep:  yup, we'll be consistent with exactly how the other clients work.
17:35:20 <banix> arosen: i uspect a lot of potential users will strongly prefer having the dashboard support
17:35:31 <pballand> banix: horizon integration makes sense, if someone want’s to propose a spec on a first-cut
17:35:33 <arosen> banix: in my opinion i think we should wait on the horizon part unless someone wants to bite this off. We won't be able to merge or horizon changes in to  their project yet untill we're incubated.
17:36:14 <thinrichs> arosen: makes sense to me to wait
17:36:16 <arosen> banix: my thought is the version of congress is just tragged to admins right? So it might be okay just to only support cli for now?
17:36:26 <pballand> agreed with arosen (I think) - if someone is particularly interested in UI, they should do it, but it isnt’ a core priority right now
17:36:51 <arosen> sounds good. That's all i have for now.
17:36:52 <banix> arosen: agree; for now (and for later) the cli is what is needed
17:36:56 <sarob> Agree to wait on UI
17:37:07 <pballand> thanks arosen
17:37:16 <pballand> sarob - any progress on the jm2 mini-summit?
17:37:46 <sarob> Thinking August in sj
17:38:02 <pballand> sounds better than August in phx
17:38:03 <pballand> ;)
17:38:23 <sarob> Taskflow yes
17:38:44 <banix> sarob: August is the month you have your vacations in not meetings :)
17:39:10 <banix> Late july or September would be better in my opinion
17:39:21 <sarob> Then  Hawaii location
17:39:48 <sarob> Plan on inviting
17:40:07 <sarob> Heat
17:40:12 <sarob> Neutron
17:40:18 <sarob> Keystone
17:40:25 <sarob> Nova
17:40:35 <sarob> Taskflow
17:40:49 <thinrichs> I just saw Swift has a policy engine
17:41:01 <sarob> True
17:41:04 <skn_> Yup
17:41:06 <banix> well, I think you could potantially invite all ; storage people missing from the above?
17:41:23 <sarob> Sure we can invite everyone
17:41:33 <sarob> I was just starting small
17:41:53 <sarob> Thoughts
17:42:04 <skn_> sarob: are you planning for a 2-day agenda?
17:42:11 <thinrichs> I suppose it depends on the goal.
17:42:26 <thinrichs> Are we hoping to have everyone working on policy engines attend so we can figure out how they all interoperate?
17:42:51 <sarob> Yes
17:42:51 <thinrichs> Or are we focused on non-policy integrations?
17:42:53 <skn_> thinrichs: thats definitely a goal
17:43:02 <skn_> but it would be both
17:43:30 <sarob> I was thinking we want to start with policy
17:43:31 <skn_> data sources, enforcement, etc
17:43:39 <sarob> Project they're working on policy that is
17:43:57 <thinrichs> I think that understanding how these different policy engines will interoperate is crucial.
17:44:20 <rajdeep> Have you guys seen this Horizon has few policy files embedded https://github.com/openstack/horizon/tree/master/openstack_dashboard/conf
17:45:26 <sarob> Start more discussion on mailing list
17:45:30 <banix> rajdeep: well these are different; Neutron has these as you can see from the Horizon side
17:45:46 <pballand> I suspect that even the projects that aren’t openly talking about policy are considering it, but it may be better to stick with those that are far along to start
17:45:52 <sarob> We need to work out the gender date time more than I thought we did
17:45:57 <banix> rajdeep: policies on who can do what
17:46:00 <thinrichs> sarob: sounds good.  Maybe float the idea of a policy-summit and see what people say.
17:46:10 <sarob> Agenda
17:46:30 <sarob> Excellent idea
17:47:14 <skn_> +2 excellent idea
17:47:23 <thinrichs> For an agenda, I’d imagine spending 1 day having different projects talk about their policy and 1 day workshopping/whiteboarding/talking/etc. about integrating them.
17:47:33 <arosen> rajdeep: I think horizon has those only to changes what it's UI looks like but those policy files really live in each project i believe.
17:48:06 <sarob> Thinrichs goodness
17:48:21 <thinrichs> sarob: want to send out the email?
17:48:25 <sarob> Yup
17:48:29 <rajdeep> arosen : but its little confusing to have them there
17:48:39 <rajdeep> from a design perspective
17:48:40 <sarob> I'll do it today
17:48:47 <arosen> rajdeep: totally agree.
17:49:16 <arosen> rajdeep:  I don't think there is an API that any project exposes to get that info so they just copy the file around :)
17:49:31 <pballand> ok, only 10 minutes left
17:49:53 <pballand> anyone else have updates theyd like to share with the group?
17:49:55 <banix> rajdeep: i think they use these policies in Horizon to see which buttons to gray out, etc. just guessing here.
17:50:29 <sarob> #link https://review.openstack.org/#/c/102935/
17:50:46 <sarob> Needs policy spec feedback
17:50:48 <skn_> I am starting to look into trying out an IDS (BRO, for now) with OpenStack, with the intention of demo’ing a IDS use case with Congress
17:51:37 <thinrichs> skn_: sarob and I were working on the compromised-vm spec, which is IDS.  Could you take a look?
17:51:48 <sarob> That's it
17:51:57 <skn_> Sure, I’ll take a look at that
17:52:04 <sarob> #link https://review.openstack.org/#/c/102935/
17:52:28 <thinrichs> skn_: what are you hoping to do in terms of enforcement?  I.e. what happens when IDS finds something suspicious?
17:52:37 <sarob> #link https://review.openstack.org/#/c/105371/
17:53:03 <skn_> I don’t currently see Neutron supporting IDS monitoring-like support natively, or am I missing something?
17:53:21 <sarob> More details from the spec authors
17:53:27 <banix> skn_: no it won’t
17:53:39 <sarob> On this other policy spec
17:53:55 <skn_> enforcement: (1) isolate a compromised VM
17:54:46 <skn_> I am planning to work on this network monitoing support for neutron tenant nets
17:55:01 <thinrichs> skn_: how do you isolate a VM?  What Neutron/Nova API calls would you make?
17:55:36 <skn_> thinrichs: to start with, we just add a rule to drop all in/out traffic from/to the VM’s IP
17:55:38 <rajdeep> you can detach a port from the VM
17:55:42 <rajdeep> to isolate it
17:56:06 <arosen> rajdeep: or set the port to admin-state-down in neutron.
17:56:18 <rajdeep> yeah thats another option
17:56:24 <skn_> I was thinking we could add a rule to the portgroup to start
17:56:26 <arosen> detaching the port might have some guest requirements.
17:56:26 <sarob> Id like to add as next step to remove from nova scheduler as well
17:56:30 <banix> yes that setting the state would be the way to do it
17:56:33 <rajdeep> or modify router/ switch entries
17:56:45 <skn_> there are plenty of options
17:56:51 <skn_> like you guys suggest
17:56:53 <pballand> sarob: +1 for nova scheduler hint
17:56:59 <sarob> All this can go into the spec
17:57:17 <sarob> Good stuff. Make reviews
17:57:24 <thinrichs> sarob: agreed—let’s put some options into the spec.
17:57:25 <sarob> Do good things
17:57:35 <skn_> sarob: I agree with the nova sched hint
17:57:42 <sarob> Coolness
17:58:17 <thinrichs> I like the idea of this use case driving how we add actions to the policy framework for the beta.
17:58:40 <sarob> The increAse in reviews is very good
17:58:49 <arosen> Sorry guys I got to bounce to a meeting but I'll read the rest of the logs. Later!
17:59:00 <skn_> banix: if we add some native monitoring support, how do you think is the right way to put that into Neutron?
17:59:01 <sarob> Thinrichs +1
17:59:12 <sarob> Arosen cheers
17:59:22 <pballand> by aronsen
17:59:29 <banix> skn_: monitoring the traffic for signs og intrusion?
17:59:39 <pballand> bye
17:59:41 <sarob> By and by
17:59:46 <pballand> heh
17:59:47 <skn_> just plain monitoring, for IDS deployment
17:59:59 <skn_> later on, the IDS will determine the intrusion
18:00:09 <thinrichs> Bye
18:00:18 <rajdeep> bye
18:00:23 <skn_> lets discuss this in email, or next meeting
18:00:24 <sarob> Good meet
18:00:28 <banix> skn_: monitoring the traffic? not Neutron events. right?
18:00:30 <pballand> sorry to cut everyone off, but we’re out of time
18:00:35 <skn_> yes
18:00:42 <banix> see you all on the review board :)
18:00:45 <pballand> thanks for the great discussion
18:00:58 <pballand> lets keep the momentum going on specs and reviews :)
18:01:08 <sarob> Roger that
18:01:20 <pballand> #endmeeting