15:00:07 <nijaba> #startmeeting Ceilometer
15:00:07 <nijaba> #meetingtopic Ceilometer
15:00:07 <nijaba> #chair nijaba
15:00:07 <nijaba> #link http://wiki.openstack.org/Meetings/MeteringAgenda
15:00:07 <nijaba> ATTENTION: please keep discussion focused on topic until we reach the open discussion topic
15:00:08 <openstack> Meeting started Thu Jan 24 15:00:07 2013 UTC.  The chair is nijaba. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:09 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:11 <openstack> The meeting name has been set to 'ceilometer'
15:00:13 <openstack> Current chairs: nijaba
15:00:19 <nijaba> Hello everyone! Show of hands, who is around for the ceilometer meeting?
15:00:19 <nijaba> o/
15:00:22 <spn> o/
15:00:25 <yjiang5_home> o/
15:00:30 <dhellmann> o/
15:00:30 <danspraggins> o/
15:00:33 <llu-laptop> o/
15:00:35 <fnaval> o/
15:00:38 <jhopper> o/
15:00:46 <jd__> o/
15:01:00 <nijaba> good to see everyone and new faces !
15:01:04 * jd__ sees new hands
15:01:08 <nijaba> #topic actions from previous meeting
15:01:13 <eglynn> o/
15:01:18 <divakar> <divakar>
15:01:25 <nijaba> #topic nijaba to specify draft policy on wiki for units
15:01:47 <YehiaBeyh> <YehiaBeyh>
15:01:50 * dragondm waves hi
15:01:59 * nijaba has been a bad boy and has not had time to work on this
15:02:07 <nijaba> #action nijaba to specify draft policy on wiki for units
15:02:26 <nijaba> That's it for last week
15:02:45 <nijaba> #topic  relevance of https://blueprints.launchpad.net/ceilometer/+spec/ceilometer-agent-object-storage
15:02:52 <nijaba> jd__: floor is yours
15:02:58 <YehiaBeyh> there was an action "llu to get in touch with the healthmon team to see what their reaction is to our plan for integration, putting the ml in cc". Divakar was trying to setup a meeting to go over the plan - any luck on this?
15:03:32 <divakar> I have updated the ceilometer wiki with the healthnmon plans http://wiki.openstack.org/Ceilometer/CeilometerAndHealthnmon
15:03:49 * jd__ let the floor to YehiaBeyh and divakar
15:04:54 <llu-laptop> i'm looking at the wiki
15:04:54 <divakar> As per my proposal
15:04:58 <divakar> Healthnmon as the source of metering data (for compute to start with)
15:05:30 <divakar> Healthnmon currently has implemented drivers for KVM to collect the required meters data for both Compute and Instances running on the compute remotely. The same data can be leveraged by Ceilometer thru Healthnmon APIs as initial step
15:05:57 <divakar> Ceilometer Centralized Agent mechanism can be leveraged to pull the required metering data from Healthnmon
15:06:34 <divakar> Healthnmon is working on the required drivers for vCenter ESX and Hyper-V as well
15:07:03 <dhellmann> so this plan is the opposite of the plan we've discussed previously?
15:07:10 <divakar> Collecting the data from healthnmon would help in getting the data for all the hypervisors
15:07:18 <divakar> that are supported thru openstack
15:07:50 <dhellmann> we need drivers for all of the hypervisors for metering, so we need to implement those in ceilometer at some point anyway
15:07:53 <nijaba> dhellmann: this is what it sounds like
15:07:58 <spn> Are you are talking about some virch url://of-some-remote-hypversir?
15:08:12 <sandywalsh> (belated o/)
15:08:14 <jd__> I don't think it buys anything to use healthnmon as another abstraction layer for that
15:08:29 <dhellmann> jd__: agreed
15:08:30 <nijaba> jd__: +1
15:09:02 <dragondm> I've been looking at implementing for xenserver...
15:09:05 <jd__> I admit it can be a good source of information, but we want to support the hypervisors Nova does directly
15:09:11 <YehiaBeyh> how is the plan different from what was discussed previously?
15:09:17 <dhellmann> divakar: can you discuss a bit your objections with the plan described in 6.1 and 6.2 of the wiki page?
15:09:47 <dhellmann> YehiaBeyh: in the previous plan the data would flow from ceilometer to healthnmon, in the new plan that is reversed
15:10:12 <sandywalsh> can we not do this through the existing hypervisor polling mechanism in Nova and not require the agent (or have to depend on healthmon) for it?
15:10:13 <dhellmann> that really only works for deployments where the admins want both healthnmon monitoring and ceilometer metering
15:10:30 <dhellmann> sandywalsh: the plan is to get a version of that code in ceilometer and take it out of nova
15:10:42 <dhellmann> sandywalsh: that's probably at least an H change for nova
15:10:47 <sandywalsh> hmm
15:10:54 <jd__> sandywalsh: there isn't such polling for now AFAIK
15:10:56 <divakar> As part of healthnmon we are already collecting the inventory data + alerting + utilization data (meters)
15:11:03 <sandywalsh> jd__: yup, we use it
15:11:14 <jd__> sandywalsh: you retrieve CPU time and disk IO from nova ?
15:11:28 <dragondm> we already poll in nova for bw data
15:11:36 <sandywalsh> jd__: whatever the hypervisor offers
15:11:49 <sandywalsh> jd__: essentially, whatever the agent is doing, we can do in the polling
15:11:54 <dragondm> the low level code for disk/cpu is there
15:12:06 <divakar> So healthnmon has the required data for making the decisions while scheduling,  monitoring, metering and also for analytics
15:12:09 <dragondm> we  just need to emit it.
15:12:10 <eglynn> dragondm: I believe those bw stats only reported by the xenapi driver though
15:12:13 <dhellmann> hey, folks, let's please focus on divakar's proposal for now
15:12:21 <dhellmann> we can discuss APIs in a bit
15:12:34 <dragondm> ok
15:12:34 <sandywalsh> dhellmann: it's related is it not?
15:12:49 <dhellmann> sandywalsh: one thing at a time
15:12:50 <divakar> Let me summarize
15:13:01 <divakar> healthnmon has the required data for making the decisions while scheduling,  monitoring, metering and also for analytics
15:13:38 <divakar> We are looking at providing a single point of data around monitoring, scheduling and support for use cases around analytics, autonomics and planning
15:14:08 <dhellmann> divakar: that "single point" is overlapping with a couple of other projects at this point :-)
15:14:22 <divakar> metering also can be driven from this data and hence the proposal
15:15:14 <divakar> At this point I see that Heat is looking for scheduling data + alerting data which can be integrated as well
15:15:21 <nijaba> yes, it seems that we are hitting again the same issue of goals for each projects which have a big overlap
15:16:03 <nijaba> lot of good work is being put into multi publisher in ceilo
15:16:19 <nijaba> I would propose that we rationalize around this
15:16:24 <n0ano> dare one suggest the next design summit, seems like we're impinging too many different areas
15:16:39 <nijaba> n0ano: I was driving to this
15:16:55 <nijaba> specially since we are in the last milestone of the project
15:17:06 <nijaba> and need to finalize existing bp
15:17:15 <sandywalsh> divakar: fwiw, we've stopped stacktach development in favor of CM development for this very reason ... project overlap.
15:17:29 <jhopper> this is also the reason for me being here as well
15:17:31 <jhopper> project overlap
15:17:55 <divakar> Monitoring is not a overlap at this point
15:18:04 <nijaba> I think we should start preparing the meetings at the summit to deep dive on this
15:18:05 <sandywalsh> divakar: with stacktach it is
15:18:22 <dhellmann> nijaba: +1000
15:18:24 <nijaba> but please, let's move back to the advertised topics
15:18:29 <spn> +1
15:18:32 <nijaba> jd__: please go ahead
15:19:00 <YehiaBeyh> what is the major overlap here?
15:19:13 <YehiaBeyh> is it the data collection?
15:19:21 <nijaba> #topic relevance of https://blueprints.launchpad.net/ceilometer/+spec/ceilometer-agent-object-storage
15:19:21 <jhopper> For me, yes
15:19:32 <jd__> so this blueprint is about creatin another new agent
15:19:34 <sandywalsh> collection, storage, api, aggregation, propagation
15:19:49 <jd__> technically this is isn't required since it can be done with the central agent
15:19:53 <jd__> -is
15:20:17 <jd__> I'm not sure it's a really good idea to split the central agent again and create more namespace
15:20:35 <dhellmann> jd__: what's the motivation for doing this specific polling in a separate agent?
15:20:46 <nijaba> why were you thinking about spliting it in the first place? to be able to disable it?
15:21:04 <jd__> dhellmann: in case you just run swift?
15:21:12 * sandywalsh votes to kill the agent altogether ... nova is the touch point to the hypervisor.
15:21:22 <jd__> nijaba: yes, I think it was about being able to enable/disable things, but we can do this now
15:21:24 <dragondm> +1
15:21:37 <danspraggins> +1
15:21:41 <nijaba> jd__: agreed, this is now par of multi publisher, IIUC
15:21:44 <dhellmann> jd__: the existing config option to disable pollsters isn't very rich
15:21:56 <jd__> dhellmann: but it's enough to do that IIUC
15:22:02 <jd__> nijaba: now it is even more yes
15:22:19 <dhellmann> jd__: yeah, I hit send too soon -- the existing option should work, but the new publisher config will make it even easier
15:22:27 <yjiang5_home> sandywalsh: this is for swift.
15:22:41 <jd__> ok, so sounds like we all agreed to say that this blueprint is obsolete
15:22:42 <jd__> ?
15:22:48 <dhellmann> +1
15:22:50 <nijaba> +1
15:22:56 <yjiang5_home> jd__: +1
15:22:58 <jhopper> I would argue against multiple agents - they all serve a similar domain purpose and a much richer configuration may make deployment simpler (same package, different cfg)
15:23:06 <jd__> this is what I though :-) I'll change its status, thanks guy
15:23:09 <jhopper> +1
15:23:10 <llu-laptop> +1
15:23:16 <fnaval> +1
15:23:19 <jd__> guyS
15:23:20 <eglynn> yep, +1 to non-agent-proliferation
15:23:34 <YehiaBeyh> +1
15:23:35 <jd__> we can move to the next topic I guess
15:23:44 <sandywalsh> +1 (no agents)
15:23:44 <nijaba> #topic blueprint review
15:23:57 <nijaba> #link - https://launchpad.net/ceilometer/+milestone/grizzly-3
15:24:16 <nijaba> we have quite a few not started ones
15:24:47 <nijaba> can you guys tell me if you think we should postpone them or keep them?
15:24:51 <yjiang5_home> I'm working on Publisher counters frequency receival now, since the multiple publisher patch is under review
15:24:52 <eglynn> all my synaps wqork is on hold again this (snowed under with downstream work)
15:25:01 <dhellmann> nijaba: I am going to try to start https://blueprints.launchpad.net/ceilometer/+spec/move-listener-framework-oslo next week
15:25:02 * jd__ updated https://blueprints.launchpad.net/ceilometer/+spec/pollster-global-keystone-auth
15:25:08 <nijaba> yjiang5_home: should I mark it as started?
15:25:20 <jd__> yjiang5_home: great
15:25:32 <yjiang5_home> nijaba: I will send patch out possibly early next week.
15:25:49 <nijaba> yjiang5_home: great ,thanks
15:26:01 <jd__> nijaba: https://blueprints.launchpad.net/ceilometer/+spec/ceilometer-agent-object-storage still appears in g3, maybe you should remove it? I don't know why it shows
15:26:40 <jd__> I think https://blueprints.launchpad.net/ceilometer/+spec/api-aggregate-average is implemented, dhellmann you confirm?
15:26:56 <nijaba> jd__: fixed
15:27:02 <dhellmann> jd__: yes, that's part of the "statistics" endpoint in the v2 api
15:27:17 <jd__> marking complete
15:27:43 <nijaba> perfect
15:28:02 <jd__> multi-publisher seems in good shape to me
15:28:07 <nijaba> eglynn: what about qpid?
15:28:17 <jd__> (I think I'm the only one who did a review since a moment now :)
15:28:30 <yjiang5_home> jd__: thanks for your review.
15:28:49 <eglynn> nijaba: lets keep that, I'll find time for it next week
15:28:56 <jd__> yjiang5_home: I saw you updated it, I'll try to take a look again :)
15:29:10 <yjiang5_home> jd__: thanks.
15:29:16 <nijaba> eglynn: great, thanks
15:29:51 <dhellmann> I'm back online today, so I should have time to look over the multipublisher stuff this afternoon
15:30:19 <nijaba> ok, so now we have a TON of bp marked for grizzly with no milstone: https://blueprints.launchpad.net/ceilometer/grizzly
15:30:38 <nijaba> I think synaps is going to slide until H
15:30:45 * jd__ proposes to tie dhellmann to review.openstack.org
15:30:52 <nijaba> eglynn: what's your pov?
15:30:55 <eglynn> nijaba: agree that a strong possibility
15:31:12 <nijaba> eglynn: should I remove the target for now?
15:31:15 <eglynn> (I"m been snowed under with downstream work the last couple weeks)
15:31:18 <nijaba> we can always chnage back
15:31:24 <eglynn> fair enough
15:31:39 <nijaba> perfect, I'll do
15:31:51 <nijaba> #action nijaba to untarget synaps bp for now
15:32:15 <nijaba> any other that should be untargetd from grizzly?
15:32:29 <nijaba> or, which one should we target to g3?
15:32:41 <nijaba> and i'll untarget the others
15:32:43 * dhellmann looks for the bug about sqlalchemy metadata queries
15:32:57 <llu-laptop> I think test-db-backends should be done now.
15:33:02 <dhellmann> we should add https://bugs.launchpad.net/ceilometer/+bug/1098603
15:33:03 <uvirtbot> Launchpad bug 1098603 in ceilometer "need to handle missing units values in existing mongodb data" [Medium,New]
15:33:12 <dhellmann> and https://bugs.launchpad.net/ceilometer/+bug/1093625
15:33:15 <uvirtbot> Launchpad bug 1093625 in ceilometer "no metaquery implementation in sqlalchemy DB backends" [Medium,Confirmed]
15:33:51 <nijaba> dhellmann: +1.  would you care to do that?
15:33:52 <YehiaBeyh> do we want to follow up on the healthnmon/integration proposal in email or do we need a special meeting?
15:33:53 <dhellmann> that 2nd maybe big
15:34:14 <jd__> ah I created a BP for 1093625 this morning :(
15:34:23 <nijaba> YehiaBeyh: meeting, eventually voice?
15:34:33 <YehiaBeyh> yes
15:34:44 <dhellmann> nijaba: done
15:34:46 <yjiang5_home> nijaba: I think https://blueprints.launchpad.net/ceilometer/+spec/counter-disabling is already in multiple publisher code.
15:34:46 <sandywalsh> can we be in on that?
15:34:59 <nijaba> #action nijaba to propose a doodle for helthmon meeting
15:35:08 <jd__> nijaba: https://blueprints.launchpad.net/ceilometer/+spec/sqlalchemy-metadata-query FWIW
15:35:09 <YehiaBeyh> in addition, if we do need to deep dive into this we can propose something for the summit
15:35:27 <nijaba> yjiang5_home: agreed
15:35:34 <jd__> yjiang5_home: yes it is, this is why it's assigned to me, so I can click on Implemented without writing code :-D
15:35:35 <YehiaBeyh> #action nijaba to propose a doodle for helthmon meeting - what does that mean?
15:35:36 <sandywalsh> nijaba: can we participate in the voice meeting?
15:35:54 <nijaba> YehiaBeyh: doodle to pick a date/time that suits most of ut
15:35:59 <nijaba> s/ut/us
15:36:03 <yjiang5_home> jd__: :)
15:36:04 <eglynn> voice, as in G+ hangout or the linkes?
15:36:09 <YehiaBeyh> that sounds great
15:36:19 <eglynn> s/linkes/likes/
15:36:27 <nijaba> sandywalsh: yes, weĺl share a bridge info once a date/time is picked
15:36:33 <sandywalsh> nijaba: thanks
15:36:59 <divakar> I can setup the meeting.. please do let me know what all wants to be part of that conference call
15:37:01 <nijaba> np
15:37:50 <YehiaBeyh> can the list of participant be added to the notes so Divakar can set up the meeting. thx
15:38:26 <dragondm> i'd like in on that meeting as well.
15:38:36 <nijaba> divakar: I'll share with you the list of respondant to the doodle
15:38:45 <jhopper> please include me as well if possible
15:38:55 <divakar> nijaba: that will be great
15:38:56 <YehiaBeyh> Thank you nijaba
15:39:08 <nijaba> just watch the ml for a doodle invite, respond to it, and you will be invited
15:39:09 <divakar> nijaba: thank you
15:39:38 <nijaba> ok, back to the bps, anything else we should clean up?
15:40:06 <llu-laptop> nijaba: i think  	test-db-backends should be marked done.
15:40:21 <jd__> llu-laptop, nijaba: +1
15:40:34 <nijaba> llu-laptop: yup
15:40:35 <jd__> good job has been done on this
15:40:43 <nijaba> hats off
15:42:12 <nijaba> ok, let's move on
15:42:17 <nijaba> #topic open discussion
15:42:21 <eglynn> FOSDEM planning
15:42:34 <nijaba> eglynn: very good point!
15:42:47 <eglynn> IIRC from that mail thread, the plan was ...
15:42:54 <nijaba> jd__: eglynn and I should have a quick voice call to prep
15:43:01 <eglynn> nijaba 5mins intro, eglynn 10mins architecture, jd_ 10mins contributing to ceilo
15:43:06 <nijaba> yup
15:43:12 <eglynn> are we still good with that split?
15:43:16 <jd__> sure
15:43:20 <nijaba> +1 for me
15:43:21 <eglynn> cool
15:43:33 <eglynn> should we aim to have drafts to for review for say Monday?
15:43:40 <eglynn> (in advance of a call?)
15:43:44 <dhellmann> this is for a presentation?
15:43:45 <eglynn> or do the call first?
15:43:50 <eglynn> dhellmann: yep
15:43:53 <dhellmann> nice
15:44:04 <nijaba> eglynn: prep first our slides :)
15:44:15 <llu-laptop> I saw nova and other openstack projects replaces the nosetest with testr for parellel unittest, shall we follow that fashion?
15:44:17 <nijaba> then meeting on tue
15:44:17 <eglynn> dhellmann: https://fosdem.org/2013/schedule/event/openstack_ceilometer/
15:44:21 <nijaba> or wed
15:44:22 <eglynn> nijaba: cool
15:44:42 <jd__> llu-laptop: probably, but I've no clue what we should do, I think -infra took care of that so far but I may be wrong
15:44:44 <dhellmann> eglynn: nice++
15:45:00 <yjiang5_home> jhopper: jd__: the idea of against multiple agent is quite interesting, I noticed not big differenece in bin/ceilometer-agent-compute and "bin/ceilometer-agent-central, possibly we can work to merge them? https://review.openstack.org/#/c/20123/ can be an preparation for it.
15:45:09 <dhellmann> llu-laptop: do you have any idea why they didn't just use py.test?
15:45:18 <jhopper> I absolutely agree
15:45:24 <danspraggins> +1 on that
15:45:28 <jhopper> There are numerous de-duplications that we could take advantage of
15:45:34 <jd__> yjiang5_home: yeah https://review.openstack.org/#/c/20123/ is about this, exactly, there's minimum difference after
15:45:37 <jhopper> not to mention provide a more contigious namespace for the agents
15:45:37 <spn> +1 on that
15:45:39 <llu-laptop> I think the testr supports parrallel testing
15:45:43 <jhopper> or rather their flavors
15:45:46 <dhellmann> llu-laptop: so does py.test
15:46:37 <llu-laptop> dhellmann: then I don't know why. It just seems that nova/olso/glance/etc. all turns to testr
15:46:38 <dhellmann> yjiang5_home: it should be possible to create one agent that takes a list of plugin namespaces to use to load pollsters
15:46:43 <dhellmann> llu-laptop: ok
15:46:59 <sandywalsh> why. not. kill. the. agent?
15:47:14 <dhellmann> sandywalsh: how many times do you want the same answer?
15:47:21 <llu-laptop> if it's ok, i'd like to help use testr in ceilometer
15:47:23 <sandywalsh> I haven't heard an answer
15:47:42 <dhellmann> sandywalsh: we have 2 agents for different purposes. not everything is about nova.
15:47:56 <yjiang5_home> dhellmann: yes, that's what we want.
15:47:57 <dhellmann> sandywalsh: we will also eventually be moving the stats collection out of nova
15:47:59 <danspraggins> i tend to agree with sandywalsh. why can't we rely on openstack notifications.
15:48:12 <sandywalsh> dhellmann: then change the underlying project (glance, etc) to use notifications properly
15:48:16 <danspraggins> for all projects. not just nova.
15:48:38 <nijaba> danspraggins: have you worked with swift before?
15:48:49 <danspraggins> nijaba: i have not.
15:49:15 <dhellmann> danspraggins: we're moving in that direction, too, but in the mean time...
15:49:19 <nijaba> danspraggins: unlikely they will accept such a modification
15:49:35 <sandywalsh> nijaba: if there is a hard road block on a particular system, then sure, use an agent. But in 90% of the situations, notifications should and can be used.
15:49:36 <danspraggins> dhellmann: fair enough.
15:49:39 <nijaba> danspraggins: but yes, this is the edn goal
15:49:51 <danspraggins> nijaba: good deal.
15:49:53 <dragondm> Cool
15:50:00 <nijaba> but in the meean time. we need to be able to capture what we need NOW
15:50:11 <danspraggins> nijaba: makes sense.
15:51:30 <yjiang5_home> jhopper: I will create a bp for single agent.
15:51:49 <jhopper> I would be more than happy to cut my teeth on it unless the effort is already spoken for
15:52:05 <nijaba> dhellmann, jd, eglynn: did you have any proposals for new core devs?
15:52:23 <dragondm> I am already looking into what it would take to get nova to emit the needed stats.
15:52:41 <nijaba> dragondm: thanks!
15:52:52 <jd__> dragondm: great
15:52:53 <thomasbiege> hi
15:52:55 <sandywalsh> anyone use uses oslo, should be willing to use notifications
15:53:03 <sandywalsh> s/use/who/
15:53:11 <nijaba> sandywalsh: yup
15:53:19 <jd__> anything else for open topic?
15:53:28 <dragondm> (ill see abt writing up some bp's for nova & ceilio to that end)
15:53:44 <yjiang5_home> dragondm: There is some discussion about get data from nova in mailing list  and some challenge.
15:53:45 <sandywalsh> how about adopting the HACKING guide?
15:53:47 <nijaba> jd__: we are on core dev proposals
15:54:01 <jhopper> yjiang5_home: rather the work required to implement the bp
15:54:06 <yjiang5_home> dragondm: s/is/was/
15:54:56 <jd__> nijaba: sorry missed your question :) likely yjiang5_home
15:54:57 <eglynn> nijaba: re new core devs, I'd propose yjiang5_home if he's willing
15:54:59 <dragondm> yjiang5_home: yup, been following.
15:55:26 <eglynn> also I think llu-laptop has been doing great work
15:55:33 <eglynn> (if he's willing also ...)
15:55:34 <nijaba> in which case, with yjiang5_home approval, I'll start a formal mail thread for approval
15:55:41 <dhellmann> +1 to both yjiang5_home and llu-laptop
15:55:44 <yjiang5_home> jd__: eglynn: dragondm: really thanks
15:55:45 <jd__> +1 eglynn for llu-laptop
15:55:47 <nijaba> ditto for llu-laptop
15:56:13 <jd__> thanks for your #action nijaba :-)
15:56:16 <nijaba> #action nijaba to formaly start ml thread about core dev startus for yjiang5_home and llu-laptop
15:56:26 <llu-laptop> thanks, I'd love to
15:56:52 <nijaba> sounds like a done deal, but we have to follow the official process
15:57:17 <jd__> indeed
15:57:41 <nijaba> ok, looks like we've ran out of off topics :)
15:57:44 <sandywalsh> how about adopting the HACKING guide?
15:57:54 <nijaba> sandywalsh: ??
15:58:08 <yjiang5_home> sandywalsh: you mean like coding style etc?
15:58:20 <dhellmann> #link https://github.com/openstack/nova/blob/master/HACKING.rst
15:58:23 <dragondm> I think he means nova's code guidelines
15:58:23 <sandywalsh> https://github.com/openstack/nova/blob/master/HACKING.rst
15:58:46 <sandywalsh> yup, import order, etc
15:58:57 <dhellmann> I think we've been trying to follow that, but it would be good to go through and make sure now that we're incubated
15:58:57 <nijaba> good point for a ml discussion?
15:58:58 <sandywalsh> makes code reviews easier when coming over from other projects
15:59:06 <nijaba> sandywalsh: do yiou want to start the thread?
15:59:14 <sandywalsh> sure
15:59:17 <nijaba> thanks
15:59:35 <nijaba> #action sandywalsh to start a thread about adopting https://github.com/openstack/nova/blob/master/HACKING.rst
15:59:45 <nijaba> ok, we are out of time
15:59:52 <nijaba> thanks a lot everyone!
16:00:02 <nijaba> #endmeeting