Re: [openstack-dev] [magnum] Magnum is now in the openstack git namespace

I have updated the Magnum project wiki pages for new contributors with revised instructions so they reflect the new repo location. Adrian On Mar 27, 2015, at 8:27 PM, Steven Dake (stdake) mailto:std...@cisco.com>> wrote: For those folks that weren’t aware of the scheduled outage today in gerri

[openstack-dev] [magnum] Magnum is now in the openstack git namespace

For those folks that weren’t aware of the scheduled outage today in gerrit to handle the renames, the magnum repository has moved to the openstack namespace \o/ :) I pull from git pull http://github.com/openstack/magnum But you can also pull from the openstack git server Regards -steve _

Re: [openstack-dev] Gerrit maintenance concluded

On 2015-03-28 02:30:58 + (+), Everett Toews wrote: > How is a repo determined to be unmaintained/abandoned? In this particular case its authors requested the change. See https://review.openstack.org/167387 for details. -- Jeremy Stanley ___

Re: [openstack-dev] Gerrit maintenance concluded

On Mar 27, 2015, at 8:06 PM, Jeremy Stanley wrote: > We retired 6 unmaintained/abandoned repositories: How is a repo determined to be unmaintained/abandoned? Everett __ OpenStack Development Mailing List (not for usage que

[openstack-dev] Gerrit maintenance concluded

Our maintenance has concluded successfully without incident and the accompanying Gerrit outage was roughly 30 minutes as predicted. We moved 5 repositories to new Git namespaces: stackforge/bindep -> openstack-infra/bindep stackforge/gnocchi -> openstack/gnocchi stackf

[openstack-dev] [ceilometer][FFE] Floating IP traffic statistics meters

Hello, Apologies for the double post, forgot to include FFE in the subject: I’d like to request an exemption for the following to go into the Kilo release. This work is crucial for: Cloud operators need to be able to bill customers based on floating IP traffic statistics. Why this needs an FFE

Re: [openstack-dev] [Nova][Neutron] Status of the nova-network to Neutron migration work

So, I figured I'd weigh in on this as an employee of a nova-network using company. Nova-network allowed us to do a couple things simply. 1. Attach openstack networks to our existing VLANs using our existing firewall/gateway and allow easy access to hardware such as database servers and storage on

Re: [openstack-dev] [Group-Based-Policy] Service Chain Instance ownership

Hi Ivar, Thanks for bringing this up and my apologies for the late response (although I noticed that you already provided a fix, so thankfully you were not blocked ;-)). As discussed during the GBP IRC meeting, my suggestion would also be to use the first option, and create the service chain instan

[openstack-dev] [ceilometer] Floating IP traffic statistics meters

Hello, I’d like to request an exemption for the following to go into the Kilo release. This work is crucial for: Cloud operators need to be able to bill customers based on floating IP traffic statistics. Status of the work: In summary the patch only introduces 4 new meters - ip.floating.transm

Re: [openstack-dev] [swift] swift memory usage in centos7 devstack jobs

On 03/27/2015 08:47 PM, Alan Pevec wrote: But how come that same recent pyOpenSSL doesn't consume more memory on Ubuntu? Because we don't use it in CI; I believe the packaged version is installed before devstack runs on our ubuntu CI vm's. It's probably a dependency of some base package there,

Re: [openstack-dev] [nova] how to handle vendor-specific API microversions?

On 03/27/2015 01:40 PM, Steve Gordon wrote: - Original Message - From: "Chris Friesen" So for the case where a customer really wants some functionality, and wants it *soon* rather than waiting for it to get merged upstream, what is the recommended implementation path for a vendor?

Re: [openstack-dev] [heat] heat delete woes in Juno

Pavlo, Here is a link to one of the stacks. It is fairly simple just some routers/nets/subnets. The description is a bit odd perhaps, but legal. I've changed the template to not point at IPs at internal DNS. http://paste.ubuntu.com/10690759/ I created and deleted this in a loop about 5 times and

Re: [openstack-dev] [nova] how to handle vendor-specific API microversions?

- Original Message - > From: "Chris Friesen" > To: openstack-dev@lists.openstack.org > > On 03/27/2015 12:44 PM, Dan Smith wrote: > >> To quote John from an earlier email in this thread: > >> > >> Its worth noting, we do have the "experimental" flag: > >> " > >> The first header specifies

