21:00:07 <nijaba> #startmeeting Ceilometer
21:00:07 <nijaba> #meetingtopic Ceilometer
21:00:07 <nijaba> #chair nijaba
21:00:08 <nijaba> #link http://wiki.openstack.org/Meetings/MeteringAgenda
21:00:09 <openstack> Meeting started Wed Oct 24 21:00:07 2012 UTC.  The chair is nijaba. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:00:10 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:00:11 <openstack> The meeting name has been set to 'ceilometer'
21:00:13 <openstack> Current chairs: nijaba
21:00:17 <nijaba> Hello everyone! Show of hands, who is around for the ceilometer meeting?
21:00:18 <nijaba> o/
21:00:20 <dhellmann-afk> o/
21:00:22 <eglynn> o/
21:01:00 <asalkeld> hi
21:01:19 <nijaba> ok, let's start
21:01:23 <nijaba> #topic actions from previous meeting
21:01:23 <nijaba> --> skipping that topic as all action were completed prior to release
21:01:34 <nijaba> #topic Ceilometer is now an incubated project
21:01:40 <eglynn> w00t!
21:01:44 <nijaba> Congratulations to all of us, Ceilometer was accepted as an incubated project at the first official TC meeting last night.  That's really a great news, but with incubation also comes new responsabilities: we need to adhere to milestone release, and at the latest the Grizzly-3 milestone.
21:01:44 <asalkeld> well done
21:01:56 <nijaba> #link http://wiki.openstack.org/GrizzlyReleaseSchedule
21:02:04 <nijaba> As you can see, that's Feb 27th, or 3.5 month away.  Better get organized soon and define our priorities right...
21:02:35 <dhellmann> I made a list of some suggested items at the bottom of http://wiki.openstack.org/EfficientMetering/RoadMap based on what I remembered from the summit
21:02:41 <dhellmann> I'm sure there are more items to add to the list
21:03:23 <nijaba> dhellmann: I was about to suggest, in the next topic, to have one volunteer per session to scrub the notes and add bugs and items to the roadmap
21:03:45 <nijaba> would that make sense?
21:03:53 <dhellmann> sure
21:03:58 <asalkeld> yip
21:04:17 <nijaba> we could then work on prioritization during the next meeting
21:04:26 <dhellmann> that sounds like a good idea
21:04:27 <eglynn> sounds like a plan
21:04:47 <dhellmann> should we set up an etherpad for drafting, and then move it to the wiki when we're happy?
21:05:01 <nijaba> dhellmann: that could work nicely, indeed
21:05:11 <dhellmann> ok, I'll set that up, starting with a copy of the wiki page
21:05:28 <nijaba> #link https://etherpad.openstack.org/grizzly-ceilometer-actions
21:06:20 <nijaba> #agreed use https://etherpad.openstack.org/grizzly-ceilometer-actions to capture actions from the summit sessions
21:06:53 <nijaba> so, we had 4 sessions
21:07:19 <nijaba> #link http://etherpad.openstack.org/grizzly-ceilometer-state-of-metering
21:07:19 <nijaba> #link http://etherpad.openstack.org/grizzly-ceilometer-customizing
21:07:19 <nijaba> #link http://etherpad.openstack.org/grizzly-ceilometer-beyond-metering
21:07:19 <nijaba> #http://etherpad.openstack.org/ceilometer-design
21:07:27 <nijaba> #link http://etherpad.openstack.org/ceilometer-design
21:07:41 <nijaba> who wants to cover which?
21:07:53 <nijaba> please feel free to #action yourself
21:08:39 <krtaylor> hi everybody, sorry joining late
21:08:54 <dhellmann> #action dhellmann review state-of-metering notes for roadmap items
21:09:09 <DanD_> I am on as well
21:09:32 <jd__> hi
21:09:38 <eglynn> #action eglynn distill roadmap items from ceilometer-design
21:09:49 <asalkeld> I am looking at "plugins for places to send counters from agents"
21:09:50 <nijaba> #action nijaba scrubs http://etherpad.openstack.org/grizzly-ceilometer-customizing
21:10:18 <dhellmann> asalkeld: I saw that you posted a link to a repo on github this morning, but haven't had a chance to look at the code yet
21:11:08 <asalkeld> yea just a sand pit to plan in
21:11:08 <nijaba> anyone wants to scrub grizzly-ceilometer-beyond-metering?
21:11:25 <asalkeld> that will probably be me
21:11:59 <jd__> nijaba: anything
21:12:09 <nijaba> first to use #action wins ;)
21:12:28 <jd__> #action jd__ scrub grizzly-ceilometer-beyond-metering
21:12:36 <nijaba> nice
21:13:13 <dhellmann> asalkeld: jd__ , nijaba, and I discussed a slight change to the Counter class in https://bugs.launchpad.net/ceilometer/+bug/1070857 earlier today
21:13:14 <uvirtbot> Launchpad bug 1070857 in ceilometer "set default source to something meaningful" [Low,Triaged]
21:13:19 <nijaba> #action everyone should feel free to complete our reviews of action on https://etherpad.openstack.org/grizzly-ceilometer-actions
21:13:36 <DanD_> I would volunteer but with my tenuous grasp on where things are at I would probably cause more damage than good
21:13:42 <asalkeld> so what was the intension of source
21:14:07 <nijaba> asalkeld: to capture where the identity can be resolved
21:14:09 <eglynn> asalkeld identify the orgin
21:14:10 <dhellmann> nijaba: should we get someone to go through https://etherpad.openstack.org/grizzly-ceilometer-actions to mark completed items done (or just remove them)?
21:14:25 <nijaba> dhellmann: +1
21:14:28 <eglynn> s/orgin/origin/
21:14:35 <asalkeld> so like the project name?
21:14:44 <asalkeld> volume/compute
21:15:04 <eglynn> I would think more like metering versus metrics etc.
21:15:05 <dhellmann> asalkeld: nijaba suggested the keystone endpoint or similar *specific* place to look for project/account info
21:15:14 <nijaba> asalkeld: I was thinking of the keystone API url
21:15:24 <dhellmann> I like the idea of something shorter, though
21:15:25 <nijaba> asalkeld: or something else
21:15:33 <asalkeld> ok
21:15:35 <dhellmann> maybe we could have a registry of short names to more details
21:15:41 <dhellmann> this obviously needs more thought :-)
21:15:51 <jd__> but as I pointed out, a keystone proposing several isolated regions does not help as a source
21:15:52 <asalkeld> so cloudwatch has NameSpace
21:15:55 <nijaba> the idea being that other project running on top of openstack could use another identity provider
21:16:08 <asalkeld> we could have OS/cinder
21:16:33 <asalkeld> or user data could have
21:16:40 <nijaba> actually, anything that uses keystone as an IDP should have the same source
21:16:42 <asalkeld> user/user_id
21:17:01 <nijaba> actually, anything that uses *THE SAME* keystone as an IDP should have the same source
21:17:29 <jd__> nijaba: even if for examplesinstances are from different nova? how do you know which nova the resource id is tied to?
21:17:31 <dhellmann> so source is tied to the user_id/project_id fields, not the meter name, volume, or resource?
21:17:31 <eglynn> asalkeld: the other option would just re-use the AWS namespaces
21:17:49 <eglynn> (given that say the nova EC2 largely apes the EC2 naming schemes)
21:17:50 <nijaba> but if one uses ceilometer to meter, let's say openshift, which could use another IDP, then the source  should be different
21:18:05 <nijaba> dhellmann: yes
21:18:32 <dhellmann> nijaba: ok, that makes sense. so we may need to add something to handle the idea of "namespace" in AWS/CW
21:18:39 <asalkeld> nijaba, then this is really trusted/not-trusted?
21:19:07 <jd__> but why the IDP?
21:19:17 <nijaba> asalkeld: no, just a way to have ceilometer be extended to other projects outside of openstack without risking collisions
21:19:57 <dhellmann> so instead of "source" we probably should have called that field "id_source"
21:20:14 <nijaba> dhellmann: that would work
21:20:17 <dhellmann> jd__: what is "IDP"?
21:20:23 <jd__> dhellmann: keystone
21:20:27 <jd__> identity provider
21:20:30 <nijaba> if you guys think that I am not smoking crack with this, that is
21:20:47 <dhellmann> jd__: thanks
21:20:54 <asalkeld> dhellmann, we could just make a long name "os.cinder.<name>"
21:21:02 <jd__> well, I don't think keystone is the best choice here because you can only link user and project id on this
21:21:27 <jd__> if you use something unique among a region for example, you can link to the right nova cluster, and to the right keystone
21:21:30 <dhellmann> asalkeld: that works. We're doing something like that for our router stuff "akanda.bandwidth.in.bytes"
21:21:36 <jd__> which is far better for tracability
21:21:52 <asalkeld> just requires consistency
21:22:03 <nijaba> jd__: I am very open.  I just want to avoid future collisions
21:22:13 <dhellmann> jd__: I don't like the idea of embedding the URL in the meter, but having a reference to something that the API knows about makes sense
21:22:23 <jd__> nijaba: that, I agree :)
21:22:28 <jd__> dhellmann: which API?
21:22:40 <nijaba> user: aaa might be a very different person for project a and b
21:22:42 <dhellmann> the ceilometer api
21:22:50 <dhellmann> so we would register sources with a name, URL, and maybe other metadata then the counters would just have the short name in them
21:22:51 <dhellmann> that
21:22:52 <dhellmann> wa
21:23:00 <dhellmann> that way if the url changes, the old meter data is still valid
21:23:08 <jd__> dhellmann: that I'd prefer
21:23:14 <nijaba> dhellmann: +1
21:23:34 <jd__> dhellmann: you want to be able to export metadata from a source IIUC?
21:23:39 <jd__> s/form/for/
21:23:46 <jd__> (via a configuration file or something)
21:24:08 <dhellmann> I think the use case is that a client of the ceilometer API needs to be able to map the user/project for a meter to a user/project in another system
21:24:23 <dhellmann> for the DUDE we are doing that using our own database, updated when a DreamCompute user is created
21:24:30 <jd__> + resource ID
21:25:11 <dhellmann> if we start using ceilometer to meter DreamObjects, which has its own account info already, we would say the source is "DreamObjects" and stick a URL there to look up the project_id to get a DH account id (like we have for DreamCompute)
21:25:32 <nijaba> dhellmann: exactly!
21:25:34 <jd__> dhellmann: ok, makes sense to me
21:25:39 <dhellmann> that way ceilometer doesn't have to care about who owns what, but clients can always look at a resource owner and work back to the account that should be charged
21:25:50 <jd__> dhellmann: I just don't want to have only the link to the IDP in the source, we need an indirection level
21:25:57 * dhellmann *finally* understands this after talking to nijaba about it 1/2 dozen times
21:26:05 <jd__> better late than never :)
21:26:06 <dhellmann> jd__: exactly
21:26:14 * nijaba feel sorry for not expressing this better
21:26:29 <jd__> ok, so I'll propose I'll update the bug and will try to implement that
21:26:37 <eglynn> is it fragile to embed a (presumably mutable) URL in the meter?
21:26:47 <eglynn> why not just a region identifier (and find the actual URL is say config)?
21:27:01 <jtran> eglynn:  +1
21:27:03 <nijaba> eglynn: this what dhellmann and jd__ are now proposing
21:27:04 <jd__> eglynn: that's sort of what we're talking about, but at larger scale
21:27:15 <dhellmann> eglynn: yes, the idea now is to let ceilometer (optionally) register a source "name" and "details" of some sort (to be worked out later)
21:27:16 <dhellmann> 
21:27:17 <dhellmann> e me
21:27:18 <dhellmann> er
21:27:19 <dhellmann> ou
21:27:21 <jd__> eglynn: region is openstack specific, dhellmann wants to use it for non-openstack projects :)
21:27:23 <dhellmann> the meter would include just the name
21:27:31 <DanD_> by config you mean in the database or something seperate?
21:27:37 <eglynn> a-ha, gotcha
21:27:42 <jd__> DanD_: yup
21:27:57 <dhellmann> DanD_: I was thinking the db, but we could just as easily use a simple config file for this
21:28:05 <dhellmann> in fact, for the first version, maybe that's all we need
21:28:14 <DanD_> that aligns well with a email I just sent to the mailing list concerning the need for additional meta data in the data model
21:28:34 * dhellmann took a sick day today and hasn't kept up with email
21:28:55 <DanD_> dhellman: basically what we discussed at the summit
21:28:55 <jd__> didn't had a chance to read it neither yet
21:29:04 <nijaba> so I guess the action on this is for jd__ to propose an implementation and wait for our comments?
21:29:14 * nijaba neither
21:29:20 <jd__> agreed
21:29:32 <dhellmann> +1
21:29:42 <eglynn> DanD_ old or new dev list?
21:29:43 <nijaba> #action  jd__ to propose an implementation for source and wait for our comments
21:29:55 <jd__> eglynn: just saw on old I think
21:29:59 <eglynn> k
21:30:12 <nijaba> confirmed
21:30:17 <DanD_> probably the old one
21:30:27 <nijaba> sent 20 min ago
21:30:45 <eglynn> cool, I see it now
21:30:47 * eglynn wishes we just had one list ...
21:30:58 <eglynn> (old one is v. slow ...)
21:31:45 <dhellmann> the state-of session didn't generate a lot of action items for grizzly, so I've added them to https://etherpad.openstack.org/grizzly-ceilometer-actions
21:33:09 <nijaba> ok. so now that we are a bit more organized to prepare our prios for next week, should we change topic, or are we missing anything on that subject?
21:34:11 <dhellmann> +1
21:34:52 <nijaba> #topic Change of project scope
21:34:52 <nijaba> As you may know, we agreed during the summit to change the project scope to "The project aims to become the infrastructure for all measurements within OpenStack. "
21:35:28 <nijaba> it seems that one of the remark we got from the TC, was that this maybe a little too broad
21:35:31 <eglynn> nijaba: weak push-back on that from the TC yesterday?
21:36:02 <dhellmann> perhaps we did not clearly differentiate between collecting the data and analyzing it?
21:36:18 <nijaba> dhellmann: I think that is a very good point
21:36:20 <dhellmann> for example, one goal is to eliminate duplicate agents collecting the same data
21:36:30 <asalkeld> monitoring and metering?
21:36:31 <nijaba> yes
21:37:07 <dhellmann> when I talked to Vish about collecting info for the scheduler, I pointed out that we might just send the data from our agent to something else to hold on to it and let the scheduler ask questions, since our API wasn't really organized to answer the question the scheduler has
21:37:20 <dhellmann> however, that same information could be useful for general health monitoring
21:37:38 <dhellmann> so if the agent sent it in a generic way, it could be consumed by other apps
21:38:04 <jd__> can't we also enhance the API to satisfy the scheduler?
21:38:11 <jd__> if that's not too complicated
21:38:19 <eglynn> so there's always the presumtion that users are free to their own off-line analytics over the caputured data, no suggestion tha ceilo is prescriptive about that, right?
21:38:52 <dhellmann> jd__: sure, that's possible, I don't know what sorts of questions it asks or how we could frame them
21:38:57 <jd__> I dont't think we ever wanted to block anybody doing anything
21:39:06 <nijaba> so proposing "The project aims to become the infrastructure to collect all measurements within OpenStack so that no two agent would need to written to collect the same data.  It's primary targets are monitoring and metering, but the framework should be easily expandable to collect for other needs."
21:39:08 <jd__> dhellmann: me neither (:
21:39:12 <dhellmann> eglynn: it has always been my goal to make any piece of ceilometer swappable/replacable/optional
21:39:24 <dhellmann> nijaba: I like that wording.
21:40:04 <jd__> do we talk about storage too? I mean ceilometer collect, and stores also
21:40:05 <dhellmann> nijaba: we could say something explicit about sharing collected data with a variety of consumers
21:40:17 <jtran> does that mean there will still be a "heat", and a "stachtach" , etc, but they would simply be the analytical tools only and then would rely on ceilometer for the measurements?
21:40:21 <eglynn> like the wording, though maybe the 'all' in 'all measurements' is a tad exclusive?
21:40:32 <jd__> jtran: I think that's the plan indeed
21:40:37 <jtran> whew
21:40:56 <jtran> it'd be ugly otherwise , imo
21:41:05 <asalkeld> I am ok with that
21:41:10 <jd__> ok, not sure what 'wheh' meant :]
21:41:17 <jd__> s/h/w/
21:41:22 <jtran> whew, like as in a relief
21:41:27 <dhellmann> jtran: yes, although some of what tach reports requires instrumenting beyond an agent
21:42:03 <nijaba> so proposing "The project aims to become the infrastructure to collect measurements within OpenStack so that no two agent would need to be written to collect the same data. It's primary targets are monitoring and metering, but the framework should be easily expandable to collect for other needs. To that effect, ceilometer should be able to shar collected data with a variety of consumers"
21:42:03 <asalkeld> dhellmann, well the instrumentation code can go in oslo
21:42:03 <eglynn> how about something slightly softer, e.g. '... the primary infrastructure for collecting measurements ...'
21:42:16 <dhellmann> asalkeld: that would make sense
21:42:29 <eglynn> actually cool, dropping the 'all' is sufficient
21:42:30 <dhellmann> nijaba: "no two agent" -> "no two agents"
21:42:51 <dhellmann> "shar" -> "share"
21:43:21 <dhellmann> otherwise, +1
21:43:25 <jtran> one of my coworkers asked, well what's the diff between 2+ agents, since having an agent other than standard nova-compute is already "having 2 agents"
21:43:39 <nijaba> new try: "The project aims to become the infrastructure to collect measurements within OpenStack so that no two agents would need to be written to collect the same data. It's primary targets are monitoring and metering, but the framework should be easily expandable to collect for other needs. To that effect, ceilometer should be able to share collected data with a variety of consumers"
21:44:04 <nijaba> shall we vote?
21:44:17 <jd__> +1
21:44:21 <asalkeld> grr, keep pushing "ctrl-r" == disconnect
21:44:23 <eglynn> jtran: idea would be to avoid say 2 separate agents polling the hypervisor on the cimpute node
21:44:23 <jtran> +1
21:44:32 <eglynn> +1
21:44:41 <nijaba> #vote agree on new project objective statemment? yes, no, abstain
21:44:50 <nijaba> #startvote agree on new project objective statemment? yes, no, abstain
21:44:51 <openstack> Begin voting on: agree on new project objective statemment? Valid vote options are yes, no, abstain.
21:44:52 <openstack> Vote using '#vote OPTION'. Only your last vote counts.
21:44:58 <nijaba> #vote yes
21:44:58 <eglynn> yes
21:44:59 <jd__> #vote yes
21:45:01 <asalkeld> #vote yes
21:45:04 <dhellmann> #vote yes
21:45:04 <jtran> eglynn:  agreed but i think what he was getting at is that ideally if ceilometer was in incubation and instead core, it would make sense to not have any +1 agents and instead to fold it into nova-compute
21:45:04 <eglynn> #vote yes
21:45:07 <DanD_> #vote yes
21:45:18 <eglynn> jtran: gotcha
21:45:28 <nijaba> waiting 30s
21:45:32 <asalkeld> bbl : I have to take kids to school
21:45:33 <jd__> jtran: we all hope this time will come :-)
21:45:42 <krtaylor> #vote yes
21:45:51 <eglynn> jtran: I suspect over time it will evolve in that direction anyway
21:46:05 <eglynn> jtran: yep, what you said ;)
21:46:06 <nijaba> #endvote
21:46:07 <openstack> Voted on "agree on new project objective statemment?" Results are
21:46:08 <openstack> yes (7): krtaylor, DanD_, jd__, nijaba, eglynn, asalkeld, dhellmann
21:46:15 <nijaba> cool
21:46:22 <jd__> isn't it
21:46:40 <nijaba> ok, last topic
21:46:50 <nijaba> #topic open discussion
21:47:20 <nijaba> #action nijaba to update project objective on relevant pages
21:47:25 <jtran> i meant to vote yes on the above, my bad.
21:47:54 <nijaba> jtran: np
21:48:38 <jd__> anything?
21:48:54 <jtran> yes, one sec
21:48:58 <jd__> ah :)
21:48:59 <jtran> when are the new meeting times?
21:49:11 <jd__> I think we're back on the double schedule
21:49:21 <nijaba> jtran: http://wiki.openstack.org/Meetings/MeteringAgenda
21:49:35 <jtran> ok thx
21:49:42 <nijaba> jd__: yes, as asalkeld is back from vacation
21:50:11 <jd__> I'm glad summer time ends
21:50:21 <eglynn> jd__ I hear ya ;)
21:50:23 <krtaylor> has the tasks on https://etherpad.openstack.org/ceilometer-design from summit been discussed?
21:50:48 <eglynn> krtaylor: I was going to distill into roadmap items
21:50:56 <eglynn> do you have input?
21:50:57 <nijaba> krtaylor: not yet, we will do this during the next meeting
21:51:04 <mordred> hey guys - we should coordinate a gerrit namespace change for you at some point, yeah?
21:51:22 <dhellmann> hi, mordred, yeah it seems like doing that sooner rather than later would be a good idea
21:51:28 <nijaba> mordred: to specify "incubated"?
21:51:41 <dhellmann> we get to move from "stackforge" to "openstack" right?
21:52:00 <eglynn> yep joining the big boy's club :)
21:52:57 <eglynn> probably should do that sooner rather than later, to underscore the change in project status
21:53:16 <dhellmann> mordred: what do you need from us for that? just hold off on committing for a period of time?
21:53:54 <jd__> do we need to approve what's in the queue now before?
21:55:20 <dhellmann> while we wait, another topic: As one outcome of the WSGI session at ODS I was supposed to build a "real" API server using the tools I proposed. I would like to use the ceilometer API server as the first example. The new tools have better Python 3 support and would give us XML output "for free". Does anyone object in principle to moving away from Flask to Pecan and WSME?
21:55:37 <nijaba> mordred seems to have let us hanging?  Who feels like chasing him later today?
21:56:05 <nijaba> dhellmann: no opposition from me
21:56:22 <eglynn> dhellmann: have at it!
21:56:30 <dhellmann> I will, of course, put the code up for review
21:56:31 <jd__> dhellmann: sounds good
21:56:34 <mordred> sorry
21:56:44 <mordred> and yes - from stackforge to openstack
21:57:02 <mordred> shall we try to do that this week?
21:57:13 <nijaba> mordred: do we need to clear the review queue?
21:57:13 <jd__> I think so
21:57:14 <jtran> dhellmann:  if we use flask, and nobody else in openstack core are using it, wouldn't that create an issue if and when we get out of incubation to core?
21:57:16 <eglynn> dhellmann: it would be great to have that proven out before we start craft any new services (e.g. a CW-api, if needed)
21:57:18 <mordred> (also, I prefer anything with better python3 support)
21:57:21 <dhellmann> what do you need from us to make it go smoothly?
21:57:29 <mordred> nijaba: I do not believe so - I believe we can do a project rename ...
21:57:45 <dhellmann> jtran: moving *away* from flask to the tools I proposed for new api development
21:57:47 <mordred> but it's going to be mildly wonky from the perspective of the devs
21:57:54 <nijaba> mordred: then I think it really is whenever you feel like it then, the sooner the better
21:57:57 <mordred> because the upstream remote will change
21:57:59 <mordred> cool
21:58:00 <jtran> whoops yes, i meant pecan, if nobody else using it..
21:58:06 <dhellmann> jtran: so this is the proof-of-concept work (and we're already using tools no one else is using)
21:58:10 <jd__> mordred: not a big problem :)
21:58:22 <mordred> I have several project create things with gerrit I need to do this week, I'll try to batch them up and get them all done
21:58:35 <jd__> mordred: thanks, ping us if you need anything
21:58:35 <mordred> who is the best person to ping when I'm ready to roll?
21:58:40 <jtran> dhellmann: from that summit session it didn't sound like the other guys were too enthused about moving away from their custom wsgi
21:58:46 <jtran> but i'm all for pecan otherwise
21:58:47 <jd__> mordred: me or dhellmann or nijaba
21:58:57 <mordred> jd__: awesome
21:59:01 <jd__> mordred: we're on #openstack-metering
21:59:07 <nijaba> mordred: agree with jd__ suggestion
21:59:24 <dhellmann> +1
22:00:07 <nijaba> not sure if there is another meeting afterward, but we are out of official time
22:00:11 <dhellmann> jtran: they want proof that something different will make a difference. there were some other sessions on validation and serialization where the idea was met a little more warmly
22:00:21 <jtran> that makes sense
22:00:39 <jtran> that's right you now reminded me, that 'test case' they wanted for api on nova 'create' instance.
22:01:08 <dhellmann> jtran: right, but I want to work on something I'm familiar with first :-)
22:01:23 <jd__> so we provide first case for incubation/core, and soon first case for wsgi replacement
22:01:28 <dhellmann> nijaba: do we need to wrap up?
22:01:29 <dhellmann> j
22:01:30 <dhellmann> d
22:01:35 <jtran> good move.  the contrib exts for the nova api is scaaaary
22:01:38 <dhellmann> jd__: and for subscribing to notifications
22:01:45 <jd__> dhellmann: yeah :)
22:01:58 <dhellmann> jtran: I might want to pick your brain on those, if you have experience with them.
22:02:11 <jd__> this sounds scary
22:02:12 <jtran> dhellmann: sure , any way i can help .  i have worked on them before.
22:02:23 <dhellmann> jtran: when I get there, I'll ping you
22:02:33 <dhellmann> jd__: ?
22:02:41 <jd__> dhellmann: brain picking
22:02:51 <dhellmann> jd__: halloween is coming up soon
22:02:54 <nijaba> dhellmann: no one is complaining
22:02:55 <jd__> haha
22:03:18 <dhellmann> nijaba: ok, good
22:03:52 <dhellmann> nijaba: so to make sure I'm ready, next week we will try to set priorities and a schedule?
22:04:01 * nijaba seems to be experiencing a 60s lag
22:04:29 <nijaba> dhellmann: yes, that's the idea, but that should not prevent us to start working on real stuff too
22:04:52 <dhellmann> nijaba: yep
22:05:57 <nijaba> and if eglynn (or anyone else) want to propose a design for the new agents, he's welcome to propose that as a topic for next week
22:07:03 <eglynn> nijaba: cool, will aim to have something for then (with asalkeld)
22:07:23 <nijaba> great
22:07:55 <nijaba> looks like we ran out of topic for today?
22:08:15 <nijaba> ending the meeting in 30s if no one objects
22:08:46 <nijaba> #endmeeting