20:03:34 <ttx> #startmeeting tc
20:03:35 <openstack> Meeting started Tue Feb 12 20:03:34 2013 UTC.  The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:03:36 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:03:38 <openstack> The meeting name has been set to 'tc'
20:03:43 <ttx> Agenda for today:
20:03:49 <ttx> #link http://wiki.openstack.org/Governance/TechnicalCommittee
20:04:07 <ttx> #topic Special motion on Incubation process evolution
20:04:16 <ttx> As discussed last week, we followed a bit of formality to make sure we were in line with the joint committee
20:04:31 <ttx> So we worked on with a set of changes to the incubation process and charter wording based on the work on the joint committee
20:04:39 <ttx> The joint committee approved that set and recommends that the TC now approves it
20:04:55 <ttx> It's the same text that was posted to openstack-tc and openstack-dev and didn't trigger any comment on any list afaict
20:05:00 <gabrielhurley> sorry I'm late
20:05:03 <ttx> np
20:05:09 <ttx> just warming up
20:05:15 <ttx> #link http://lists.openstack.org/pipermail/openstack-dev/2013-February/005421.html
20:05:18 <markmc> and it closely matches what the TC agreed back in november
20:05:25 <ttx> One important thing to note is that this motion doesn't prevent future changes as the joint committee makes further progress in defining "core" and the process around it
20:05:31 <markmc> i.e. the mandate for the TC reps on in the committee
20:05:37 <ttx> It just updates our process and texts to the current thinking so that we know how to proceed in the immediate future for projects currently in incubation
20:05:56 <ttx> This is a special motion since it requires wording changes to our Charter to introduce the concept of "Integrated" project
20:06:10 <ttx> So we need 9+ "Yes" for this to be approved
20:06:22 <ttx> Comments before we vote ?
20:06:26 <notmyname> yes
20:06:36 <gabrielhurley> is that a vote or a comment? ;-)
20:06:38 <notmyname> comment on item 6 in the email
20:07:22 <ttx> removal of the "TC recommends core" sentence
20:07:28 <notmyname> this removes the TC from involvement in what is considered "openstack", at least to the external world. currently the BoD takes input from the TC on this. this clause seems to remove that
20:08:03 <ttx> notmyname: So this point was raised because that would be the only place where "core" is mentioned in our charter
20:08:14 <ttx> once we replace other mentions by "integrated"
20:08:20 <markmc> we know the TC's involvement isn't going to be "the project is graduating, we recommend it for core"
20:08:27 <markmc> there will likely be some other involvement
20:08:34 <ttx> It doesn't make any assumption on how the core process will evolve
20:08:36 <markmc> maybe the BoD asking for our opinion on specific technical matters
20:08:49 <markmc> but we can add that to the charter later when we know what it should be
20:09:01 <ttx> yeah, we just don't know how much we'll be involved
20:09:03 <mordred> or - the BoD might come back with a core process that specifically empowers the tc in additional ways
20:09:16 <ttx> I'm fine with leaving that in... it's just inaccurate because we have no idea
20:09:47 <ttx> so I figured we should remove it to reflect the fac tthat we don't have any process defined for "core" yet
20:09:59 <ttx> rather thah leaving it in and imply we still have one
20:10:12 <annegentle> ttx: I wonder if you could just remove the word "Core" but still show the TC involvement in status changes
20:10:16 <ttx> What's the others opinions on that ?
20:10:34 <jaypipes> ttx: I'm fine with the removal of that sentence.
20:10:53 <jaypipes> ttx: per my change of heart wrt the whole pointlessness of the "core" label.
20:11:04 <markmc> I'd prefer it to be removed, but it's the least important part of the motion
20:11:16 <jgriffith> ttx: I'm fine with removing it as well for the same reasons noted by jaypipes
20:11:21 <ttx> annegentle: you mean "recommends projects for status changes" ? That would also be a bit presomptuous, but why not
20:11:36 <annegentle> ttx: aim high
20:11:52 <vishy> I'm fine with it being removed.
20:11:55 <gabrielhurley> ditto
20:12:07 <russellb> fine with me too
20:12:20 <mordred> ++
20:12:23 <annegentle> remove "Core" or the entire sentence?
20:12:25 <bcwaldon> +2
20:12:28 <ttx> I think it makes more sense to remove it and update that again when we know what the joint committee and the BoD want to do with "core"
20:12:40 <ttx> so I prefer to leave point 6 in, personally
20:13:02 <ttx> annegentle: the entire setence
20:13:12 <jaypipes> ttx: ++
20:13:15 <mordred> ++
20:13:27 <annegentle> ttx: I'm amenable to removing the whole sentence and update later
20:13:36 <ttx> OK, let's have a try at this, then
20:13:47 <ttx> any other comment before we vote ?
20:14:16 <jaypipes> pugs are awesome.
20:14:24 <ttx> #startvote Approve special motion on incubation process evolution? yes, no, abstain
20:14:25 <openstack> Begin voting on: Approve special motion on incubation process evolution? Valid vote options are yes, no, abstain.
20:14:26 <openstack> Vote using '#vote OPTION'. Only your last vote counts.
20:14:31 <jaypipes> yes
20:14:33 <markmc> #vote yes
20:14:33 <ttx> #vote yes
20:14:35 <russellb> #vote yes
20:14:35 <gabrielhurley> #vote yes
20:14:36 <jaypipes> #vote yes
20:14:37 <heckj> #vote yes
20:14:41 <jgriffith> #vote yes
20:14:44 <annegentle> #vote yes
20:14:51 <vishy> #vote yes
20:14:56 <mordred> #vote yes
20:15:17 <notmyname> #vote yes
20:15:39 <danwent> #vote yes
20:15:40 <bcwaldon> #vote yes
20:15:48 <ttx> 30 more seconds
20:16:19 <ttx> #endvote
20:16:20 <openstack> Voted on "Approve special motion on incubation process evolution?" Results are
20:16:21 <openstack> yes (13): markmc, bcwaldon, ttx, notmyname, vishy, annegentle, heckj, jaypipes, russellb, jgriffith, mordred, gabrielhurley, danwent
20:16:28 <markmc> wow
20:16:35 <heckj> heh
20:16:39 <ttx> awesome, so now the next agenda item doesn't look s oweird
20:16:45 <jgriffith> ha
20:16:49 <nijaba> hehe
20:16:50 <ttx> #topic End-of-cycle graduation review
20:17:30 <ttx> we can start with the end-of-cycle graduation review now. This needs to be completed before the end of the month.
20:17:39 <ttx> It was proposed that we could start with "Why we think we're ready" statements from Ceilometer and Heat
20:17:49 <ttx> Then a report on release cycle alignment progress
20:18:01 <sdake_z> http://wiki.openstack.org/Heat/Graduation
20:18:01 <ttx> Then assessments of technical stability and architecture maturity (probably next week)
20:18:16 <ttx> And finally a check of scope to ensure the complementarity we judged at incubation time is still present
20:18:30 <ttx> Anything more you'd like to see considered/discussed in that review process ?
20:19:38 <ttx> Note that the process might get influenced by future progress on the joint committee. Like if the BoD defines the outer limits of openstack and what we should be focusing resources on
20:20:06 <ttx> Is that process looking good for everyone ?
20:20:11 <markmc> yes
20:20:19 <gabrielhurley> +1
20:20:20 <heckj> good by me
20:20:22 <jgriffith> yup
20:20:52 <russellb> question on outer limits of openstack ... that putting bounds on what we can include in coordinated release?
20:20:56 <danwent> yes
20:21:11 <markmc> russellb, I don't think the BoD can do that
20:21:16 <markmc> russellb, it can recommend, but ..
20:21:21 <russellb> i didn't think so either
20:21:35 <ttx> russellb: That could happen, I think. They could say that "openstack" is not doing GMail clones
20:21:36 <russellb> just trying to interpret ttx's comment
20:21:56 <ttx> so a project that proposes that could be refused on that ground, maybe
20:22:12 <mordred> ttx: how about let's not spend a lot of time thinking about what might could be decided in the future
20:22:23 <jgriffith> mordred: +1
20:22:24 <russellb> k, i'm not actually worried, so we can move on
20:22:25 <ttx> yeah, that's a bit of astroturfing
20:22:39 <ttx> handling the present is hard enough
20:22:48 <ttx> #topic "Why we think we're ready", Ceilometer
20:22:55 <ttx> nijaba: floor is yours
20:22:58 <nijaba> for ceilometer it is at: http://wiki.openstack.org/Ceilometer/Graduation
20:23:11 <ttx> could you summarize for those who can't read ?
20:23:12 <nijaba> do you want me to copy paste?
20:23:29 <nijaba> yes, we think we are ready
20:23:58 <sandywalsh_> ugh, sorry
20:24:08 <nijaba> Robust multi purpose architecture recently extended to support multiple publishing channels, thus allowing ceilometer to become a metrics source for other tools apart from metering
20:24:08 <nijaba> Successfully passed the challlenge of being adopted by 3 related projects which have agreed to join or use ceilometer:
20:24:08 <nijaba> Synaps
20:24:08 <nijaba> Healthnmon
20:24:08 <nijaba> StackTach
20:24:09 <nijaba> Delivered Folsom within 2 weeks of release, prior to incubation
20:24:12 <nijaba> Successfully delivered the G2 milestone aligned with the overall project release cycle
20:24:14 <nijaba> Good integration with all core projects now, including Swift
20:24:16 <nijaba> Built up a diverse and sustainable core developer community, affiliated to multiple organizations
20:24:18 <nijaba> Followed openstack community best practices from the outset
20:24:20 <nijaba> Deployed at many sites
20:25:44 <notmyname> nijaba: is the goal of ceilometer to provide monitoring info or usage info (eg for billing)?
20:26:14 <nijaba> notmyname: used to be focused on metering, now expanded to metrics in general
20:26:41 <nijaba> that was a conclusion of the last summit
20:26:57 <nijaba> based on request from other project to not have to duplicate our efforts
20:27:14 <mordred> kk
20:27:27 <bcwaldon> nijaba: instantaneous metrics, or eventual?
20:27:52 <notmyname> nijaba: I ask because my understanding (could be incorrect) is that you seem to be doing metering, but promising usage. those have very different requirements
20:27:57 <nijaba> bcwaldon: eventual, each subscriber can set a frequency independentl of others
20:29:09 <gabrielhurley> You've got the statement "There are still some aspects of the architecture that are still emerging (such as database schemas for metadata/rich data and aggregation)" in that wiki page... could you talk a little about your schema and what you're facing since that's a significant challenge you've described?
20:29:10 <eglynn> "eventual" could equal a 60s measurement cadence for example
20:29:50 <sandywalsh_> bcwaldon: and instantaneous is possible with UDP notifiers that dragondm is working on (for statsd-like integration)
20:30:12 <gabrielhurley> sandywalsh_: nice. I was gonna ask about that too.
20:30:14 <nijaba> gabrielhurley: the question that is being discussed is regarding how we do indexing and what to index.  the content will not chnage
20:30:36 <ttx> sandywalsh: are you happy with ceilometer architecture now ? i.e. you won't make them rewrite everything over the H cycle ?
20:31:08 <ttx> I see StackTach is mentioned above
20:31:33 <sandywalsh_> ttx: I think we've identified the main areas of contention (metadata on metrics and how roll-ups will be done) ... we still need to pin down a solution, but CM is pretty flexible currently
20:31:46 <sandywalsh_> I can't imagine a radical fork-lift change
20:31:54 <ttx> sandywalsh: thx, good t oknow
20:32:33 <dragondm> BTW, bp for the udp notifications: https://blueprints.launchpad.net/oslo/+spec/lightweight-notifications-driver   I will be fleshing out the spec momentarily.
20:33:02 <ttx> OK, any more question on that "why we think we are ready" statement ?
20:33:04 <russellb> are there any "competing" projects at this point?  or is everyone happily working together?
20:33:36 <nijaba> I think we are all joined in a happy family ;)
20:33:37 * jaypipes would like to see better packaging and coordination with QA/Tempest
20:33:52 <russellb> nijaba: excellent
20:33:57 <mordred> I'd like to point out how happy I am at all of the cross-project collaboration via ceilometer
20:34:04 <notmyname> I'd like to hear more about the goals re monitoring vs billing
20:34:05 <ttx> jaypipes: we can cover that in the technical assessment later
20:34:10 <heckj> has there been any additions into tempest to do full integration testing at this point (or is that expected post graduation)?
20:34:11 <nijaba> jaypipes: point taken. we'll discuss the details offline?
20:34:13 <eglynn> jaypipes: distro-level packaging do you mean?
20:34:19 <jaypipes> eglynn: ya
20:34:24 <jaypipes> nijaba: yup, no worries.
20:34:36 <nijaba> jaypipes: distro packaging should be our concern?
20:34:48 <jaypipes> nijaba: working with the packagers...
20:34:52 <nijaba> I thought otherwise.  We just need to enable it
20:35:02 <nijaba> jaypipes: that we do quite a bit already
20:35:04 <mordred> I do not think that distro packaging is our concern
20:35:04 <vishy> notmyname: I don't thing "monitoring" has ever been a stated concern of ceilometer
20:35:06 <ttx> heckj: it's a bit of chicken-and-egg problem, like horizon integration
20:35:10 <eglynn> jaypipes: I'm working on Fedora packaging, zul has done work for deb/ubuntu
20:35:40 <notmyname> vishy: except that's what it's doing, from what I can tell
20:35:44 <jaypipes> eglynn: things like the mongodb dep, etc, and lack of folsom packaging are a concern.
20:35:46 <nijaba> and zigo is working on the debian pkg
20:35:50 <sandywalsh_> notmyname: and monitoring is a big bucket (is it just "watch" or "watch and react") ... I think the synaps guys are working on that front.
20:36:03 <heckj> is there a solid API that can be used to provide horizon (or other dashboard) support to the data store?
20:36:07 <ttx> vishy: I think they want to cover collecting monitoring data at this point
20:36:07 <eglynn> vishy: a goal though is avoid monitoring tools having to duplicate measurements already taken by ceilo
20:36:08 <nijaba> there are pkg for folsom on debian and ubuntu
20:36:52 <nijaba> heckj: yes, and their is an horizon plugin beeing developped by brooklyn shen
20:36:58 <heckj> nijaba: thanks
20:37:58 <nijaba> vishy: we don't want to do monitoring bu we want to allow collecting data for a monitoring tool as one of our publisher
20:38:12 <jaypipes> nijaba: don't mind me.... just being nit-picky, really...
20:38:33 <Daviey> jaypipes: It does seem all distro's are keen on it :)
20:38:59 <al-maisan> sandywalsh_: IMHO monitoring is typically watch, define thresholds and raise alarms, the react part is somewhere else..
20:39:08 <nijaba> vishy: thus avoiding duplication of collection, and avoiding to have to support everything through our metering db api
20:39:09 <jgriffith> nijaba: So is it accurate to say the intent is "data collection" and leave it at that?
20:39:21 <sandywalsh_> al-maisan: that's a reasonable perspective :)
20:39:23 <jgriffith> nijaba: The monitoring/billing etc debate is what's had me a bit confused
20:39:28 <jaypipes> al-maisan: ++
20:39:43 <nijaba> jgriffith: yes, with a possible extension to alerting
20:39:54 <jgriffith> nijaba: k, thanks
20:40:18 <sandywalsh_> jgriffith: RAX needs CM for SEC-compliant billing, it's our primary driver.
20:40:22 <ttx> OK, can we switch to Heat statement now, or are there more questions ? or questions unanswered ?
20:41:01 <eglynn> main focus of the ceilo core IMO is on data (measurement) acquisition ... many potential down-pipeline uses of that data of course
20:41:12 <nijaba> eglynn: right
20:41:16 <ttx> We can discuss scope and complementarity when we reach that point in the review
20:41:40 <heckj> ttx: I'm good
20:41:43 <ttx> though it's good for the ceilometer crew to know that's one of the hot zones
20:41:44 <sandywalsh_> eglynn: +1
20:42:13 <ttx> OK, let's examine Heat statement now...
20:42:16 <ttx> #topic "Why we think we're ready", Heat
20:42:20 <sdake_z> hi guys
20:42:29 <sdake_z> http://wiki.openstack.org/Heat/Graduation
20:42:34 <sdake_z> for those that dont like to click links :)
20:42:38 <sdake_z> We have followed the full OpenStack process for the entire G cycle
20:42:51 <sdake_z> Heat has been in development for about 11 months. Our developers have learned to follow the openstack workflow while implementing a pure OpenStack style implementation of orchestration during the G cycle.
20:42:56 <sdake_z> There are many people evaluating Heat for field deployments
20:43:02 <sdake_z> Several enterprises are waiting for a stable G release of Heat to begin deploying. Some of those folks such as HP are contributing blueprints and code to improve Heat's functionality.
20:43:09 <sdake_z> We have a growing user community
20:43:13 <sdake_z> The Heat IRC channel is growing rapidly and adding new developers. The mailing list traffic related to heat is increasing as well.
20:43:18 <sdake_z> Deployments want heat functionality
20:43:25 <sdake_z> Lots of folks want an easy way to wrap all of the great OpenStack APIs into one template format. We provide value for these deployments and speed up deployment and development times
20:43:30 <sdake_z> Developers are interested in Heat
20:43:34 <sdake_z> We have many blueprints scheduled for H submitted by community developers.
20:43:38 <sdake_z> We work with other core and non-core projects
20:43:47 <sdake_z> We currently work with all core projects including Nova, Cinder, Glance, Quantum, Keystone, Swift, and Horizon. We were an early adopter of Oslo, before it entered Nova or other projects. We also have interest in working well with Ceilometer and have contributed ideas and patches to implement some of our dependent functionality. Finally we are always looking for new projects to integrate with. An example of a new integration point
20:43:47 <sdake_z> is Moniker which had a blueprint for G cycle but was deferred to H because of maturity problems with Moniker client libraries.
20:43:50 <sdake_z> ok thats it ;)
20:44:49 <ttx> questions ?
20:46:08 <ttx> sdake: roughly, how much of the API features are actually exposed in the templates ? 20% ? 50% ? 80%
20:46:24 <ttx> 99% ?
20:46:37 <mordred> I didn't say it for ceilometere - but  it does apply to both projects ...
20:46:38 <sdake_z> well if you mean resources, I'd say we are at 90% - missing some quantum integration
20:46:47 <gabrielhurley> that summary makes things sound pretty rosy. what's still missing? what's challenging? I know y'all aren't done.
20:47:06 <ttx> gabrielhurley is the atheist non-believer
20:47:06 <mordred> heat and ceilometer both have been very responsive and self-sufficeient in CI/infra concerns
20:47:10 <gabrielhurley> ha
20:47:15 <heckj> heh
20:47:36 <nijaba> mordred: and the reverse has been true to... and we did stress you a bit lately
20:47:38 <sdake_z> gabrielhurley we currently implement cloudwatch, which is going I believe into ceilometer so that is a chunk of work that needs sorting out
20:47:58 <sdake_z> gabrielhurley the other point is our quantum integration which stevebaker is working on for g
20:48:23 <sdake_z> gabrielhurley some folks want a non cloudformation CDL (the template language) which we plan to take up in G if there is interest
20:48:38 <sdake_z> thats all I can think of at the moment
20:48:53 <gabrielhurley> looks like there are a large number of untriaged blueprints...
20:48:54 <sdake_z> heat usable today though with nearly all the infrastructure
20:49:02 <sdake_z> those aren't untriaged, they are g cycle
20:49:04 <jaypipes> sdake_z: plan to take up a non-CF CDL in G or H?
20:49:15 <sdake_z> sorry they are h cycle
20:49:22 <sdake_z> non-cf cdl for H
20:49:22 <jaypipes> ok
20:49:25 <sdake_z> sorry not g guys, h :)
20:49:29 <jaypipes> np
20:49:34 <gabrielhurley> figured that's what you meant
20:49:53 <sdake_z> cdl, untriaged blueprints -> h
20:50:11 <sdake_z> this is the normal model for projects, accept blueprints at beginning of cycle,then accept new set at beginning of next cycle
20:50:51 <gabrielhurley> so from your perspective Heat is basically solid where it is, and the future is just about adding additional functionalities people would like to see (e.g. all those blueprints)?
20:51:05 <sdake_z> yes, and sorting out cloudwatch
20:51:11 <gabrielhurley> got it
20:51:29 <sdake_z> cloudwatch not a major problem tho, it will end up somewhere just a matter of where
20:51:41 <sdake_z> community has decided ceil is place for that and I agree - just matter of  timing now
20:52:00 <gabrielhurley> and graduation ;-)
20:52:06 <ttx> sdake: so having both considered at the same time is actually a good thing
20:52:08 <sdake_z> agree ;)
20:52:10 <jaypipes> and documentation :)
20:52:12 <russellb> and there seems to be very good collaboration between ceilometer and heat, so that helps
20:52:17 <annegentle> jaypipes: +1
20:52:20 <gabrielhurley> jaypipes: docs? I've heard of those...
20:52:20 <nijaba> russellb: +1
20:52:24 <jaypipes> lol
20:52:27 * annegentle sobs
20:52:30 <ttx> OK ,if we don't have further question, I'll do the release management repotr today as well
20:52:39 * gabrielhurley feels bad for making annegentle cry
20:52:49 * annegentle recovers quickly
20:52:50 * jaypipes hands annegentle a tissue
20:52:54 <ttx> gabrielhurley: she never actually cries
20:52:57 <gabrielhurley> lol
20:53:01 <sdake_z> we will improve docs - could use a bit of coaching there tho
20:53:03 <annegentle> it seems like the API docs all point to AWS pages
20:53:30 <nijaba> sdake_z: force doc contrib along with any new feature/change
20:53:34 <annegentle> both projects will have to be on their toes with the wiki migration coming this weekend since quite a few docs are in there
20:53:39 <sdake_z> makes sense nijaba
20:54:11 <ttx> anything else before we do the release alignment report ?
20:54:12 <sdake_z> one last point which I should mention is we feel the security model of heat is rock solid as well
20:54:17 <sdake_z> something we have really spent alot of time on
20:54:20 <annegentle> and use DocImpact in commit messages
20:54:38 <annegentle> ttx: sure go ahead
20:54:39 <gabrielhurley> sdake_z speaking of... how do you get around issues of trust/delegation?
20:54:54 * ttx holds until that question is answered
20:55:19 <sdake_z> you mean where keystone requires admin to do something and the user only has some other privs like "demo"?
20:55:26 <heckj> yeah
20:55:46 <sdake_z> ya we haven't fixed that yet, that is a blueprint for h - what we would like is a "sudo" for keystone but that may be untenable
20:55:53 <sdake_z> definately a solveable problem though
20:56:06 <ttx> ok, moving on
20:56:09 <ttx> #topic Report on release cycle alignment progress
20:56:18 <ttx> Both projects were aligned to the common release process by grizzly-2.
20:56:27 <ttx> Ceilometer had last-minute issues that made it 4 days late, critical bugs that should probably have been spotted earlier... I don't think that would happen again
20:56:46 <ttx> grizzly-3 should be a good test, one week from now
20:56:54 <ttx> All in all, they are better integrated than Cinder or Keystone were at this point in their incubation cycle
20:57:12 <ttx> but we have higher expectations now, that's how you make progress :)
20:57:20 * jgriffith feels the sting
20:57:21 <bcwaldon> ttx: I'm not sure that's a fair argument ;)
20:57:23 <ttx> I don't foresee any issue on the release management side.
20:57:46 <ttx> Both PTLs and teams were reactive and accessible
20:57:51 <ttx> read: not in california
20:58:07 <bcwaldon> read: ttx is being a jerk
20:58:07 <danwent> haha
20:58:13 <rainya> hehehehehe
20:58:13 <ttx> questions on that front ?
20:58:16 <ttx> bcwaldon: hehe
20:58:46 <mordred> nope. I'm happy with both projects in that regard
20:59:09 <markmc> me too, both are doing a great job
20:59:10 <ttx> mordred: is infra happy with both as well ?
20:59:42 <heckj> bcwaldon: nothing unusual, really
20:59:56 <mordred> ttx: yup
21:00:09 * ttx cries now, to see if Jay will give him a tissue
21:00:17 <ttx> OK time is off
21:00:25 <ttx> We'll continue with technical review next week
21:00:42 <ttx> Thanks everyone !
21:00:42 * jaypipes hands ttx a hankie
21:00:49 * annegentle hands ttx a tissue
21:00:50 <sdake_z> thanks guys
21:00:54 <ttx> #endmeeting