Re: [openstack-dev] [nova] how to handle vendor-specific API microversions?

On 03/27/2015 03:03 PM, Chris Friesen wrote: > On 03/27/2015 12:44 PM, Dan Smith wrote: >>> To quote John from an earlier email in this thread: >>> >>> Its worth noting, we do have the "experimental" flag: >>> " >>> The first header specifies the version number of the API which was >>> executed. Ex

Re: [openstack-dev] [Fuel] Bug tagging practice

Clarification: numbers include only open bugs on 6.1. We have about 15 module-volumes bugs on 7.0, many bugs on the 'next' milestone and some number of bugs in progress. On Fri, Mar 27, 2015 at 9:40 PM, Dmitry Pyzhov wrote: > Guys, > > I've tried to sort more than 200 bugs on my team. I've tried

Re: [openstack-dev] [nova] how to handle vendor-specific API microversions?

On 03/27/2015 12:44 PM, Dan Smith wrote: To quote John from an earlier email in this thread: Its worth noting, we do have the "experimental" flag: " The first header specifies the version number of the API which was executed. Experimental is only returned if the operator has made a modification

Re: [openstack-dev] [nova] how to handle vendor-specific API microversions?

- Original Message - > From: "Chris Friesen" > To: openstack-dev@lists.openstack.org > > Haven't seen any responses to this. > > As I see it, nova is really pushing for interoperability, but what is a > vendor > supposed to do when they have customers asking for extensions to the existi

Re: [openstack-dev] [nova] how to handle vendor-specific API microversions?

> To quote John from an earlier email in this thread: > > Its worth noting, we do have the "experimental" flag: > " > The first header specifies the version number of the API which was > executed. Experimental is only returned if the operator has made a > modification to the API behaviour that is

[openstack-dev] [Fuel] Bug tagging practice

Guys, I've tried to sort more than 200 bugs on my team. I've tried several approaches to this issue and here the solution. First of all, assigning bugs to teams is great. Totally. Awesome. Let's keep using it. Second. I have my own one-more-launchpad-parser: https://github.com/dmi-try/launchpad-

Re: [openstack-dev] [nova] how to handle vendor-specific API microversions?

On Fri, Mar 27, 2015 at 1:28 PM, Chris Friesen wrote: > On 03/24/2015 11:10 AM, Chris Friesen wrote: > >> On 03/24/2015 07:42 AM, Sean Dague wrote: >> >>> On 03/24/2015 09:11 AM, Jeremy Stanley wrote: >>> On 2015-03-23 22:34:17 -0600 (-0600), Chris Friesen wrote: > How would that be

Re: [openstack-dev] [nova] how to handle vendor-specific API microversions?

On Fri, Mar 27, 2015 at 12:28 PM, Chris Friesen wrote: > As I see it, nova is really pushing for interoperability, but what is a > vendor supposed to do when they have customers asking for extensions to the > existing behaviour, and they want it in a month rather than the 6-9 months > it might ta

Re: [openstack-dev] [Nova][Neutron] Status of the nova-network to Neutron migration work

I think the main disconnect comes from this Is NaaS a critical feature of the cloud, or not? nova-network asserts no. The neutron team asserts yes, and neutron is being developed with that in mind currently. This is a critical assertion that should be discussed. With my app developer hat on

[openstack-dev] [Neutron][TripleO] API validation breaks physical/flat network creation

We had a breaking API validation land a week ago which prevents our TripleO physical/flat network from being created. As such we would request a fast revert here to fix things: https://review.openstack.org/#/c/168207/1 It took us a bit longer than normal to identify this regression and push the s

Re: [openstack-dev] [Nova][Neutron] Status of the nova-network to Neutron migration work

On Fri, Mar 27, 2015 at 01:17:48PM EDT, Jay Pipes wrote: > But, there's the rub. Neutron *isn't* attractive to this set of people > because: > > a) It doesn't provide for automatic (sub)net allocation for a user or > tenant in the same way that nova-network just Gets This Done for a user > that wa

Re: [openstack-dev] [Fuel] Nominate Irina Povolotskaya for fuel-docs core

+ 10 On Fri, Mar 27, 2015 at 4:28 AM, Igor Zinovik wrote: > +1 > > On 26 March 2015 at 19:26, Fabrizio Soppelsa > wrote: > > +1 definitely > > > > > > On 03/25/2015 10:10 PM, Dmitry Borodaenko wrote: > >> > >> Fuelers, > >> > >> I'd like to nominate Irina Povolotskaya for the fuel-docs-core tea

