22:01:43 <danwent> #startmeeting
22:01:44 <openstack> Meeting started Tue Aug  9 22:01:43 2011 UTC.  The chair is danwent. Information about MeetBot at http://wiki.debian.org/MeetBot.
22:01:45 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic.
22:01:53 <danwent> Agenda: http://wiki.openstack.org/Network/Meetings
22:02:14 <danwent> busy meeting, lots of topics, so if something gets too detailed, we'll probably have to pull it to the netstack list
22:02:24 <danwent> #general status
22:02:30 <danwent> #topic general status
22:02:44 <danwent> wanted to touch on issue of moving to github/gerrit
22:02:59 <danwent> recent ppb meeting said that core projects are going to try and move before essex summit
22:03:16 <danwent> of course, there's natural concern about it not wanting to disrupt diablo release
22:03:33 <danwent> plan is to try and move after we close D-4
22:03:39 <danwent> any thoughts or concerns on this?
22:03:48 <salv-orlando> better move now than later
22:03:52 <markvoelker> mtaylor: around?
22:04:14 <mtaylor> markvoelker: hey
22:04:17 <danwent> salv: agreed... there will only be more code, more people, more merges, etc. in the future
22:04:31 <markvoelker> mtaylor: quick overview of what's necessary to get us moved perhaps?
22:04:41 <salv-orlando> I'd say after D-4 we start a "transition period". I think the official diablo release should still come from launchpad
22:04:52 <danwent> salv: yes
22:04:53 <mtaylor> markvoelker: it's not too terrible - we have scripts to sync your user account info with gerrit already
22:05:07 <SumitNaiksatam> why not move after essex summit?
22:05:11 <danwent> mtaylor: don't oversell :P
22:05:34 <mtaylor> markvoelker: the general steps are: 1) stop using the launchpad branches 2) let us do a few things (transitioning your branches) 3) start using gerrit
22:05:37 <danwent> Sumit: I think that is what it will amount too... anything targeted for Diablo will be fully launchpad
22:05:49 <SumitNaiksatam> ok good
22:05:49 <mtaylor> so the main thing is just that you need to coordinate with jeblair and I
22:05:59 <danwent> but anything targeted for beyond diablo will end up in git/gerrit
22:06:06 <SumitNaiksatam> perfect
22:06:13 <danwent> definitely don't want disruption to mess with the release
22:06:13 <bhall> mtaylor: are the karma points migrated too? :)
22:06:24 <danwent> we stay on launchpad for BP, bugs, right?
22:06:29 <mtaylor> yes
22:06:30 <salv-orlando> thanks mtaylor. Does not sound too hard... do we have a tutorial for github/gerrit ? (we had one for bzr + launchpad)
22:06:31 <danwent> as well as releases
22:06:37 <markvoelker> mtaylor: Ok, sounds about like what I expected.  I have no problems with this (kinda looking forward to it even =p).
22:06:38 <mtaylor> and gerrit has integration with lp bugs
22:06:42 <danwent> so salv, bhall.... your karma is safe
22:06:46 <mtaylor> markvoelker: it'll be fun!
22:06:51 <mtaylor> salv-orlando: we do
22:07:03 <mtaylor> http://wiki.openstack.org/GerritWorkflow
22:07:09 <salv-orlando> danwent: you can buy a lot stuff on amazon with your karma points :-)
22:07:20 <mtaylor> key points to remember there are instaling the commit hook in each repo you clone
22:07:25 <salv-orlando> mtaylor: thanks for the pointer
22:07:35 <mtaylor> and setting up the review git alias
22:07:43 <mtaylor> but if you do all the steps on the wiki page, you should be set
22:08:04 <mtaylor> we're trying to keep that up to date as we migrate other people
22:08:07 <danwent> great.  we can play around with it a bit before making the real jump
22:08:32 <danwent> any other questions/thoughts on github/gerrit?
22:08:33 <mtaylor> also - the biggest hurdle is a slight change in mentality from bzr ... where squashing multiple commits into one to submit is the best practice here
22:08:52 <mtaylor> but once you get used to that - it's pretty straight forward
22:09:13 <mtaylor> there's also command line access to gerrit- https://review.openstack.org/Documentation/cmd-index.html
22:09:17 <mtaylor> for your reading pleasure
22:09:30 <danwent> ok, thanks mtaylor... much appreciated
22:09:33 <markvoelker> mtaylor: Great.  Ok, I know we have a crowded agenda tonight, so suggest we move on if no other major concerns?
22:09:35 <mtaylor> my pleasure!
22:09:45 <danwent> #topic melange
22:09:52 <danwent> troy?
22:10:28 <danwent> just said hello a minute ago...
22:10:31 <troytoman> we are moving forward on integration
22:10:46 <troytoman> (sorry, I have deployment going on with our UK service right now - little distracted.)
22:11:04 <danwent> ok, maybe send an email to the netstack list if you have any other info to share.
22:11:07 <danwent> anything else on melange?
22:11:15 <troytoman> we have been working on validating our ability to meet Nova needs before we drop it into a folder
22:11:22 <troytoman> so far, things look good
22:11:28 <danwent> great
22:11:38 <danwent> #topic donabe
22:12:12 <danwent> any updates?
22:12:20 <SumitNaiksatam> afaik rick is on it
22:12:46 <danwent> is rick online?  a couple people were asking about public code for this... I didn't really have an update for them.
22:13:11 <danwent> Ok, let's ping rick to get an update as well.
22:13:13 <SumitNaiksatam> rick/debo have started a branch
22:13:19 <SumitNaiksatam> i dont have it here with me
22:13:27 <SumitNaiksatam> but he had sent it out earlier
22:13:36 <SumitNaiksatam> i will ping him again
22:13:52 <danwent> ok, here's what I have: https://code.launchpad.net/~netstack-core/donabe/diablo
22:14:02 <danwent> Sumit: thanks!
22:14:05 <somik> i saw the branch publicly but there was just framework stuff and some API
22:14:08 <salv-orlando> SumitNaiksatam: last time Rick was mentioning an API landing soon in that branch. Is this API there?
22:14:25 <somik> but no blueprints for the API yet
22:14:28 <danwent> salv: last I looked through the branch I didn't see it.
22:14:52 <danwent> it would be great to have something concrete before the essex summit
22:15:04 <danwent> ok, anything else on donabe?
22:15:20 <danwent> #topic quantum
22:15:36 <danwent> several people have been asking about incubation, now that dashboard and keystone are incubated.
22:15:49 <danwent> I definitely think we're ready
22:16:06 <danwent> as far as quantum is concerned... the stats and progress on the project has been really impressive.
22:16:17 <somik> +1
22:16:22 <danwent> I'd like to be incubated before the essex summit.
22:16:40 <danwent> I'll be pushing on this in the next few weeks, will keep the list updated.
22:16:55 <salv-orlando> danwent: It would be great to see you incubated at the summit :-)
22:16:55 <danwent> thoughts?
22:17:04 <troytoman> +1
22:17:10 <salv-orlando> +1
22:17:37 <danwent> more importantly, anyone who feels incubation is not the right thing to do?
22:17:46 <danwent> and if so, why not?
22:17:59 <SumitNaiksatam_> what's the other option?
22:18:16 <danwent> limbo... which is where we are not
22:18:22 <devcamcar> danwent: I'd say based on the progress you guys have made, it may be the right time to propose for incubation
22:18:25 <SumitNaiksatam_> + incubation :-)
22:18:30 <SumitNaiksatam_> +1
22:18:34 <danwent> everyone things we're an openstack project, we act like an openstack project, but we aren't actually an openstack project
22:18:45 <danwent> things -> thinks
22:18:55 <danwent> Ok, sounds pretty unamimous
22:18:56 <salv-orlando> IMHO incubation has only advantages, I don't see any cons
22:19:19 <danwent> we've done an incredible amount of work... definitely think it deserves official openstack incubation status.
22:19:21 <danwent> cool.
22:19:26 <salv-orlando> if Quantum gets incubated does that imply we then shall run it only against Openstack? I don't think so...
22:19:43 <danwent> #agreed #danwent, make progress on incubation status
22:19:50 <danwent> salv: definitely not
22:20:01 <somik> I dont think thats a requirement, for e.g. swift can run against Nova or standalone serviing objects
22:20:04 <troytoman> salv-orlando: no - just puts it on a course to be a core openstack project
22:20:06 <salv-orlando> so I'm 101% in favour of incubation
22:20:11 <danwent> it does mean adherence to PPB guidelines, etc though.
22:20:28 <danwent> but that's already a core part of the project
22:20:43 <danwent> D-4 milestone
22:20:44 <salv-orlando> we should also get one of us in Openstack PTL which is more than good
22:21:12 <somik> I think that would come after incubation
22:21:35 <danwent> https://launchpad.net/quantum/+milestone/diablo-4
22:21:45 <salv-orlando> somik: sure I was referring to dan mentioning "official openstack project"
22:22:05 <danwent> there's a lot of stuff there.  I'd like to identify anything that we consider "at risk" and make sure someone is on it.
22:22:41 <danwent> I think ryu is out this week, but the nova vif-id stuff is going to be a bit tricky....
22:22:46 <danwent> I think he already has a branch
22:23:13 <SumitNaiksatam_> is anyone reviewing our branch? :-)
22:23:21 <SumitNaiksatam_> we got to add more stuff
22:23:26 <danwent> if you're the assignee of a D-4 item, please let me know if you consider it at risk (just send an email)
22:23:42 <danwent> Sumit: we're definitely planning on reviewing (congrats on the branch)
22:23:49 <SumitNaiksatam_> branch -> merge-prop
22:23:52 <danwent> Sumit: I would change the status to WIP if you want to make more changes
22:24:07 <SumitNaiksatam_> ok, you mean on the BP?
22:24:08 <danwent> to avoid people reviewing code if you plan on making additional changes.
22:24:21 <salv-orlando> the merge proposal
22:24:33 <SumitNaiksatam_> oh let me clarify - the merge prop is good for review
22:24:40 <salv-orlando> SumitNaiksatam: BTW, that merge proposal does not target lp:quantum
22:24:40 <asomya> Dan, is there more to the VIF-id's than just exposing them in the nova instance view builder?
22:24:48 <SumitNaiksatam_> once merged, we need to add more after that
22:25:24 <danwent> asomya: yes, it is also making sure it is passed to the vif-plugin, and making sure it is globally unique (sequential integers don't tend to be)
22:25:32 <danwent> Sumit: that is fine
22:25:47 <SumitNaiksatam_> salv: i am referring to: https://code.launchpad.net/~cisco-openstack/quantum/l2network-plugin/+merge/70804
22:25:54 <danwent> In fact, I'd encourage you to merge in multiple chunks, as long as they can be indepdentently verified
22:26:01 <salv-orlando> SumitNaiksatam_: If the current merge-prop is self contained  you can stack the other on top of it using the previous one as a pre-requisite
22:26:09 <danwent> Ok, officially moving to the "merges + reviews" section of the agenda
22:26:20 <markvoelker> danwent: Looking at that list, CI still doesn't have an assignee...but I think heckj has it?
22:26:20 <Jamey_> .
22:26:32 <danwent> https://code.launchpad.net/quantum/+activereviews
22:26:44 <danwent> heckj, does that sound OK with you?
22:26:56 <salv-orlando> 4907 lines... it's going to take a while :-)
22:27:19 <danwent> #action #danwent, find owner for CI blueprint, possibly heckj
22:27:35 <heckj> uh, just a sec - reading back
22:27:48 <danwent> on the topic of merges, congrats to Vinkesh, Santhosh and team on the extensions branch.
22:27:50 <heckj> danwent: yeah, good for me
22:27:58 <danwent> heckj: thx
22:28:13 <danwent> extensions branch is good to merge, once they clear out a couple merge conflicts.
22:28:21 <danwent> thanks for all the reviews.
22:28:23 <carlp> I guess I need to coordinate with mtaylor and heckj this week to get the Jenkins environment up
22:28:45 <mtaylor> carlp: yes! we shall make everything lovely
22:28:55 <asomya> danwent: ok, I managed to expose just the VIf id's with the nova network and fixed_ip details for the dashboard from nova and just pass the vif id to the quantum client to plug into a port. Should I commit this bit if it's useful?
22:29:16 <danwent> carlp: that would be great.  Shweta from cisco is also going to be getting involved
22:29:19 <danwent> Shweta, you here?
22:29:59 <danwent> asomya: cool.  I think ryu has a branch as well.  please send an email to the netstack list with a pointer to the branch and we'll coordinate on that.
22:30:06 * markvoelker calls over the cubical walls for shwetaap to wake up
22:30:24 <asomya> danwent: soudns good
22:30:24 <shwetaap> dawent: I am here
22:30:32 <danwent> no worries, just wanted to make sure they new to keep her in the loop
22:30:53 <danwent> CC'ing the list will also be sufficient.
22:31:03 <markvoelker> danwent: better, even. =)
22:31:22 <danwent> big focus of this week on merges will be getting the cisco plugin reviewed.
22:31:29 <salv-orlando> om review and merges. we have two fairly big merge-props
22:31:50 <salv-orlando> test-refactor: 896 lines, and l2network-plugin from Cisco: 5109 lines
22:31:54 <danwent> and salv's API as well.
22:32:07 <danwent> test-refactor is just a lot of code moved around, review should be quite simple
22:32:15 <SumitNaiksatam> on the cisco plugin - all the code is new, so it wont break anything :-)
22:32:29 <salv-orlando> I moved api-alignment back to WIP, should be merge prop again next monday
22:32:32 <danwent> we'll talk more about the API later, but getting that code frozen ASAP will be important.
22:33:05 <danwent> salv: great, good to know.   we should also coordinate on changing the client code, as I believe there were some changes to API attributes, no?
22:33:40 <salv-orlando> I will volunteer for reviewing the Cisco plugin, should be able to get a review in by Thursday
22:33:51 <mtaylor> heckj: I've added carlp to openstack-ci-admins so that he can be directly involved
22:33:52 <danwent> #info extension code is reviewed and ready for merge
22:33:55 <SumitNaiksatam> salv: thanks!
22:34:07 <danwent> #info major review this week are cisco plugin code
22:34:19 <danwent> #info expect merge prop of API alignment next monday
22:34:35 <danwent> ok, let's move on to discussing API spec alignment
22:34:38 <danwent> salv?
22:34:39 <salv-orlando> Good.
22:34:50 <salv-orlando> I've taken into account your feedback
22:35:23 <salv-orlando> and updated the spec accordingly. Most of the confusion was due to the concept of port state, and of a non-up-to-date section on "theory of operation"
22:36:13 <salv-orlando> now it should all be consistent. I saw a bit of email on the enum values for port states. Whether we choose "ACTIVE" or "UP" is more or less the same for me. Personally I'd have "UP" in the API, as it makes more sense in networking terms
22:36:41 <salv-orlando> Apart from this, the merge prop will be delayed until next monday as I need to make sure the clients will not be broken
22:37:28 <salv-orlando> I also want to make sure we kind of stop changing the API spec by the end of this week.
22:37:35 <somik> salv-orlando: I was reviewing gaps in our tests and had came across a test that enforces that quantum network names are unique, but reviewing API wiki, I dont see such agreement. I believe since we already have UUID assocaited with every quantum network, there should be no requriement to have redundant uniqueness of names either.
22:37:37 <danwent> salv: is plan to keep state in for v1.0, or shift it to v1.1?
22:38:13 <salv-orlando> for resource state, I still see too much noise on the mailing list to declare it could be in API 1.0
22:38:22 <somik> we should finalize what we have as 1.0
22:38:31 <salv-orlando> if anybody feels the need to have it in 1.0, please speak now.
22:39:02 <danwent> I think  it will be very valuable, but we need to lock down the API and it still seems to need more discussion on the details.
22:39:11 <danwent> i'm in favor of leaving it out for 1.0
22:39:28 <salv-orlando> somik: about that test. You're right, but that constraint is actually in the db model. I did not want to mess with that code, but I too think we can remove this constraint.
22:39:31 <heckj> mtaylor: sweet!
22:39:42 <danwent> somik: please file a bug on this
22:39:46 <somik> salv : DB model != API :)
22:39:57 <somik> danwent: sure, will do.
22:40:35 <salv-orlando> I know that, but how can I possibly create two network with the same name, if then each plugin that uses that db model is going to raise an exception? :-)
22:40:37 <danwent> salv: what is the plan regarding the existing "state" field in the API?  keep it but define it as a logical-only "admin state"?  remove it?  something else?
22:40:54 <salv-orlando> logical-only administrative state.
22:41:03 <danwent> salv, somik: this is outdated code in the db, will remove
22:41:05 <salv-orlando> No implications on operations you can perform
22:41:13 <danwent> salv: ok, makes sense
22:41:25 <salv-orlando> Will smooth this out (the db thing) in API alignment
22:41:38 <danwent> salv: anything else on API alignment?
22:41:47 <salv-orlando> Somik: if you file a bug, link lp:~salvatore-orlando/quantum/quantum-api-alignment to it
22:41:50 <salv-orlando> I guess that is all
22:41:53 <danwent> thx.
22:41:54 <salv-orlando> Summarizing:
22:42:01 <somik> salv-orlando: sounds good.
22:42:02 <salv-orlando> few bits left to smooth
22:42:12 <salv-orlando> make sure clients do not break
22:42:22 <salv-orlando> and status will NOT be part of API 1.0
22:42:46 <salv-orlando> that's decided, unless you express your disagreeement now :-)
22:42:54 <danwent> ok, on to nova + quantum
22:43:14 <danwent> already talked about vif-id workasomya will send an email to the list,
22:43:32 <danwent> #action asomya will send an email to the list about vif-id branch
22:43:49 <danwent> linuxnet_vif plug branch has two approves, one needs info
22:43:53 <danwent> should be merged soon.
22:44:19 <salv-orlando> what about the admin API?
22:44:27 <danwent> quantum manager:  I need to send out a link to this branch
22:44:49 <danwent> salv: yup, I was trying to whip of a first cut at the admin api, two goals:
22:45:16 <danwent> communicate ownerhship of "interface-ids" from nova to quantum, so quantum can enforce that only the owner of an interface can plug that interface in.
22:45:33 <danwent> this will probably just be a simple call that includes the interface-id and the tenant-id
22:46:08 <danwent> was also planning on trying to tackle a generic admin API for "interface bindings"....  though this requires some more thought/input
22:46:37 <danwent> I ported the code over to use the new quantum client lib though, so adding these calls once we know what they want to look like should be simple.
22:47:00 <danwent> currently we copy the client.py file over, but I'd like to have the packaging so we can just install a dependency, which is definitely the right way to go.
22:47:18 <salv-orlando> danwent: elaborate on generic admin API
22:47:50 <danwent> sorry, the generic referred to "interface bindings".... i.e., an interface bindings API that could work with any plugin
22:47:53 <salv-orlando> is that meant to be part of nova or quantm
22:48:33 <danwent> salv: same discussion we had on the launchpad merge prop....
22:48:53 <salv-orlando> ok, let's take it offline. move to next topic.
22:48:53 <danwent> #action: #danwent, send out link to discussion on quantum admin APIs
22:49:04 <danwent> Ok, GUI work
22:49:11 <markvoelker> New screenshots for anyone who hasn't seen 'em (great work here asomya!): http://wiki.openstack.org/QuantumClientGUI
22:49:15 <danwent> awesome screenshots uploaded to wiki page
22:49:30 <danwent> anything else to report that wasn't already mentioned on the email list?
22:49:31 <asomya> thanks guys.. Dashboard's done and ready all basic quantum operations are fully functional
22:49:43 <danwent> can't wait to try it out
22:49:47 <asomya> just working on a few enhancements like the breadcrumbs and instance details in the VIf column
22:49:59 <danwent> plans for multi-nic support?
22:50:16 <somik> the GUI is coming along really great guys! Very good work!
22:50:35 <asomya> it's totally agnostic to the instances.. just gets a list of VIF's from nova with the instance labels and prceeds to attach whatever VIF to any port
22:50:49 <danwent> ok, very cool
22:51:12 <danwent> salv: api auth, anything to add beyond your detail email to the list?
22:51:24 <markvoelker> Also, there was some discussion on the ML with devcamcar regarding a possible better way to integrate with Dashboard rather than the top-level module route....haven't seen a reply lately though.
22:51:26 <salv-orlando> just that I'd like to hear your opinion
22:51:28 <markvoelker> devcamcar: around?
22:51:59 <danwent> salv: sent some questions via email, but overall sounds great.
22:52:28 <salv-orlando> about whether we should use keystone's middleware and talk to keystone people for issue, or develop our own middleware based on keystone one
22:52:29 <danwent> mark: he's definitely interested in helping, so i suspect he'll respond soon
22:52:43 <danwent> salv: what's your expert opinion?
22:52:47 <markvoelker> danwent: grand.
22:53:12 <salv-orlando> I think it will surely be quicker if we develop a middleware starting from keystone
22:53:18 <danwent> btw, is tyler around to talk about packaging?
22:53:30 <danwent> salv: makes sense.... probably the right place to start.
22:53:36 <salv-orlando> but it would be good to talk to Ziad & other folks at keystone as well.
22:53:39 <devcamcar> markvoelker: pong
22:53:43 <markvoelker> danwent: unfortunately not, but should have a bp out later this week I think.
22:53:45 <salv-orlando> okay, move to packaging
22:53:46 <dolphm_> salv-orlando, what are you looking for that keystone middleware doesn't currently provide?
22:53:54 <danwent> mark: k, sounds good.
22:54:10 <devcamcar> markvoelker: speak of the devil, I actually just hit send on a message about how best to integrate quantum and dashboard
22:54:21 <salv-orlando> it provides all that I need, the bit I don't really understand is why we have need an admin token rather than admin credentials
22:54:31 <markvoelker> devcamcar: awesomesauce!  Reading...
22:54:32 <salv-orlando> what if that token expires?
22:54:36 <danwent> #action: #danwent send email to netstack list about where interface ownership should be enforced.
22:55:05 <dolphm_> salv-orlando, reauthenticate with keystone and get a new admin token?
22:55:49 <danwent> #topic open discussion
22:56:01 <salv-orlando> dolphm_: sure. that is fine. The bit that puzzles me is that the admin token goes in the configuration file
22:56:02 <danwent> please continue to talk about keystone auth, as well as anything else (5 minutes left)
22:56:10 <asomya> A minor dashboard  thing I forgot.. quantum needs a setup script for the dashboard venv installer .. i've been using a private branch with the setup script.. i'll check the script in tomorrow to trunk
22:56:20 <dolphm_> salv-orlando, which configuration file are you referring to??
22:56:56 <danwent> asomya:  great.  are there any gotchas in setting up the dashboard with quantum?  definitely want to take a crack at that soon (as, I assume, will others)
22:56:58 <salv-orlando> the one for using auth_token.AuthProtocol as a middleware in your app pipeline
22:57:24 <asomya> danwent: it;s fully function here : https://github.com/CiscoSystems/dashboard-quantum-beta .. just that it should grab my private branch instead of trunk
22:57:46 <danwent> asomya: sweet
22:58:20 <danwent> ok, will keep the logger running to capture the keystone discussion, but any other topics for opendiscussion?
22:58:38 <somik> asomya: I am guessing once you have the setup script, we are good to grab and setup dashboard
22:59:18 <dolphm_> salv-orlando, that's a good question that i can't answer (haven't looked at the middleware much) - can you open an issue on github.com/rackspace/keystone ?
22:59:30 <dolphm_> salv-orlando, doesn't make sense to me either
22:59:30 <somik> that would be a great UI to showcase quantum and even test quantum
22:59:35 <asomya> somik: you're good to go now.. it graba a private quantum branch that has the setup script
22:59:45 <carlp> mtaylor: when do you want to talk jenkins?  after this?
22:59:49 <salv-orlando> dolphm_: sure. (I wanted to do that earlier today - too lazy to set up a github account)
23:00:10 <danwent> ok, going once.... twice....
23:00:13 <markvoelker> General topic for disussion...
23:00:22 <danwent> just in time :)
23:00:31 <somik> asomya: tahnks!
23:00:41 <markvoelker> I was at CloudCamp earlier this week and got lots of questions about OpenStack in general and Quantum in particular.  That's good. =)
23:01:28 <danwent> very cool
23:01:40 <markvoelker> However I noticed a few BP's were showing still in Unknown state that were actually in flight..mostly ours. =)  Some of them hadn't been moved to Approved because I'm not sure we'd agreed on what it takes to be approved?
23:02:13 <danwent> mark: funny, this topic has actually come up recently in email to
23:02:33 <markvoelker> danwent: exactly. =)  Partly why I thought I'd bring it up here too
23:02:42 <danwent> my take is that we're still a small group of devs.... there doesn't need to be an official "approval" process.
23:02:57 <danwent> right now, if your code impacts someone else, you should be sure to bring it up in the IRC Meeting.
23:03:11 <markvoelker> danwent: +1, great.  Just wanted to make sure we weren't stepping on any toes.
23:03:12 <salv-orlando> IMHO the BP approval process should be something that will come in place with time.
23:03:14 <danwent> once we grow larger, this may have to change
23:03:47 <salv-orlando> +1
23:03:56 <danwent> #agreed  no official blueprint approval process for quantum.... feel free to move your own blueprint to approved, and be a nice community member and make sure you let people know if your changes affect code they care about
23:04:17 <salv-orlando> talking about quantum interest, my blog post has now 913 views, in 6 weeks
23:04:28 <danwent> I'm super happy with the velocity we've been able to have with this project, see no reason to change.
23:04:50 <danwent> salv: great
23:05:03 <danwent> ok, we're 5 minutes over, anything else?
23:05:14 <salv-orlando> just goodnight from me...
23:05:18 <danwent> great work folks, let's keep it up
23:05:22 <danwent> #endmeeting