00:03:01 <pballand> #startmeeting CongressTeamMeeting
00:03:03 <openstack> Meeting started Thu Feb  4 00:03:01 2016 UTC and is due to finish in 60 minutes.  The chair is pballand. Information about MeetBot at http://wiki.debian.org/MeetBot.
00:03:04 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
00:03:06 <openstack> The meeting name has been set to 'congressteammeeting'
00:03:15 <pballand> thinrichs is running late, so he asked me to run the meeting this week
00:03:49 <pballand> topic list:
00:03:56 <pballand> 1. midcycle recap
00:04:04 <pballand> 2. distributed arch next steps
00:04:21 <pballand> 3. mitaka3
00:04:28 <pballand> push datasource driver
00:04:33 <pballand> (4.)
00:04:53 <pballand> 5. monasca integration update
00:04:57 <pballand> 6. other status updates
00:05:09 <pballand> does anyone have somthing else they would like to cover?
00:05:19 <bryan_att> hi, Bryan here for the congress meeting
00:05:32 <pballand> bryan_att: welcome :-)
00:05:47 * bryan_att thanks!
00:06:41 <pballand> ok, lets get started
00:07:08 <pballand> we had a great midcycle sprint last week
00:07:46 <pballand> fabiog gracioulsy hosted - thanks for providing the venue and food :)
00:07:59 <fabiog> pballand: my pleasure
00:08:23 <pballand> thinrichs sent out a summary to openstack-dev .. I can’t seem to find a web link to it but I’m sure it’s out there
00:08:49 <fabiog> https://etherpad.openstack.org/p/congress-mitaka-sprint
00:08:59 <pballand> fabiog: thanks
00:09:31 <pballand> we made a lot of progress, but as thinrichs pointed out in the email, there is still much work to be done
00:10:02 <pballand> so that brings us to 2.) next steps
00:10:48 <pballand> I had a brief chat with tim before the meeting and he is proposing a goal for being on the new architecture by mitaka 3
00:11:02 <pballand> #link http://docs.openstack.org/releases/mitaka/schedule.html
00:11:53 <pballand> that gives us only three weeks to knock off remaining features and get to a functional release
00:12:17 <pballand> the thought is that we can run single-node only to start, but using the new bus in the backend
00:12:58 <pballand> that would make customer transition seamless, and give us time to address issues as they arrive
00:13:10 <pballand> thoughts?
00:13:18 <ekcs> makes sense!
00:14:04 <masahito_> sounds good.
00:14:26 <pballand> okay, along with that, the mitaka3 milestone brings a feature freeze, so any new features need to be “in” by then
00:15:05 <pballand> any questions or comments on the midcycle or distributed arch work?
00:15:25 <ekcs> question: What is our plan with datasource manager?
00:15:38 <ekcs> will in continue to exist?
00:16:18 <pballand> ekcs: good question - Tim brought that up to me
00:16:57 <pballand> originally we had discarded that feature, but it is appealing to maintain it
00:17:23 <pballand> it doens’t seem like much additional work, since the vast majority of the code could be resused
00:17:44 <pballand> one issue that came to mind is that oslo.messaging has a deprecation notice about restarting RPC services
00:18:07 <pballand> it seems like we could easily work around that by spawning new services though (we would probably do that anyway, actually)
00:18:59 <pballand> so it seems like we can maintain the same management APIs in the single-node-on-new-bus version
00:19:00 <pballand> thoughts?
00:19:25 <ekcs> i see. at some point i need to understand more the vision for ds maanger in this world.
00:19:51 <ekcs> for  example whether it should be a global ds manager or a per node ds manager.
00:20:41 <ekcs> doesn’t need to be now.
00:20:45 <pballand> ekcs: I agree that it can get a bit confusing / error prone for services that aren’t natively multi-node
00:21:14 <pballand> I think we can expect the general case to be single-node for now, and tackle the more complicated cases later, fair?
00:21:54 <pballand> ramineni: I wanted to give you a chance to chime in with any questions about the midcycle or dist arch since you weren’t able to attend
00:22:00 <fabiog> pballand: what is the role of the Manager? Is the message filtering task or something else?
00:22:31 <pballand> fabiog: I believe the manager ekcs is referring to is the ability to start/stop datasources dynamically
00:22:39 <pballand> ekcs: did I get that right?
00:23:24 <ramineni> pballand: sure, thanks :) .. going through all the patches to make myself understand the new arch
00:23:27 <ekcs> pballand: yes. also just a central place where you ask for schemas and tables and data.
00:23:47 <fabiog> pballand: ok, got it and the request is initiated by the UI
00:24:11 <pballand> (sorry for forking 3 conversations)
00:24:15 <fabiog> pballand: so eventually this can be distributed too
00:24:18 <pballand> ekcs, right ;thanks
00:24:33 <fabiog> using the queue as a request/response mechanism
00:25:23 <pballand> fabiog: yes, the UI can control datasources; since not all datasources are distribution or HA aware, however, it could cause problems if the operator is not careful in a mulit-node setup
00:26:26 <pballand> ramineni: great, just let us know if you have questions, concerns, or suggestions
00:27:05 <pballand> alright, lets move on
00:27:30 <pballand> masahito_: an updates on the push driver?
00:27:40 <ramineni> pballand: sure
00:28:26 <masahito_> I updated the patch based on previous IRC meeting.
00:28:53 <masahito_> 1. remove http_driver out from the patch
00:29:46 <masahito_> 2. API request updates its table with request body.
00:30:11 <masahito_> All the patch for the push driver is in review now.
00:30:16 <masahito_> that's it
00:31:03 <masahito_> https://review.openstack.org/#/c/256303/
00:31:09 <masahito_> https://review.openstack.org/#/c/266347/
00:31:24 <thinrichs> Hi all.  Sorry I'm late.  I caught up on eavesdrop.  Please continue.
00:31:57 <pballand> masahito_: thanks
00:32:12 <pballand> all, please take some time to review the patches
00:32:18 <pballand> (that applies to me too :-P)
00:32:45 <pballand> thinrichs: do you want take over?  I only have one more item
00:33:25 <thinrichs> pballand: please continue.  You've already covered the main thing I wanted to discuss.
00:34:18 <pballand> ok, fabiog, you’re up next, can you please give an update on monasca?
00:34:42 <fabiog> sure. I managed to get a devstack with both congress and monasca
00:34:47 <fabiog> actually ceilosca
00:34:56 <fabiog> which is ceilometer and monasca
00:35:24 <fabiog> I am also working on getting the monasca client part of the global-requirements
00:35:38 <fabiog> this week we have a "virtual" Monasca mid-cycle
00:35:48 <fabiog> so I hope to get that resolved by EOW
00:36:16 <fabiog> then I will push a patch that enables the python client so then you can get it working with the current data source
00:36:22 <fabiog> any questions?
00:36:41 <fabiog> regarding the alarm notifications
00:36:58 <fabiog> my understanding is that I have to leverage masahito_ work on the datasource_rpc
00:37:02 <fabiog> is that correct?
00:37:35 <fabiog> the alarm will hit the endpoint that calls the rpc in the "monasca_alarm_handling" datasource and update the table
00:37:50 <thinrichs> fabiog: I think not.
00:38:05 <thinrichs> We decided you could use the existing datasource functionality to execute actions
00:38:12 <fabiog> thinrichs: ah, so I got it wrong
00:38:16 <thinrichs> So the webhook for the alarm would be something like….
00:38:55 <thinrichs> … /v1/data-sources/monasca?execute&action=alarm_notif
00:39:23 <thinrichs> Then in the monasca datasource driver (or in a separate driver), you'd add the method alarm_notif() and do whatever you need there.
00:39:32 <thinrichs> That's the picture you took of the whiteboard
00:39:44 <fabiog> ok, I thought that required the push mode
00:39:58 <fabiog> so you are saying that the callback is there already
00:40:08 <thinrichs> (For a while we thought we could use masahito's push driver, but then realized the alarm wasn't strictly pushing data.)
00:40:19 <thinrichs> So yes the callbacks are already available via the API.
00:40:48 <fabiog> thinrichs: and is the payload already passed by default or do I need to have it part of the request URI?
00:40:58 <fabiog> I am thinking here at the alarm id for instance
00:41:06 <fabiog> and alarm status
00:41:19 <thinrichs> I think it's a POST, so you can include arbitrary json in the body of the request.
00:41:33 <thinrichs> I believe that json is passed to the alarm_notif() function as an arg.
00:41:49 <fabiog> ok, that should make things easy, then
00:42:51 <thinrichs> Hmm… looks like the data sent to the action might be a little more complicated:
00:43:01 <thinrichs> {'positional': ['arg1', 'arg2'],
00:43:01 <thinrichs> 'named': {'key1': 'value1', 'key2': 'value2'}}
00:43:16 <fabiog> my real constraint is time right now. With the big Cisco conference in Berlin coming up in 2 weeks my time is really constrained, but I would like to at least try to build a scheleton patch
00:43:29 <thinrichs> fabiog: totally understand.
00:43:49 <fabiog> thinrichs: but those seems to be query params
00:44:44 <thinrichs> fabiog: right—you may just need to make the body of the POST be a dictionary with keys 'positional' and 'named'.  I'm not 100% sure that's necessary, but it might be.
00:44:54 <fabiog> can you post the reference to the code you are looking at, pleasE?
00:45:42 <thinrichs> #link https://github.com/openstack/congress/blob/master/congress/datasources/datasource_driver.py#L1292
00:45:47 <fabiog> thanks
00:46:56 <thinrichs> pballand: anything else on the agenda?
00:47:12 <pballand> that was all I have
00:47:20 <pballand> open floor
00:47:42 <thinrichs> bryan_att: how are things going for you?  Anything to report?
00:49:18 <thinrichs> Any questions about how we're migrating to DSE2?
00:50:45 <thinrichs> Just saw this tempest failure in the gate…anyone know if this is real?
00:50:47 <thinrichs> http://logs.openstack.org/34/273734/11/gate/gate-congress-dsvm-api/63f423c/console.html
00:52:01 <ramineni> thinrichs: i think recheck will do
00:52:08 <thinrichs> ok
00:53:07 <ramineni> thinrichs: pballand: one question
00:54:08 <ramineni> everytime , in tests we are registering rule-api , row-api as service right?  why is that necessary? it will create as rpcserver?
00:54:52 <thinrichs> That's an intermediate step.
00:54:58 <ramineni> API services just interact with rpcclient for invoking server right
00:55:30 <thinrichs> We're working on adding all the api models into a single DataService.
00:55:57 <thinrichs> Then all of the tests will add that 1 DataService to the DseNode instead of adding rule-api, row-api, etc. as separate DataServices
00:56:02 <thinrichs> But that's not done yet.
00:56:14 <thinrichs> So until we have 1 DataService node that contains all the api models,
00:56:25 <ramineni> thinrichs: ok
00:56:26 <thinrichs> we're adding each of the API models as separate DataServices.
00:57:08 <thinrichs> But this way we can make progress in parallel on (i) migrating API models and (ii) bundling the API models together.
00:57:41 <ramineni> thinrichs: ohok, got it ..thanks
00:58:54 <pballand> ok, we’re pretty much out of time
00:58:57 <pballand> thanks everyone!
00:59:05 <pballand> #endmeeting