20:02:07 <ttx> #startmeeting tc
20:02:08 <openstack> Meeting started Tue May 31 20:02:07 2016 UTC and is due to finish in 60 minutes.  The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:02:09 * devananda heats up lunch and sits in the back
20:02:09 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:02:12 <openstack> The meeting name has been set to 'tc'
20:02:14 <russellb> notmorgan: hello there!
20:02:14 <mtreinish> o/
20:02:16 <ttx> Hi everyone!
20:02:23 <ttx> almost full house today
20:02:25 * dims is at a soccer field parking lot
20:02:26 * flaper87 bows and says hi
20:02:27 <annegentle> why hello there
20:02:30 <johnthetubaguy> o/
20:02:32 <ttx> Our agenda:
20:02:36 <ttx> #link https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee
20:02:37 <mestery> dims: that sounds fun :)
20:02:42 * edleafe waves from PyCon
20:02:46 <dims> :)
20:02:48 <ttx> NB: We'll skip the golang discussion this week as we made little progress over the past week
20:02:51 * dhellmann waves to edleafe from pycon
20:02:57 <ttx> We should gather enough info to push it forward next week though.
20:03:02 <notmorgan> edleafe: i'll wave from a couple miles away from pycon :)
20:03:07 <ttx> In the mean time let's burn some backlog
20:03:12 <ttx> #topic Add resolution explaining which tests we think defcore should use
20:03:20 <ttx> #link https://review.openstack.org/312718
20:03:26 <ttx> dhellmann: care to present this one ?
20:03:31 <dhellmann> sure
20:03:42 <dhellmann> this is the result of a part of the discussion at the summit
20:03:59 <dhellmann> there was some talk of supporting tests outside of tempest, and in fact tempest and or refstack already do
20:04:13 <dhellmann> but for the purposes of defcore, I think that having a strong central review team is valuable
20:04:44 <dhellmann> and so I am proposing that we "indicate the technical direction" of the project by asking defcore to look only at tests in the tempest repo
20:05:11 <dhellmann> that will mean adding or moving tests from other places, but I didn't want to specify the process for doing that in the resolution itself
20:05:18 <dhellmann> the defcore, qa, and project teams can handle the details
20:05:20 <ttx> ok. It's not completely crazy to require some consistency in tests that are used to assess interoperability
20:05:32 <notmorgan> ttx: ++
20:05:51 <dims> dhellmann : are the respective teams ok to carry out this work?
20:05:53 <ttx> s/require/encourage
20:06:07 <mestery> ttx: I think require is actually fine
20:06:08 <dhellmann> dims : I discussed it with the qa team, and they agreed
20:06:08 <notmorgan> AIUI the QA/tempest team were ok with this
20:06:16 <dims> notmorgan : dhellmann : cool
20:06:24 <flaper87> dhellmann: so, the QA team will do most of this work
20:06:24 <sdague> the qa and refstack folks were in the room, right?
20:06:36 <ttx> and the qa PTL supported the change
20:06:39 <catherineD> sdague: yes I am from the refstack team
20:06:46 <dhellmann> flaper87 : no. as tests are identified for defcore needs, I would expect the project teams to work with the qa team to get them moved
20:06:46 <sdague> flaper87: the qa team does the review work, they don't write every test
20:06:57 <dhellmann> with trademark and interop support as the carrot to do that
20:07:08 <notmorgan> 058698
20:07:10 <flaper87> sdague: yeah, I meant that and some of the moving work, not really writing the tests
20:07:16 * flaper87 should have been more specific
20:07:21 * notmorgan sighs.
20:07:25 <flaper87> dhellmann: ok, thanks for clarifying
20:07:26 <notmorgan> stupid OTP.
20:07:28 * dhellmann waits for notmorgan to touch his yubikey again
20:07:31 <johnthetubaguy> so I totally like the idea of it being in a central place, tempest sounds good if tempest folks like that idea
20:07:33 <rockyg> I have a question:  Defcore may also include "scenario tests" in the future (like my first app)  can we make this a "future" collaboration with QA?
20:07:54 <notmorgan> dhellmann: it'll get me out of sync and i'll need to re-sync the token soon enough.
20:07:55 <sdague> rockyg: yeh, future things are always subject to figuring out the right thing to do in the future
20:08:11 <dhellmann> rockyg : likely. The proposal is that we ask defcore to only use tests from tempest, which will trigger adding more tests there to support them.
20:08:11 <sdague> this seems more like a statement of how to do all the things that are being done now
20:08:13 <hogepodge> as a defcore working group member I am happy to work with the qa team and projects
20:08:41 <notmorgan> hogepodge: good to hear
20:08:56 <flaper87> hogepodge: ++
20:08:59 <ttx> OK, we seem to have agreement
20:09:03 <dhellmann> hogepodge : great! and I want to be clear that although we may rely on defcore to identify tests, I think it's entirely reasonable to leave the work of moving/updating them to project teams
20:09:10 <ttx> 8 votes without counting Doug
20:09:12 <johnthetubaguy> I guess we start marking tests as explicitly interop tests in tempest at some point?
20:09:20 <rockyg> Mom and apple pie
20:09:26 <hogepodge> note that markvoelker and eglute are the chairs of the working group, so speak on an official capacity for it
20:09:33 <dhellmann> johnthetubaguy : yes, that's a good idea
20:09:42 <sdague> johnthetubaguy: maybe, refstack already has a way to track that in their repo
20:09:44 <mtreinish> johnthetubaguy: maybe, how we tag things isn't necessarily that straightforward
20:09:44 <hogepodge> I administer defcore for the foundation
20:09:50 <johnthetubaguy> dhellmann: I loved your point on them needing a different sort of review
20:09:56 <mtreinish> johnthetubaguy: because there is already a list maintained
20:10:13 <sdague> that's why the stable uuid exists to make that external tagging work well
20:10:18 <dhellmann> johnthetubaguy : thanks
20:10:29 <johnthetubaguy> I was thinking a more reverse things
20:10:46 <johnthetubaguy> hang on, thats nonsense
20:10:47 <ttx> dhellmann: do you think that needs a new patchset or should it be approved as-is ?
20:10:50 <annegentle> ttx: do we know who all needs to agree for this resolution to work out?
20:10:59 <johnthetubaguy> I mean make it clear to reviewers the intent of the test is interop
20:10:59 <dims> as a result of this action, is there a project likely to drop from defcore radar/coverage?
20:11:08 <annegentle> wondering as I read some of the comments
20:11:13 <dhellmann> ttx: I can spin a new version if needed. I don't remember any edits that I thought I needed, but let me look again
20:11:22 <johnthetubaguy> I know we track it, but its not infront of your else right now, but I could be missing something
20:11:24 <ttx> annegentle: the way it's phrased it's just a TC resolution, so majority of TC member votes
20:11:28 <dhellmann> annegentle : TC, QA, DefCore?
20:11:40 <flaper87> dhellmann: the only one I remember is the third option but we can add that in a follow-up patch
20:11:50 <mtreinish> dims: not really, the projects currently covered by defcore all have existing tempest tests
20:11:52 <hogepodge> dims: defcore is completely covered in tempest right now, with additional features from heat and swift in external test repos
20:11:57 <dhellmann> flaper87 : at that point in the resolution I was recording history, and that option was not part of the history
20:11:59 <annegentle> dhellmann: ok so do we need Mark and Egle to vote or is it okay as-is?
20:12:04 <dims> mtreinish : hogepodge : cool!
20:12:07 <ttx> but then to "work out" someone will have to carry the work, so QA+Defcore support can't hurt
20:12:08 <flaper87> dhellmann: ah, fair enough
20:12:11 <hogepodge> the additional features are not required or advisory, just under review
20:12:20 <dims> ttx : +1
20:12:22 <dhellmann> annegentle : it's a tc resolution, so we need to vote and then it's our suggestion/request to them
20:12:29 <annegentle> dhellmann: ok check
20:12:30 <dims> hogepodge : ack.
20:12:38 <ttx> dhellmann: ready to approve on your command
20:12:48 <dhellmann> ttx: I'm happy with this draft
20:12:54 <ttx> ok, sold
20:13:08 <devananda> dhellmann: I thought there was an initiative to move a lot of the tempest tests to use tempest-lib -- ie, put them in the project specific repos
20:13:12 <ttx> #topic Add resolution asking defcore committee to avoid using proxy APIs in tests
20:13:18 <ttx> #link https://review.openstack.org/312719
20:13:24 <dhellmann> devananda : that's good for non-interop functional tests
20:13:26 <ttx> dhellmann: you again
20:13:30 * ttx sits back
20:13:41 <dhellmann> devananda : and in the review comments I mention that this resolution may result in some test duplication
20:14:07 <dhellmann> ok, this one is another "please take this as technical direction" request for defcore to avoid using tests that use features of one service proxied through another
20:14:19 <dhellmann> for example, calling nova apis to proxy to glance to test image management features
20:14:31 <dhellmann> they have used those tests because those were the ones that existed, which is understandable
20:14:47 <dhellmann> I think a better outcome is to identify the need for those tests and ask for new ones to be written that do not use the proxies
20:14:57 <dhellmann> and then those are more appropriate for interop testing and trademark
20:15:01 <dhellmann> enforcement
20:15:16 <dhellmann> questions?
20:15:20 <ttx> That sounds sane, actually already has majority votes in support
20:15:25 <rockyg> fyi, DefCore is on top of this, but having the resolution is a hard direction point that makes it easier to score "future direction -not"
20:15:26 <sdague> dhellmann: yep, all very sensible. Also, fyi, Nova is deprecating all those proxies this cycle
20:15:26 <flaper87> I'm sold already
20:15:36 <ttx> I agree with comments who say that we should probably also state at some point that proxy APIs are evil and should diaf
20:15:38 <dhellmann> johnthetubaguy pointed out that this follows nova's -- what sdague said faster
20:15:38 <dims> dhellmann : sounds good to me
20:15:38 <mtreinish> dhellmann: in most cases those tests which go right to the projects already exist (and have for a long time)
20:15:39 <johnthetubaguy> so I think the image api is a bad example here in some ways, but totally agree with us saying not to add the proxy APIs
20:15:40 <thingee> http://docs.openstack.org/developer/nova/project_scope.html#no-more-api-proxies
20:15:45 <annegentle> can someone define proxy as we see it?
20:15:46 <mestery> ttx: ++
20:15:48 * flaper87 thanks all the gods for the proxies deprecations
20:15:50 <dhellmann> mtreinish : ok, cool.
20:15:53 <sdague> https://review.openstack.org/#/c/312209/
20:15:54 <devananda> fwiw, I'm very much in agreement with this
20:15:57 <rockyg> In fact, I think this is a great start for doing this with more phase-out or phase-in stuff
20:16:08 <flaper87> thingee: that was me, I think. Happy t owrite that down
20:16:20 <flaper87> erm
20:16:21 <flaper87> ttx: ^
20:16:22 <annegentle> so is a proxy only one service to another service?
20:16:24 <flaper87> thingee: sorry
20:16:34 <annegentle> what about keystone v2.0 to v3? Is that not a proxy?
20:16:41 <notmorgan> annegentle: that is not a proxy
20:16:43 <annegentle> or is that a redirect?
20:16:46 <sdague> annegentle: no, that's not a proxy
20:16:49 <dhellmann> annegentle : yeah, if I call nova to do something and it really only talks to another service to do the work where I could have called that API myself
20:16:50 <notmorgan> not even a redirect
20:16:57 <dims> annegentle : if we test something in glance by calling Nova's REST API for example
20:16:59 <notmorgan> they are separate paths.
20:17:11 <annegentle> dims: I get that one. I'm not sure about the keystone case.
20:17:13 <notmorgan> and run concurrently today
20:17:14 <sdague> this is things like /images or /volumes in Nova which are really just proxies to another REST service, there for historical reasons
20:17:17 <dhellmann> if you want to test the feature of an openstack project, you should talk directly to it as much as possible
20:17:21 <sdague> because that other service used to be Nova
20:17:21 <annegentle> okay, got it.
20:17:26 <notmorgan> sdague: ++ :)
20:17:26 <sdague> but it isn't any more
20:17:29 <dims> annegentle : ah. listening :)
20:17:30 <rockyg> definition of "proxy api" would be good to have in the resolution
20:17:47 <dhellmann> it's ok to use other projects to "set up" for a test, but better if you don't have to
20:17:55 <annegentle> yeah I'll comment on the review, I already said I approve but just want to be clear
20:18:02 <dhellmann> that way we get good test isolation, and don't have implicit things being wrapped up in interop tests
20:18:09 <dims> annegentle : good one.
20:18:21 <ttx> rockyg: feels clear enough, there is an example in the text
20:18:52 <ttx> dhellmann: ok, looks like there is agreement. Shall I approve current version of the text or do you want to make changes ?
20:18:54 <rockyg> ttx, thanks.  I have problems reading two things at once, especially when one is changing rapidly;-)
20:18:56 <annegentle> actually, reading it again, it's fine. There's a clear statement of "service to service"
20:19:03 <dhellmann> ttx: I'm happy with this draft
20:19:05 <ttx> rockyg: I wonder which :)
20:19:28 <ttx> OK then, approving now
20:19:38 <ttx> #topic Add Juju Charms for OpenStack
20:19:42 <jamespage> o/
20:19:45 <ttx> #link https://review.openstack.org/224797
20:19:51 <ttx> This was originally proposed in Sept 2015.
20:19:54 <ttx> jamespage: o/
20:20:03 <ttx> Back then it was postponed waiting for some activity in the team and clarification of our licensing rules
20:20:16 <ttx> Since then activity has happened, and to me it appears to be following the OpenStack way enough
20:20:25 <ttx> But we also clarified our licensing rules
20:20:28 <dhellmann> what was the outcome of the license discussion?
20:20:30 <ttx> #link http://governance.openstack.org/reference/licensing.html
20:20:43 <ttx> Under those rules it seems difficult to accept charms that would be GPLv3. They should be ASLv2, MIT or BSD (any form)
20:21:21 <mtreinish> ttx: then wouldn't this be blocked until things are relicensed?
20:21:30 <dhellmann> it seems so
20:21:37 <ttx> mtreinish: that is my interpretation of the current rules yes
20:21:43 <thingee> mtreinish: +1
20:21:49 <johnthetubaguy> yeah, +1
20:21:55 <notmorgan> that is what it sounds like to me.
20:22:01 <dhellmann> does that need a vote on the patch, or do you want to just communicate that to them ttx?
20:22:17 <russellb> i figure we don't need to pile on -1s
20:22:21 <dims> ttx : jamespage : what happens to existing forks under GPLv3 (from folks outside of canonical) if they want to be folded back to our repo?
20:22:24 <flaper87> russellb: ++
20:22:28 <dhellmann> russellb : right, that seems excessive
20:22:36 <ttx> Yeah, maybe I can just register a -1 if you agree with my reading
20:22:41 <russellb> ++
20:22:45 <dhellmann> ttx: I certainly agree.
20:22:57 <notmorgan> a single -1 for that seems reasonable
20:22:59 <ttx> and then if the relicensing discussion takes forever we'll temporarily abandon the review until it's settled
20:23:04 <dhellmann> ++
20:23:25 * jamespage crosses fingers it won't take for ever but he has some running around todo for that
20:23:32 <ttx> do you have other objections that we should record ?
20:23:35 <anteaya> ttx when you -1 can you say that you do so as a representative of the group, for archival purposes
20:23:37 <notmorgan> i also want to voice a minor disappointment they're doing independant releases instead of trailing. as long as they're happy with that placement, i'm ok with it
20:24:14 <notmorgan> but minor disappointment is strictly because i don't want concern that it's not "part" of the release.
20:24:16 <dhellmann> jamespage : yeah, if you'd like to talk about release models we can do that next week when I'm back on a non-conference schedule
20:24:16 <dims> i am good with just the relicensing
20:24:30 <jamespage> dhellmann, sure sounds good - we're every 3 months atm
20:24:31 <notmorgan> down the road.
20:24:42 <dims> notmorgan : ++
20:25:00 <dhellmann> jamespage : ok, you may have the right model then, but let's make sure
20:25:13 <dhellmann> sort out the license stuff first, the model is easy enough to deal with
20:25:24 <dims> dhellmann : agree
20:25:31 <ttx> FTR I'm good with the proposal if we can get the licensing fixed. I think those packaging teams have been pretty successful collaboration efforts in the big tent
20:25:37 <dhellmann> ++
20:25:50 <flaper87> ttx: agreed!
20:25:53 <johnthetubaguy> +1
20:25:56 <dims> +1
20:26:19 <ttx> It's like magic that turns a dozen crappy github forks into something usable
20:26:24 <notmorgan> ttx: ++
20:26:42 <russellb> ha... packaging teams?  or you mean the config mgmt teams?
20:26:52 <ttx> OK, if we don't have further questions on this topic I propose we move on
20:27:05 <russellb> not sure the packaging teams have been terribly productive ..
20:27:07 <ttx> russellb: packaging/deployment-recipes thingies
20:27:20 <russellb> k, moving on is fine
20:27:24 <ttx> russellb: traditional packaging, yeah
20:27:40 <ttx> Alright, moving on
20:27:44 <ttx> #topic Add project Vitrage to OpenStack big-tent
20:27:51 <ttx> #link https://review.openstack.org/320296
20:27:57 <ttx> Anyone from Vitrage present ?
20:28:02 <ifat_afek> hi, I'm here
20:28:07 <ttx> Hi Ifat!
20:28:29 * flaper87 just noticed gertty didn't store his comment on the Vitrage review
20:28:32 <alexey_weyl> Hi
20:28:33 <ttx> flaper87: would you mind explain your -1 ?
20:28:35 <dims> flaper87 : what was your -1 for?
20:28:37 <dims> :)
20:28:44 <flaper87> I just commented again
20:28:50 <ttx> blaming gertty will get you NOWHERE
20:28:54 <notmorgan> flaper87: ah now your -1 is more clear
20:28:57 <flaper87> It's a nit. The project uses Engine instead of service
20:29:09 <dims> ah. thx
20:29:11 <flaper87> I wonder if there's an real motivation for that
20:29:16 <ttx> oh, nice nit
20:29:22 <flaper87> otherwise I'd prefer using service
20:29:50 <flaper87> Vitrage is a service (tagged type:service) so, it kinda makes more sense to use service instead
20:29:55 <ifat_afek> flaper87: can you please explain?
20:30:15 <notmyname> flaper87: there isn't an "engine" type defined, is there?
20:30:21 <dhellmann> ifat: we get picky about the wording there, because we want projects to all look the same in the rendered veersion of the documentation
20:30:30 <notmorgan> dhellmann: ++
20:30:33 <annegentle> ifat_afek: it matters for REST API docs too
20:30:37 <ifat_afek> Oh, you mean we should call it RCA service?
20:30:38 <flaper87> ifat_afek: ^
20:30:43 <ttx> ifat_afek: yes
20:30:43 <notmorgan> ifat_afek: yeah
20:30:44 <flaper87> ifat_afek: yeah
20:30:45 <dhellmann> ifat_afek : right
20:30:49 <flaper87> ifat_afek: sorry for not being clear
20:30:51 <flaper87> :)
20:31:00 <ifat_afek> I see you all agree :-) guess it's fine with us
20:31:02 <notmorgan> ifat_afek: unless there is a real reason to call it an "engine"
20:31:09 <ttx> Otherwise Vitrage seems to fit the requirements for me - definitely developed in the OpenStack Way
20:31:16 <flaper87> I panic'd when I noticed my comment was missing
20:31:19 <flaper87> :D
20:31:29 * thingee is already imagining how this will be expressed in the service type auth repo
20:31:31 <ttx> Like I said in the review, the use case seems a bit focused on specialized private clouds where exposing the user to underlying topology is seen as a feature rather than a bug
20:31:44 <flaper87> yup, that's my only comment, otherwise it looks good
20:31:47 <ifat_afek> notmorgan: no real reason, it just sounded good to us. We weren't aware of these terminology issues
20:31:59 <notmorgan> ifat_afek: no worries then, easy fix
20:32:05 <ifat_afek> sure
20:32:06 <edleafe> ttx: anti-cloud?
20:32:21 <notmorgan> edleafe: what happens if anti-cloud and cloud touch?
20:32:29 <mtreinish> notmorgan: warp drive?
20:32:31 <edleafe> notmorgan: you don't want to know
20:32:32 <annegentle> ifat_afek: do you see this as an admin API only? Or is there a way to configure for admins only to view the topology?
20:32:38 <ttx> ifat_afek: could you explain how multitenancy would fix that ? It feels like Vitrage provides clarity in a cloud where by design some people want to hide which switch is connected to which VM
20:32:53 <sdague> ttx: it is a pretty common use case though. self service users make a ton of sense when you have addition trust in your users.
20:33:23 <ifat_afek> ttx: we would like to let admin see everything; and for users of other tenants filter what they see - only their instances, stacks, alarms, etc.
20:33:24 <ttx> sdague: I understand the use case, I'm just wondering about that comment which says multitenancy would fix it
20:33:46 <ttx> ifat_afek: I see, makes sense
20:33:47 <ifat_afek> ttx: we can add a comment
20:34:13 <ttx> ifat_afek: it's not blocking the review, just wanted to make sure I understood
20:34:35 <jroll> sounds like the use case for end users could be something like "alert infra@openstack.org that git01.openstack.org is down because foo"
20:34:38 <ttx> Other questions, objections ?
20:34:40 <amrith> ttx ./
20:34:57 * ttx passes mike to amrith
20:35:00 <amrith> thx ttx
20:35:01 <dhellmann> ttx: should ifat_afek update the wording in this patch, or via a second?
20:35:14 <ttx> dhellmann: yes, if that's the only objection
20:35:14 * dhellmann doesn't need a mic
20:35:21 <amrith> jus a question about the relationship, if any with the telemetry projects.
20:35:27 <fungi> jroll: or notify jroll when we have issues with his employer's cloud and can't get a response on a ticket ;)
20:35:31 <amrith> is this a part of 'telemetry'
20:35:34 <ttx> amrith: it gets alamrs from them
20:35:38 <flaper87> dhellmann: if ifat_afek does it now, I think we can vote quickly
20:35:44 <dhellmann> flaper87 : ++
20:35:46 <ifat_afek> amirth: we are currently working on integration with aodh
20:35:46 <dims> looks like they are using oslo_messaging, aodh/ceilometer etc
20:35:54 <annegentle> ifat_afek: my question on the review is about whether you'll expect operators to protect the API or if a policy is already builtin
20:35:58 <amrith> ttx, would that mean it should be part of telemetry or is it a top level project in its own right.
20:36:06 <amrith> that's my only question
20:36:07 <jroll> fungi: :D
20:36:09 * amrith returns mic to ttx
20:36:12 <ttx> amrith: different team, different project team
20:36:16 <ifat_afek> we already have an aodh datasource, and we are designing a notifier of vitrage alarms to aodh, in coordination with aodh guys
20:36:23 <ttx> amrith: we don't do "programs" anymore
20:36:35 <ttx> so there is no reserved territory for telemetry
20:36:41 <amrith> ah, thanks ttx
20:36:50 <ttx> here it's a complement service that doesn't duplicate feature
20:37:01 <ttx> and actually integrates with telemetry services
20:37:16 <dims> ttx : ++
20:37:18 <dhellmann> we have more and more projects now consuming the output of existing projects and building on their features
20:37:25 <ifat_afek> annegentle: I'm no sure I understand the question, can you please explain?
20:37:32 <flaper87> ifat_afek: are you amending the review now? Or planning to do it later?
20:37:36 <ttx> ifat_afek: could you quickly fix the wording to say "service" ? I think we could approve it just after you post it
20:37:39 * flaper87 hands ifat_afek a marker
20:37:48 <ttx> We can review Watcher in the mean time
20:37:50 <ifat_afek> ttx: sure, doing it now
20:37:55 <ttx> ifat_afek: thanks!
20:38:00 <ttx> #topic Add project Watcher to OpenStack big-tent
20:38:02 <acabot_> o/
20:38:05 <ttx> #link https://review.openstack.org/320941
20:38:07 <ttx> acabot_: o/
20:38:08 <annegentle> ifat_afek: Wanted to also ask the same as ttx
20:38:10 <sballe_> o/
20:38:23 <ttx> This one sounds mostly straightforward to me. Developed in the OpenStack Way, good diversity already for a non-official project
20:38:26 <annegentle> ifat_afek: do you expect this to be an admin api and if so, what's the mechanism
20:38:27 * mestery waves at sballe_ :)
20:38:35 <flaper87> ttx: acabot_ looks like there's a small thing to fix.
20:38:42 <ttx> flaper87: yes
20:38:43 <flaper87> I held off my vote waiting on that fix, fwiw
20:38:50 <flaper87> otherwise, lgtm
20:38:55 <mestery> flaper87: ++
20:38:56 <ttx> Proactive resource optimization sounds like a useful thing to have in most use cases, be it public or private cloud, and at any size -- so that fits the mission well
20:39:02 <notmorgan> flaper87: ++
20:39:39 <ttx> If we remove the diverse-affiliation claim which is incorrect (as of now), I'm fine approving it
20:39:48 <johnthetubaguy> lots of operators seemed interested in the project at the ops meetup in manchester, not that thats really relevant to the approval, just interesting
20:39:51 <ttx> questions ?
20:40:03 <notmorgan> ttx: wfm
20:40:12 <flaper87> acabot_: any chance you can address ttx's comment now? that way we can approve it now
20:40:13 <annegentle> good to know johnthetubaguy
20:40:14 <dhellmann> sorry for not reading up in advance, but what sort of optimizations are we talking about here?
20:40:17 <ttx> johnthetubaguy: yes it seems to strike a chord. Or whatever is appropriate to strike in a tuba
20:40:27 * ttx is a piano guy
20:40:30 <acabot_> flaper87 : yes
20:40:39 <johnthetubaguy> ttx: you can do that actually, multi-phonics, but anyways, yeah, it did just that
20:40:54 <edleafe> dhellmann: dynamic relocation of resources based on pre-defined criteria
20:41:07 <johnthetubaguy> dhellmann: shuffle the deck so you can fit more VMs in, or some other handy things
20:41:10 <ttx> dhellmann: resource placement. Think: consolidate VMs on machines and turn off others to reduce energy consumption
20:41:22 <ttx> or spread out heat
20:41:22 <thingee> so heat mentions of doing auto scaling ... this wants to optimize resources
20:41:28 <dims> ttx : i am wondering what kind of things they would need in say Nova or Neutron to make the optimizations possible. guess i have to go read up on what they are doing :)
20:41:29 <edleafe> dhellmann: or spread them ouot to reduce noisy neighbors
20:41:35 <dhellmann> very neat. how does that fit with congress' role?
20:41:40 <johnthetubaguy> basically, it calls Nova's live-migrate, as I understand it
20:41:45 <johnthetubaguy> post creating of instances
20:41:56 <sdague> dims: there have been some specs
20:42:05 <edleafe> Congress could be a source for the strategies
20:42:07 <dims> sdague : ah cool
20:42:08 * ttx has been doing his homework and can explain projects today
20:42:16 <dims> yay ttx :)
20:42:27 <ttx> but really I should let acabot answer
20:42:29 * flaper87 copied ttx's homework
20:42:29 <thingee> so heat autoscale would be to add more instances and watcher is to move things around?
20:42:30 * edleafe hands ttx a sticker
20:42:33 <sdague> there were some concerns about how we were adapting our os-migrations API
20:42:40 <johnthetubaguy> dims: actually edleafe's spec is one, about passing in a list of candidate hosts into live-migrate
20:42:59 <sdague> thingee: yeh, this does not assume your stuff is 12 factor stateless apps
20:43:03 <edleafe> dims: yeah, what johnthetubaguy said
20:43:06 <sdague> it assumes the apps you launched is what you want
20:43:15 <gordc> amrith: just fyi, we have a list of services that extend existing services under telemetry umbrella: https://wiki.openstack.org/wiki/Telemetry#Externally_Managed
20:43:16 <dims> edleafe : ack
20:43:33 <sdague> and then tries to rejigger their placement to optimize for various things as time goes on
20:43:59 <dhellmann> sdague : so watcher may know more about the cloud implementation than heat would take advantage of?
20:44:03 <sdague> "cloud defrag"
20:44:08 <flaper87> acabot_: another small nit, sorry for not catching it earlier
20:44:10 <edleafe> sdague: +1
20:44:11 <dhellmann> but less about the application?
20:44:19 <dims> acabot_ : one thing about heat was excessive polling of Nova API (as there's no other way to know what's going on)...wondering what kinds of hooks you need more than what exists today
20:44:20 * amrith responds to gordc privately to reduce cross-talk
20:44:23 <sdague> dhellmann: it knows about the application from a black box perspective
20:44:29 <johnthetubaguy> heat starts VMs, watcher moves them later on
20:44:30 <dhellmann> ok, makes sense
20:44:52 <edleafe> dhellmann: yes. Heat is for tenants to optimize their apps, while Watcher is for ops to optimize their deployment
20:44:53 <annegentle> sdague: I want a visual tool for that cloud defrag
20:45:02 <johnthetubaguy> moves them after all your friends got deleted as they were less pet-ey than you
20:45:04 <dhellmann> edleafe : that's very clear, thanks
20:45:09 <russellb> this is a very traditional data center virt type feature, but i'm supportive of it
20:45:20 <dhellmann> annegentle : little colored squares in your terminal? :-)
20:45:21 <sdague> so, hey, people shut stuff down, I've got idle capacity on 4 racks, maybe I could get to 3 racks and power down rack 4 entirely to save cooling/power
20:45:24 <dims> "pet-ey" :) nice johnthetubaguy
20:45:28 <annegentle> dhellmann: zactly
20:45:33 <acabot_> flaper87 : done ;-)
20:45:41 <sdague> it's still early, but it's definitely an interesting space to be tackling
20:45:45 <johnthetubaguy> dims: heh, thats better than I intended
20:45:49 <thingee> sdague: ok I think I got it. it's just confusing with things like auto scaling.
20:45:55 <ttx> I like to think of it as more generally the background process that will apply some long-term optimization policy as you have churn on your resources
20:46:02 <jroll> another example use case besides power saving: shuffle things around to get a bunch of empty hypervisors, update kernels on the empties, move things back around to get other empties
20:46:22 <sdague> jroll: right, from the "oh noes hypervisor exploit!"
20:46:23 <sdague> pov
20:46:25 <dims> jroll : sold!
20:46:29 <johnthetubaguy> yeah, the updates is what makes defrag critical
20:46:39 <edleafe> jroll: good point
20:46:40 <jroll> sdague: or even basic cleanliness :)
20:46:40 <russellb> "policy based live migration" is what it's called in some other things ...
20:46:43 <ttx> Looks like we have a winner: https://review.openstack.org/#/c/320941/3
20:47:08 <sdague> jroll: yup
20:47:09 <flaper87> acabot_: thanks
20:47:21 <acabot_> thanks !
20:47:28 <sballe_> thanks!
20:47:32 <ttx> please vote there
20:47:39 <ttx> and also at https://review.openstack.org/#/c/320296
20:47:42 <acabot_> and sorry for not being reactive enough on all your comments !
20:47:52 <flaper87> ifat_afek: one more nit, sorry :(
20:47:53 <dims> acabot_ : no worries.
20:47:56 <ttx> acabot_: you were reactive alright. Thanks for staying up
20:48:35 <edleafe> flaper87: eagle-eye!
20:48:44 <ttx> hmm https://review.openstack.org/#/c/320296 needs another turn
20:48:47 <dhellmann> flaper87 : we could fix that in a follow-up to keep this moving. ttx can approve typo-fixes
20:48:54 <ttx> yeah
20:49:00 <dims> dhellmann : ttx : +1
20:49:12 <flaper87> dhellmann: good for me, just thought this one could be super quick
20:49:15 <flaper87> :D
20:49:17 <ifat_afek> flaper87: sure, will fix in a minute.
20:49:29 <dhellmann> flaper87 : sure, either way, just wanted ifat_afek to get the vote today :-)
20:49:40 <flaper87> ifat_afek: you can do it in a follow-up
20:49:42 <ttx> ok, let's give Ifat a couple more minutes
20:49:47 <dims> acabot_ : ifat_afek : thanks!
20:49:47 <ifat_afek> ifat
20:49:49 * flaper87 stfu
20:49:54 <flaper87> we're confusing ifat_afek
20:49:56 <flaper87> hahahah
20:49:57 <ttx> I'm approving Watcher now, please vote if you want to be counted
20:50:42 <annegentle> ttx: voted
20:51:16 <ttx> Alright done
20:51:22 <ttx> #topic Open discussion
20:51:24 <acabot_> thanks ttx
20:51:40 <sballe_> +1
20:52:08 <ttx> We have a number of stale changes that it might be good to quickly review
20:52:16 <ttx> unless someone has another topic
20:52:19 <jwcroppe> thx
20:52:37 <annegentle> I didn't get to my projects.yaml patch with the three-day weekend
20:52:49 <ttx> https://review.openstack.org/#/c/293140/ was proposed by lifeless and was supposed to get another revision. If someone is interested you can pick it up
20:53:21 <flaper87> We haven't posted anything lately (comm wg) and I think we've accumulated some interesting topics for a blog post
20:53:41 <flaper87> annegentle: I can help drafting it
20:53:47 <annegentle> flaper87: oh yeah, good point
20:53:49 <ttx> There is also the series of changes for type:packaging and type:deployment tags (proposed by sdake) but I think those were made mostly redundant by our new cycle-trailing release model
20:53:54 <dims> ttx : i'll volunteer to touch up that review from lifeless
20:53:58 <ttx> dims: thx
20:54:12 <dhellmann> annegentle, flaper87 : a summary of the golang discussion in particular, even though that's ongoing
20:54:14 <ifat_afek> pushed another fix, waiting for git review :-)
20:54:18 <ttx> If those don't get a refresh soon I'll probably abandon them to avoid clogging the view
20:54:29 <notmorgan> ttx: just a drop the names?
20:54:38 <notmorgan> ttx: who should be included for the review, the TC?
20:54:47 <annegentle> flaper87: we've done a summit wrapup in the past (though is that old news by now?)
20:54:48 <notmorgan> ttx: for the AGPL change
20:55:03 <annegentle> dhellmann: agreed, though that's difficult :)
20:55:05 <flaper87> dhellmann: yeah, I think that one will take a couple of blog posts for sure. I guess we should start with a summary as you suggested
20:55:14 <flaper87> annegentle: mmh, I'd say it's
20:55:16 * notmorgan will fix that line quickly if we have direction on who should be included
20:55:22 <ttx> notmorgan: not sure what you're talking about
20:55:39 <notmorgan> ttx: Good people to seek initial
20:55:42 <notmorgan> opinions on such cases include Monty Taylor, Jim Blair and Robert Collins
20:55:42 <annegentle> flaper87: a summary is straightforward
20:55:43 <notmorgan> ttx: just drop that line?
20:56:00 <dhellmann> ttx: I'll pick up those type tag reviews in the next couple of weeks if sdake_ doesn't
20:56:05 <ttx> notmorgan: somethign like that. dims said he would pick it up though
20:56:10 <ttx> dhellmann: ok
20:56:11 <notmorgan> ah ok
20:56:17 <dims> notmorgan : ttx : yep
20:56:19 * notmorgan didn't see dims responding
20:56:30 <johnthetubaguy> so I just did an inline edit, does that look better?
20:56:39 <flaper87> I ran the validate tags script yday and there are some "team" tags updates to do. I'll submit a patch in the next couple of days
20:56:40 <notmorgan> johnthetubaguy: that was what i was going to do
20:56:43 <notmorgan> ;)
20:56:48 <flaper87> do we have that automated ?
20:56:55 <ttx> Hmm, feels like we have enough votes on the Vitrage review with an S
20:57:12 <ttx> hm
20:57:30 <ttx> ah, merge conflict now
20:57:36 <ttx> bad voodoo on this one
20:57:38 <flaper87> :(
20:58:02 <ttx> ifat_afek: is your git review going through ?
20:58:10 <ttx> And I thought my network was slow...
20:58:12 <dhellmann> ttx: we've previously delegated rebasing approved patches like that and said you can approve once the rebase passes the tests
20:58:23 <ifat_afek> ttx: got messed up with some other updates, working on that
20:58:32 <ttx> dhellmann: yeah, but looks better with proper recorded approvals
20:58:34 <dims> johnthetubaguy : we should provide something like "drop a note to legal-discuss" or something like that at least
20:58:37 <dhellmann> ttx: ok
20:58:48 <johnthetubaguy> dims: we could
20:59:15 <annegentle> ok
20:59:20 <ttx> flaper87, annegentle: so are you up for a blog post ? Feels like the project additions and the various other things we passed since the beginning is enough material
20:59:28 <flaper87> ttx: yes
20:59:32 <annegentle> ttx: ayup
20:59:46 <dims> 1 min left
20:59:58 <flaper87> annegentle: that's how one sneezes in spanish... almost
21:00:02 <flaper87> annegentle: s/y/ch/
21:00:05 * amrith wonders if others have ticketed for the training in just over a month.
21:00:07 <annegentle> hee
21:00:12 <flaper87> random comment for the last minute open discussion
21:00:17 <dhellmann> amrith : yes, I'm all booked
21:00:21 <ttx> all booked
21:00:24 <amrith> dhellmann, sheraton?
21:00:27 <amrith> ttx sheraton?
21:00:33 <dims> have fun you all !
21:00:34 <dhellmann> amrith : one of the b&b options
21:00:34 * notmorgan needs to book travel.
21:00:35 <flaper87> amrith: all booked
21:00:35 <ttx> At a B&B
21:00:39 * jroll is local and commuting, no booking needed \o/
21:00:46 <ttx> jroll: nice
21:00:47 <notmorgan> jroll: oh nice.
21:00:49 <amrith> ok, thanks folks.
21:00:49 <ttx> ok, time is up
21:00:51 * flaper87 is at the same b&b as ttx
21:00:59 <jroll> amrith: I have a couch!
21:01:00 <ttx> we own the HOUSE
21:01:00 <annegentle> oh nice jroll
21:01:01 <dhellmann> thanks everyone, good meeting
21:01:08 <flaper87> jroll: lucky
21:01:11 <flaper87> ++
21:01:16 <ttx> #endmeeting