20:02:50 <ttx> #startmeeting tc
20:02:51 <openstack> Meeting started Tue Aug  5 20:02:50 2014 UTC and is due to finish in 60 minutes.  The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:02:52 <jaypipes> o/
20:02:52 <russellb> o/
20:02:53 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:02:56 <openstack> The meeting name has been set to 'tc'
20:03:00 <ttx> Our agenda for today is at:
20:03:08 <ttx> #link https://wiki.openstack.org/wiki/Governance/TechnicalCommittee
20:03:14 <ttx> #topic Rally incubation request
20:03:25 <boris-42> #link https://docs.google.com/a/pavlovic.ru/document/d/137zbrz0KJd6uZwoZEu4BkdKiR_Diobantu0GduS7HnA/edit# summary of mailing list
20:03:37 <ttx> So this is split into two governance changes, one asking for a new program:
20:03:42 <ttx> #link https://review.openstack.org/108502
20:03:48 <ttx> The other asking to add Rally for incubation into the integrated release:
20:03:54 <ttx> #link https://review.openstack.org/110638
20:04:02 <ttx> On the first part there is tension on the need for a separate program
20:04:23 <ttx> That tension imho revolves around the two aspects of Rally: performance testing on one side (which is seen as a QA thing), and operators-facing performance ("SLA") monitoring-as-a-service (which is seen as one of several operators tools)
20:04:43 <ttx> Personally I see value in more direct integration/collaboration between performance testing and QA, and being under the same program would help
20:04:53 <ttx> But then a program around operators tooling is not such a bad idea either
20:05:08 <ttx> So I'm torn on that first review. I'm much more circumspect on Rally incubating to become part of the integrated release, though
20:05:11 <mordred> ttx: I agree with those sentences
20:05:19 <ttx> To me it sounds like a tool that could happily sit on top of "OpenStack"
20:05:22 <devananda> o/
20:05:24 <zehicle_at_dell> o/
20:05:29 <russellb> ttx: agreed
20:05:31 <jeblair> we've certainly discussed performance testing (especially how hard it is to do right) in the qa context before
20:05:32 <ttx> rather than "in"
20:05:36 <dhellmann> there were some comments about rally (re)producing some things that should be in tempest, did we get more detail about what those are?
20:06:01 <boris-42> devananda so there is tempest.conf generation
20:06:03 <sdague> dhellmann: rally has a bunch of statistics collection and reporting pieces around the tempest subunit output
20:06:04 <boris-42> dhellmann&
20:06:05 <devananda> sorry for being a bit late. still recovering from last week.
20:06:32 <ttx> so in summary: I think Rally fills an important role, performance testing is definitely a good idea, so it should fall into some official program, in QA or separate
20:06:44 <sdague> that's my current main objection of function in the wrong place, as I think that should be part of what any tempest user gets at the end of the run
20:07:04 <boris-42> sdague yep but in case of making rally launcher for tempest
20:07:13 <boris-42> sdague we can simplify a lot infra patches
20:07:15 <dhellmann> that does feel like it should live closer to tempest in terms of code management
20:07:17 <boris-42> sdague and end users life
20:07:22 <devananda> sdague: aiui, rally also instruments many things, even in the absense of tempest
20:07:32 <ttx> and then I'm not sure it *needs* to be in the integrated release, it can very well live in peripheral tooling
20:07:40 <boris-42> devananda that is true, but we don't want to make a duplication with tempest
20:07:46 <mordred> in fact, given experience with no-branch tempest ...
20:07:47 <dhellmann> devananda: yes, that's the osprofiler part
20:07:49 <annegent_> if it's SLA management, is it important to track release? SLA for icehouse for example? And does Rally track now with a cloud in production that's on the tip?
20:07:50 <boris-42> devananda e.g. for running functional testing we would like to use tempeest
20:07:51 <russellb> totally agree perf testing / profiling / benchmarking is important and useful ... but feel it needs to be tightly coupled into the QA group to be successful
20:07:52 <mordred> we may not WANT it in the integrated release
20:08:01 <annegent_> mordred: that's my thinking as well
20:08:02 <mordred> because honestly rally probably wants to be able to run against any release of openstack
20:08:05 <sdague> devananda: entirely possible, the point being rally is highly monolythic today
20:08:07 <devananda> dhellmann: right. the osprofiler bit, as proposed to oslo, seems to fill an important role
20:08:08 <annegent_> mordred: right
20:08:10 <mordred> which is out-of-band of releases
20:08:21 <boris-42> mordred yep
20:08:28 <dhellmann> devananda: well, if there's going to be a new program managing this stuff, it doesn't need to go into oslo
20:08:33 <sdague> which makes it actually really hard to sort out what should and should not be different places, because the architecture doesn't currently support that
20:08:57 <mordred> I think jaypipes made a good point wrt scalr and that on the mailing list
20:09:12 <boris-42> mordred but seems like it was a bit another story?
20:09:27 <mordred> I'm very torn, because I think rally has some great stuff and I support its goals and I think it does things taht are useful to operators
20:09:29 <boris-42> mordred it was developed by one company and so on
20:09:47 <boris-42> mordred yep so the idea is to provide official OpenStack API for that
20:09:50 <mordred> but also there are clearly parts and places wehre it wants to collaborate more directly with existing things and that keeps being a struggle
20:09:57 <boris-42> mordred that will bring tempest to operation level as well
20:10:12 <boris-42> mordred what about doc that I proposed?
20:10:21 <dhellmann> #link http://stackalytics.com/?release=all&project_type=stackforge&module=rally
20:10:35 <mordred> honestly - as a user of a cloud ... I'm not sure I want an API for this - as much as a tool I can point to clouds
20:10:38 <sdague> mordred I agree there is a lot of good stuff in rally, but I think it crosses a lot of existing boundaries, and it would be better to get of the parts into the various "upstreams"
20:10:56 <mordred> it might be nice for us to be able to easily run rally against hp and rax public cloud in infra to get a sense of how they are doing for workload scheduling purposes
20:10:59 <boris-42> dhellmann #link http://stackalytics.com/?release=juno&project_type=stackforge&module=rally&metric=commits in juno it's better
20:11:19 <boris-42> dhellmann community is rising and influence of mirantis is less and less and it is nice
20:11:19 <devananda> dhellmann: hmm, that piechart has one main ingredient...
20:11:40 <boris-42> devananda yep cause rally was started by me
20:11:45 <boris-42> devananda and I am in Mirantis lol=)
20:11:46 <mikal> So the board also has their tempest sub set thing
20:11:50 <dhellmann> sdague: it would be useful to have a more specific list of those things and where they might go as part of an approval process
20:11:55 <mikal> Do we think that should somehow become part of rally?
20:11:56 <annegent_> mikal: yeah tcup?
20:12:07 <mikal> annegent_: yeah, that
20:12:09 <russellb> mikal: no :)
20:12:12 <annegent_> and do users expect to be able to point a tool at a cloud? and is rally that?
20:12:24 <boris-42> mordred ?
20:12:26 <dhellmann> rally is for performance testing, not compliance testing
20:12:33 <boris-42> mordred could you elaborate we already have performance jobs..
20:12:49 <mordred> boris-42: what I'm saying is, to _me_ it's useful to be able to download rally and run it at endpoints
20:12:50 <devananda> boris-42: ok, http://stackalytics.com/?release=juno&project_type=stackforge&module=rally&metric=commits looks somewhat bettr
20:12:52 <ttx> annegent_: I don't expect rally to be run by end users, it's more geared towards cloud operators
20:12:52 <mikal> annegent_: they're certainly intending tcup to just be a thing you point at an existing cloud
20:12:57 <mordred> it's not useful for rally to be an endpoint a cloud exposes to me
20:12:57 <annegent_> dhellmann: ok, that makes sense, but performance does not equal "meets sla"
20:13:00 <sdague> dhellmann: honestly, beyond the statistics collection, no. Honestly, I've not dug in further because rally was always off in a corner doing their own thing
20:13:03 <boris-42> mordred ah*
20:13:07 <dhellmann> annegent_: agreed
20:13:22 <boris-42> mordred so the idea is to organize some kind of periodic tasks & benchmarks on demands
20:13:33 <boris-42> mordred so you don't need to install and setup anything
20:13:34 <dhellmann> sdague: sure, I didn't mean right now, I just meant if the outcome of the discussion is "well, break it up" then we need to work with boris-42 on how
20:13:34 <sdague> dhellmann: honestly, I don't think a tool is for "performance testing" or "compliance testing". I think tools run loads, and produce results.
20:13:35 <boris-42> mordred just run it
20:13:42 <zehicle_at_dell> we've had similar discussions around refstack and these use caes
20:13:46 <dhellmann> sdague: pedant
20:14:00 <dhellmann> :-)
20:14:08 <sdague> dhellmann: maybe, but I think people are getting too wrapped up with intent, vs. function
20:14:12 <boris-42> dhellmann heh I am not sure how to split rally on parts
20:14:19 <devananda> boris-42: is the REST API you've proposed end-user facing, or only operator-facing?
20:14:20 <boris-42> dhellmann the major reasons is that we have resources*
20:14:20 <mordred> boris-42: yes. I understand. I'm giving you feedback as a large cloud enduser that I do not think that API endpoint is something I would ever use
20:14:21 <ttx> At this stage, the reason we want Rally as an official OpenStack project is so that we can rely on it to do QA. Not really to serve a benchmark-as-a-service use case imho
20:14:28 <boris-42> dhellmann admin-facing (in horizon)
20:14:31 <mordred> boris-42: but I'm very interested in the ability to run such workloads against endpoints I ahve
20:14:32 <boris-42> devananda ^
20:14:42 <boris-42> mordred you will be able
20:14:46 <boris-42> mordred we are going to support 2 modes
20:14:50 <dhellmann> sdague: I'm not sure I understand the distinction you're making
20:14:53 <jeblair> ttx: which very deftly illustrates the point: rally's performance testing should be in the qa program
20:14:56 <boris-42> mordred rally as a service and just rally as a cli tool
20:15:04 <boris-42> mordred cli tool for hackers like me=)
20:15:14 <russellb> so rally used to seem dev focused ... the results you give devs to improve their code, and the info you give cloud admins are different things
20:15:18 <russellb> rally wants to do both?
20:15:19 <mordred> oh - admin facing service
20:15:25 <mordred> gotcha
20:15:26 <boris-42> russellb not only
20:15:30 <mordred> not an end-user facing service
20:15:39 <boris-42> russellb we can track for example such things like how much some request work in specific service
20:15:44 <mordred> "how is my cloud doing" - not "how is this cloud over here doing"
20:15:44 <russellb> i'm also sad that i've never seen any nova results :)
20:15:49 <boris-42> russellb and then operators can manage such sitatuions
20:16:00 <boris-42> russellb e.g. keystone started working slow we need to do something
20:16:00 <russellb> boris-42: sounds like a general monitoring thing
20:16:01 <ttx> jeblair: doesn't mean it can't move to a more "operators tools" program some day
20:16:04 <russellb> that we shouldn't be reinventing
20:16:27 <ttx> ok... so:
20:16:28 <dhellmann> boris-42: do the tests rally uses require admin rights on the cloud?
20:16:37 <boris-42> dhellmann at this moment yes
20:16:47 <boris-42> dhellmann but it's high priority task already for couple of months
20:16:52 <ttx> I think we want Rally to be an official openstack project living in an official openstack program
20:16:53 <boris-42> dhellmann and we are quite close to remove it
20:17:06 <devananda> boris-42: so your goal is for rally-cli to be useful for an  end-user to point at a public cloud?
20:17:07 <boris-42> dhellmann as well adding support of LDAP
20:17:11 <sdague> ttx: I'm not convinced that's true in the current state honestly
20:17:15 <boris-42> dhellmann so you can specify pre created users
20:17:30 <ttx> it should prove itself necessary, and growing in the QA program is probably the best way to achieve that
20:17:30 <sdague> there needs to be some disagregation first
20:17:36 <boris-42> dhellmann yep for developers espcially
20:17:39 <boris-42> devananda ^
20:17:42 <jeblair> ttx: i think we want at least the functionality in an official project
20:17:43 <markmcclain> ttx: +1
20:17:45 <boris-42> devananda that don't want to deploy
20:17:48 <russellb> i think it'd be nice to see an evaluation from the QA program
20:17:52 <sdague> jeblair: agreed
20:17:57 <russellb> and how they think it (or parts) could fit in
20:18:08 <dhellmann> russellb: +1, that's what I was trying to get at before
20:18:10 <jeblair> mtreinish: ^
20:18:26 <sdague> jeblair: mtreinish is still traveling back from au IIRC
20:18:30 <boris-42> dhellmann russellb  does that document makes sense?)
20:18:42 <ttx> basically, we need rally to fill first and foremost the QA needs. It migth need to be tweaked to achieve that
20:18:43 <russellb> boris-42: it's very opinionated :)
20:18:52 <russellb> ttx: +1
20:18:52 <ttx> THEN if it can also be resued by operators, all the better
20:18:59 <ttx> rused*
20:19:02 <boris-42> ttx what do you mean by QA needs?
20:19:06 <ttx> reused*
20:19:25 <boris-42> ttx ahh so using rally for QA at first step?
20:19:40 <ttx> boris-42: from what I hear here, there are some concerns on how to best fit and avoid duplication of functionality etc
20:19:52 <devananda> ttx: ++ to that. I'm not yet convinced it should be part of the integrated release, but there's clearly a QA (and eventually operational) need to be filled
20:19:54 <boris-42> ttx so what we do in rally is reuse tempest =)
20:19:58 <ttx> solving that, I thinnk, increases the chances of ultimate success for rally
20:20:26 <boris-42> ttx sure but what about  current POC that we made?
20:20:29 <ttx> It will help evolve it from a monolithic product to something that is really part of openstack
20:20:32 <boris-42> sdague ^
20:20:33 <annegent_> I'd like to have us think about where an operator / cloud admin toolset lives, does it have to be a program? Does it have to be integrated releases?
20:20:42 <mordred> annegent_: ++
20:20:50 <sdague> annegent_: agreed
20:20:57 <boris-42> annegent_ as far as I understand if it present OpenSatck API
20:20:57 <annegent_> and boris-42 your user base will be a huge part of that
20:20:59 <boris-42> annegent_ it should be
20:21:10 <ttx> I'm not closing the door on an operator tooling program... just sayign it's probably not the right timing for it
20:21:20 <boris-42> ttx I agree with this
20:21:26 <boris-42> ttx we should present this API
20:21:28 <mordred> boris-42: we're saying we're not sold on it presenting an API - and we'd like to take things one step at a time
20:21:31 <boris-42> ttx before doing such request=)
20:21:33 <ttx> boris-42: it doesn't have to be in the integrated release to have an API
20:21:34 <jaypipes> annegent_: ++
20:21:52 <boris-42> mordred sure baby steps=)
20:22:07 <boris-42> mordred ttx  what I am worried that if we will be in QA program
20:22:07 <sdague> boris-42: that presuposes a very specific way that people want to consume this, instead of, for instance script to fit tempest runs + results into nagios or jmeter or something else that is already on site and used by operators
20:22:12 <annegent_> boris-42: I'm a bit more conservative in the shared resources, esp. API docs :)
20:22:16 <boris-42> mordred ttx  we won't be able to extend scope
20:22:25 <mordred> boris-42: I believe we're also saying that an important first step is figuring out the code duplication relationship with tempest and the monolithic architeceture concerns
20:22:26 <boris-42> annegent_ we care about docs=)
20:22:33 <boris-42> annegent_ so there will be docs=)
20:22:46 <ttx> boris-42: I think the TC is worried that if it's on its own program it will never reduce scope.
20:22:57 <boris-42> mordred so in current POC there is no duplication, if tempest won't start doing performance tests
20:23:00 <russellb> it actually feels like it's trying to do too much
20:23:07 <russellb> without having fully accomplished step 1
20:23:13 <sdague> and never really fit well into an integrated environment
20:23:18 <boris-42> mordred e.g. functional tests are in tempest, and rally can use them or own performance scenarios for testing
20:23:20 <sdague> russellb: agreed
20:23:23 * jaypipes thinks that a more effective (for the OpenStack community as a whole and Rally contrib community specifically) plan is to 1) propose OSProfiler for inclusion in the QA program (immediately), b) Propose to governance repo a new program called Operator Tools, with Rally and maybe a couple other projects like StackTach living in the openstack/ namespace, but not incubated or integrated or anything, and c) havi
20:23:56 <jaypipes> (i.e. forget about incubation/integration etc
20:24:05 <boris-42> jaypipes +1
20:24:18 <boris-42> jaypipes unties we present API =)
20:24:19 <jaypipes> and just do the needful and get these worthwhile projects into an operator program that has code in openstack namespace.
20:24:20 <jeblair> jaypipes: your (c) was cut off
20:24:20 <ttx> jaypipes: looks like the TC is converging towards making Rally a part of the QA program, and decline incubation at this point
20:24:21 <boris-42> unitl*
20:24:31 <sdague> honestly, I still want the parts of rally that make more sense back in tempest, like the results pieces separated out first
20:24:39 <mordred> sdague: ++
20:24:41 <ttx> which is not exactly matching your (b) above
20:24:47 <jaypipes> sdague: I don't disagree with that at all.
20:24:54 <boris-42> mordred sdague  why not using rally in gates and everywehre?
20:25:05 <boris-42> mordred sdague  for tempest tests, performance tests and other stuff
20:25:11 <mordred> boris-42: because we're asking you to take the code that should be in tempest and put it there
20:25:22 <jaypipes> sdague: but there's a chunk of stuff in rally roadmap that simply doesn't belong in QA, and I think we need a place to put that code that isn't stackforge, frankly.
20:25:25 <sdague> boris-42: right, because those parts should be back in *tempest*
20:25:25 <boris-42> mordred we are working on that
20:25:30 <sdague> jaypipes: agreed
20:25:33 <boris-42> sdague agree
20:25:34 <jeblair> mordred: ++
20:25:48 <boris-42> sdague mordred actually Rally should just call tempest and store results
20:25:49 <sdague> boris-42: the parts that would run in the gate, should all be back in tempest.
20:25:54 <boris-42> sdague mordred  and do some aggreagtion
20:26:06 <sdague> boris-42: right, and what I'm saying is that whole flow should actually be tempest :P
20:26:14 <boris-42> sdague nope
20:26:20 <ttx> jaypipes: isn't being included in the QA program as a first step a way to ensure the QA program will be able to live with Rally, though
20:26:20 <jaypipes> jeblair: sorry! my c) was: c) having the Rally and QA folks work out the differences and do the needful in terms of libifications <-- in other words, what boris and sean are currntyly talking about ;)
20:26:21 <boris-42> sdague disagree with this
20:26:27 <sdague> and the fact that the rally team ran off in a corner instead of contributing to tempest is a big problem
20:26:30 <boris-42> sdague there is difference between tempest & rally
20:26:47 <boris-42> sdague they arch is build for different people
20:26:48 <ttx> I think there is no point in an operators program growing a Rally that the QA team doesn't like
20:26:50 <russellb> i think it's a problem that it took until now to figure this out
20:27:04 <sdague> russellb: it didn't take this long
20:27:08 <boris-42> sdague rally is something that should work out of box with own DB and so on
20:27:18 <sdague> I've been providing this feedback to the rally team for the last 6 months
20:27:24 <sdague> and just threw up my hands
20:27:26 <boris-42> sdague tempest is bunch of scripts for creating exactly what you need in your CI
20:27:32 <dhellmann> boris-42: so rally supports having test scenarios that are not part of tempest?
20:27:37 <russellb> sdague: good to hear ... i guess i mean it's unfortunate that a proposal is made when there's clearly still such a big gap
20:27:38 <jaypipes> ttx: well, I think *parts* of Rally do belong in the QA program, along with OSProfiler... but I don't think Rally should just ask to go into the QA program now, then in some short time once pieces are pulled out of it, then propose to start up a new Operator Tools program
20:27:39 <boris-42> dhellmann yep
20:27:42 <devananda> boris-42: the scope diagram in rally's repo includes  "deploy openstack cloud", "run tempest", "benchmark", and "generate report"
20:27:46 <boris-42> dhellmann cause it is impossible to create any load
20:27:57 <russellb> sdague: agree it seems it was "off in a corner"
20:28:00 <boris-42> dhellmann yep it includes some dev cases that were orignial
20:28:02 <boris-42> devananda ^
20:28:04 <devananda> boris-42: I, for one, am quite concerned that this is duplicatign several existing programs' efforts
20:28:23 <boris-42> devananda so the idea was just to put some glue for using devstack and other stuff
20:28:23 <devananda> boris-42: and agree that it's better for the parts that should be in existing projects to be contributed there
20:28:29 <boris-42> devananda to deploy on what you have
20:28:37 <boris-42> devananda it was dev case at the very begging
20:28:48 <boris-42> devananda but what I saw from different companies nobody is interested in that
20:28:51 <mordred> boris-42: right. but the thing is, we ALSO had code to do that
20:28:54 <boris-42> devananda everybody has own clouds
20:29:02 <boris-42> devananda and they need just to get reports=)
20:29:03 <ttx> OK, so there is agreement around that the incubation request is not warranted, at least not as this early stage, but still discussion on whether we want Rally in QA or in some operator tooling program
20:29:07 <boris-42> rudrarug_ or debug=)
20:29:15 <jeblair> boris-42: i think some of us are having trouble seeing the difference between rally and QA scope.  i think we'd like you to try to work it out and incorporate parts of rally in tempest.
20:29:17 <boris-42> mordred yep I know
20:29:21 <mordred> boris-42: so, what I personally need to see from you other than good code is an ability to work within other people's designs
20:29:26 <mordred> boris-42: and to collaborate with existing programs
20:29:29 <mordred> it's very important
20:29:30 <boris-42> mordred but if we can have code in one place that can be reused by everybody
20:29:31 <devananda> mordred: ++
20:29:37 <boris-42> mordred it means for me to be "open"
20:29:42 <russellb> mordred: ++
20:29:52 <boris-42> mordred I agree
20:29:55 <annegent_> boris-42: I think it's fine to get the discussion, and we're offering input even early
20:30:06 <dhellmann> boris-42: sometimes that openness means putting things in the right place, not just in a central place
20:30:17 <boris-42> devananda sure
20:30:21 <boris-42> dhellmann sure**
20:30:28 <mordred> boris-42: so let's suggest this - for now, I think it's very important that you figure out which bits of rally actually need to live in tempest with sdague and then get that work done
20:30:30 <vishy> so it sounds like the main issue is scope creep
20:30:45 <vishy> i.e. rally needs to be scoped back down to something reasonable
20:30:46 <mordred> and once that's underway, it seems like we'll be pretty excited about seeing where we can take the next step with rally
20:30:48 <mordred> no?
20:30:52 <ttx> We have other items to cover, and I think we won't solve that one today. We should continue the discussion on the mailing-list and the reviews, based on the feedback we just provided
20:30:57 <dhellmann> vishy: +1
20:31:02 <davidlenwell> boris-42: if you need help with that refstack has some of the same needs from tempest and I have a few people who need things to do.
20:31:02 <vishy> honestly i would throw out the operator stuff completely
20:31:05 <vishy> make it a dev tool
20:31:07 <dhellmann> mordred: +1
20:31:13 <russellb> vishy: +++
20:31:21 <devananda> vishy: ++
20:31:22 <boris-42> mordred https://review.openstack.org/#/c/94473/
20:31:26 <boris-42> mordred this is major part
20:31:31 <boris-42> mordred that should be moved out of rally
20:31:34 <devananda> vishy: the osprofiler work looks MUCH more useful to operators to me
20:31:35 <ttx> vishy: that means.. in the QA program :)
20:31:43 <dhellmann> vishy, russellb : I see some value in an operator tool to look at the full stack performance
20:31:50 <vishy> sure that is fine
20:31:55 <vishy> but rally is trying to do both
20:31:57 <russellb> but let's start with dev tool
20:31:58 <vishy> start with one
20:32:01 <russellb> yes, that
20:32:08 <russellb> and make it really awesome at that
20:32:09 <gokrokve> As an operator I would prefer well defined service which provides me an information about my current deployment status, rather then having bunch of scripts I have to know how to run and use.
20:32:13 <russellb> i mean, i've never seen a single set of results for nova
20:32:14 <devananda> boris-42: an initial guess, from a previous operator-of-things. Something like osprofiler + the reporting tools would be helpful for operators. but those tools don't need an API
20:32:15 <ttx> vishy: yes, that's what I meant by suggesting to grow as a QA use case first
20:32:25 <boris-42> gokrokve but it's goal of rally..
20:32:30 <boris-42> gokrokve on operators program
20:32:30 <sdague> gokrokve: how do you monitor the monitor?
20:32:53 <boris-42> devananda they already have actually*=)
20:33:04 <boris-42> devananda they API is special headers and in python clients --profile
20:33:06 <dhellmann> boris-42: do you have any links to results handy for russellb ?
20:33:09 <boris-42> devananda btw could you take a look at spec
20:33:09 <gokrokve> If it is a service I can use some tools available. If it is a bunch of tests I cant monitor them at all.
20:33:21 <boris-42> russellb ?
20:33:28 <ttx> boris-42: do you agree to abandon the incubation request part ? I think we need to discuss the program placement a bit more
20:33:30 <dhellmann> russellb: I've seen a few nice graphs, but didn't save the links
20:33:35 <dhellmann> boris-42: rally output
20:33:35 <boris-42> ttx +1
20:33:39 <russellb> dhellmann: don't need to see them this minute ...
20:33:42 <boris-42> ttx it is not time to incubated
20:33:47 <boris-42> ttx we should disucss program
20:33:48 <ttx> #agreed Rally incubation request dropped
20:34:05 <boris-42> dhellmann russellb one sec
20:34:14 <ttx> #info Still disagreement on whether Rally should be placed under QA program or new "operators tools"-like program
20:34:16 <russellb> boris-42: don't worry about it
20:34:19 <boris-42> russellb btw wanna rally perfroamnce job
20:34:22 <boris-42> russellb in nova?
20:34:22 <russellb> i'm more concerned about regular results being provided
20:34:26 <russellb> boris-42: of course
20:34:32 <boris-42> mordred ^=)
20:34:37 <boris-42> russellb mordred  we will make a patch then
20:34:48 <boris-42> russellb https://review.openstack.org/#/c/111973/
20:34:54 <boris-42> russellb take a look at jenkins output
20:34:59 <ttx> Let's continue that discussion on the ML and the review, please
20:35:00 <boris-42> russellb http://logs.openstack.org/73/111973/1/check/gate-rally-dsvm-rally/cd94a94/
20:35:13 <boris-42> russellb in rally-plot you have different presentation of result
20:35:30 <boris-42> russellb it some kind of functional testing of rally
20:35:48 <boris-42> russellb this is what was actually run https://github.com/stackforge/rally/blob/master/rally-scenarios/rally.yaml
20:36:11 <boris-42> russellb sla: max_failure_precent means that job will fail if any of iteration in scenario will fail
20:36:14 <dhellmann> ttx: do you mean discuss the operators tool program on the ML?
20:36:34 <ttx> I mean present the two options and gather pros/cons
20:36:41 * dhellmann nods
20:36:51 <ttx> I would like ot be sure that the QA team would take it, too
20:37:07 <boris-42> ttx dhellmann one more thread?
20:37:17 <ttx> and I think there needs to be more education and reflection on that topic, we won't choose today
20:37:28 <mordred> ++
20:37:29 <boris-42> ttx +1
20:37:30 <ttx> and we have other topics to cover.
20:37:30 <boris-42> =)
20:37:48 <ttx> #topic Integrated projects and new requirements: Gap analysis for Swift
20:37:53 <notmyname> hello
20:37:53 <ttx> notmyname: o/
20:38:01 * ttx considers having two TC meetings per week
20:38:08 <ttx> #link https://etherpad.openstack.org/p/swift_gap_analysis
20:38:36 <ttx> So.. swift is the last currently-integrated project to go through this
20:38:48 <notmyname> sorry I couldn't make it a few weeks ago
20:39:05 <ttx> the goal again is to make sure currently-integrated projects match the requirements we place on new projects
20:39:21 <mordred> ttx: jogo wants us to meet daily you know ...
20:39:26 <ttx> and if there is any gap, we have a plan to address it
20:39:39 <annegent_> so swift didn't get a cease and desist from Apple? :) I kid, I kid.
20:39:51 <ttx> annegent_: they got one from Taylor Swift
20:39:58 <notmyname> heh
20:39:59 <annegent_> ttx: NO
20:40:07 * dhellmann believes it
20:40:16 <mikal> I think John should sing more Taylor Swift songs at summits
20:40:16 * mordred sends Taylor Swift a C&D
20:40:26 * mordred is pretty sure his last name was Taylor before she was born
20:40:28 <dhellmann> mikal: +1
20:40:33 <mordred> mikal: ++
20:40:40 <ttx> notmyname: so... we have one well-known difference, not sure we can consider it a gap though...
20:40:52 <notmyname> ttx: I agree with that statement :-)
20:40:56 <ttx> which is that swift has its own intra-cycle release schedule
20:40:57 <russellb> release cycle?
20:41:34 <ttx> We basically special-case Swift, of all the integrated release pieces, in release scripts to support that... difference
20:41:41 <dhellmann> ew
20:41:48 <notmyname> we fully participate in the integrated release
20:42:03 <notmyname> but instead of milestones, we have semantically versioning releases
20:42:06 * reed announces Taylor Swift will be in Paris
20:42:25 <mordred> also, I'm not sure I agree with the answer to * Project should use oslo libraries or oslo-incubator where appropriate
20:42:26 <russellb> on a different schedule, not just the naming
20:42:27 <dhellmann> notmyname: "we do what you want, but something different"?
20:42:31 <ttx> Specific versioning which also triggers that special-casing in release scripts
20:42:32 <annegent_> reed: NO :)
20:42:33 <devananda> reed: lol
20:42:37 <mordred> given there is no use of oslo whatsoever, I don't think "done" is the right answer
20:42:47 <russellb> mordred: agreed
20:42:55 <annegent_> mordred: but they just started using oslosphinx :)
20:43:00 <notmyname> mordred: jsut today I merged using oslosphinx :-)
20:43:06 <mordred> notmyname: neat!
20:43:06 <dhellmann> annegent_: I'm more interested in oslo.config
20:43:08 <mordred> :)
20:43:17 <annegent_> dhellmann: Actually, yah, me too
20:43:26 <annegent_> docs team had to write a scraper
20:43:27 * mordred doesn't necessarily want to push for a particular change - just wants to call a spade a spade
20:43:30 <annegent_> for config options
20:43:38 <dhellmann> annegent_: so that's 2 teams special casing things for swift?
20:43:43 <ttx> notmyname: I just want to make sure we are different there for a reason -- I just don't want each integrated project to come up with their own variation of release schedule
20:44:02 <ttx> and if we grant swift an exception, that it's documented as an exception
20:44:04 <notmyname> ttx: ok, so there's a few things going on here so far. hard to handle 2 conversations
20:44:08 <notmyname> ttx: which do you want first?
20:44:15 <ttx> I was first
20:44:17 <ttx> :)
20:44:18 <notmyname> :-)
20:44:26 <notmyname> ok, release cycle
20:44:33 <ttx> basically we force new projects to follow the common cycle
20:44:40 <ttx> including dev milestones
20:44:59 <notmyname> https://wiki.openstack.org/wiki/Release_Cycle
20:45:09 <notmyname> see the 3rd paragraph
20:45:12 <ttx> I'm fine to keep the swift exception, but I want to make sure we are doing it for the right reason, and that it's seen as an exception
20:45:29 <notmyname> there are a few reasons we do the releases the way we do
20:46:02 <notmyname> first, historical reasons. that's not always a reason to keep doing something some way, but it is one reason
20:46:03 <ttx> we no longer give that choice to new projects
20:46:03 <mikal> I don't personally have a problem with swift's release cycle, and we can always tell new projects that its different for historical reasons
20:46:21 <ttx> mikal: I would be fine with that
20:46:29 <ttx> it's different for historical reasons
20:46:30 <russellb> it affects more than just new projects
20:46:43 <russellb> it's also a complication for anyone consuming openstack releases
20:46:45 <jeblair> let's see if there's any reason other than historical to keep doing it
20:46:46 <russellb> so it comes at a cost to keep it
20:46:58 <markmcclain> just because we've always done something that way doesn't mean we shouldn't consider aligning
20:47:05 <dhellmann> I would like to understand more about why it's different, though, because "we've always done it that way" isn't really much of a reason
20:47:22 <notmyname> I've asked operators at just about every one of the last 4-5 summits, and have been told that they like it. therefore, from swift deployers, I've not heard a request to change it
20:47:39 <notmyname> markmcclain: certainly. I only wanted to point that out
20:47:44 <dhellmann> notmyname: did you ask them if it would bother them if you did change?
20:47:59 <russellb> and are these people only using swift?
20:48:07 <ttx> notmyname: don't you think that... difference is also what's causing people to see swift as different and optional in an openstack deployment, though?
20:48:11 <ttx> I think it cuts both ways
20:48:23 <dhellmann> ttx: +1
20:48:33 <notmyname> dhellmann: most of it is over casual conversation or "poll the room" sort of stuff. some said that's what they liked. it's come up in the design sessions several times.
20:48:42 <markmcclain> notmyname: what are the technical/project management benefits to the unique schedule?
20:49:00 <ttx> markmcclain: basically, they do feature-badsed releasing
20:49:01 <vishy> access to features sooner
20:49:09 <ttx> and also release more often
20:49:14 <notmyname> markmcclain: it works for those who are contributing to and deploying swift. IOW it's not broken from the perspective of those writing the code
20:49:23 <dhellmann> notmyname: right, but if the question is "is what we're doing now working for you" that doesn't tell you anything about whether changing would be bad
20:49:29 <ttx> which, given that they are really more stable that the rest of openstack, kind of make sense (faster cadence)
20:50:09 <notmyname> to be very explicit here, I'm not 100% opposed to changing it. but changing does have a cost (as does keeping it).
20:50:09 <annegent_> it's a headache to explain in docs, doesn't mean we won't keep doing it for historical reasons, I mean, Google indexes stuff forever
20:50:31 <notmyname> ttx: right. I think the faster access to features and stability has been well-demonstrated over the last 4+ years of semver releases
20:50:37 <russellb> it's a headache for planning from a distro perspective, too
20:50:44 <ttx> notmyname: I think we can consider this an identified "difference" and discuss the pros/cons of alignment
20:50:50 <ttx> in future discussions
20:50:56 <notmyname> russellb: how? distros take the integrated release. which we fully participate in
20:51:07 <russellb> notmyname: it's everything in between
20:51:09 <notmyname> ttx: ack
20:51:20 <ttx> #info identified difference (which needs analysis and justification): different release schedule
20:51:27 <ttx> notmyname: maybe address the second concern now
20:51:32 <notmyname> oslo.config
20:51:45 <dhellmann> let's talk oslo in general, that was just one example
20:52:02 <notmyname> ok, oslo in general
20:52:39 <notmyname> first, we are not going to accept the copy/pasted code externally managed. if it's a library available upstream, then let's consider it
20:52:49 <notmyname> if it is available, then there are a few questions
20:52:58 <notmyname> does it fix something that is broken
20:53:00 <ttx> I think in both cases we need to have an open discussion on why being different has more benefits than drawbacks, to justify the unique case
20:53:16 <notmyname> and what is the impact to deployers (dependencies and upgrades)
20:53:44 <dhellmann> yeah, I'm less worried about the incubator use. if you don't want that, I don't want to waste time arguing. You'll just have less input into the APIs of the libraries, and I do expect you to use those
20:53:54 <notmyname> specifically, oslo.config has grown up after swift's config stuff (which does work) has settled. so I'd be happy to discuss that one in particular
20:53:55 <ttx> #info identified difference: oslo library adoption
20:54:20 <ttx> notmyname: it's also a "be more openstack" or "be less openstack" question imho
20:54:31 <russellb> really, they both are
20:54:34 <jeblair> broken for deployers can also mean for new deployers.  the differences in config and logging across openstack projects are burdensome for people deploying the whole thing.
20:54:49 <annegent_> ttx: and does a defcore inclusion discussion belong in a gap analysis?
20:54:49 <mordred> jeblair: ++
20:54:57 <ttx> notmyname: given the project history you 're fine with not being openstack where it doesn't help you, but as I said it cuts both ways
20:54:59 <russellb> annegent_: imo, no
20:55:00 <dhellmann> jeblair: right, that's a bit reason for oslo to even exist
20:55:03 <dhellmann> *big
20:55:12 <ttx> being "less openstack" left the door more open to alternate solutions
20:55:15 <annegent_> russellb: seems like it was already tc-discussed but just checking
20:55:37 <mikal> annegent_: so, the tc said "integrated release", right?
20:55:42 <notmyname> ttx: I don't like the characterization of "we don't do X, therefore we aren't "more openstack""
20:55:48 <mikal> annegent_: so I think we've designated swift as code to ship for defcore
20:56:01 <ttx> notmyname: see jeblair remark above
20:56:04 <russellb> notmyname: but it's when *everyone* else does X
20:56:09 <annegent_> mikal: yep
20:56:09 <russellb> and is happily doing it to converge
20:56:25 <ttx> notmyname: for someone that deploys "openstack", swift is configured slightly differently, logs slightly differently
20:56:32 <zehicle_at_dell> mikal, I thought that the TC chose to get out of designating code
20:57:02 <mikal> zehicle_at_dell: well, we said we wanted all of the integrated release to be designated
20:57:03 <dhellmann> russellb: +1
20:57:10 <mikal> zehicle_at_dell: but that the board could override us if they wanted
20:57:12 <russellb> mikal: not exactly ...
20:57:15 <dhellmann> please let's not re-open that discussion
20:57:15 <mordred> zehicle_at_dell: what mikal said
20:57:17 <russellb> and that's a totally different topic anyway
20:57:17 <zehicle_at_dell> mikal, that's not what I remember.
20:57:21 <mikal> zehicle_at_dell: but this is a side line, let's keep to swift
20:57:27 <ttx> But these are difficult questions, that's why I'm not calling them "gaps", as swift lived with those pretty happily so far
20:57:29 <dhellmann> zehicle_at_dell: we are not talking about defcore right now, please
20:57:42 <annegent_> sorry, did not mean to derail gap analysis
20:57:48 <zehicle_at_dell> dhellmann, I did not bring it up... was addressing a statement
20:57:50 <ttx> ok, 3 minutes left -- any other area of difference or gap ?
20:58:20 <ttx> I think we need to have a frank discussion on each of those, but could be a summit thing too, not really urgent
20:58:25 <notmyname> ttx: to summarize oslo usage, there are areas where we do not us oslo where functionality may need to be considered
20:58:26 <ttx> but we need to call out all areas
20:58:45 <ttx> where current requirements do not fit the swift use case
20:58:56 <ttx> anything else than release cycle and oslo adoption ?
20:59:37 <ttx> there is a blurb about "lifecycle of resources managed by the project should be externalized via notifications"
20:59:49 <russellb> that falls under the oslo topic to me
20:59:49 <ttx> not sure swift does that, but then...
20:59:52 <ttx> ok
20:59:53 <notmyname> ttx: ya, what is that?
20:59:59 <dhellmann> russellb: I think that's more for ceilometer integration
21:00:00 <russellb> oslo.messaging notifications
21:00:08 <russellb> every other project uses that
21:00:10 <ttx> ok, that falls into the oslo bucket
21:00:23 <ttx> I think we identified the two key areas then
21:00:41 <ttx> notmyname: i'll be in touch on how we can have a healthy discussion about those
21:00:46 <notmyname> ttx: ok
21:00:50 <annegent_> there's the separate auth that then enables non-keystone installs, but that's not a big concern I don't think, and makes sense for the object storage use
21:00:55 * ttx rushes through a few items
21:01:08 <ttx> #topic Other governance changes
21:01:13 <ttx> * Add repository glance.store to glance (https://review.openstack.org/107585)
21:01:16 <ttx> This one is missing markwash's +1, then if nobody objects I'll approve it
21:01:21 <ttx> * use ">" to indicate multiline mission statements (https://review.openstack.org/109021)
21:01:24 <ttx> This one is cosmetic, will approve now unless someone yells
21:01:31 <ttx> #topic Open discussion
21:01:35 <ttx> Famous last words ?
21:01:51 <dhellmann> in case anyone doesn't know, I've moved from Dreamhost to HP. My new email is doug@doughellmann.com, so please update your address books.
21:01:59 * mordred wins
21:02:02 <russellb> heh
21:02:06 <ttx> dhellmann: noted and congrats and all.
21:02:13 <dhellmann> thanks :-)
21:02:16 <vishy> can we propose a moratorium on mordred’s hiring practicies
21:02:18 <annegent_> heh
21:02:21 <ttx> Remember to think of names to suggest for our user committee nominee
21:02:23 <vishy> other companies need good engineers too :)
21:02:23 <mordred> vishy: want a job?
21:02:23 <devananda> heh
21:02:33 <ttx> Also I raised a "winter is coming" thread about the integrated release
21:02:34 <mikal> Well, we need to talk about TC balance at some point
21:02:34 <reed> lol
21:02:39 <ttx> you might want to chime in there
21:02:53 <russellb> mordred: hiring the whole TC?
21:03:00 * mordred may have also responded to ttx winter is coming thread ..
21:03:05 <devananda> ttx: thanks. that's been on my mind (probably all of our minds, I think)
21:03:09 * mordred is sharpening his axe
21:03:14 <dhellmann> mikal: fwiw, we talked a lot more about oslo than the tc
21:03:21 <markmcclain> ttx: thanks for raising that thread
21:03:24 <ttx> If people contributed to the Night Watch we wouldn't have that problem again
21:03:32 <ttx> #endmeeting