Re: [openstack-dev] [keystone][fernet] Fernet tokens sync

On Fri, Mar 27, 2015 at 11:48:29AM -0400, David Stanek wrote: > On Fri, Mar 27, 2015 at 10:14 AM, Boris Bobrov wrote: > > > As you know, keystone introduced non-persistent tokens in kilo -- Fernet > > tokens. These tokens use Fernet keys, that are rotated from time to time. A > > great descriptio

Re: [openstack-dev] [nova] how to handle vendor-specific API microversions?

On 03/24/2015 11:10 AM, Chris Friesen wrote: On 03/24/2015 07:42 AM, Sean Dague wrote: On 03/24/2015 09:11 AM, Jeremy Stanley wrote: On 2015-03-23 22:34:17 -0600 (-0600), Chris Friesen wrote: How would that be expected to work for things where it's fundamentally just a minor extension to an ex

Re: [openstack-dev] [Nova][Neutron] Status of the nova-network to Neutron migration work

On Fri, Mar 27, 2015 at 09:31:39AM +1100, Michael Still wrote: > Hi, > > I thought it would be a good idea to send out a status update for the > migration from nova-network to Neutron, as there hasn't been as much > progress as we'd hoped for in Kilo. There are a few issues which have > been slowi

Re: [openstack-dev] [Nova][Neutron] Status of the nova-network to Neutron migration work

On 03/27/2015 11:48 AM, Assaf Muller wrote: > > > - Original Message - >> On 03/27/2015 05:22 AM, Thierry Carrez wrote: >> >>> Part of it is corner (or simplified) use cases not being optimally >>> served by Neutron, and I think Neutron could more aggressively address >>> those. But the

Re: [openstack-dev] Volunteers Needed for OpenStack Booth at PyCon

On Mar 26, 2015, at 4:42 PM, Stefano Maffulli wrote: > Details of the show, schedule and peak times on the show floor are on > https://etherpad.openstack.org/p/pycon-2015-booth > > If you are interested in helping, please add your name to the etherpad > in the time slot you'd be available. I to

Re: [openstack-dev] [Nova][Neutron] Status of the nova-network to Neutron migration work

Let's also keep in mind that the ML2 Plugin has *both* openvswitch and linuxbridge mechanism drivers enabled[1]. If I understand things correctly, this means this discussion shouldn't turn into a debate about which mechanism everyone prefers, since *both* are enabled. There is one thing that we do

Re: [openstack-dev] [Nova][Neutron] Status of the nova-network to Neutron migration work

