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