17:01:31 #startmeeting CongressTeamMeeting 17:01:31 Meeting started Tue Oct 14 17:01:31 2014 UTC and is due to finish in 60 minutes. The chair is thinrichs. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:01:31 yo 17:01:32 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:01:35 The meeting name has been set to 'congressteammeeting' 17:02:56 I know several people are in Europe, so I'm guessing they'll be missing today. 17:03:23 Let's just get started with status updates. 17:03:27 #topic status 17:03:38 sarob: want to start? 17:03:43 Morn 17:03:54 Hi 17:03:57 I'm still driving 17:04:08 15 m 17:04:14 sarob: okay, let's have you go later then. 17:04:24 rajdeep: would you like to give a status update? 17:04:28 yes 17:04:45 i have been working on the datasource tab of horizon 17:05:11 panel showing datasources and their respective tables is completed 17:05:33 now working on the child view for each table 17:05:35 Great! 17:05:45 working on top of work being done by janet 17:05:50 +1 17:05:56 I haven't done development on Horizon before: what is a child view? 17:06:11 its my term :) 17:06:33 panel which opens on clicking the hyperlink of the main panel 17:06:56 in our case it is a details page for each table in a datasource 17:06:56 Could you briefly describe what information is on the main panel and what goes into the child panel? 17:07:06 Maybe with an example? 17:07:17 main panel has datasource name and table name example 17:07:40 neutron | routers 17:07:44 neutrons | ports 17:07:59 child pane will come on clicking ports 17:08:46 looking at the screen to give you details 17:09:08 Got it. Do we see actual rows of data anywhere? If so, is there pagination or do we pull all the data at once? 17:09:18 ports | [u'2cecb91b-53f7-46ac-a362-7dc03ee8b87c', u'de810f43-4ed8-4353-83cb-6381893dc5fe', u'84602362-de31-4275-962e-988eed18e4af', u'None', u'DOWN', u'', u'True', u'9ee2dee0-ea55-4b4f-a9e6-a60da23916b1', u'54267c459dfc49858df903bc47ce3c9e', u'None', u'network:dhcp', u'fa:16:3e:9d:d2:fd', u'ed028826-7ac6-410f-b0bc-0bed96cf11f0', u'7c9cc3e5-93fa-43fe-acb9-a0a2405590e5', u'dhcp46bf075a-c687-5415-9f5a-56104ed491ce-9ee2dee 17:09:37 yes planning to add pagination 17:10:15 Sounds good. 17:10:18 hope the example helps in understanding 17:10:25 Yep—the example was helpful. 17:10:30 Is there anything you need from us? 17:11:08 not really, janet has been quite helpful 17:11:33 Okay—well let us know if there's information that you think is useful to display but that isn't exposed via the API/client. 17:11:42 ok, sure 17:11:58 glebo: It's good to "see" you here again. 17:12:01 how about last updated time 17:12:24 thinrichs: thx. happy to b here ;-) 17:12:37 rajdeep: I'm hoping to get datasource statuses written and exported through the API this week. last_updated time will be included. 17:13:01 glebo: anything to report or questions to ask? 17:13:03 ok 17:13:30 thinrichs: Not today. Just lurking. 17:13:38 Sounds good. Just wanted to check. 17:13:46 alexsyip: want to give a status report? 17:13:46 thinrichs: thx for asking 17:14:23 I went through a bit of code review with Aaron and Tim for the datasource driver translations. I’m addressing those comments now. 17:14:43 I also worked with Louis a bit on the GBP integration spec. 17:14:55 That’s all. 17:15:17 thinrichs: actually, I will have some questions, but I should probably hold off until everyone else is done with their status and issues, as there is nothing pressing about my questions. 17:15:32 alexsyip: That datasource driver stuff is looking good. It'll be a big help, I think. 17:15:47 glebo: okay. Don't let me forget. 17:15:54 Yes, I hope so. 17:15:55 thinrichs: promise 17:16:14 Okay, I'll do a status update for some of the missing people. 17:16:23 arosen has pushed a bunch of code recently. 17:16:40 He's got a change in review for persisting policy to disk via oslo.db. 17:17:08 He's got a glance datasource driver. 17:17:26 He's got tempest tests for nova/neutron, if I remember right. 17:17:45 I may be forgetting things. 17:18:05 I've also seen some specs moving forward, which is good. 17:18:20 *snaps for arosen* 17:19:01 There's a cinder datasource driver now in review (written by a first-time commiter). 17:19:28 Cinder writer: https://review.openstack.org/#/q/owner:%22Samta+Rangare%22+status:open,n,z 17:19:57 I finished up the simulate() functionality last week. 17:20:14 I'm working to add a collection of date-time builtins, so we can reason about dates and times in policy. 17:20:50 And I spent 6 hours doing reviews yesterday—digging out from review-debt. 17:21:17 I think that's about it for me and the folks I know about that aren't here. 17:21:29 sarob: are you still driving? 17:21:30 *snaps for thinrichs 6 hrs of reviews* 17:21:42 5 mi 17:21:46 +1 17:21:49 Min 17:22:02 sarob: if u r, don't text, for heaven's sake!! 17:22:23 I think this will be a short meeting, given how many people are missing. 17:22:31 lol 17:22:44 Anyone else have anything to report? If not, we'll have glebo ask his questions. 17:22:45 I can post to the ML 17:22:46 *rarely complains about short mtgs* 17:23:00 *waiting for any others* 17:23:06 Short meetings are definitely good. 17:23:17 ok, 17:23:20 Q1: 17:24:00 have we come to consensus on the declarative protocol? It sounded at the meetup like we were trending to a decision, but it wasn't final yet 17:25:27 Okay I'm good now 17:25:54 glebo: what declarative protocol are you talking about? 17:26:06 The language we use to communite policy to Congress? 17:26:13 The language congress uses to talk to other policy engines? 17:27:19 thinrichs: right, sorry for the ambiguity. The protocol that congress uses to declare the configured policy to the policy endpoints or implementers 17:27:42 thinrichs: who will then take that declaration and "make it so" 17:28:05 thinrichs: based on their capabilities 17:28:21 glebo: we've been assuming that Congress will leverage whatever other policy engines (and more generally datacenter services) that exist. 17:28:54 For basic datacenter services, we had planned on teaching Congress what their API is and what it does. 17:29:17 So there's no new protocol there—we'd just use HTTP or whatever the service expects. 17:29:50 For policy engines, there are 2 pieces: (1) what policy does Congress push and (2) what protocol does it use to do that? 17:30:23 We don't know the answer to (1) yet. (2) is less important, I think. 17:30:36 For (2) we could use opflex, for example, or create a new one. 17:31:13 (1) is hard because the policy engines likely have different languages that they understand. 17:31:15 thinrichs: for (2), that's my question: Are we moving toward consensus on that? 17:31:32 are people leaning toward OpFlex, or I thought there were 17:31:57 some pretty strong sentiments that OpFlex wouldn't get us where we needed to be and something more full-bodied was necessary 17:32:20 I'm not aware of anyone thinking about (2). 17:32:24 i think i have the same need as glebo 17:32:43 I recall john s (don't know his irc handle) saying he was mucking about with some datalog on steroids, or such? 17:32:44 I'm not thinking about (2) b/c I don't know the answer to (1). 17:33:00 glebo: but that has more to do with (1) than (2). 17:33:01 thinrichs: lol 17:33:13 thinrichs: ok 17:33:49 thinrichs: well, re: (1), if we don't specify something strongly 17:34:11 then we certainly will have an issue where all the engines go off and do their own thing, whereas 17:34:12 The *really* hard thing to understand IMO is how these policy engines should cooperate (in terms of the information they exchange and the functionality they provide). The bits they use to wrap the messages they send while cooperating is a lower-level question. 17:34:54 if we come out strongly with a framework spec, and make it clear that we are all in consenus, along with several of the engines, on FOO, then all the engines will line up and do FOO, 17:34:55 glebo: agreed that other engines doing their own thing is a challenge. 17:35:10 because nobody wants to be an island as unto themselves, right? 17:35:13 But I don't believe we can actually stop engines from doing that. 17:35:29 Because there are already engines running around in datacenters that no one will ever modify. 17:36:13 But I agree that once we figure out something sensible, we should get consensus around that and push everyone to adopt. 17:36:19 thinrichs: sure, but those engines will either become obsolete quickly, and fade away, or they will be updated to join the automated system 17:36:40 hmmm… 17:36:55 glebo: Someone told me that something like 10% of code running in their datacenter was Cobol. 17:36:57 thinrichs: me thinks about it a bit differently., 17:37:20 I'm not convinced legacy management tools will die so quickly. 17:37:29 glebo: I thought I was agreeing with you. :) 17:37:49 thinrichs: first, by way of creating a concrete example, give me an example of an engine that you think is ripe for congress integration 17:38:15 thinrichs: Lol. u r, at the highest level, at the end-state. 17:38:29 thinrichs: I think the diff comes from how to get from here to end state 17:38:41 GBP is the obvious first choice 17:39:12 really, as an engine? Don't u think GBP will be subsumed by congress down the road? 17:39:45 I was thinking more of something like neutron/L2-network-assignment 17:39:46 Do you have an engine in mind? 17:39:58 or FWaaS 17:40:02 or LBaaS 17:40:30 or Nova-placement-of-instance-on-host 17:40:42 I guess I don't think of those as policy engines. 17:40:50 They don't separate desired state from observed state. 17:40:57 oh no? Maybe I'm goofed on my definitions here 17:41:18 There's no hard definition of course. And my thinking about this changes weekly. 17:41:40 Up to now we've treated Neutron as a standard data service. 17:41:45 You write policy over the tables it exports. 17:41:47 don't they take desired state, in the form of a policy declaration from congress, and then create the actual state, which quickly turns into observed state? 17:42:06 And enforcement is done by making Neutron API calls. 17:42:12 thinrichs: "changes weekly": lmao 17:42:25 glebo: what isn't a policy engine then, by that definition? 17:42:57 thinrichs: hmmm…. 17:43:07 thinrichs: I guess I tend to think of things as 17:43:29 But let's not get hung up on english words. Sounds like you want us to take a policy and push down L2/L3 connectivity in Neutron. 17:43:30 Yes? 17:43:39 thinrichs: policy description points, and policy enactments points 17:44:00 thinrichs: but it seems that perhaps you have a middle layer of policy consumption points? 17:44:28 thinrichs: not quite what I was thinking, 17:44:39 From Congress's point of view Neutron is a PEP. 17:44:44 Congress is a PDP. 17:45:22 Nothing I'd call a middle-layer that I can think of. 17:45:32 thinrichs: I was thinking that congress takes policy and declares the desired state "down", and the recipient of that declaration is then responsible for enacting the declaration, or stating it can't do so. 17:46:15 right, so, if I'm understanding this correctly, we can either (a) have 1000 API's supported, or 17:46:31 sorry, that was an ( a ), not angel, 17:47:32 ( b ) use a protocol for declaring desired policy in a structured format, and highly adaptable registries for the contents of those messages, 17:47:49 so that all recipients understand the same message constructs 17:47:52 e.g. 17:48:18 the protocol all PEPs speak with Congress is *FOO*, and 17:48:41 there is some sort of TLV format, 17:49:13 where the Types and fixed values are all clearly defined in an Internet registry 17:49:21 , e.g. 17:49:47 Having all PEPs speak the same language would be fantastic! But I don't see that as a practical solution in the short term. I'm dubious that anyone will use Congress if it only works when all of the PEPs speak the Congress language. 17:49:55 It's an insertion question. 17:50:03 subnet, or IPv4addr, or AccessControlAction 17:50:28 We've spent quite a bit of time minutes on this. I know sarob is patiently waiting to give us a status report. 17:50:30 thinrichs: for sure 17:50:37 np 17:50:49 but we can say, for the small, fixed …. 17:50:49 And we want to have some time for others to ask questions. 17:50:56 *breaks to give air to others* 17:51:03 glebo: :) 17:51:12 sarob: want to give us an update? 17:51:44 sure 17:52:36 the kilo design summit etherpad is here #link https://etherpad.openstack.org/p/par-kilo-congress-design-session 17:53:09 i have dumped all the possible specs, bp, and topics 17:53:19 i will start consolidating today 17:53:37 we need the team to start dumping ideas into here as well 17:53:48 so we can put together an agenda 17:54:15 we also have the operations design sessions again 17:54:33 the operations design etherpad is here #link https://etherpad.openstack.org/p/PAR-ops-meetup 17:54:55 we should at least reprise our brief talk from the last operations summit 17:55:11 or give an updated version of the same talk 17:56:16 other than me responding to reviews and starting to clean up the wiki 17:56:21 that is all for me 17:56:49 Great! Let's all try to dump ideas into the etherpad so we can set an agenda before Paris. 17:56:51 anything outstanding for me that I left out? 17:57:16 would others be interested in taking the discussion thinrichs and I were having into congress channel after our conclusion here? 17:57:26 i would 17:57:31 ill bite too 17:57:35 glebo: yes 17:57:40 *glee* 17:57:48 sarob: I didn't see an entry for Congress in the operators etherpad. 17:58:07 sarob: want to add something so we have a shot at giving the talk you described? 17:58:22 thinrichs: i thought i added that already... hmmm 17:58:34 sarob: maybe I missed it. Just did a search for Congress 17:59:01 +1, no hits on "congress" 17:59:05 nope its not there, strange 17:59:14 ill pop it in there again 17:59:19 *hears twilight zone theme song* 17:59:26 we are pumpkin! 17:59:57 Oops—we're out of time. Let's continue on #congress. Fair warning: I only have 30 minutes. 17:59:58 * sarob i like glee 18:00:05 #endmeeting