>From the stats >(http://superuser.openstack.org/articles/openstack-user-survey-insights-november-2014), -43% of production clouds use OVS (the default for Neutron) -30% of production clouds are Nova network based -15% of production clouds use linux bridge There is the

Re: [openstack-dev] [Nova][Neutron] Status of the nova-network to Neutron migration work

On Fri, Mar 27, 2015 at 11:35 AM, Fox, Kevin M wrote: > So I would expect the number of folks needing to go from nova-network to > neutron to be a small number of clouds, not a big number. Changing the > defaults now to favor that small minority of clouds, seems like an odd > choice. > This is

Re: [openstack-dev] What's Up Doc? March 26, 2015 [all]

Anne Gentle wrote on 03/26/2015 08:37:13 PM: > Install Guides updates > - > We've got a spec ready for the changes to the Install Guides now > published at: > http://specs.openstack.org/openstack/docs-specs/specs/kilo/ > installguide-kilo.html > I'm sure the keyston

Re: [openstack-dev] [keystone] What's Up Doc? March 26, 2015 [all]

> On Mar 27, 2015, at 09:29, Brant Knudson wrote: > > > >> On Thu, Mar 26, 2015 at 7:37 PM, Anne Gentle >> wrote: >> Here's the latest news installment from docsland. >> >> Install Guides updates >> - >> We've got a spec ready for the changes to the Install Guid

Re: [openstack-dev] [Nova][Neutron] Status of the nova-network to Neutron migration work

No, no. Most OpenStack deployments are neutron based with ovs because its the default these days. There are all sorts of warnings to folks for years saying if you start with nova-network, there will be pain for you later. Hopefully, that has scared away most new folks from doing it. Most of the

Re: [openstack-dev] [Nova][Neutron] Status of the nova-network to Neutron migration work

Inline… On Mar 27, 2015, at 11:48 AM, Assaf Muller wrote: > > > - Original Message - >> On 03/27/2015 05:22 AM, Thierry Carrez wrote: >> >>> Part of it is corner (or simplified) use cases not being optimally >>> served by Neutron, and I think Neutron could more aggressively address >

Re: [openstack-dev] [keystone] What's Up Doc? March 26, 2015 [all]

On Thu, Mar 26, 2015 at 7:37 PM, Anne Gentle wrote: > Here's the latest news installment from docsland. > > Install Guides updates > - > We've got a spec ready for the changes to the Install Guides now published > at: > > http://specs.openstack.org/openstack/docs-specs

Re: [openstack-dev] [Nova][Neutron] Status of the nova-network to Neutron migration work

The floating ip only on external netwoks thing has always been a little odd to me... Floating ip's are very important to ensure a user can switch out one instance with another and keep 'state' consistent (the other piece being cinder volumes). But why can't you do this on a provider network? It

Re: [openstack-dev] Volunteers Needed for OpenStack Booth at PyCon

On 26/03/15 14:42 -0700, Stefano Maffulli wrote: Volunteers Needed for OpenStack Booth We are looking for 3 more knowledgeable volunteers who can staff the OpenStack booth in shifts (see the booth schedule below). If you are available and have at least one year of experience contributing to or

Re: [openstack-dev] [keystone][fernet] Fernet tokens sync

Matt, The idea is you have a staging key (next key) and you generate that, and sync it out. Once it is synced out you can rotate to it as needed. All keys on the server are valid for token validation. Only the "active" key is used for a given keystone to issue a token. Lance has some ansible s

Re: [openstack-dev] [os-ansible-deployment] Nominating Nolan Brubaker for core team

+1 >>> Dave Wilde ... Software Engineer III - RCBOPS ... Rackspace - the open cloud company From: Ian Cordasco Reply: OpenStack Development Mailing List (not for usage questions) > Date: March 25, 2015 at 10:48:3

Re: [openstack-dev] [Nova][Neutron] Status of the nova-network to Neutron migration work

On Fri, Mar 27, 2015 at 10:48 AM, Assaf Muller wrote: > Looking at the latest user survey, OVS looks to be 3 times as popular as > Linux bridge for production deployments. Having LB as the default seems > like an odd choice. You also wouldn't want to change the default before > LB is tested at th

Re: [openstack-dev] [keystone][fernet] Fernet tokens sync

On Friday 27 March 2015 17:14:28 Boris Bobrov wrote: > Hello, > > As you know, keystone introduced non-persistent tokens in kilo -- Fernet > tokens. These tokens use Fernet keys, that are rotated from time to time. A > great description of key rotation and replication can be found on [0] and > [1]

Re: [openstack-dev] [keystone][fernet] Fernet tokens sync

Do the keys all need to be changed at once in a cluster? If so that makes it difficult for puppet at least how we do puppet deployments. Also, David can you share your ansible script for this? On Fri, Mar 27, 2015 at 9:48 AM, David Stanek wrote: > > On Fri, Mar 27, 2015 at 10:14 AM, Boris Bobro

Re: [openstack-dev] [Nova][Neutron] Status of the nova-network to Neutron migration work

- Original Message - > On 03/27/2015 05:22 AM, Thierry Carrez wrote: > > > Part of it is corner (or simplified) use cases not being optimally > > served by Neutron, and I think Neutron could more aggressively address > > those. But the other part is ignorance and convenience: that Neutro

Re: [openstack-dev] [keystone][fernet] Fernet tokens sync

On Fri, Mar 27, 2015 at 10:14 AM, Boris Bobrov wrote: > As you know, keystone introduced non-persistent tokens in kilo -- Fernet > tokens. These tokens use Fernet keys, that are rotated from time to time. A > great description of key rotation and replication can be found on [0] and > [1] > (thank

Re: [openstack-dev] [Nova][Neutron] Status of the nova-network to Neutron migration work

On Fri, Mar 27, 2015 at 11:11:42AM EDT, Mohammad Banikazemi wrote: > Are you suggesting that for the common use cases that will use the default > setup, the external network connectivity doesn't matter much? No, if anything the reverse. The default will have external connectivity by default, by us

Re: [openstack-dev] [nova] [libvirt] The risk of hanging when shutdown instance.

On 03/26/2015 07:44 PM, Rui Chen wrote: Yes, you are right, but we found our instance hang at first dom.shutdown() call, if the dom.shutdown() don't return, there is no chance to execute dom.destroy(), right? Correct. The code is written assuming dom.shutdown() cannot block indefinitely. The

Re: [openstack-dev] [Nova][Neutron] Status of the nova-network to Neutron migration work

Sean Dague wrote on 03/27/2015 07:11:18 AM: > From: Sean Dague > To: openstack-dev@lists.openstack.org > Date: 03/27/2015 07:12 AM > Subject: Re: [openstack-dev] [Nova][Neutron] Status of the nova- > network to Neutron migration work > > On 03/27/2015 05:22 AM, Thierry Carrez wrote: > > > Par

[openstack-dev] [Horizon][Sahara] FFE Request for bp/sahara-shell-action-form

I'm requesting a FFE for a Data Processing (Sahara) feature. The job type that this form supports is merged for Kilo on the backend. The patch (which has no unmerged dependencies) is here: https://review.openstack.org/#/c/160510/ Thank you, Ethan ___

[openstack-dev] [keystone][fernet] Fernet tokens sync

Hello, As you know, keystone introduced non-persistent tokens in kilo -- Fernet tokens. These tokens use Fernet keys, that are rotated from time to time. A great description of key rotation and replication can be found on [0] and [1] (thanks, lbragstad). In HA setup there are multiple nodes wit

Re: [openstack-dev] Fwd: PCI passthrough of 40G ethernet interface

After update to latest firmware and using version 1.2.37 of i40e driver, things are looking better with PCI passthrough. ]# ethtool -i eth3 driver: i40e version: 1.2.37 firmware-version: f4.33.31377 a1.2 n4.42 e1930 bus-info: :00:07.0 supports-statistics: yes supports-test: yes supports-eeprom

[openstack-dev] [Horizon][Sahara] FFE Request for bp data-processing-edit-templates

I'd like to request a FFE for a Data Processing (Sahara) feature. The backend and client lib work are already in for Kilo. The 2 patches are here: https://review.openstack.org/#/q/status:open+project:openstack/horizon+branch:master+topic:bp/data-processing-edit-templates,n,z Thanks, Chad ___

Re: [openstack-dev] [Fuel] fuel-dev-tools repo

IIRC in this thread we agreed to use separate core groups for different repositories http://lists.openstack.org/pipermail/openstack-dev/2015-January/055111.html Why not follow that approach in this case? > 27 бер. 201

Re: [openstack-dev] Is yaml-devel still needed for Devstack

On 03/27/2015 09:04 AM, Sean Dague wrote: > On 03/27/2015 09:01 AM, Adam Young wrote: >> I recently got Devstack to run on RHEL. In doing so, I had to hack >> around the dependency on yaml-devel (I just removed it from devstack's >> required packages) >> >> There is no yaml-devel in EPEL or the ma

Re: [openstack-dev] Is yaml-devel still needed for Devstack

On Fri, Mar 27, 2015 at 09:01:12AM -0400, Adam Young wrote: > I recently got Devstack to run on RHEL. In doing so, I had to hack around > the dependency on yaml-devel (I just removed it from devstack's required > packages) > > There is no yaml-devel in EPEL or the main repos for RHEL7.1/Centos7.

Re: [openstack-dev] Is yaml-devel still needed for Devstack

On 03/27/2015 09:01 AM, Adam Young wrote: > I recently got Devstack to run on RHEL. In doing so, I had to hack > around the dependency on yaml-devel (I just removed it from devstack's > required packages) > > There is no yaml-devel in EPEL or the main repos for RHEL7.1/Centos7. > > Any idea what

[openstack-dev] Is yaml-devel still needed for Devstack

I recently got Devstack to run on RHEL. In doing so, I had to hack around the dependency on yaml-devel (I just removed it from devstack's required packages) There is no yaml-devel in EPEL or the main repos for RHEL7.1/Centos7. Any idea what the right approach is to this moving forward? Is th

Re: [openstack-dev] [Heat] Decoupling Heat integration tests from Heat tree

On 03/27/2015 06:57 AM, Pavlo Shchelokovskyy wrote: > Hi, > > On Thu, Mar 26, 2015 at 10:26 PM, Zane Bitter > wrote: > >> [snip] >> >>> 3) move the integration tests to a separate repo and use it as git >>> submodule in the main tree. The main reasons

Re: [openstack-dev] [Fuel] Nominate Irina Povolotskaya for fuel-docs core

+1 On 26 March 2015 at 19:26, Fabrizio Soppelsa wrote: > +1 definitely > > > On 03/25/2015 10:10 PM, Dmitry Borodaenko wrote: >> >> Fuelers, >> >> I'd like to nominate Irina Povolotskaya for the fuel-docs-core team. >> She has contributed thousands of lines of documentation to Fuel over >> the pa

Re: [openstack-dev] [infra] What do people think of YAPF (like gofmt, for python)?

On 03/26/2015 06:46 PM, Robert Collins wrote: > On 27 March 2015 at 09:14, Ryan Brown wrote: > >> Ooof, that's huge. If we can configure it to be less aggressive I love >> the *idea* of having everything formatted semantically, but that's a >> pretty major burden for everyone involved. > > It's

Re: [openstack-dev] [Nova][Neutron] Status of the nova-network to Neutron migration work

On 03/27/2015 05:22 AM, Thierry Carrez wrote: > Part of it is corner (or simplified) use cases not being optimally > served by Neutron, and I think Neutron could more aggressively address > those. But the other part is ignorance and convenience: that Neutron > thing is a scary beast, last time I l

Re: [openstack-dev] [Heat] Decoupling Heat integration tests from Heat tree

Hi, On Thu, Mar 26, 2015 at 10:26 PM, Zane Bitter wrote: > On 26/03/15 10:38, Pavlo Shchelokovskyy wrote: > >> Hi all, >> >> following IRC discussion here is a summary of what I propose can be done >> in this regard, in the order of increased decoupling: >> >> 1) make a separate requirements.txt

Re: [openstack-dev] [Heat] Decoupling Heat integration tests from Heat tree

Hello, As a QA engineer, I like the idea to make integration tests more independent and have an ability to package them and run against any deployed cloud, it will be very useful. But I assume, that creating a separate repository is not needed and it is enough to just collect all functional/integr

Re: [openstack-dev] [swift] swift memory usage in centos7 devstack jobs

> I'll spend a bit more time on this -- I haven't determined if it's > centos or swift specific yet -- but in the mean-time, beware of > recent pyOpenSSL But how come that same recent pyOpenSSL doesn't consume more memory on Ubuntu? Alan _

Re: [openstack-dev] mox3 WAS Re: [nova] Do we have some guidelines for mock, stub, mox when writing unit test?

> I'm working on removing mox in favor of mox3 to reduce a bit our dependency. Then mox3 should be imported to openstack namespace as suggested by Chuck in Dec 2013. Looks like last known source repository is https://github.com/emonty/pymox with last commit from Aug 2013 or did it move somewhere e

Re: [openstack-dev] [Nova][Neutron] Status of the nova-network to Neutron migration work

Kyle Mestery wrote: > On Thu, Mar 26, 2015 at 7:58 PM, Russell Bryant > wrote: > > On 03/26/2015 06:31 PM, Michael Still wrote: > > Hi, > > > > I thought it would be a good idea to send out a status update for the > > migration from nova-network to N

Re: [openstack-dev] mox3 WAS Re: [nova] Do we have some guidelines for mock, stub, mox when writing unit test?

On Fri, Mar 27 2015, Alan Pevec wrote: > What's the status of migration to mock, can mox and mox3 be dropped > from global-requirements ? I'm working on removing mox in favor of mox3 to reduce a bit our dependency. But it takes a lot of time, especially because almost no reviewer care so the patc

Re: [openstack-dev] [Fuel] fuel-dev-tools repo

Sorry, I meant [2] https://github.com/CGenie/fuel-utils/ P. On 03/27/2015 08:34 AM, Przemyslaw Kaminski wrote: > Hello, > > In accordance with the consensus that was reached on the ML I've set up > the fuel-dev-tools repository [1]. It will be the target repo to merge > my 2 private repos [2] a

[openstack-dev] [Fuel] fuel-dev-tools repo

Hello, In accordance with the consensus that was reached on the ML I've set up the fuel-dev-tools repository [1]. It will be the target repo to merge my 2 private repos [2] and [3] (I don't think it's necessary to set up 2 different repos for this now). The core reviewers are the fuel-core group.