00:02:17 <thinrichs> #startmeeting CongressTeamMeeting
00:02:18 <openstack> Meeting started Thu Aug 25 00:02:17 2016 UTC and is due to finish in 60 minutes.  The chair is thinrichs. Information about MeetBot at http://wiki.debian.org/MeetBot.
00:02:18 <aimeeu> good day everyone!
00:02:19 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
00:02:21 <openstack> The meeting name has been set to 'congressteammeeting'
00:02:32 <masahito> hello
00:03:03 <thinrichs> Here's my agenda for today…
00:03:06 <thinrichs> 1. newton3
00:03:10 <thinrichs> 2. status updates
00:03:25 <thinrichs> Anything else?
00:04:00 <masahito> summit room
00:04:57 <thinrichs> masahito: thanks!
00:05:01 <masahito> I saw some mails in openstack-dev ML about how much they want to request summit room.
00:05:02 <thinrichs> 3. summit rooms
00:05:29 <thinrichs> Let's get started.
00:05:31 <thinrichs> #topic newton3
00:05:44 <thinrichs> We release newton3 next week along with the client library
00:06:29 <thinrichs> So we should be getting our least features in over the next week
00:06:38 <thinrichs> Anything that we're worried about finishing in time?
00:07:36 <masahito> I noticed client doesn't support pushing data
00:07:37 <ekcs> I’m not working on any features right now. but working on testing. only concern is finding out something is broken last min.
00:08:09 <masahito> I'll push it in today.
00:09:09 <ramineni_> hi, sorry, im late
00:09:20 <thinrichs> Okay, so that seems like there's nothing too risky to pay much attention too.
00:09:40 <thinrichs> ramineni_: hi.  Going over newton3.  Any features you're worried about not getting finished by next week?
00:10:29 <ramineni_> no, i think should be fine
00:11:48 <thinrichs> Anything else for newton3 then?
00:13:19 <thinrichs> #topic meeting rooms for barcelona
00:13:32 <thinrichs> We need to figure out how many rooms to request for barcelona and what types of rooms.
00:13:56 <thinrichs> 2 types of rooms.  Small ones (20ish, if it's like Austin) and large ones (50ish people)
00:14:12 <thinrichs> Large rooms are better if we want to engage non-congress teams
00:14:16 <thinrichs> Small rooms are good for us.
00:14:28 <thinrichs> Last couple of summits we had 3 small and 1 large room.
00:15:16 <thinrichs> It's worth brainstorming about what topics we'd want to cover in the small rooms and whether we have a cross-project topic for a large room.
00:15:20 <thinrichs> Any thoughts?
00:16:09 <aimeeu> Are there many blueprints for Ocata?
00:16:41 <thinrichs> The majority of our focus has been on HAHT for quite some time.
00:17:24 <thinrichs> The policy-history blueprint is out there (masahito).
00:17:30 <aimeeu> Ok. I see there are a number of approved blueprints that haven't been started.
00:18:49 <ekcs> hmmm. cross project collab discussion (like last time) would definitely be good if there is interest. not sure if there is the same kind of interest though.
00:19:16 <thinrichs> Now that we're almost out from under HAHT, I'd say it's time to return to the long-term goal of proliferating policy throughout the openstack ecosystem
00:20:01 <thinrichs> Devoting a session to brainstorming how we might do that seems worthwhile to me.
00:20:15 <aimeeu> As a newbie I like that idea.
00:20:40 <thinrichs> Going back to some use-cases and understanding how to drive them
00:20:57 <thinrichs> That
00:21:10 <thinrichs> That'll take up 1-2 small sessions I'd say.
00:21:30 <thinrichs> If we have concrete teams we want to talk to, we could pull them into a Large room.
00:22:29 <thinrichs> ekcs: we could invite the vitrage and watcher teams for the large session to update each other on projects and look for synergies.
00:22:54 <thinrichs> (Those were the 2 projects from last summit that seemed quite close in goals.)
00:23:43 <thinrichs> Let's all brainstorm so that next week we can have another discussion.
00:23:55 <thinrichs> Right now I'm thinking we ask for our usual 3+1 rooms.
00:24:27 <thinrichs> Any thoughts/comments?
00:25:06 <ekcs> makes sense!
00:25:11 <masahito> thinrichs: I agreed. then let's discuss what we use the slot in etherpad or somewhere.
00:25:25 <thinrichs> Great!  Moving on then…
00:25:28 <thinrichs> #topic status
00:25:43 <thinrichs> ramineni_: want to give a status update?
00:25:50 <ramineni_> sure
00:27:19 <ramineni_> last week, mostly i was trying to complete/update the patches which are put up already.
00:27:32 <ramineni_> some pacthes are removing old dse code
00:28:08 <ramineni_> reminding me, should we remove one gate job, where we test distrubuted_architecture=False, i think its not useful now right
00:28:38 <thinrichs> ramineni_: agreed that we can drop that gate job
00:29:05 <ramineni_> thinrichs: great, ill remove them then
00:29:13 <ramineni_> thinrichs: thats it from my side
00:29:13 <ekcs> should we keep the gate job just make it do nothing for now? so we can easily reappropriate it for something else later?
00:29:16 <thinrichs> There's also the job where we run tests2, but that's empty
00:29:38 <ekcs> instead of waiting for infra.
00:29:55 <ramineni_> thinrichs: yes, both we need to remove ,
00:30:14 <ramineni_> ekcs: why do we want that?
00:30:34 <ramineni_> ekcs: we can make both gate jobs do test only dist_arch=True
00:30:52 <thinrichs> ekcs: I think we need to wait on infra to change what the gate jobs are doing anyway
00:30:54 <ekcs> we’ll need another gate job for HA when that’s ready. I figure we may shift things over
00:31:17 <ekcs> where regular gate now runs dist_arch=True.
00:31:18 <ramineni_> ekcs: that need changes anyway in infra
00:31:23 <ekcs> and newarch gate runs HA.
00:31:25 <ekcs> oh ak.
00:31:35 <ekcs> ok
00:32:06 <ramineni_> ill try to post the job on HA also this week
00:32:08 <ekcs> nvm then =p
00:32:54 <masahito> ekcs: I think infra team usually doesn't refuse our requests adding new voting test, so we don't need to mind it.
00:32:58 <masahito> :)
00:33:20 <thinrichs> aimeeu: want to give us a status update?
00:33:31 <aimeeu> Sure. I was on vacation last week so not much from me.
00:34:02 <aimeeu> I pushed an update to the HA guides #link https://review.openstack.org/#/c/350731/2   thanks masahito for your comments
00:34:37 <aimeeu> I plan to work on #link https://bugs.launchpad.net/congress/+bug/1602837  the rest of this week
00:34:37 <openstack> Launchpad bug 1602837 in congress "Policy UI (Horizon): Unable to get policies list (devstack)" [High,In progress] - Assigned to Aimee Ukasick (aimeeu)
00:34:55 <aimeeu> That's it for me
00:35:18 <thinrichs> aimeeu: Any luck with devstack?
00:35:30 <thinrichs> We all struggle with it
00:36:04 <aimeeu> not in the VM. I just installed Ubuntu server on a spare laptop and will try devstack there. Worst case I disable Tempest in the local.conf
00:36:33 <aimeeu> at least that will give me running devstack instance so I can work on my bugs
00:36:41 <thinrichs> Sounds good.  Getting the right base OS can be a challenge
00:37:01 <thinrichs> masahito: want to go next?
00:37:02 <ekcs> aimeeu: I think it’s an SSL issue. I’ll irc/email you more later if I find a solution.
00:37:11 <masahito> ok
00:37:31 <masahito> 1. Starting to clean up old dse codes in policy engine
00:37:36 <masahito> 2. First patch for lazy datasource was merged. Working on other datasource supporting the feature
00:37:40 <masahito> 3. Working on client codes to support push-data
00:37:51 <masahito> that's from my side
00:37:58 <thinrichs> Is (3) going into newton?
00:39:15 <masahito> The change is not big. So if someone could review it I think we can go.
00:39:49 <masahito> I think our client supports all API the server has.
00:40:07 <masahito> How do you think?
00:40:49 <thinrichs> masahito: sounds good.
00:41:17 <thinrichs> The client should support that for sure.  We forgot to add it at the end of mitaka.
00:42:46 <masahito> right. And not tested the API well at mitaka release.
00:43:10 <masahito> But now we have tempest test for the API.
00:44:25 <thinrichs> All sounds good to me.
00:44:28 <thinrichs> ekcs: status?
00:44:35 <ekcs> Been working on doing HA functional testing inside test_congress. Current plan is to spin up new processes using Popen, similar to how it's done in testHA. Except using congress_server.py rather than bin/congress-server
00:44:38 <ekcs> N API+PE nodes on different ports, 1 DSD node, each in it's own process.
00:44:43 <ekcs> Not totally sure it'll work yet. Will probably need to force some tests to be non-parallel to avoid DB clashing. Is it bad practice to Popen in the unittest framework?
00:45:13 <ekcs> I also came across something weird where even though config.py has distributed_architecture default to True, congress_server.py still sees it as False if not specified in conf file. Maybe it's user error on my part. Still investigating.
00:45:19 <ekcs> Other than that, I have the auto resub patch ready. #link https://review.openstack.org/#/c/356806/
00:45:19 <ekcs> But it has a limitation that if there is only a single update, but that update gets lost, it would not be detected as missing. If we have time I'd like to hear your thoughts on whether that's fine or we should take a different approach.
00:45:22 <ekcs> That’s all.
00:48:34 <thinrichs> The distributed_arch flag seems worrisome.  I thought we removed all the code that used it, so it wouldn't matter what it was set to.
00:48:40 <thinrichs> Or is there still code that depends on it?
00:49:21 <ramineni_> yes, we need to remove from congress_server I guess
00:49:32 <ekcs> I didn’t find any real code that depended on it. just surface things like disallowing certain flags without it. easy to fix.
00:49:53 <ekcs> I’m just stumped as to why it shows up as false even though we set default to true.
00:50:37 <thinrichs> Okay.  Sounded like a scary thing at first, but not so scary now.
00:50:59 <thinrichs> The unittests sound interesting.  I don't know about conventions around popen.
00:51:18 <thinrichs> I'm guessing it's frowned upon.
00:51:44 <thinrichs> But we only have 2 real options: tempest and unittests.
00:52:27 <thinrichs> It's hard to tell on the auto-resub patch.
00:52:40 <ekcs> Once it’s done as unittest, it shouldn’t be hard to convert to tempest if desired.
00:53:07 <thinrichs> Missing a case is obviously not great, but for us we expect the datasources to be continually sending updates.
00:53:38 <thinrichs> If there's an edge case that only happens when (a) you kill a datasource and (b) the last message gets lost in transit, I'd say that's acceptable.
00:53:52 <thinrichs> You're killing the datasource anyway.
00:53:59 <thinrichs> Or is this also a problem with push drivers?
00:54:21 <ekcs> thinrichs: exactly. the missing a case was a deliberate design to use only information availble on teh receiver end. but with push driver, it’s not good.
00:54:59 <thinrichs> Is the policy engine syncing pushed data from the DB?
00:54:59 <ekcs> if push just once and never again, but that one update is lost, then we don’t detect it.
00:55:40 <ekcs> not syncing at the moment. only the dsd grabs from DB if it restarts.
00:55:42 <thinrichs> B/c then there wouldn't be a problem
00:56:11 <ekcs> maybe those interested can take a look at the alternatives I described in the commit message.
00:56:24 <ekcs> and say what you think.
00:56:25 <thinrichs> Lost track of time…let's all comment on this in gerrit
00:56:31 <thinrichs> 4 minutes left
00:56:37 <thinrichs> #topic open discussion
00:56:42 <thinrichs> Anything else to discuss?
00:56:58 <thinrichs> (If not, we can continue the auto-resub discussion.)
00:58:03 <thinrichs> Back to auto-resub then I guess...
00:58:28 <thinrichs> If the pusher sends 2 messages, will we detect that the 2nd didn't happen if it gets lost?
00:58:39 <ekcs> no.
00:58:49 <thinrichs> So we may always miss the last message
00:59:00 <ekcs> right.
00:59:03 <thinrichs> Hmmm…the push driver may be different anyway though
00:59:19 <thinrichs> because there's no reasonable interval we can use to detect when a message *should* have arrived
00:59:29 <thinrichs> Am I thinking about that right?
01:00:01 <ekcs> well the alternative is for the DSD to broadcast in HB last push time/seqnum
01:00:22 <ekcs> or for the subscriber to periodically request that from all publishers.
01:00:49 <ekcs> anyway I have sketched the options in the patch.
01:01:01 <thinrichs> I see.  There must be standard answers to these questions.
01:01:02 <ekcs> HB as in heartbeat.
01:01:08 <thinrichs> Out of time.
01:01:18 <masahito> another alternative is subscriber pull data from push (or poll) driver every time when they want to need the data
01:01:31 <thinrichs> Remember to think about ideas you'd like to see covered in the summit sessions!
01:01:35 <thinrichs> Thanks all!
01:01:38 <thinrichs> #endmeeting