10:02:47 <tonyb> #startmeeting requirements
10:02:48 <openstack> Meeting started Wed Nov  2 10:02:47 2016 UTC and is due to finish in 60 minutes.  The chair is tonyb. Information about MeetBot at http://wiki.debian.org/MeetBot.
10:02:49 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
10:02:51 <openstack> The meeting name has been set to 'requirements'
10:02:54 <tonyb> #topix rollcall
10:03:23 <tonyb> #topic rollcall
10:03:34 <tonyb> sigmavirus, prometheanfire, number80, dirk, coolsvap, toabctl ... we're over here for today
10:03:48 <toabctl> hey
10:03:52 <number80> o/
10:04:17 <tonyb> sorry for the venue change .. not sure how we have a conflict :(
10:04:43 <number80> it's okay, I also live here :)
10:04:47 <tonyb> :)
10:06:32 <tonyb> okay well the other can wander in late ...
10:06:46 <tonyb> #topic Any controversies in the Queue?
10:07:07 <tonyb> I have gunicorn and kobu/amqp to talk about alter but others?
10:08:35 <number80> no other controversies in the queue for me
10:08:52 <tonyb> okay
10:09:13 <tonyb> So do we need to go into the background on gunicorn?
10:09:34 <number80> I think so, other projects are using uwsgi and we already have waitress
10:10:20 <coolsvap> hey
10:10:24 <tonyb> I don't know abotu waitress but es otehrs are using uwsgi or apache with mod_wsgi
10:10:28 <tonyb> coolsvap: hey
10:10:31 <number80> yes
10:11:12 <tonyb> there has been a line drwn in the sand that thr application uses a frame work (flask, etc) and it up to deployers to choose which server they want (uswsgi / apache)
10:11:53 <tonyb> in this cane we're beeing requiested to add gunicorn so that a mircoservice installed in a service VM can use it *and* the project can be managed by g-r
10:12:23 <tonyb> the issues I have are 1) g-r is about co-installability and this service isnt co-installed with the rest of OpenStack
10:13:06 <tonyb> 2) AFAICT this forces gunicorn on all users regardless of the preferred server choice in the service VM
10:13:37 <tonyb> and 3) an ammount of history/FUD around adding gunicorn to g-r beeing taken as a blessing for oethr to use it
10:13:48 <tonyb> which removes more choice from deployers / packagers
10:14:22 <tonyb> There is an Octavia? review up that shows how it'll be used but I habent had time to review it
10:14:41 <tonyb> Have others ooked at it ?
10:14:43 <number80> since they only need it for the gate, then waitress should probably do the job
10:15:49 <tonyb> number80: okay but we dont' seem to have waitress in g-r (only in u-c) so that doesn't really help the meta-question
10:16:11 <coolsvap> tonyb: i believe the the points mentioned is a good reason to not let it in and we have alternatives which other projects are using
10:16:31 <number80> well, forcing a wsgi framework is not acceptable as you said
10:18:11 <coolsvap> I havent seen the octavia review either
10:18:33 <tonyb> let me dif it up ...
10:18:51 <tonyb> #link https://review.openstack.org/#/c/386758/
10:19:06 <tonyb> It's in the commit message of the gunicorn (requirements change)
10:21:30 <number80> this change is incorrect, they were using incorrectly werkzeug in the first place (of course, they'd have bugs by using the dev server in prod)
10:22:15 <tonyb> number80: right, and this is the fix
10:23:34 <number80> maybe we should point them to how neutron solved that since they both use Pecan
10:24:01 <tonyb> number80: they don't want pecan as it's "too heavy" for the microservice
10:24:20 <tonyb> I think we need to accept that gunicorn is a good fit for want they want
10:24:49 <tonyb> it's just a question of adding it to g-r *or* not and them workign around that in the gate
10:25:02 <tonyb> My worry is about user expectations and flexibility
10:25:29 <number80> ack
10:25:52 <tonyb> The seems to be only for the gate and not for actual users of the service VM BUT that seems non-sensical to me
10:26:02 <tonyb> which probably measn I'm missing something
10:26:36 <tonyb> I also don't want to cause undue burdon / stall on anyone
10:27:12 <tonyb> If you have any free time leave a review and I'll do the same
10:27:25 <number80> I'll do
10:27:29 <tonyb> I'd like to have this merged or abandoned by next weeks meeting
10:27:50 <coolsvap> tonyb: yes, if they need it only in gates, can they work with it only in test-requirements?
10:28:28 <tonyb> coolsvap: Well that still measn adding it to g-r so it doesn't change the conversation greatly
10:29:28 <tonyb> frankly my gut is saying it wrong but we shoudl take it with a "big comment" because I really don't like saying "no"
10:29:46 <coolsvap> tonyb: yes but then it makes more sense than what it correctly
10:29:48 <tonyb> but I'm worried that'll just buy us moer trouble down the track ...
10:30:21 <tonyb> coolsvap: perhaps.  I need to learn more about Octavia
10:30:59 <tonyb> I think we shoudl timebox this conversation as we have the amqp/kombu discussion
10:31:26 <coolsvap> yes lets put more comments on review this week and get it concluded
10:31:51 <coolsvap> tonyb: another review i had on my mind is https://review.openstack.org/#/c/374432/
10:32:03 <tonyb> ampq/kombu ... https://bugs.launchpad.net/oslo.messaging/+bug/1638263/comments/5
10:32:05 <openstack> Launchpad bug 1638263 in OpenStack Global Requirements "Unit tests failing on vine.five import" [Medium,Confirmed]
10:32:26 <tonyb> I think that link cover my expectations/understand and history of how we got here
10:33:09 <tonyb> I *think* a compromise position would be the block 4.0.0 rather than cap and then we can progress towards 4.0.0 as cycle occur
10:33:51 <tonyb> the +/- of that pproach is *everytime* kombu release oslo.messaging will break until we block new version in g-r
10:35:30 <coolsvap> yes i also think block 4.0.0 would be better forward looking approach
10:35:40 <number80> *nods*
10:36:05 <tonyb> okay I'll unblock the 2 reviews and leave that as a comment
10:37:45 <tonyb> coolsvap: to the review to brought up ...
10:37:55 <tonyb> It looks like it can be +W'd
10:38:48 <coolsvap> tonyb: yes thats why i brought it up
10:39:28 <tonyb> coolsvap: done.
10:39:58 <tonyb> coolsvap: I don't like bypassing a core's -1 but AFICT it shoudl have been lost when patchset 4 was uploaded anyway
10:40:25 <coolsvap> tonyb: ack
10:41:00 <tonyb> I have on the agenda to talk about the priorities but I need to really sit down an write that up befoer it'll really make sense (interms of what needs doing and in what order)
10:41:35 <tonyb> We started with the base assuption that "everything uses constrainst" but we can't saitisfy that
10:42:12 <tonyb> so between now and next week it's be good to find the low hanging fruit for projects that don't support constratins and either
10:42:57 <tonyb> a) add support or b) if adding support is compex (like oslo.messaging) open a bug tracking bug in the project and requirements so we can see our debt/backlog
10:43:13 <tonyb> can y'all spare a few mintutes to do that?
10:43:37 <number80> ack
10:43:54 <tonyb> In parallel we can do some tox work to paper over the real probelm and/or some pip work to fix it
10:43:56 <coolsvap> yeah https://etherpad.openstack.org/p/requirements-track-constraints-usage
10:44:14 <coolsvap> lets use this to track so we do not end up tracking the same project
10:44:20 <tonyb> but those last 2 things are big efforts
10:44:29 <tonyb> coolsvap: good idea
10:44:50 <number80> sure
10:45:21 <tonyb> I'll do oslo.* tomorrow (starting with messaging)
10:45:51 <tonyb> #action <all> deep dive into projects missing constraints support
10:45:59 <tonyb> #link https://etherpad.openstack.org/p/requirements-track-constraints-usage
10:46:52 <tonyb> #topic Open Discussion
10:47:08 <tonyb> 14mins left ... anything to discuss?
10:47:24 <tonyb> coolsvap, toabctl, number80: recoverd from the travel?
10:47:31 <coolsvap> nothing on my mind as this is my first working day after summit
10:47:43 <tonyb> coolsvap: mine too
10:47:43 <coolsvap> we had the diwali holidays right after I came back
10:48:01 <coolsvap> had lot of fun with friend and family
10:48:13 <coolsvap> still coming out of it
10:48:26 <coolsvap> one of the reasons i missed the ping for meeting ;-)
10:48:32 <number80> well, I had fun with administration to replace my ID and few other cards I lost in Barcelona :)
10:48:35 <tonyb> coolsvap: nice.  I've wanted to see that I've heard it's very spectacular
10:48:43 <tonyb> number80: Oh :(
10:49:01 <coolsvap> number80: oh
10:49:13 <number80> well, nothing important was lost or that can't be replaced :)
10:49:24 <coolsvap> tonyb: yeah it is
10:49:33 <coolsvap> number80: yes I can be sure about your yubikey
10:49:39 <coolsvap> it was safe ;-)
10:49:41 <tonyb> coolsvap: :)
10:49:51 <number80> :)
10:50:21 <tonyb> Well I think we're done
10:50:27 <number80> yep
10:50:31 <coolsvap> yup
10:50:32 <tonyb> #endmeeting