17:02:21 #startmeeting CongressTeamMeeting 17:02:22 Meeting started Tue Feb 3 17:02:21 2015 UTC and is due to finish in 60 minutes. The chair is thinrichs. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:02:23 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:02:26 The meeting name has been set to 'congressteammeeting' 17:02:55 Let's get started with status updates. 17:02:58 #topic status 17:03:06 People with high priority blueprints should go first. 17:03:13 cloudtoa_: want to get us started? 17:03:45 I am working on the control-bus now, should have something submitted in the next couple of days (code). 17:04:25 Nice. 17:04:29 Anything you need from us? 17:04:45 Not at this time. 17:05:25 cloudtoa_: sounds good. Looking forward to seeing it on gerrit :) 17:05:33 Okay. So that will probably get in close to kilo2 (which is sometime this week). 17:05:53 zhipeng: since it's late for you, want to go next so you can take off? 17:07:42 Maybe he left himself logged in. We'll come back. 17:07:59 madhumohan: how are the modals coming? 17:09:13 rebase is giving me a common error for all tests in test_congress.py: Parse Failure... 17:09:44 madhumohan: is the patch posted on gerrit? 17:10:07 I just sent a snippet of the error log.... I guess, there should be a small change i have missed in the test setUp() that is causing this error. 17:10:30 arosen1: yes... https://review.openstack.org/#/c/144922/ 17:12:32 madhumohan: where'd you send the snipit of the error log? I'm sure we can help you in #congress after the meeting with debugging it. 17:12:49 Looks like a merge problem. 17:13:13 I'd fix the pep8 errors (where we're creating a uuid). 17:13:47 A failure there will cause nearly every test to fail. 17:14:10 There has been a lot of churn in the policy engine recently. 17:14:35 I'm happy to help if you like—just let me know. 17:16:39 madhumohan: anything else? 17:18:17 zhipeng_: here for Congress? 17:18:39 hey 17:18:45 Hi 17:18:50 yes just finished another meeting 17:18:57 JimJunXu: hi! 17:19:06 zhipeng_: how's the policy trigger work going? 17:19:32 I'm still working on it, and have to deal with some company upload issue 17:19:46 but I will try to upload the first version before the deadline 17:19:52 if I could sort that all out 17:20:21 zhipeng upload issues as in there is a firewall in the way or getting permission to contribute? 17:20:27 zhipeng_: sounds good. Don't hesitate to ask for help. 17:20:43 yes permission issue, mostly procedure stuff I need to follow 17:20:51 yes you guys are very nice 17:21:19 :) 17:22:23 madhumohan: do you know how srangare is doing on the aggregates? 17:24:37 Perhaps he stepped away. 17:24:43 jwy: how's your progress going? 17:24:57 On the horizon UI for policy? 17:25:28 met with JimJunXu yesterday to discuss having a graphical representation of policies and converting those to datalog 17:26:23 there were some unresolved issues still, as with the form builder, such as how to represent joins 17:27:05 i think they are still interested in exploring this UI more, though, as a way to abstract policies for the user more than the form builder would 17:27:12 JimJunXu: do you want to comment? 17:27:22 This is related to the current BP - 'Policy creation in Horizon'. 17:28:07 Need a solid congress example and to see what can be done by following the current approach. 17:28:50 the major issue in the UI can be representing the 'join' and 'not allow/error' directives 17:29:39 we started to look into it. 17:30:33 I've said this before, but it's worth repeating.... 17:31:02 The UI is super important here. People are always skeptical that operators/devs/etc. will be able to write policy. 17:31:09 So we need to make that as easy as possible. 17:31:38 Let us know if there's anything we can do to help. 17:31:49 thinrichs (or anyone else, really): could you give several example policies that cover various data sources to see how that would translate to a graphical rep? 17:32:13 and various combinations of joins and "not"s 17:33:26 I was looking to find the link to our use case document. 17:33:28 #link https://docs.google.com/document/d/1ExDmT06vDZjzOPePYBqojMRfXodvsk0R8nRkX-zrkSw/edit#heading=h.fbota2qx0jad 17:33:59 Perhaps it is time to update that so people have a handful of worked out policy examples. 17:34:08 So some of our customers want to use Congress just as a simple "state-checker." For instance, if something is configured in "x" (like a VLAN on a port) then that VLAN should exist on that port. So a data source driver examines config, and another examines corresponding state. Like a verifier that alerts you when something doesn't work. 17:34:39 Makes sense to me. 17:34:41 These should be relatively simple policies to write and the value and purpose should be clear to an operator. 17:34:54 It might be a good starting point in the UI... 17:35:16 If there is something shaky in OpenStack now that is tedious to check, that could be a good nexus for us. 17:35:37 yes, that is one good case. 17:35:51 good info, thanks 17:36:14 Let's try to add that to the use case doc. 17:37:00 If we used the vxlan example, we're checking neutron for the config, right? 17:37:04 Roger.. will add after meeting. 17:37:06 What are we checking for the actual state. 17:37:08 ? 17:37:40 yup sounds like it - the vlan value. 17:37:55 on the switch vs expected from the cloud operator. 17:38:13 Anyway—if you're going to add it to the doc we'll see what example you come up with, cloudtoa_. 17:38:18 I think the question is: which part of the system knows if a vlan exists on a particular port. 17:38:57 I'd say probably the datasource driver that talks to what ever knows about vlans. 17:39:09 Well, the VLAN thing is just an example. Surely there are other things as well. A VM is deployed but something goes wonky with some other component... it's a complex dist system, there has to be numerous examples... 17:39:24 So which part of the system knows about vlans ? 17:40:17 Nova can tell you the segment ID associated with a virtual network... that would be source 1. 17:40:43 Then another source would tell you where hosts are connected in the network (via LLDP harvesting, I imagine). 17:41:02 Then another source could tell you what is configured on the switch access-port associated with that host. 17:42:10 Sounds good. I'm looking forward to reading more in the doc. 17:42:20 Let's move on and finish up status updates. 17:42:29 stevenld: do you have anything to report? 17:42:55 yes. I'd like to update on murano-driver 17:44:01 I submitted the code for review for the driver, however I'm being blocked by the issue where Congress is in the tracked projects and python-muranoclient is not in global_requirements 17:44:35 stevenldt: go ahead and add python-muranoclient to the global requirements. 17:44:48 It's a .txt file, and you're free to edit it as you see fit. 17:45:22 You're talking about requirements.txt, right? 17:45:46 That's where we typically add the python clients we are using. 17:45:46 would adding python-muranoclient to global requirements require approval from Murano team? 17:46:28 as well add the python clients to global requirements as we need? 17:46:30 So you're saying the OpenStack blessed list of possible requirements? 17:46:36 whoops sorry i got disconnected. I'm not sure how much of my stuff posted. 17:46:52 as well == or we 17:47:06 stevenldt: i'm running into that same issue for the cloudfoundry client. Is it possible to have the driver and test work in the tree with just mock? 17:47:32 I think that should work. This way we don't have to have these clients in the requirements.txt file for now. 17:48:04 I don't think these stackforge clients are going to be allowed in global requirements anytime soon. At least from how that email on the list sounded. 17:49:11 arosen1: so you are saying that I should replace the whole muranoclient with a mock? 17:49:24 Are there any driver test that is using mock now ? 17:50:02 sorry about that got disconnected again :( 17:50:06 stevenldt: i'm running into that same issue for the cloudfoundry client. Is it possible to have the driver and test work in the tree with just mock? 17:50:12 I think that should work. This way we don't have to have these clients in the requirements.txt file for now 17:50:17 I don't think these stackforge clients are going to be allowed in global requirements anytime soon. At least from how that email on the list sounded. 17:50:37 What happens if we add the murano client to our requirements.txt ? 17:50:42 Does something fail ? 17:51:10 yup 17:51:14 alexsyip: yes, the tempest fails 17:51:15 what fails ? 17:51:20 Why does tempest fail ? 17:51:26 there is a test to ensure requirements.txt makes the reqirement repo 17:51:36 devstack will fail too. 17:52:00 Why does openstack require that our requirements.txt is a subset of the global requirements.txt ? 17:52:26 stevenldt: this way you can run openstack on the same box and not have to worry about using virtual env 17:52:50 it ensures all the libs use the same python versions 17:53:13 we can’t be the first project to run into this. 17:53:43 How do other projects deal with this issue? 17:54:09 I think there are 3 options 17:54:10 Clearly we need to work out what to do when we want to integrate with a system not blessed by OS. 17:54:28 1) remove congress from a being an openstack tracked project 17:54:52 right now jenkins posts patches for us keeping our requirements files in sync with global requirements 17:55:14 (Running short on time. Still need to talk about hackathon.) 17:55:15 2) figure out a way to get the tests to work with out adding this to the requirements file. 17:55:30 k we can sort this out later. We'll need to figure something out for the cloudfoundry driver anyways. 17:55:37 I'll sync up with stevenldt later about this. 17:55:42 ok 17:55:46 sounds good 17:55:53 sure. I'll ask more in #congress 17:56:00 It's definitely worth discussing. In the long term we need a solution. Follow up in #congress. 17:56:12 sarob: how's the hackathon going? 17:56:21 hackathon *planning* going? 17:57:37 sarob: you there? 17:58:00 yup 17:58:16 i have a room reserved 17:58:21 for both days 17:58:32 what are the date we are targetting again? 17:58:37 dates* 17:58:44 this thurs and friday 17:58:50 ah okay. 17:59:18 Have we confirmed people working on high-priority blueprints can attend? 17:59:38 no one has confirmed yet 17:59:42 :( 17:59:44 maybes 18:00:00 im asking for 3-4 hour blocks 18:00:11 then run over irc and hangout 18:00:30 i will forward once i have any confirmations 18:00:46 thats all 18:00:49 Let's follow up on the ML. We want to make sure we have a good number of people who can attend. 18:00:55 other than clarizen fun :) 18:01:04 ML, right on 18:01:14 Anyone working on Congress. 18:01:25 Out of time. (Over-time, actually.) Let's follow up on the ML and #congress. 18:01:27 Thanks all! 18:01:31 #endmeeting