20:01:49 <jbryce> #startmeeting
20:01:50 <openstack> Meeting started Tue Jul 10 20:01:49 2012 UTC.  The chair is jbryce. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:01:51 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:01:57 <heckj> o/
20:01:59 <johnpur> o/
20:02:02 <nijaba> o/
20:02:02 <jaypipes> o/
20:02:05 <jgriffith> o/
20:02:05 <jbryce> sorry i'm late...
20:02:10 <ttx> \o
20:02:11 <jk0> o/
20:02:13 <notmyname> here
20:02:29 <jbryce> great...that's 7 ppb members (anyone want to double check my count?)
20:02:33 <jbryce> http://wiki.openstack.org/Governance/PPB - agenda
20:02:42 <ttx> hmmm
20:02:58 <ttx> yes 7
20:02:59 <danwent> o/
20:03:01 <pvo> o/
20:03:02 <ttx> 8
20:03:06 <jbryce> #topic cinder core progress
20:03:07 <ttx> ..
20:03:13 <anotherjesse> o/
20:03:33 <jbryce> so we had agreed to fast track cinder provisionally for core in Folsom with a check at the f-2 milestone
20:04:07 <jbryce> the requirement was enough feature parity to replace nova-volumes as default
20:04:08 <anotherjesse> vishy is on the way
20:04:17 <ttx> From a release management perspective, the project hit its deadlines and followed the procedured, even if jgriffith is obviously still learning the ropes
20:04:22 <vishy> o/
20:04:39 <ttx> so no blocker from my release-management-hat side
20:04:50 <jbryce> jgriffith: could you give us a status update from your perspective?
20:04:52 <mtaylor> jgriffith talks to me, so CI is not unhappy
20:05:12 <jgriffith> jbryce: Yes, for the most part we're at feature parity
20:05:26 <jgriffith> jbryce: Remaining issues are availability zones and quota implementation
20:05:41 <jgriffith> jbryce: After that we have mostly the same bugs as Nova-V today :)
20:05:48 <jaypipes> jgriffith: can those be done by F3?
20:05:57 <jgriffith> jaypipes: Absolutely!!
20:06:06 <jaypipes> k
20:06:09 <jgriffith> jaypipes: We hit my goals for F2
20:06:14 <jaypipes> excellent.
20:06:15 <jgriffith> Remaining is slated F3
20:06:39 <jgriffith> May not get to the "new" features I had hoped for but...
20:06:46 * jaypipes has noticed an increase in coordination with dtroyer around devstack and cinder, which is great to see
20:07:00 <jbryce> anyone have other questions for jgriffith?
20:07:10 <jgriffith> dtroyer along with other folks have been very willing to help
20:07:28 <jaypipes> jgriffith: I'd like to see some more involvement between cinder folks and tempest team
20:07:36 <jaypipes> jgriffith: I'll email you about it.
20:07:39 <jgriffith> jaypipes: You got it
20:08:09 <johnpur> looks like the project is tracking and being managed well. jgriffith, what are your concerns?
20:08:22 <jgriffith> johnpur: time :)
20:08:39 <johnpur> lol, always
20:08:40 <jgriffith> johnpur: Really it's getting better, more folks becoming interested
20:08:49 <jaypipes> jgriffith: my final question is how have you been regarding coordination with annegentle and the docs team. that is an absolutely critical integration point IMHO considering the accelerated core promotion.
20:09:04 <johnpur> do we have POC installs that we trust?
20:09:05 <jbryce> jaypipes: +1
20:09:13 <jgriffith> jaypipes: I've chatted with anne a number of times....
20:09:27 <jgriffith> jaypipes: I have a lot of work to do there but I'm keeping in communication with her
20:09:33 <jgriffith> jaypipes: I have a plan for F3
20:09:36 <jaypipes> good to hear!
20:10:10 <johnpur> remind me... if cinder is pushed to core is nova volume deprecated? what is the plan?
20:10:12 <jaypipes> jgriffith: see johnpur's ? above... I agree would be cool to see some demo/POC envs for cinder
20:10:28 <jgriffith> johnpur: There's some debate on if/when that happens
20:10:31 <jaypipes> johnpur: no, shouldn't be. similar to Quantum, IIRC.
20:10:43 <jaypipes> johnpur: deprecated over the following release series, right?
20:10:45 <johnpur> so nova volume is being maintained?
20:10:51 <anotherjesse> jaypipes: actually we are hoping that we remove nova-volumes
20:10:54 <jgriffith> johnpur: correct
20:10:55 <anotherjesse> since the code was literally a cp -r
20:10:57 <jaypipes> oh, ok...
20:11:05 <jgriffith> johnpur: Maintained in terms of bug fixes yes
20:11:09 <anotherjesse> since otherwise we have to port between them
20:11:12 <jgriffith> johnpur: crtical features as well
20:11:22 <anotherjesse> hopefully we can just take the bugs in nova for volumes and move them to cinder
20:11:25 <anotherjesse> and they are relevant
20:11:33 <jaypipes> anotherjesse: well, if it *can* be a drop-in replacement, I suppose I could go along with that... if it truly is drop-inable by F3
20:11:43 * jaypipes adds drop-inable to Merriam Websters
20:11:45 <jgriffith> anotherjesse: currently I'm fixing any bugs in "both" and will continue to do so as long as feasible
20:11:51 <johnpur> anotherjesse, you seem to be disagreeing with jgriffith?
20:12:04 <anotherjesse> johnpur: yes, doing double work for literally the same code base doesn't add value
20:12:05 <vishy> I think we have to leave nova-volumes in for compatibility in Folsom, but mark it deprecated.
20:12:18 <johnpur> anotherjesse +1 if we can pull it off
20:12:19 <ttx> vishy: +1
20:12:47 <johnpur> vishy: that makes sense to me
20:12:51 <jaypipes> vishy: I actually thought that was the plan... am a bit surprised about the planned exorcism of nova-volume in Folsom.
20:13:07 <jgriffith> jaypipes: There was some concern raised from lunar team to me
20:13:17 <jgriffith> jaypipes: Being the new guy trying to keep people happy :(
20:13:19 <jaypipes> jgriffith: could you elaborate?
20:13:25 <johnpur> but that means that there is a level of maintenance that has to continue, at least until the code is deprecated
20:13:53 <ttx> I think we need to maintain both until the end of Folsom, and mark it deprecated there
20:13:55 * bcwaldon shows up late
20:14:11 <anotherjesse> so, what is the messaging?  do we recommend anyone uses nova-volumes?
20:14:13 <jgriffith> jaypipes: They're not likey to be ready to switch at F3, they are just asking to make sure we don't rip nova-v out
20:14:20 <jgriffith> jaypipes: which we wouldn't
20:14:39 <ttx> anotherjesse: no, we wuld recomment people use cinder fir volumes (and quantum for networking) in folsom
20:14:45 <jgriffith> jaypipes: But that means IMO that there is still some bug maintenance that has to be done, at least up until F3
20:14:49 <jaypipes> jgriffith: ok, I see. it seems you and anotherjesse need to discuss?
20:14:51 <johnpur> we cannot "force" everyone to move overnight
20:15:08 <jaypipes> jgriffith: or is it just a matter of timing?
20:15:11 * ttx should fix his keyboard
20:15:31 <jgriffith> jaypipes: I think it's timing more than anything.  TBH I think it's handled and not going to be a major issue
20:15:42 <jgriffith> I've had a number of talks with cthier about it
20:15:56 <jgriffith> anotherjesse: I'm not proposing full on support of both either
20:16:05 <jaypipes> jgriffith: k. so are we saying that n-vol will be deprecated through f3 and beyond, or removed?
20:16:14 <jgriffith> jaypipes: deprecated
20:16:22 * creiht bows
20:16:23 <creiht> :)
20:16:29 <jaypipes> k. I *think* anotherjesse was saying removed though :)
20:16:33 <jgriffith> jaypipes: I would propose removal in the H release
20:16:34 <jaypipes> creiht: afternoon!
20:16:47 <jaypipes> jgriffith: hmm... ok. not G?
20:16:59 <jbryce> let's hold on a minute
20:17:03 <jaypipes> k
20:17:06 <jbryce> sounds like we're digging into a separate issue
20:17:10 <jaypipes> yes
20:17:38 <jaypipes> jbryce: vote on cinder core promotion?
20:17:41 <jbryce> first, does anyone have any objections to cinder being core in folsom? then we can decide if we need to make a call on it's relationship to nova-volumes or if that's just up to the nova team to decide
20:17:45 <jbryce> jaypipes: exactly
20:17:57 <jbryce> #startvote Has cinder met the folsom-2 milestone requirements and should be included in the Folsom core release? yes, no, abstain
20:17:58 <openstack> Begin voting on: Has cinder met the folsom-2 milestone requirements and should be included in the Folsom core release? Valid vote options are yes, no, abstain.
20:17:59 <openstack> Vote using '#vote OPTION'. Only your last vote counts.
20:18:07 <jaypipes> #vote yes
20:18:09 <notmyname> #vote abstain
20:18:09 <ttx> jaypipes: don't believe everything anotherjesse says.
20:18:16 <anotherjesse> #yes
20:18:18 <jbryce> #vote yes
20:18:20 <danwent> #vote yes
20:18:21 <pvo> #vote yes
20:18:21 <johnpur> #vote yes
20:18:22 <heckj> #vote yes
20:18:23 <jk0> #vote yes
20:18:23 <ttx> #vote yes
20:18:24 <bcwaldon> #vote yes
20:18:30 <vishy> #vote yes
20:18:31 <jaypipes> quorum reached.
20:18:34 <anotherjesse> jaypipes: I dislike nova-volumes  it in G, but that is a different topic
20:18:47 <jbryce> anotherjesse: do you want to revote just to make yours count?
20:18:53 <anotherjesse> no
20:18:54 <jbryce> #endvote
20:18:55 <jaypipes> lol
20:18:56 <openstack> Voted on "Has cinder met the folsom-2 milestone requirements and should be included in the Folsom core release?" Results are
20:18:57 <openstack> yes (10): bcwaldon, johnpur, jbryce, vishy, heckj, jaypipes, jk0, ttx, danwent, pvo
20:18:58 <openstack> abstain (1): notmyname
20:18:59 <anotherjesse> my irc is really delayed
20:19:11 * koolhead17 looks around
20:19:14 * mtaylor too
20:19:50 <jaypipes> so it looks like that's settled... jbryce move on to ceilometer proposal?
20:19:58 <jbryce> so the second issue is what to do in relation to nova-volumes and the options seem to be rip out completely in F or deprecate in Folsom and remove in G (or H). is that correct? in
20:20:02 <ttx> anotherjesse: you should move to a 1st-world country.
20:20:25 <jgriffith> My vote is deprecated in Folsom
20:20:39 <vishy> anotherjesse is suggesting that we should delete it
20:20:41 <jaypipes> jbryce: I think we were just discussing the possibilities there... not sure the technical committee is needed to decide that? the PTL can/should be able to?
20:20:54 <ttx> I think it would be a bad message to send (and contrary to our lately-established practices) to deprected and rip in the same release
20:21:03 <creiht> ttx: ++
20:21:04 <johnpur> Deprecate in Folsom, remove in G seems logical
20:21:05 <ttx> deprecate*
20:21:08 <anotherjesse> jbryce: I don't like having the same code in two places… multiple places to fix bugs, we have to explain when to use one versus another
20:21:22 <vishy> ttx: who is going to commit to maintaining the nova-volumes code?
20:21:22 <anotherjesse> ttx: but it isn't a rewrite or a remove, it is a MOVE
20:21:30 <vishy> ttx: is that the cinder team?
20:21:39 * mtaylor agrees with anotherjesse
20:21:41 <creiht> it is effectively a remove though
20:21:48 <mtaylor> this is a reorg, not a rewrite
20:21:55 <ttx> anotherjesse: then it's not a question of deprecating.
20:22:08 <vishy> mtaylor: can the packaging issues be solved?
20:22:09 <jbryce> how much does it change the user experience though in terms accessing and using block storage?
20:22:20 <creiht> jbryce: a huge amount
20:22:23 <johnpur> anotherjesse: we should be recommending/pushing folks to Cinder in Folsom... Deprecation implies that the Volumes code will be static and not updated.
20:22:23 <jaypipes> jbryce: good question.
20:22:25 <anotherjesse> jbryce: we never had a release of a client or library that used the nova volumes extension
20:22:28 <jgriffith> I disagree with that
20:22:29 <vishy> jbryce: if they were using essex nova client it works exactly the same way
20:22:29 <mtaylor> anotherjesse: would it be possible to list cinder as a dep of nova, and replace nova-volume with a proxy shim?
20:22:32 <ttx> anotherjesse: it's a question of reorganizing, and we can do that in a single release alright. There is nothing being "deprecated"
20:22:44 <vishy> jbryce: or they can switch to cinder client.
20:22:45 <anotherjesse> ttx: yes, because in essex we had a VOLUME endpoint
20:22:51 <creiht> anotherjesse: python-novaclient uses nova columes
20:22:53 <creiht> volumes
20:22:54 <anotherjesse> and nova-client used the VOLUME endpoint
20:22:55 <mtaylor> vishy: I do not know what all of the packaging issues are
20:23:06 <anotherjesse> not the volume extension for COMPUTE
20:23:16 <creiht> mtaylor: I don't like that idea
20:23:33 <creiht> at one time it did use the volume extension
20:23:38 <vishy> creiht: it actually doesn't, the essex (and current release) uses /volumes
20:23:38 <creiht> before you guys just ripped it out
20:23:42 <anotherjesse> creiht: right, but it was never in a release
20:23:47 * creiht sighs
20:23:48 <anotherjesse> it was in the internal release ...
20:24:20 <vishy> creiht: so the only change is switching the endpoint in keystone
20:24:34 <creiht> I will just say that I think we set a very bad president if we make that drastic of change by removing nova-volume and only having cinder in the next release
20:24:49 <mtaylor> vishy: but I'm happy to go bang on figuring them out if I someone has a list
20:24:51 <creiht> from a client perspective that is correct vishy, but not from a provider perspective
20:25:03 <jaypipes> vishy: and what abvout the migration story... will volumes regiastered using nova-volumes work with cinder (and the vbolume endpoint) out of the box?
20:25:10 <anotherjesse> creiht: if the code is the same on both sides, how is it a different story?
20:25:12 <creiht> I'm about to release a whole set of infrastructure, and if you do this you will rip the carpet right out from under us
20:25:17 <jgriffith> jaypipes: yes
20:25:21 <jaypipes> jgriffith: k, thx
20:25:34 <vishy> creiht: if there is an upgrade path for packaging, is it still an issue?
20:25:36 <creiht> anotherjesse: it isn't exactly the same on both sides
20:26:01 <anotherjesse> creiht: elaborate?
20:26:05 <creiht> the code
20:26:11 <creiht> can't be exactly the same
20:26:18 <creiht> specifically for attach
20:26:26 <creiht> /detach
20:26:33 <creiht> either way
20:26:53 <creiht> you have a prescident of infrastructure for nova with nova-volumes that has already been a pain to track
20:27:08 <creiht> and now you are saying you want to rip the whole rug out from under the table
20:27:15 <anotherjesse> creiht: so for your internal project, just don't delete it?
20:27:15 <jbryce> is this different than if those changes were made in nova-volumes inside of the nova codebase?
20:27:17 <creiht> I don't think that is acceptable
20:27:29 <anotherjesse> creiht: rax has their own branches for this stuff right?
20:27:36 <creiht> nope
20:27:40 <vishy> creiht: since you're the advocate of keeping nova-volumes in, can you commit to helping keep it maintained
20:27:42 <creiht> not for volume
20:27:45 <creiht> we are tracking trunk
20:27:51 <creiht> as close as we can
20:28:08 <vishy> creiht: the main issue with leaving it in deprecated is it doubles maintenance for bug fixes
20:28:26 <vishy> creiht: and nova-core has already demonstrated that they don't really care about keeping that up-to-date
20:28:30 <ttx> creiht: so if I understand correctly, it's technically a move, but it affects you because you were expecting it not to chnage in Folsom release, is that right ?
20:28:44 <creiht> vishy: I understand, we will help where we can, but I can't promise to take over all maint
20:28:47 <jbryce> creiht: is deprecating in f and removing in g going to be better for you?
20:28:56 <jbryce> or is it still the same problem just later
20:29:02 <creiht> jbryce: I think that is very reasonable
20:29:09 <vishy> jbryce: it allows them to switch over at there leisure
20:29:15 <creiht> That gives providers time to adjust
20:29:15 <anotherjesse> what about leaving the code in there the deprecation means that we don't even release it....
20:29:19 <anotherjesse> if people want to notice it is there
20:29:22 <anotherjesse> then they can use it?
20:29:46 <jgriffith> anotherjesse: +1
20:30:00 <creiht> anotherjesse: define don't even release it
20:30:08 <anotherjesse> creiht: we don't have packages of it
20:30:24 <anotherjesse> and don't recommend that redhat, ubuntu or other distros/companies ship it
20:30:26 <vishy> I think we need to take this to the mailing list and see if we are causing anyone else pain
20:30:32 <jbryce> vishy: +1
20:30:35 <notmyname> I didn't think openstack provided any packages for anything
20:30:39 <mtaylor> we don't
20:30:40 <creiht> vishy: +1
20:30:49 <jbryce> i don't think this is a ppb call ultimately, but i think it's a worthwhile discussion to be had and the mailing list is a better place
20:30:53 <creiht> anotherjesse: I can't speak for everyone, but for me personally that wouldn't bother me
20:30:58 <jbryce> let's move on to ceilometer
20:31:00 <mtaylor> but we can do what anotherjesse said and recommend that redhat and ubuntu don't make packages for it
20:31:01 <johnpur> jbryce: agree
20:31:12 <jbryce> #option ceilometer incubation application
20:31:13 <vishy> my compromise would be to leave it in in the source tree for people building their own packages
20:31:18 <mtaylor> we _could_ filter it out from the source tarball
20:31:24 <vishy> and ++ mtaylor anotherjesse
20:31:25 <jbryce> #topic ceilometer incubation
20:31:29 <creiht> vishy: would you commit to continued bug fixing?
20:31:35 <jbryce> (reading and typing at the same time...)
20:31:39 <jbryce> http://wiki.openstack.org/Governance/Proposed/Ceilometer
20:31:58 <vishy> creiht: well hopefully there are no bug reports because no one is using it!
20:32:00 <vishy> :p
20:32:04 <ttx> jbryce: I'd say it's a cinder+Nova call, the PPb should only be involved if the decision creates issues... not to make the call
20:32:04 * creiht sighs
20:32:14 <vishy> creiht: I have no problem merging bugfixes
20:32:16 <jbryce> ttx: i agree
20:32:18 <creiht> lol
20:32:24 * creiht stands down
20:32:38 <jbryce> creiht: sighs and laughter?
20:32:49 <vishy> creiht: but I plan on immediately dumping the code, so it will have to be a backport from cinder i guess?
20:32:51 <anotherjesse> jbryce: incubation meaning that it is on the way to becoming core?
20:32:57 * ttx has been missing creiht sighing lately. happy to see you're back :)
20:33:11 <vishy> creiht: it would be ship folsom, remove code right after release
20:33:14 <jaypipes> anotherjesse: yes, the same meaning for incubation we've had for the past year :P
20:33:20 <creiht> vishy: if it is the same code, then why don't they share some *gasp* common codebase? so that they could share bug fixes?
20:33:26 <anotherjesse> jaypipes: right - just making sure :)
20:33:29 <jaypipes> :)
20:33:36 <vishy> creiht: craziness!
20:33:40 <anotherjesse> do we expect a metering project to be part of core?
20:33:41 <jaypipes> Are we on the Ceilometer topic?
20:33:45 <anotherjesse> I think so
20:33:55 <jaypipes> anotherjesse: I think that's what we're about to discuss.
20:33:57 <jbryce> yes...on the topic of ceilometer incubation...
20:33:58 <mtaylor> creiht: that's what I was suggesting earlier when I suggested making cinder a dep of nova and having nova/volume just be proxy calls to the cinder code, btw
20:34:02 <anotherjesse> (think that we are on the topic - I am not sure if metering should be core)
20:34:05 <creiht> vishy: I don't like that idea either, but will wait to see what the mailing list turns up
20:34:23 <vishy> creiht: ok. Am I on the hook for the email?
20:34:28 <jbryce> can we take the other discussion to the mailing list? or we can hit it again next week if we need to
20:34:45 <creiht> vishy: depends... do you *really* want the mailing list email from me? ;)
20:34:51 <jbryce> jgriffith: can you take point on sending a mailing list email out?
20:34:57 <jgriffith> jbryce: Yes!!
20:35:01 <jbryce> thanks
20:35:02 <creiht> jgriffith: thanks
20:35:05 <jbryce> CEILOMETER!
20:35:05 <creiht> :)
20:35:07 <jbryce> NOW!
20:35:08 <jbryce> = )
20:35:13 <vishy> jgriffith: talk with me offline
20:35:20 <jaypipes> nijaba: you're up. :)
20:35:21 <jbryce> ceilometer has applied for incubation
20:35:27 * nijaba is here :)
20:35:36 <jbryce> nijaba: would you like to give an overview of what you all are trying to build?
20:35:36 * dhellmann is here, too
20:35:52 <ttx> On Ceilometer, the application says, incubation in F, core in G: I think in all cases it would need to incubate longer than just one month (core projects for G need to be decided before the G cycle starts, which means somewhere in August)
20:36:08 <jaypipes> dhellmann: welcome.
20:36:16 <nijaba> so we are trying to collect all metering information from various projetcs so that billing system and others have a single point of contact to callect all info
20:36:21 <ttx> so we are talking incubation for the rest of F and for G, I think
20:36:29 <jbryce> ttx: i agree
20:36:50 * nijaba makes a note of it
20:37:00 <koolhead17> ttx, can`t extra effort make it possible to have metering in G ?
20:37:17 <soren> Just because it's not core doesn't mean it doesn't exist.
20:37:18 <vishy> the ceilometer team has been doing a great job of being open, using common code and practices, etc. I'm just not totally convinced that it needs to be a core project.
20:37:18 <ttx> koolhead17: it's not a question of effort, it's a demonstration that you can follow a cycle
20:37:25 <nijaba> koolhead17: having it != core
20:37:31 <anotherjesse> koolhead17: just because the project isn't core / incubated doesn't mean that it doesn't work
20:37:58 <ttx> koolhead17: doing just one milestone before an application sounds like an automatic rejection reason for me
20:38:09 <koolhead17> ooh okey
20:38:19 <dhellmann> vishy and anotherjesse, can you elaborate?
20:38:37 <jbryce> so we have 3 main infrastructure categories with compute, storage and networking. and then we have shared services like dashboard and keystone that make the other categories more unified and more easy to use. seems like metering is something that we get a LOT of requests for and could make sense in the shared services category
20:38:40 <nijaba> vishy: can you elaborate?  I would think it is a piece of code that most if not all deployment will need
20:38:51 <ttx> jbryce ++
20:39:11 <koolhead17> jbryce, ++
20:39:41 <vishy> nijaba: We've discussed limiting the scope of infrastructure to core IaaS services, metering seems to be right on the border
20:39:46 <johnpur> my reaction is that the ceilometer project should continue as they have, and the incubation discussion should be just before the G summit. If it makes sense, the project incubates in G and applies for core in H if it makes sense.
20:39:51 <anotherjesse> jbryce: although I can see it being that we have the hooks for it, and let various entities support it
20:40:09 <anotherjesse> an opensource project called ceilometer or a commercial product called FOO
20:40:19 <anotherjesse> johnpur: ++
20:40:24 <vishy> anotherjesse: I think the plan is to support multiple backends in ceilometer
20:40:28 <johnpur> in september we should have a good view on the metering project, and gives the community/mailing list time to react as well
20:40:43 <nijaba> anotherjesse: FOO would talk to ceilometer, but why have all FOO reimplement the hooks?
20:40:46 <ttx> johnpur: would be a valid objection if we were questioning their maturity... but apparently we are questioning the coreness of its scope..; and that can be answered today
20:40:54 <dhellmann> that's right, vishy: we won't be charging users, just collecting data
20:40:55 <vishy> but i don't know how well it would support commercial implementations
20:40:59 <anotherjesse> nijaba: because then it requires that everyone runs ceilometer ...
20:41:08 <jaypipes> johnpur: I don't think there's any reason not to start incubation in F (and continue incubation in G) if the PPB decides Ceilometer has the potential to be core.
20:41:12 <anotherjesse> nijaba: if you already have a metering system in place then you might want to use it
20:41:17 <johnpur> ttx: i am proposing delaying that determination, subject to more discussion
20:41:38 <vishy> jaypipes: yes, i think the question is do we reasonably see that ceilo fits in core
20:41:40 <heckj> nijaba: reading the roadmap - is there no public API to this in the folsom release?
20:41:43 <vishy> (at some point)
20:41:51 <ttx> johnpur: I think that's a bit unfair to them. We can determine the coreness of the matter now. Unless we prefer to punt to the TC
20:41:56 <nijaba> heckj: it's about to be done
20:41:57 <jaypipes> vishy: sure, that is a perfectly reasonable question.
20:41:58 <ttx> (which would be a valid thing)
20:42:06 <dhellmann> heck, we are starting work on the API in the next week or two
20:42:07 <vishy> jaypipes: if we say no now, I don't think it is no forever, but we could say lets let it stew a while longer.
20:42:08 <nijaba> heckj: before folsom is released
20:42:17 <jaypipes> vishy: sure, agreed.
20:42:29 <jbryce> i don't think that saying it's attacking a problem that could also be attacked by a commercial entity is necessarily the best argument since everything in openstack has commercial competitors
20:42:50 <johnpur> ttx: i don't get the attitude that if a project isn't in incubation/tracking to core that it isn't important?
20:43:02 <jbryce> and as nijaba said, from my understanding, it's more about centrally exposing data from the different projects which could be consumed by zuora or x commercial billing product
20:43:14 <nijaba> jbryce: exactly
20:43:16 <dhellmann> jbryce, that's right
20:43:26 <pvo> heckj: http://wiki.openstack.org/EfficientMetering/APIProposalv1
20:43:29 <koolhead17> jbryce, sounds good
20:43:41 <dhellmann> at dreamhost we are going to pull data from ceilometer and push it into our existing billing system
20:43:46 <ttx> johnpur: oh, no. By a bit unfair to them, I just mean, we make them wait and do extra efforts, which will not really help us determine the question of whether metring is core openstack or not
20:43:51 <nijaba> The project is for collecting resource usage data related to billing, but does not include any facility for recording customer billing details or actually charging customers or for transforming collected data into billing items
20:44:08 <johnpur> ttx: ok, ic
20:44:20 <jaypipes> As someone who vote no to Horizon being core (for reasons that I believed core projects to be the building blocks of the infrastructure), I've come to view Horizon as the critical piece of the OpenStack puzzle that it is: while it is not required for Openstack to function, it is the canonical reference implementation for a GUI. And if Ceilometer represents a canonical reference implementation for a metering project, I think it deserves to
20:44:21 <jaypipes> be incubated.
20:44:26 <anotherjesse> if ceilometer is incubated and becomes core, does that mean you *HAVE* to use it to be considered an OpenStack cloud (TM)
20:44:44 <ttx> johnpur: but yes, I can see how waiting could help us see how their API stabilizes and how well they become indispensable to the other projects
20:44:49 <mtaylor> anotherjesse: I'd say no more than horizon
20:44:59 <nijaba> anotherjesse: I woudl hope not
20:45:13 <jaypipes> anotherjesse: no. you don't require Horizon, but it's still a critical core reference implementation of a part of OpenStack
20:45:27 <bcwaldon> anotherjesse: can we say that being an OpenStack cloud (TM) is providing all published APIs?
20:45:30 <anotherjesse> jaypipes: while I'm almost the other way - horizon is critical but it confuses to have a GUI next to the service - I had voted yes originally ;)
20:45:33 <pvo> anotherjesse: how would you even test that? the others apis, horizion, etc would be easier to test for.
20:45:52 <pvo> i guess the ceiliometer api could be tenant facing
20:46:00 <jaypipes> anotherjesse: funny how time changes our opinions, eh? :)
20:46:00 <anotherjesse> I'm asking because I want to know what it means to be in core for ceilometer
20:46:13 <jbryce> currently we single out compute and storage apis as requirements for being "openstack", not the shared services
20:46:15 <nijaba> pvo: not at this point, but is considered for future versions
20:46:21 <dhellmann> pvo: it isn't clear to me that the ceilometer API needs to be tenant facing, but it could be
20:46:24 <anotherjesse> I hope that we can grow to have lots of projects that integrate with openstack but aren't core… I'm now pro-small-core ;)
20:46:29 <dhellmann> I mean in terms of providing features useful to tenants
20:46:32 <pvo> I would love to know my potential bill through an api
20:46:33 <jaypipes> anotherjesse: to me, "being core" means that the project prioritizies integration with the other core pieces of OpenStack.
20:46:49 <dhellmann> pvo: we don't know how much you might be charged, only how many resources you've used
20:46:57 <pvo> *potential*
20:47:01 <dhellmann> so the provider still needs to do some calculation to determine the bill
20:47:03 <pvo> the usage consumed is the important part
20:47:06 <koolhead17> anotherjesse, ask me how much horizon changes openstack. greatly :)
20:47:06 <nijaba> pvo: from roadmap: "End-User API access to own metering information"
20:47:18 <pvo> nijaba: totally agree
20:47:25 <anotherjesse> koolhead17: I know - I and my team has done a lot of work on it
20:47:27 <mtaylor> and usage consumed metering with an api seems like a useful thing to be consistent across implementations
20:47:30 <mtaylor> to me
20:47:43 <pvo> mtaylor: ++
20:47:45 <jbryce> core designation really has historically been around integration with other releases, coordinated cycles, a level of maturity and meeting a threshold of being generally useful to most openstack users
20:47:49 <koolhead17> anotherjesse, :)
20:48:02 <jaypipes> mtaylor: ++
20:48:09 <jaypipes> jbryce: ++
20:48:24 <koolhead17> jbryce, ++
20:48:53 <johnpur> also, core projects are packaged by our downstreams, with other projects added by picking and choosing
20:48:53 <anotherjesse> given that approving for incubation today won't mean it is in core by G, I like johnpur's originally idea of voting before the summit
20:49:03 <ttx> One thing to note is that the foundation would weigh in on the final core inclusion call anyway
20:49:12 <jbryce> ttx: good point
20:49:14 <ttx> (board of directors)
20:49:18 <jaypipes> anotherjesse: yes, that would be totally fine with me.
20:49:50 <ttx> so the question of "belonging to the scope of openstack" might end up being decided by them... while the TC vouches that the project is well ru and integrated with the others
20:49:54 <jbryce> i'm ok with deferring, but could we define what we are hoping to gain in the deferral period so we can make sure we act on it?
20:50:04 <jaypipes> jbryce: so shall we vote on whether to delay this incubation vote until September?
20:50:08 <jbryce> is it more feedback from the mailing list?
20:50:17 <jbryce> making sure it's taking a sane technical approach?
20:50:25 <jbryce> scope of openstack?
20:50:39 <anotherjesse> jbryce: I kinda feel like we should have a section in proposals of integration status and efforts with all existing core projects
20:51:06 * jaypipes thought we had that..
20:51:25 <ttx> basically its a bit of bad timing, with Folsom nearing the end and the future BoD/TC split
20:51:32 <johnpur> since the project is primarily about aggregating and making usage information available to a variety of downstream consumers (billing systems, etc.) it would be cool to get feedback fromt he potential consumers on the approach, API, etc.
20:51:52 <nijaba> anotherjesse: Nova integration is close to complete, and we have intiated dicussions with all other projects
20:51:59 <pvo> its on my list to evaluate, just haven't had time
20:52:19 <vishy> on the other side, there is no reason why we couldn't incubate it and later the TC can decide that it doesn't belong as a core project.
20:52:26 <jbryce> vishy: also true
20:52:35 <notmyname> but unlikely
20:52:45 <anotherjesse> nijaba: cool - I'm just thinking about the meta-process :)  that as we incubate things we should have an explicit section on what it means for all the projects - for instance nova has a notification queue, but what does it mean for keystone, or glance
20:52:49 <ttx> vishy: yes, that would be my preferred option
20:52:53 <ttx> notmyname: unlikely what?
20:53:01 <pvo> I don't see the need to vote today. The work is progressing and the decision will be reevaluated later.
20:53:15 <notmyname> ttx: unlikely that a vote today would be overturned by tomorrows PPB/TC
20:53:17 <dhellmann> anotherjesse, we are going to be working with the other projects to add notifications as needed
20:53:18 <jbryce> ttx: i think he's going off the track record that we've sent everything through incubation to core so far
20:53:18 <johnpur> pvo: +1
20:53:37 <dhellmann> anotherjesse, that is easier now that RPC and notifications are in openstack-common
20:54:05 <ttx> notmyname: right... I think there would actually be more risk that the BoD would turn down our suggestion as "not in their idea of openstack scope"
20:54:47 <jbryce> i think we should defer and try to gather a little more information
20:55:03 <notmyname> jbryce: to answer which question?
20:55:16 <heckj> I think we made a mistake with keystone, incubating it before it was ready to be used. I'd prefer to look about incubation *after* the project is fully operational rather than make a keystone-mistake again
20:55:18 <jbryce> nijaba: can you add a new section to the application and discuss the integration status with each of the other projects. that does seem key since it's a shared service
20:55:23 <ttx> and give Ceilometer time to prove they are actually an almost-indispensable companion to other core projects
20:55:26 <pvo> heckj: ++
20:55:35 <jbryce> heckj: i kind of agree. was actually thinking of that example
20:55:40 <nijaba> jbryce: k
20:55:40 <jaypipes> ++
20:55:59 <nijaba> #action nijaba to  add a new section to the application and discuss the integration status with each of the other projects. that does seem key since it's a shared service
20:56:00 <heckj> to be clear - I'm not against incubation at all, I'd ljust like to see the project mature before talking about it.
20:56:09 <vishy> +1 to delay
20:56:21 <jbryce> also, any information you can gather from users along the lines of what johnpur was mentioning would be useful
20:56:23 <ttx> heckj: like making a few milestones roughly around the core ones
20:56:47 <vishy> we shouldn't be too anxious to add new projects, it also gives us time to prove that projects can become healthy without having to be in core.
20:56:55 <nijaba> jbryce: who was your last remark addressed to?
20:56:59 <jaypipes> nijaba, dhellmann: a hint for your incubation future: if you haven't already, get with dtroyer on getting devstack to set up ceilometer so folks can more easily play around with it.
20:57:10 <jbryce> nijaba: you, sorry
20:57:12 <nijaba> jaypipes: noted
20:57:15 <vishy> I would like ceilo to be a success regardless of whether it s core.
20:57:36 <anotherjesse> vishy: ++++++
20:57:43 <jbryce> 2 minutes
20:57:45 <nijaba> jbryce: then I am afraid I have lost context :/
20:57:49 <johnpur> we have some largeish deployments that are using both commercial billing systems and homegrown ones that can provide some good feedback... if these guys weigh in with plans to utilize ceilometer this would be a big vote of confidence
20:57:57 <ttx> and I would like it to be core if the user crowd begs for it, which means it needs to be around a bit
20:58:01 <heckj> vishy: ++
20:58:14 <pvo> johnpur: exactly. I plan on taking a peek at it soon
20:58:18 <vishy> +1 to the devstack comment as well
20:58:25 <johnpur> right on, pvo
20:58:41 <jbryce> nijaba: did you see johnpur's last comment?
20:58:47 <nijaba> jbryce: yup
20:58:49 <dhellmann> johnpur, we got a lot of feedback from potential users when we designed the list of counters up front. is there something specific you would want us to ask now?
20:58:51 <johnpur> hint to the hp guys, you should look at how this might work with zuora
20:58:52 <ttx> (what johnpur said)
20:59:05 <pvo> dhellmann: I'll reach out soon.
20:59:15 <jbryce> dhellmann: maybe add some of that into the application as well so it's centrally available
20:59:25 <nijaba> johnpur: hp been looking at it closely, from the interactions we've had
20:59:27 <dhellmann> jbryce, ok, we can do that
20:59:34 <jbryce> thanks
20:59:39 <dhellmann> pvo, thanks, I'll watch for an email
20:59:55 <jbryce> ok. we're out of time. thanks everyone!
20:59:58 <jbryce> #endmeeting