20:01:42 #startmeeting tc 20:01:43 Meeting started Tue Oct 23 20:01:42 2012 UTC. The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:01:44 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:01:45 The meeting name has been set to 'tc' 20:01:52 The agenda for the meeting is at: 20:01:57 #link http://wiki.openstack.org/Governance/TechnicalCommittee 20:02:06 We have a bit of ground to cover today so let's start 20:02:14 #topic Motion: Nomination of Ryan Lane to the User committee 20:02:27 So this is just a formal confirmation that we nominated Ryan Lane to set up the user committee together with Tim Bell (nominated by the BoD) 20:02:35 o/ 20:02:35 * heckj seconds 20:02:40 I went to all of you last week to get your agreement, so this should just be a matter of making it part of our first meeting minutes... 20:02:49 Anyone with a last-minute objection ? 20:02:56 nope 20:03:01 sounds good to me. 20:03:04 none here 20:03:09 no objections 20:03:11 sounds great 20:03:19 #agreed Ryan Lane nominated to the original self-bootstrapping user committee 20:03:35 Ryan_Lane: you just missed your coronation 20:03:38 #topic Motion: Ceilometer application for incubation 20:03:39 :D 20:03:44 * nijaba waves 20:03:46 #link http://lists.openstack.org/pipermail/openstack-tc/2012-October/000016.html 20:03:51 * dhellmann o/ 20:03:58 A few preliminary remarks on Incubation before we start the discussion... 20:04:08 There is an upcoming discussion to have on the Incubation / Core promotion process, together with the Board of Directors 20:04:16 They should file a request to see the topic discussed soon 20:04:33 In particular, we'd like to avoid that projects follow the full incubation track only to be vetoed by the BoD at the very end of the process 20:04:44 That said I see no reason to delay the decision on Ceilometer incubation 20:04:49 they can veto it? 20:04:55 Incubation is about pushing common resources to a project that we think is promising 20:05:11 russellb: they can veto a project that we recommend for core yes. They can't veto Incubation per se 20:05:18 ok. 20:05:25 ttx: it's more than a nursery, though 20:05:30 So Incubation is about asking CI, QA and release management to work together with the incubated project 20:05:39 so that it can be ready to become a core project for the next cycle 20:05:43 * bcwaldon and vishy join the party 20:05:46 o/ 20:05:50 So it's necessary to become a core project, but it's not sufficient 20:05:50 * nijaba notes that they have been very helpful already 20:05:51 we missed bcwaldon and vishy 20:06:12 We'll have to clarify this with the BoD, but if the project is deemed out of the scope of OpenStack then it might just drop off Incubation status 20:06:21 ...and if that happens I'd rather have it happen early rather than late 20:06:22 or is it possible that a project stays in an incubated state indefinitely? 20:06:34 mordred: I hope not 20:06:39 mordred: well then the drain on common resources is unwarranted 20:06:43 With that in mind, let's open the discussion on this application 20:06:48 My impression is that the incubation period is also somewhat about holding the project accountable to a higher standard, e.g. they're ready to play nice with the ecosystem... right? 20:06:51 ok. just clarifying 20:06:56 How about discussing Technical qualities and readiness first, then Project management, then Core scope 20:07:01 gabrielhurley: yes 20:07:12 it's about proving you can align, given the help 20:07:30 On the technical qualities, the design and code looks generally good to me... 20:07:32 From my perspective they have demonstrated that pretty well already 20:07:49 Opinions on the technical side ? 20:08:08 They're pushing in the right directions in terms of their integration with other core projects and helping standardize things, which is a big + for me. 20:08:16 no objections here. 20:08:33 I don't have any complaints about the technical choices or direction 20:08:41 interfacing at the right level, working hard to help move openstack-common forward to help address their use cases, ... good stuff. 20:08:48 for me it is whether or not metering fits in with core iaas components 20:08:49 the only thing I'd like to see them focus on technically is fleshing out their API a bit more 20:09:06 OK, let's switch to project management then, if it makes sense technically for everyone 20:09:22 From a project organization perspective, I think Ceilometer was a good example of how it should be done "the openstack way". Starting from scratch... 20:09:26 same as above, project management they've been responsive and interactive 20:09:35 looking for integration points, using common, etc 20:09:39 no objections on project management 20:09:43 agreed 20:09:45 yep, seem to have been working hard to do things the openstack way 20:09:54 good openness, communication 20:10:03 ++ 20:10:06 Technically they are sound for devs to contribute and in interacting with common, but I haven't seen much about interaction with operators or a roadmap for H? Is that forthcoming? 20:10:24 I heard some informal roadmap talk from them at the summit 20:10:48 I think if prompted it would be forthcoming in a more formal way 20:10:52 nijaba: care to expand on that ? 20:10:59 annegentle-nz: we had a lot of conversations with potential users during the summit, and are working on our roadmap 20:11:05 annegentle-nz: our roadmap was at http://wiki.openstack.org/EfficientMetering/RoadMap but we exepanded quite a bit our scope at the summit, so we'll have to update it soon 20:11:25 New objective since the Grizzly summit: The project aims to become the infrastructure for all measurements within OpenStack. 20:11:35 nijaba: Awesome. The goals for the project are highly desired in operations as far as I can tell from doc search data. 20:11:40 and lots of good discussions have happened that way 20:11:53 OK, any more comment on the project management/integration side before we discuss Core scope ? 20:12:07 annegentle-nz, i see a good document in place already :) 20:12:24 sorry I'm late 20:12:36 * markmc very happy with ceilometer technically and project management wise 20:12:37 hey markmc 20:12:44 OK then the less obvious part, core scope 20:12:58 imho, you can't run a cloud without billing 20:13:00 Personally, with the extended scope of the project (metering and monitoring), having a central place to collect metrics about your running cloud infra sounds like a good addition to any cloud 20:13:02 seems pretty essential 20:13:06 same here 20:13:11 so, one way i think about this part is, how many people operating openstack need it? 20:13:13 (most of them, IMO) 20:13:19 It's definitely a supporting service... 20:13:29 In my mind the objective of "measuring" is much more aligned with Core than "metering" and having been looking at what it currently takes to measure things in any one project let alone all of them I think it's very valuable. As Horizon PTL I can say that having another project in core that experiences the pain of consuming *all* the projects is a plus to me. 20:13:35 Even if it doesn't fall in to the "necessary" category of supporting services (like Keystone), it seems to fall into the "best practice" category (like Horizon) 20:13:53 And since it's more of a collection service than an action service, it doesn't stretch the definition of openstack core that much 20:13:59 (for most definitions of it :) 20:14:12 Other opinions on that ? 20:14:16 well most people using openstack probably have to invent their own version of this right now 20:14:38 * russellb didn't read any objections ... 20:14:40 russellb: multi-tenant clouds, yes, what about private clouds? 20:14:43 russellb: this is the case from what we heard and was one of our initial motivation, indeed 20:14:51 Or let me know if you're all ready to vote 20:14:53 i think private clouds too, for doing chargeback 20:15:00 bcwaldon: Ryan_Lanecould advocate the need for metering without billing 20:15:00 I think the horizon example is a good one 20:15:01 I think it's a good project to scope to enable adoption without having everyone re-invent the wheel 20:15:03 bcwaldon, billing/metering is pretty essential for private clouds too 20:15:07 holding groups accountable for the resources they consume 20:15:10 or have more questions for the Ceilometer crowd first 20:15:20 markmc, +1 20:15:25 ok, just wanted to hear the thinking 20:15:34 in terms of it being 'best-practice' but not required 20:15:37 cool 20:15:41 one other thing we should consider 20:15:46 yeah, "showback" even if not "chargeback" is definitely a want for private clouds 20:15:55 good way to look at it 20:15:56 Just heard that you're also working on Operators docs? It's seriously the most searched for topic so the demand for docs is high. 20:16:02 we have to be careful with moving projects to core in the case that it will kill the ecosystem 20:16:05 .. and good measurement is key to healtg monitoring as well 20:16:22 vishy: can you explain a bit for me? 20:16:36 so if there are competing projects for example we need to be careful about giving a stamp of approval to one 20:16:38 vishy: that's a good argument, but I don't think that's the case here. It actually enables an ecosystem in my view 20:16:42 people might be upset if ceilometer is blessed but their billing project isn't 20:16:44 before it has been fought out in the market. 20:16:47 vishy: ahhh 20:16:58 how many other billing projects are are as mature and openstack-like? 20:17:00 that's an interesting point. 20:17:01 given the pain involved in extracting measurements right now, the only way an ecosystem could form to fill this gap is if all the projects uniformly adopt much better mechanisms for exposing data that needs measuring. 20:17:04 that is an interesting point - although I am not currently aware of any competing projects 20:17:15 markmc: ceilometer doesn't do billing though. 20:17:21 markmc: we've been very careful to limit ourselves to *measuring* things without actually billing for them, because there are a lot of billing tools 20:17:21 but since we do not do billing, only measurment, that shold be help for them, not threat 20:17:21 I think it's a good thing to keep in mind in general though 20:17:23 considering there goal of being pluggable to billing systems I think we are ok in that department 20:17:24 s/billing/metering/ 20:17:29 ++ 20:17:29 I'd see a "billing" project sitting on top of ceilometer 20:17:33 so what else exists that is comparable then? 20:17:43 but there is definitely some overlap with synapse and heat 20:17:49 there was a nova-billing thing 20:17:54 there are proprietary solutions 20:17:54 gabrielhurley, +1 20:17:57 no overlap with heat, for sure 20:18:03 vishy: we're talking with the heat folks about sharing code, and are looking at synaps now, too 20:18:20 well synaps overlaps with heat quite a bit, that's for sure 20:18:21 markmc: but proprietary systems are part of the ecosystem too 20:18:21 is there code out for synaps yet? 20:18:22 markmc: cloudwatch and ceilometer monitoring overlaps doesn't it? 20:18:23 if not, it doesn't exist IMO. 20:18:27 markmc: indeed, heat even triggered a very heathly discusison and change of scope 20:18:32 russellb: now yes 20:18:33 russellb: yes the code is out 20:18:38 ok cool. 20:18:46 notmyname, as are proprietary object stores :) 20:18:50 jd__: did a good analysis of the synaps code 20:18:55 vishy: not really... heat and cloudwatch overlap, IIRC 20:18:56 notmyname: totally - but I think if it's something that needs interfaces with things - having an open source bit that fills the spot enables the proprietary systems 20:18:57 anyway, that doesn't seem to be an objection, mpore of a concern to add to our checklist 20:19:02 I actually don't see any reasonable conflicts, I just want to make sure that we consider all of these things 20:19:14 it should be something that we consider whenever we are promoting 20:19:16 understood 20:19:17 Ready to vote ? More comments or questions ? 20:19:19 vishy: ++ 20:19:23 definitely a good point for when heat comes up, more overlap there right now 20:19:25 vishy, ok, yeah - cloudwatch is an extension of ceilometer's current scope 20:19:47 vishy, I'm pretty happy that the heat and ceilometer guys have been working well together on monitoring 20:19:48 FYI http://julien.danjou.info/blog/2012/openstack-synaps-exploration talks about the overlaps 20:19:55 markmc: ++ 20:19:56 vishy, and monitoring makes more sense in ceilometer than heat 20:20:32 * russellb is ready to vote ... 20:20:43 I think ceilometer's limited scope is their proof they'll make OpenStack stronger 20:20:56 agreed 20:21:02 annegentle: interesting way to look at it, but quite true 20:21:21 Starting the vote in 30 seconds unless someone objects 20:21:29 Note that according to our charter we need strictly more "yes" than "no" for approving 20:21:39 and at least 5 "yes" (or "no") to come to a permanent approval/rejection 20:21:48 do we have a final statement on scope? 20:21:51 ttx do you have instructions for voting for newbies? :) 20:22:04 ^^^that 20:22:04 gabrielhurley: Error: "^^that" is not a valid command. 20:22:18 lol 20:22:18 danwent: good question... ? 20:22:25 danwent makes a good point 20:22:32 just that it seems like many people running openstack might also use this? I think we're setting a standard that will be used to judge other projects as well. 20:22:39 how do we ensure projects don't grow unlimited in scope? 20:22:46 so i'd like to be a bit more crisp if possible. 20:22:51 danwent: it's in the incubation application. "The project aims to become the infrastructure for all measurements within OpenStack." 20:22:55 do we say "come back to us if you want to grow your scope dramatically?" 20:23:09 so if "many people running openstack" use something, does it get to be in core? is that the guideline now? 20:23:10 well, any change of scope should be submitted to the TC 20:23:24 dropping large amounts of functionality is also not ok 20:23:28 ttx: is that formalized anywhere? 20:23:42 also, I thnk if someone else thinks that they (or anyone) are exceeding their mandate, that can also always be raised ... 20:23:42 russellb: except in PPB pre-history ? Not really 20:23:44 "measurements" seems like an overly broad scope, at first glance 20:24:00 "dropping large amounts of functionality"... so Nova should be dropped from Core for excising the volumes code, right? ;-) 20:24:01 sorry, I thought we were going to talk about the scope of what should or should not be a core project. or ttx, did I misunderstand your earlier comment? 20:24:12 e.g. precluding other services for monitoring or performance analysis 20:24:13 I'm actually curious about the stated vs implemented scope of the existing projects - does that exist somewhere? 20:24:19 danwent: we've been doing that for the last 10 minutes ? 20:24:47 starting at: OK then the less obvious part, core scope 20:24:48 yes, but I'd like to see an actual statement summarizing what we decided. 20:24:50 Previous mission statement: The project aims to deliver a unique point of contact for billing systems to aquire all meters they need to establish customer billing, across all current and future OpenStack core components. <-- this is what we are more or less covering at the moment 20:24:52 markmc: We don't do a lot of analysis of the things we're measuring now. We leave that up to the consumers. 20:25:11 dhellmann, right, but even collecting performance measurements 20:25:25 danwent: a definitive answer on what should or should not be a core project is out of scope (haha) for this meeting 20:25:29 markmc: I see 20:25:32 dhellmann, current statement of scope would make it sounds we won't allow other new projects to do such things, that ceilometer should do all that 20:25:35 i.e., is our measuring stick "it seems like many openstack clouds would need this", how we measure if something should become a core project? 20:25:41 danwent: we can work on that but I expect it will take a few meetings ;) 20:25:46 dhellmann, why 'measurements' and not 'metering' as the project's scope? 20:26:17 ttx: ok 20:26:19 metering implies usage data, right? measurements much more broad, includes anything and everything? 20:26:33 markmc: because of the extension we discussed with heat and other project to allow for a generic infrastructure for monitoring and alerting 20:26:52 markmc: Based on our conversations at the summit with the Heat and StackTach folks, we thought it made sense to collaborate beyond metering for billing and cover measuring things for other purposes, too. We discovered areas we could reuse code, data, etc. 20:26:53 i'm personally very happy with the ceilometer stuff, just concerned about approving it without a more clear statement that would give us guidence on any other project. 20:26:58 danwent: there is no formalized "scope of openstack" doc anywhere 20:27:09 danwent: that's work in progress 20:27:22 nijaba, that conversation to extend the scope seems to be in progress though, vs ceilometer being well proven for metering 20:27:23 nijaba: so would you call your official name.. OpenStack Metering ? Measuring ? 20:27:26 right now it's gut feeling? heh. 20:27:34 markmc: true indeed 20:27:36 although I agree with danwent that having such a scope doc would be nice 20:27:42 russellb: it's always been that way so far :P 20:27:50 +1 to eventually getting a clear definition of scope, but not today 20:27:54 gotta start somewhere, it's all good. 20:27:58 * mordred also interested in ttx's 'official name' question 20:28:05 ttx: at the moment metering, if all goes well for grizzly, measurement 20:28:10 likewise, I think the project is solving a real need, but I don't know that it's good as a core project 20:28:23 my gut feeling is that the ceilometer team is doing a good job, and that it will be useful to many deployments, so I guess i'll go with that for now :) 20:28:24 or maybe "OpenStack Metrics" 20:28:35 * annegentle-nz likes metrics service 20:28:39 ttx: nice 20:28:44 * jaypipes notes that when he hears "metering", he thinks of rate limiting 20:28:45 +1 20:28:52 metrics implies analysis though 20:28:57 measurements does not 20:28:58 metrics precludes another service doing performance or monitoring metrics 20:29:07 OpenStack numbers collection and stuff? 20:29:13 lol 20:29:13 mordred++ 20:29:13 mordred: nice 20:29:15 mordred: awesome. 20:29:18 how about "metric collection and aggregation" 20:29:35 yay bikeshedding 20:29:36 why do we not like 'metering'? 20:29:44 extend the scope later if it works out 20:29:53 if the project is voted for core today, is it grizzly they'll first be in? 20:29:59 MarkAtwood: no need to come up with final name before core inclusion request anyway 20:30:03 if so we can just go to measurement 20:30:05 annegentle: maybe or maybe not, that's another step 20:30:06 annegentle: no 20:30:13 won't be core until H anyway 20:30:15 our hope is that our future agent model shold precludes having to rewrite agents for collecting metrics in other projects 20:30:21 ttx: ok 20:30:22 ah right.. 20:30:24 has to go through the whole dev cycle 20:30:40 ok, ready to vote for Incubation ? Not core. 20:30:52 * heckj ready 20:30:55 * jgriffith has been ready 20:30:59 so ready 20:31:01 * annegentle-nz ready 20:31:03 let's do this 20:31:06 go go go 20:31:15 Ok Dope, let's do this 20:31:17 #startvote Approve Ceilometer application for incubation? yes, no, abstain 20:31:18 ha 20:31:18 Begin voting on: Approve Ceilometer application for incubation? Valid vote options are yes, no, abstain. 20:31:19 Vote using '#vote OPTION'. Only your last vote counts. 20:31:25 #vote yes 20:31:26 #vote yes 20:31:27 #vote yes 20:31:30 #vote yes 20:31:31 #vote yes 20:31:32 #vote yes 20:31:33 #vote yes 20:31:36 #vote yes 20:31:37 #vote yes 20:31:47 #vote abstain 20:31:53 #vote abstain 20:32:13 vishy, bcwaldon... 20:32:14 #vote abstain 20:32:28 #vote yes 20:32:47 * ttx wonders if he missed anyone 20:32:48 actually 20:32:50 #vote no 20:32:55 closing in 30 seconds 20:33:34 #endvote 20:33:35 Voted on "Approve Ceilometer application for incubation?" Results are 20:33:36 yes (10): markmc, ttx, vishy, annegentle-nz, heckj, russellb, jgriffith, mordred, gabrielhurley, danwent 20:33:37 abstain (2): bcwaldon, jaypipes 20:33:38 no (1): notmyname 20:33:59 bcwaldon, jaypipes, notmyname: care to expand ? Could be useful for ceilometer folks to improve in the future ? 20:34:08 not clear from previous discussion why 20:34:10 or for future applicants 20:34:43 though "lack of clear definition of core and good separation of power with BoD" certainly qualifies IMHO 20:35:04 i'd like to see the scope solidified during incubation 20:35:05 of Ceilometer that is 20:35:07 I for one would like to see more clarity on what we think belongs in core. 20:35:08 Both we should address in the next months 20:35:10 I don't think we should be adding new projects before we have a good definition of what openstack core is. we are in a huge danger of scope creep (not to mention the raised issues of ecosystem development). I think they are working on solving a very real need, but I can vote +1 on that alone 20:35:27 notmyname: fair enough 20:35:40 i guess i was banking on the fact that incubation doesn't mean they'll become core 20:35:49 russellb: it always has in the past 20:35:52 and i sure hope we clarify that before anything else becomes core 20:35:52 * markmc thinks we need to discuss the meaning of incubation/core/core etc. outside of the context of any particular application 20:35:54 russellb: same here, that's why I did that long intro 20:35:58 I voted yes in that I didn't want to slow down the process of them eventually becoming core, assuming the definition of core puts ceilometer in scope 20:36:15 danwent: good summary 20:36:18 ttx: *nod* 20:36:18 markmc: +1 20:36:23 markmc +1 20:36:29 OK, next topic 20:36:38 #topic Discussion: Third-party APIs 20:36:40 thanks guys 20:36:40 yep, incubation very well may *not* mean core if we clarify what "core" means before the incubation period is up. 20:36:45 vishy: want to kick this one? 20:37:02 thanks, everyone! 20:37:03 sure 20:37:07 so way back in the day 20:37:18 we voted that 3rd party apis did not belong in the core projects 20:37:20 dhellmann: nijaba etc, nice work, guys 20:37:30 thanks 20:37:42 but that the projects should attempt to enable 3rd party apis 20:38:15 so we have made steps in nova towards the end of eventually being able to split out ec2 20:38:26 awsome seems to be totally dead 20:38:32 (and agpl) 20:38:50 and now there is a new api ready to be proposed for nova (google compute engine) 20:39:04 Please note that no formal decision can be made today on this, per our charter -- but the discussion will help vishy draft a proper motion 20:39:08 at least one, if not one or two others ... 20:39:15 Motion = push it to openstack-dev + openstack-tc for community discussion 4 business days before the next meeting 20:39:22 during the summit we had a discussion about whether it was worth it to continue to block apis 20:39:34 considering the greater cost of testing and integration if we split them out 20:39:49 and the consensus in the meeting was that it would be much easier to just leave them in 20:39:58 OCCI... 20:40:07 so the question is, should we revisit the decision 20:40:09 CIMI... 20:40:17 I'm more interested in doing it *right* rather than fast, especially when it means we're blessing more APIs 20:40:33 and throwing everything in the repo lets us get sloppy 20:40:38 bcwaldon: but what is right? forcing them to talk through the public api? 20:40:50 and adding a bunch of extensions for extra functionality? 20:40:55 there were two benefits to keeping internal - performance and not needing to make a stable public performant API 20:41:00 * jaypipes really not a fan of adding these things to Nova... they below as extensions/middleware IMHO 20:41:10 s/below/belong 20:41:13 there's the ideal theory, and the reality of what work folks are actually showing up with 20:41:19 vishy: I'm not specifying implementation 20:41:19 i'm assuming the burden to keep them up to date is on the submitter/maintainer of the API 20:41:29 IIRC Swift used the current decision to separate some parts out -- would reversing the decision mean it could be put back in ? 20:41:41 vishy: just assuming we will have more solid internal APIs if we don't throw everything into the repo 20:41:45 Personally I feel the Openstack API should be the first class citizen, others should be outside of core 20:41:48 e.g. folks showing up with internally implemented gce code, no-one showing up with a public stable performant api for building other apis on 20:41:52 i don't think we'd be asking for a revert, just the option of either way 20:42:16 I like solid APIs, and I'm not a fan of them being in nova, but I'm also not a fan of letting each 3rd=party API project halfass their own implementations externally. neither option seems great. 20:42:20 I also don't want third-party APIs driving us to implement orthogonal things 20:42:27 though I suppose bitrot in core is as likely as outside 20:42:30 like file injection or passwords 20:42:37 ++ 20:42:42 and if it bitrots, we rip it out (like hyper-v) 20:43:02 I think if we decide that outside is the right way to go, the only way we can prove that architecture works is putting ec2 outside and making it talk through the openstack api and ensuring it works 20:43:02 the cost to swift of implementing additional APIs comes mostly at the cost of additional developer and review time (and the mismatch of one api for a different implementation). I'm still opposed to adding things like CDMI and S3 into swift itself 20:43:20 +1 to both vishy and notmyname 20:43:28 essentially I think we have 3 paths forward in nova 20:44:01 1) make a stable internal version ov compute.api and provide a way for 3rd parties to talk to it (via rpc?) and make ec2 use that 20:44:16 notmyname, that assumes the developers of that api don't become part of the project's developer team 20:44:18 2) make 3rd parties speak through the rest api and port ec2 to use that 20:44:34 3) allow 3rd party apis into core 20:44:34 markmc: i'm thinking that's a requirement to have a new API in 20:44:51 all 3 of those are painful, so the question is which is the least painful. 20:44:54 (3) is clearly the path of least resist=ance, but not a big fan of it 20:44:57 I like 2 the best, but I'm not doing any of the work 20:44:58 vishy: what does "port ec2 to use that" entail? 20:45:01 vishy: what's the difference in 1 and 2? 20:45:18 1 is a stable api that already exists 20:45:21 * markmc thinks (3) gives a nice new feature, new developers, no additional work with no volunteers, ... 20:45:32 all of the existing api consumers use the internal implementation though 20:45:33 win 62 20:45:49 so there is a lot more work to port things in 2 20:45:53 compute.api is not a stable api 20:45:58 markmc: should it be? 20:45:59 vishy: and i'm not really comfortable signing up for all of that to be considered a stable public API 20:46:17 bcwaldon, yes, if we're telling external projects to build on it 20:46:29 how do options 1,2 handle metadata services? 20:46:29 I'm a fan of #1 because it doesn't proliferate HTTP calls all over the place. 20:46:57 jog0, annoying little details aren't welcome here :) 20:46:57 making compute.api stable has several benefits 20:46:58 but i don't know how practical it is 20:47:05 gabrielhurley: that's an implementation detail that may not apply to all projects 20:47:08 jog0: that is a solvable problem i think but yes it is a little tricky 20:47:43 notmyname: note that I'm not suggesting in any of the options that we require 3rd party apis be allowed in 20:48:13 notmyname: 3rd party apis remaining outside makes perfect sense for swift 20:49:12 vishy: no, the arguments can be made both ways. seems that a good argument to include a 3rd party API is a good argument because it can be applied to all projects 20:49:31 At some point I think the notion of a *stable* api is going to have to be addressed 20:49:42 The only question for me given the options is if now is the right time 20:50:29 jgriffith: if that's where we are heading anyway, implementing another option in the mean time sounds like wasted effort ? 20:50:42 * ttx doesn't like when there is no good solution 20:50:42 so can we get a quick show of hands on whether a proposal to revert the ppb decision is worth it? 20:50:47 vishy: can your proposal include a draft roadmap? 20:50:59 vishy: I think a proposal will help 20:51:04 annegentle-nz: for what as the goal? 20:51:12 vishy: to help clarify timing 20:51:15 I don't want to temporarily move these things into core 20:51:30 vishy: right, but wondering if it's a G thing or an H thing, that sort of timing 20:51:36 if they are coming in then I don't think there will be a good reason to remove them. 20:51:49 vishy, perhaps the proposal should be to add 'nuance' to the previous decisions :) 20:51:53 annegentle-nz: well number 3 which i'm proposing doesn't take any time at all 20:52:15 I can't do number 3 without violating the ppb edict 20:52:15 vishy: heh, true that 20:52:17 vishy, e.g. the previous decision said that projects should aim to provide a public stable performant api for 3rd party apis to build on 20:52:18 it just adds technical debt in a more obvious way than the others 20:52:39 vishy, we're IMHO really saying that if no-one shows up to do that work, we shouldn't reject new 3rd party apis 20:52:58 the choice between 1 and 2 should be made internal to nova. the question of [(1 || 2) || 3] should be made by the TC, IMO 20:53:32 Looks like this is not crystallizing into a clear choice yet 20:53:46 notmyname: ++ 20:53:49 ttx: does it ever? :) 20:53:58 notmyname: well the question of wether to allow 1&2 or 3 is tc 20:54:11 so far it has decided only 1||2 not 3 20:54:21 vishy: right 20:55:15