17:01:49 <thinrichs> #startmeeting CongressTeamMeeting
17:01:50 <openstack> Meeting started Tue Feb 10 17:01:49 2015 UTC and is due to finish in 60 minutes.  The chair is thinrichs. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:01:51 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:01:54 <openstack> The meeting name has been set to 'congressteammeeting'
17:02:25 <thinrichs> Let's start out with status updates.
17:02:27 <thinrichs> #topic status
17:02:45 <thinrichs> cloudtoa_: want to start?  How's the dse-control-bus work going?
17:03:01 <arosen> Hi
17:03:15 <sarob> morn
17:03:20 <arosen> ing]
17:03:35 <sarob> whatever ;)
17:04:05 <thinrichs> arosen: we're starting with statuses and waiting a minute for cloudtoa_ to pipe up.
17:04:32 <thinrichs> Maybe cloudtoa_ stepped away.
17:04:37 <arosen> sounds good :)
17:04:43 <thinrichs> sarob: want to give a status report?
17:05:12 <sarob> sure
17:06:10 <sarob> the sprint seemed to a moderate success
17:06:28 <sarob> not having people in the same physical space
17:06:35 <sarob> doesnt a strong sprint make
17:06:53 <sarob> i do see more new faces over the last week
17:07:12 <sarob> as a team we are looking good
17:07:34 <sarob> even though our reviews are bit heavy on a few people
17:08:04 <sarob> we have 7 companies contributing code
17:08:38 <sarob> actually 8 including huawei
17:09:09 <sarob> we had some discussing around cuting 2014.2.2 congress
17:09:20 <sarob> do you want to discuss that now?
17:09:29 <thinrichs> It's great to see so many different companies contributing!
17:09:48 <thinrichs> sarob: sure.
17:10:07 <arosen> I think pushing a tag for 2014.2.2 would be a good idea as a milestone.
17:10:35 <sarob> plus launchpad kilo2 milestone wrap
17:10:41 <thinrichs> Sounds good to me as well.
17:11:32 <thinrichs> sarob, arosen: anything the group needs to know or do to prepare?
17:12:06 <sarob> i dont think so
17:12:27 <sarob> other than 2014.2.2 shouldnt be too buggy
17:12:47 <arosen> Yea we'll just need to decide when we want to push that tag.
17:12:57 * arosen i believe.
17:13:08 * sarob believes too
17:13:18 <arosen> I think we could push that today before all my changes merge and break everything ;)
17:13:28 <sarob> well there you go
17:13:37 <sarob> perfect timing
17:13:46 <thinrichs> Do we have any volunteers to manually test the code at the tip of master and make sure nothing's obviously broken?
17:14:27 <sarob> ill take a pass at it
17:14:32 <arosen> we have our CI doing some limited testing on the code so we are probably okay unless someone wants to test soming specific
17:14:36 <sarob> should be a few others toooo
17:14:37 <thinrichs> sarob: thanks!
17:14:41 <arosen> cool
17:15:18 <thinrichs> It seems we have a light crew at the meeting today.
17:15:38 <thinrichs> Maybe we should send a note out to the ML to see if anyone can help out testing.
17:15:42 * sarob thinking strategy strategy strategy
17:15:53 <thinrichs> Let's pick a commit ID so everyone is testing the same thing.
17:16:00 <sarob> thinrichs that would be a good idea
17:16:39 * sarob has a fire burning
17:16:42 <thinrichs> arosen: want to pick out the commit ID you think looks best?  You've been pushing a bunch lately.
17:17:01 <arosen> lets  say current top of master:  47991c608d01721827ecaf92cf8ce05efc569f27
17:19:01 <thinrichs> Looks good to me.
17:19:33 <thinrichs> sarob: Mind driving this and letting the rest of us know what to do and when to do it?
17:19:48 <sarob> shirely
17:20:06 <thinrichs> Thanks!
17:20:12 <thinrichs> sarob: anything else to report?
17:20:16 <sarob> noope
17:20:26 <thinrichs> arosen: want to tell us what you've been up to?
17:20:27 <sarob> well other than
17:20:32 <sarob> summit talks
17:20:38 <thinrichs> arosen: hold up a sec
17:20:46 <sarob> we can discuss that next week
17:20:54 <sarob> as talks get cleaned up
17:20:57 <thinrichs> The voting begins next week?
17:21:19 <sarob> hmm, prob
17:21:34 <sarob> arosen you member the voting delay
17:21:41 <sarob> i think its a week
17:22:01 <arosen> yea i think a week
17:22:12 <thinrichs> Sounds good—let's discuss summit talks next week.
17:22:20 <thinrichs> arosen: want to do a status update?
17:22:28 <arosen> I've been working on a new api to allow us to see what datasource drivers congress has installed and then allow users to dynamically create and delete datasources
17:23:03 <arosen> Here's a quick preview of the cli showing the new api calls:   paste.openstack.org/show/170257/
17:23:26 <arosen> The patches are all up on review that implement this. I'm hoping that we'll be able to merge these soon since some of them are pretty large.
17:24:00 <arosen> once these patches merge the next thing i think i'm going to bite off is to enable our API to be muli tenant
17:24:12 <arosen> these initially patches lay a lot of ground work for that thoguh.
17:24:20 <arosen> that's it unless someone wants to discuss.
17:24:50 <thinrichs> Spinning up/down new datasource drivers at runtime is great!
17:25:48 <thinrichs> I'm a bit scared about multi-tenancy, mainly because of scale.
17:26:00 <thinrichs> But overall it's good to have it there.
17:26:15 <arosen> I think it's something we'll have to bite off eventually and I'd rather get that built into the api sooner than later :)
17:26:29 <thinrichs> It brings up a fundamental question though.
17:26:54 <thinrichs> If Alice says X is a violation, and Bob says X is not a violation, is X a violation or not?
17:27:26 <arosen> I would say it's a violation to Alice but not to Bob.
17:27:37 <alexsyip> Can it be a violation to one user and not another ?
17:28:01 <thinrichs> But at the end of the day, either Charlie can spin up a VM or he can't.
17:28:18 <thinrichs> People don't get to control their own policy.
17:28:22 <arosen> each user would have their own rules configured though. I think in the general case they wouldn't be connecting to the same thing on the backend.
17:28:29 <arosen> and if they do they would be connecting with different accounts.
17:28:33 <thinrichs> That is, one person's policy will influence another person's ability to do things.
17:28:43 <jwy> how is it resolved today if the admin user creates two conflicting policies?
17:28:50 <thinrichs> Otherwise there's no point to having policy.
17:29:02 <alexsyip> Why would Alice be worried about Charlie’s configuration ?
17:29:27 <thinrichs> jwy: you're right that we run into the same kind of thing with multiple policies.
17:29:28 <arosen> Say i want to say this.  All instances must have a security group that does not allow port 22.
17:29:36 <alexsyip> And why would Charlie care if Alice doesn’t like his VM ?
17:29:51 <arosen> Congress would scope that to just things it sees in the datasources I have configured.
17:30:05 <thinrichs> But we've always been able to say that only the admin writes policies and so it's up to them to do the proper integration.
17:30:23 <thinrichs> alexsyip: because Charlie could be Alice's manager.
17:30:32 <thinrichs> alexsyip: or vice-versa
17:30:43 <arosen> thinrichs:  i think it's the same case. The tenant is able to only write policies over datasources that he has configured.
17:31:15 <thinrichs> Standard policy: prod and test apps need to be isolated (network, compute, storage).
17:31:17 <arosen> if the cloud provider admin in congress has a special policy that will trump yours automatically and yuo won't know.
17:31:35 <thinrichs> That policy impacts *everyone*'s ability to deploy apps.
17:32:16 <thinrichs> What if each user provides policies for how they want their VMs to be deployed?
17:32:24 <thinrichs> Shouldn't the datacenter attempt to accommodate all of them?
17:32:31 <arosen> thinrichs:  that's fine as long as they don't conflict with a datacenter wide policy.
17:33:03 <thinrichs> Charlie might say he doesn't want his VMs deployed on the same host as anyone from test.
17:33:21 <thinrichs> arosen: but then what happens if Charlie's and Alice's policies conflict (and neither is an admin)?
17:33:25 <alexsyip> So one user can write policy that congress will enforce on another user.
17:33:34 <alexsyip> We make that relationship explicit.
17:33:55 <arosen> I don't think we would allow a tenant to write a policy that could affect scheduling like that.
17:34:00 <thinrichs> Good—we're getting to the point that we see multiple users have different policies that interact in some way.
17:34:01 <arosen> the reason why is because
17:34:12 <arosen> only an admin account that connects to the datasource can do that.
17:34:24 <arosen> but you are right this is an interesting example
17:34:31 <arosen> in some systems this could be the case.
17:34:41 <arosen> tricky yea..
17:34:44 <arosen> interesting.
17:34:56 <thinrichs> After all, everyone is running VMs/apps in the same datacenter.  They absolutely interact with each other, and policy will interact as well.
17:35:31 <arosen> well I think it depends on the scope of the policy. I think in general this isn't something that could occur in openstack deployments.
17:36:38 <thinrichs> My assumption has always been that we want people to tell us the policy they *actually* care about.
17:36:48 <thinrichs> We build technology that helps implement/deal with those policies.
17:37:09 <thinrichs> At any rate, I think at this point it's clear there's something more to think about here.
17:37:11 <arosen> yea i understand, i think we should follow up this converstation after the meeting.
17:37:28 <arosen> we can talk about it in person since i don't think anyone else is here right now.
17:37:37 <thinrichs> Shall we continue with status updates?
17:37:40 <arosen> sure
17:37:44 <thinrichs> jwy: how's the Horizon UI going?
17:38:48 <jwy> slow progress… i'll need to change the milestone to kilo-3
17:39:11 <thinrichs> OK.  Anything we can do to help?
17:39:24 <jwy> not at the moment. wasn't happy with what i had initially, so trying out different things
17:39:47 <jwy> once i have something i feel better about, i'll ask for some folks to try it out
17:40:26 <thinrichs> Sounds good.  I'd say we definitely want to hit kilo3, even if we're not 100% happy with it.
17:40:36 <thinrichs> Just let us know when you want us to try it out.
17:41:51 <thinrichs> alexsyip: what have you been up to?
17:42:10 <alexsyip> I’ve been working on a blog post about the performance improvements we’ve done.
17:42:31 <alexsyip> And also I’m investigating how to allow datasources to send data updates directly to congress through a congress api.
17:43:22 <thinrichs> Both of those are really important for some of the deployment environments we're targeting.
17:44:01 <thinrichs> Anyone else with a status update?
17:44:35 <thinrichs> Okay, let's open it up for discussion.
17:44:39 <thinrichs> #topic open discussion
17:44:47 <arosen> alexsyip:  interesting, yea i think that's going to be a good one to figure out.
17:45:04 <arosen> i remember theree was a blueprint i think tim wrote up about that.
17:45:12 <arosen> Though there was some questions about the design
17:45:23 <arosen> also another blueprint tim wrote up about using  oslo.db
17:45:31 <arosen> do you have a plan on how you want to do this?
17:45:43 <alexsyip> arosen: Let’s sync up about that today.  I spoke with pete a little yesterday about the overall api design which was helpful.
17:45:59 <arosen> sounds good
17:46:53 <rajdeepd> hi thinrichs
17:47:03 <rajdeepd> i had a small update
17:47:13 <thinrichs> rajdeepd: hi!  Go for it.
17:47:44 <rajdeepd> submitted the CL for data source status table in horizon UI
17:48:12 <rajdeepd> gone through a couple of reviews with jwy and arosen
17:49:02 <thinrichs> jwy, arosen: want to take another look at rajdeepd's change?
17:49:13 <arosen> sure
17:49:14 <jwy1> yep, was going to do it today
17:49:56 <thinrichs> rajdeepd: anything else?
17:49:58 <rajdeepd> if jwy1 needs help on UI i can help once this review is done
17:50:19 <rajdeepd> thats all from my side
17:50:31 <jwy1> rajdeepd: thanks for the offer, i'll let you know
17:50:56 <rajdeepd> ok jwy1
17:51:41 <thinrichs> Anything else?
17:52:19 <thinrichs> OK.  Let's end the meeting a bit early.
17:52:21 <thinrichs> Thanks all!
17:52:24 <thinrichs> #endmeeting