Re: [openstack-dev] [neutron][SFC]

[Na Zhu]

I find this issue also, I filed a bug about it 
https://bugs.launchpad.net/networking-sfc/+bug/1586721
I think logical-source-port can be optional.





Regards,
Juno Zhu
IBM China Development Labs (CDL) Cloud IaaS Lab
Email: na...@cn.ibm.com
5F, Building 10, 399 Keyuan Road, Zhangjiang Hi-Tech Park, Pudong New 
District, Shanghai, China (201203)



From:   Alioune 
To: "OpenStack Development Mailing List (not for usage questions)" 

Date:   2016/06/10 22:28
Subject:Re: [openstack-dev] [neutron][SFC]



Hi Mohan,
Even if I clone the master branch of networking-sfc project,I get the 
following errir when creating flow-classifier, therefore I do precise the 
 logical-source-port.

2016-06-10 05:34:05.693 10799 ERROR neutron.api.v2.resource DBError: 
(pymysql.err.IntegrityError) (1048, u"Column 'logical_source_port' cannot 
be null") 
 
I'm trying the example in [1] 

Here is a "ovs-ofctl dump-flows" on br-int ofter creating port-chain, I 
expected to see vxlan or gre tunnel encapsulation entries as explained in 
[1], may I know why there is no tunnel entry in br-int ?

sudo ovs-ofctl dump-flows br-int
NXST_FLOW reply (xid=0x4):
 cookie=0x90444f3c8fabcbe0, duration=2840.983s, table=0, n_packets=0, 
n_bytes=0, idle_age=2840, priority=10,icmp6,in_port=16,icmp_type=136 
actions=resubmit(,24)
 cookie=0x90444f3c8fabcbe0, duration=2837.039s, table=0, n_packets=0, 
n_bytes=0, idle_age=2837, priority=10,icmp6,in_port=17,icmp_type=136 
actions=resubmit(,24)
 cookie=0x90444f3c8fabcbe0, duration=2831.688s, table=0, n_packets=0, 
n_bytes=0, idle_age=2831, priority=10,icmp6,in_port=19,icmp_type=136 
actions=resubmit(,24)
 cookie=0x90444f3c8fabcbe0, duration=2831.038s, table=0, n_packets=0, 
n_bytes=0, idle_age=2831, priority=10,icmp6,in_port=18,icmp_type=136 
actions=resubmit(,24)
 cookie=0x90444f3c8fabcbe0, duration=2801.555s, table=0, n_packets=0, 
n_bytes=0, idle_age=2801, priority=10,icmp6,in_port=20,icmp_type=136 
actions=resubmit(,24)
 cookie=0x90444f3c8fabcbe0, duration=2840.605s, table=0, n_packets=8, 
n_bytes=336, idle_age=2591, priority=10,arp,in_port=16 
actions=resubmit(,24)
 cookie=0x90444f3c8fabcbe0, duration=2836.759s, table=0, n_packets=0, 
n_bytes=0, idle_age=2836, priority=10,arp,in_port=17 actions=resubmit(,24)
 cookie=0x90444f3c8fabcbe0, duration=2831.485s, table=0, n_packets=0, 
n_bytes=0, idle_age=2831, priority=10,arp,in_port=19 actions=resubmit(,24)
 cookie=0x90444f3c8fabcbe0, duration=2830.816s, table=0, n_packets=21, 
n_bytes=882, idle_age=1605, priority=10,arp,in_port=18 
actions=resubmit(,24)
 cookie=0x90444f3c8fabcbe0, duration=2801.309s, table=0, n_packets=10, 
n_bytes=420, idle_age=545, priority=10,arp,in_port=20 
actions=resubmit(,24)
 cookie=0x90444f3c8fabcbe0, duration=15755.073s, table=0, n_packets=3241, 
n_bytes=366555, idle_age=545, priority=0 actions=NORMAL
 cookie=0x90444f3c8fabcbe0, duration=15754.687s, table=23, n_packets=0, 
n_bytes=0, idle_age=15754, priority=0 actions=drop
 cookie=0x90444f3c8fabcbe0, duration=2841.201s, table=24, n_packets=0, 
n_bytes=0, idle_age=2841, 
priority=2,icmp6,in_port=16,icmp_type=136,nd_target=fe80::f816:3eff:fe2d:c29d 
actions=NORMAL
 cookie=0x90444f3c8fabcbe0, duration=2837.177s, table=24, n_packets=0, 
n_bytes=0, idle_age=2837, 
priority=2,icmp6,in_port=17,icmp_type=136,nd_target=fe80::f816:3eff:fee0:f8ca 
actions=NORMAL
 cookie=0x90444f3c8fabcbe0, duration=2831.794s, table=24, n_packets=0, 
n_bytes=0, idle_age=2831, 
priority=2,icmp6,in_port=19,icmp_type=136,nd_target=fe80::f816:3eff:fe86:a668 
actions=NORMAL
 cookie=0x90444f3c8fabcbe0, duration=2831.150s, table=24, n_packets=0, 
n_bytes=0, idle_age=2831, 
priority=2,icmp6,in_port=18,icmp_type=136,nd_target=fe80::f816:3eff:feb4:965f 
actions=NORMAL
 cookie=0x90444f3c8fabcbe0, duration=2801.675s, table=24, n_packets=0, 
n_bytes=0, idle_age=2801, 
priority=2,icmp6,in_port=20,icmp_type=136,nd_target=fe80::f816:3eff:fe5a:3097 
actions=NORMAL
 cookie=0x90444f3c8fabcbe0, duration=2840.794s, table=24, n_packets=8, 
n_bytes=336, idle_age=2591, priority=2,arp,in_port=16,arp_spa=55.55.55.3 
actions=NORMAL
 cookie=0x90444f3c8fabcbe0, duration=2836.901s, table=24, n_packets=0, 
n_bytes=0, idle_age=2836, priority=2,arp,in_port=17,arp_spa=55.55.55.4 
actions=NORMAL
 cookie=0x90444f3c8fabcbe0, duration=2831.587s, table=24, n_packets=0, 
n_bytes=0, idle_age=2831, priority=2,arp,in_port=19,arp_spa=55.55.55.6 
actions=NORMAL
 cookie=0x90444f3c8fabcbe0, duration=2830.933s, table=24, n_packets=21, 
n_bytes=882, idle_age=1605, priority=2,arp,in_port=18,arp_spa=55.55.55.5 
actions=NORMAL
 cookie=0x90444f3c8fabcbe0, duration=2801.431s, table=24, n_packets=10, 
n_bytes=420, idle_age=545, priority=2,arp,in_port=20,arp_spa=55.55.55.8 
actions=NORMAL
 cookie=0x90444f3c8fabcbe0, duration=15754.273s, table=24, n_packets=0, 
n_bytes=0, idle_age=15754, priority=0 actions=drop


is there a link that explains how pipelines are created by SFC in br-int 
to 

Re: [openstack-dev] [nova] Let me know if you have an approved spec but unapproved blueprint

[Matt Riedemann]

On 6/12/2016 7:48 PM, joehuang wrote:

Hello,

This spec is not approved yet: https://review.openstack.org/#/c/295595/

But the BP is approved: 
https://blueprints.launchpad.net/nova/+spec/expose-quiesce-unquiesce-api

Don't know how to deal with the spec now. Is this spec killed? Should Nova 
support application level consistency snapshot for disaster recovery purpose or 
not?

Best Regards
Chaoyi Huang ( Joe Huang )

-Original Message-
From: Matt Riedemann [mailto:mrie...@linux.vnet.ibm.com]
Sent: Sunday, June 12, 2016 9:08 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [nova] Let me know if you have an approved spec but 
unapproved blueprint

I've come across several changes up for review that are tied to Newton 
blueprints which have specs approved but the blueprints in launchpad are not 
yet approved.

If you have a spec that was approved for Newton but your blueprint in launchpad 
isn't approved yet, please ping me (mriedem) in IRC or reply to this thread to 
get it approved and tracked for the Newton release.
It's important (at least to me) that we have an accurate representation of how 
much work we're trying to get done this release, especially with non-priority 
feature freeze coming up in three weeks.



Neither the spec nor the blueprint is approved. The blueprint was 
previously approved in mitaka but is not for newton, with reasons in the 
spec review for newton.


At this point we're past non-priority spec approval freeze so this isn't 
going to get in for newton. There are a lot of concerns about this one 
so it's going to be tabled for at least this release, we can revisit in 
ocata, but it adds a lot of complexity and it's more than we're willing 
to take on right now given everything else planned for this release.


--

Thanks,

Matt Riedemann


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] Let me know if you have an approved spec but unapproved blueprint

[joehuang]

Hello,

This spec is not approved yet: https://review.openstack.org/#/c/295595/

But the BP is approved: 
https://blueprints.launchpad.net/nova/+spec/expose-quiesce-unquiesce-api

Don't know how to deal with the spec now. Is this spec killed? Should Nova 
support application level consistency snapshot for disaster recovery purpose or 
not?

Best Regards
Chaoyi Huang ( Joe Huang )

-Original Message-
From: Matt Riedemann [mailto:mrie...@linux.vnet.ibm.com] 
Sent: Sunday, June 12, 2016 9:08 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [nova] Let me know if you have an approved spec but 
unapproved blueprint

I've come across several changes up for review that are tied to Newton 
blueprints which have specs approved but the blueprints in launchpad are not 
yet approved.

If you have a spec that was approved for Newton but your blueprint in launchpad 
isn't approved yet, please ping me (mriedem) in IRC or reply to this thread to 
get it approved and tracked for the Newton release. 
It's important (at least to me) that we have an accurate representation of how 
much work we're trying to get done this release, especially with non-priority 
feature freeze coming up in three weeks.

-- 

Thanks,

Matt Riedemann


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Higgins][Zun] Project roadmap

[Hongbin Lu]

Hi team,

During the team meetings these weeks, we collaborated the initial project 
roadmap. I summarized it as below. Please review.

* Implement a common container abstraction for different container runtimes. 
The initial implementation will focus on supporting basic container operations 
(i.e. CRUD).
* Focus on non-nested containers use cases (running containers on physical 
hosts), and revisit nested containers use cases (running containers on VMs) 
later.
* Provide two set of APIs to access containers: The Nova APIs and the 
Zun-native APIs. In particular, the Zun-native APIs will expose full container 
capabilities, and Nova APIs will expose capabilities that are shared between 
containers and VMs.
* Leverage Neutron (via Kuryr) for container networking.
* Leverage Cinder for container data volume.
* Leverage Glance for storing container images. If necessary, contribute to 
Glance for missing features (i.e. support layer of container images).
* Support enforcing multi-tenancy by doing the following:
** Add configurable options for scheduler to enforce neighboring containers 
belonging to the same tenant.
** Support hypervisor-based container runtimes.

The following topics have been discussed, but the team cannot reach consensus 
on including them into the short-term project scope. We skipped them for now 
and might revisit them later.
* Support proxying API calls to COEs.
* Advanced container operations (i.e. keep container alive, load balancer 
setup, rolling upgrade).
* Nested containers use cases (i.e. provision container hosts).
* Container composition (i.e. support docker-compose like DSL).

NOTE: I might forgot and mis-understood something. Please feel free to point 
out if anything is wrong or missing.

Best regards,
Hongbin
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc][pbr][packaging][all] Definition of Data Files (config) in setup.cfg

[Monty Taylor]

On 06/11/2016 10:13 PM, Robert Collins wrote:
> On 12 June 2016 at 11:31, Thomas Goirand  wrote:
>> On 06/11/2016 05:02 AM, Robert Collins wrote:
> ...
>> Then keystone.conf ends up installed in /usr/etc/keystone when setup.py
>> install is used. With this configuration, it would be installed
>> correctly within a venv.
> 
> Except that noone uses 'setup.py install' - *except* for rpm and dpkg
> packagers. Everyone else uses pip, and pip won't pass new options.
> Worse, pip creates wheels and then installs the wheels, and until PEP
> 491 [1] is finalised and implemented, wheels won't change their
> behaviour.
> 
>> If instead we have:
>> [files]
>> data_files =
>> /etc/keystone/keystone.conf = etc/keystone.conf.sample
>>
>> [ notice the leading / for the destination... ]
>>
>> Then keystone.conf gets installed on the root of the filesystem instead
>> of properly be installed within the venv. Though it's installed properly
>> for distributions in /etc/keystone.
>>
>> To address this problem, Julien Danjou attempted to add a --sysconfdir
>> option in PBR. Though it was rejected by Robert, who wrote in the code
>> review that it should be addressed within setuptools or disutils.
> 
> Not should. Must be. A local change to pbr won't solve the problem,
> except for the very narrow case of package creators (who already have
> excellent tools - its a single one-line file to fix it on Debian, and
> I presume roughly the same on RPM distributions). It certainly won't
> solve it for virtual envs.
> 
>> If I got the above facts wrong, feel free to let everyone know. Now, my
>> reply to Robert...
>> === End of context ===
>>
>> Robert,
>>
>> I do not agree that we *must* wait until politics are discussed and a
> 
> I'm going to quote what I said back in February - 4 months ago: "Ok,
> so here's where I got to:
> 
> - wheel doesn't support or understand /etc per se
> - setuptools and distutils disagree on the meaning of data files paths
> - wheel takes the distutils value today
> - pep 491, which seems moribund, is an attempt to explicitly support
> sysconf dir's like /etc, and thats what is needed in general.
> 
> I think the way forward to get this available as a sensible,
> supportable feature is to discuss it on the distutils-sig list, and
> that community can help figure out a design, including the backwards
> compat implications."
> 
> I don't -2 lightly, and I did considerable research into this patch
> before leaving the -2 in place.
> 
> With regards to politics and consensus in the upstream packaging
> community - well, it would move faster if folk who are distro folk and
> thus want to see the mess sorted were collaborating there: its been 4
> months since Julien's original patch and no discussion has taken
> place, nor has anyone volunteered in that community to do the work.
> Its not super hard, and I'd be happy to guide anyone interested in
> reviving PEP 491 (or drafting an alternative). What I'm not interested
> in doing is adding an ineffective hack to pbr which we'll have to
> maintain for an extended period, which isn't actually in pbr's domain
> (pbr exists to prevent duplication amongst OpenStack projects and
> provide solid and sane policy, not to replace wheel and setuptools).
> I'm sorry if that sounds like a hard line, but we had an ongoing
> series of bugs in pbr - the gift that keeps on giving - from the
> previous attempts to work around defects upstream of pbr rather than
> fixing those defects directly, which is a much better strategy : less
> cost, less technical debt, benefits the entire community, gets better
> outcomes.

I'm going to have to second what Robert says here.

Also - I would like to add the following.

Having pip or setup.py install install a config file is at best a
strange thing to want, as it does not have the mechanisms to deal with
templating in values, or dealing with conflicts with locally changed
file values on upgrades.

Consider the case where a person does "pip install keystone" to install
keystone.

If that command installs keystone.conf into /etc/keystone - there is
_NO_ way that that config file will have any useful values. The user
will then edit the file to add the values into the file that need to be
added. Then, the user will, at a later point in time do "pip install -U
keystone" to upgrade the keystone installation.

What does pip do? Does it overwrite /etc/keystone/keystone.conf? What
about the user's values? Does it NOT overwrite
/etc/keystone/keystone.conf? Why not?

This is, btw, why dpkg and rpm and friends exist. It's their job.

Now, you might argue, there are files, such as the paste config files
which are configs that the software needs to install to be useful.

I will call hogwash on that. That we install files such as that which
are actually code has been a deployer nightmare since day one, and the
solution is not to make pip smarter, it's to stop installing such files.

NOW - if it's quite literally a file that just 

Re: [openstack-dev] [Kuryr] [Neutron] Controlling security groups through Kuryr's libnetwork plugin [was: Waiting until Neutron PortisActive]

[Mike Spreitzer]

Antoni Segura Puimedon  wrote on 06/11/2016 
07:39:41 PM:

> Well, with a label you can make the Neutron Port have an SG that 
> forbids pinging.

Wait, what?  Labels on what can do what?

Thanks,
Mike


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Random IP address allocations

[Jay Pipes]

On 06/10/2016 12:24 PM, Carl Baldwin wrote:

On Fri, Jun 10, 2016 at 2:40 AM, Gary Kotton  wrote:

Hi,
The patch https://review.openstack.org/#/c/292207/ has broken decomposed
plugins. I am not sure if we can classify this as a API change – basically


Can you be more specific about how it "has broken decomposed plugins?"
  What's broken?  There are no links or anything.


the IP address allocation model has changed. So someone prior to the patch
could create a network and expect addresses A, B and C to be allocated in


Nothing has ever been documented indicating that you can expect this.
People just noticed a pattern and assumed they could count on it.
Anyone depending on this has been depending on an implementation
detail.  This has come up before [1].  I think we need flexibility to
allocate IPs as we need to to scale well.  I don't think we should be
restricted by defacto patterns in IP allocation that people have come
to depend on.

Any real world use should always take in to account the fact there
there may be other users of the system trying to get IP allocations in
parallel.  To them, the expected behavior doesn't change: they could
get any address from a window of the next few available addresses.
So, the problem here must be in tests running in a contrived setup
making too many assumptions.


that order. Now random addresses will be allocated.


After nearly 3 years of dealing with DB contention around IP
allocation, this is the only way that we've been able to come up with
to finally relieve it.  When IPAM gets busy, there is a lot of racing
to get that next IP address which results in contention between worker
processes.  Allocating from a random window relieves it considerably.


I think that this requires some discussion and we should consider reverting
the patch. Maybe I am missing something here but this may break people who
are working according the existing outputs of Neutron according to existing
behavior (which may have been wrong from the start).


Some discussion was had [2][3] leading up to this change.  I didn't
think we needed broader discussion because we've already established
that IP allocation is an implementation detail [1].  The only contract
in place for IP allocation is that an IP address will be allocated
from within the allocation_pools defined on the subnet if available.

I am against reverting this patch as I have stated on the review to
revert it [4].


++ I, too, am against reverting it. If code was relying on a 
non-contractual assumption about the ordering of IP addresses, that code 
should be changed.


-jay

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [qa] Tempest unstable interfaces in plugins

[Assaf Muller]

On Sat, Jun 11, 2016 at 4:04 PM, Ken'ichi Ohmichi  wrote:
> 2016-06-10 17:01 GMT-07:00 Assaf Muller :
>> On Fri, Jun 10, 2016 at 12:02 PM, Andrea Frittoli
>>  wrote:
>>> Dear all,
>>>
>>> I'm working on making the client manager in Tempest a stable interface, so
>>> that in future it may be used safely by plugins to easily gain access
>>> service clients [0].
>>>
>>> This work inevitably involves changing the current client manager (unstable)
>>> interface.
>>> Several tempest plugins in OpenStack already consume that interface (namely
>>> the manager.Manager class) [1], so my work is likely to break them.
>>>
>>> I would ask the people maintaining the plugins to be careful about using
>>> unstable interfaces, as they are likely to change, especially since we're
>>> working on converting them to stable.
>>>
>>> If you maintain a plugin (in OpenStack or outside of OpenStack) that is
>>> likely to be affected by my work, please keep an eye on my gerrit review
>>> [0], leave a comment there or ping me on IRC (andreaf), I would very much
>>> like to make sure the transition is as painless as possible for everyone.
>>
>> FWIW this doesn't seem to break Neutron:
>> https://review.openstack.org/#/c/328398/.
>>
>> I would appreciate it if changes are made in a backwards compatible
>> manner (Similar to this:
>> https://review.openstack.org/#/c/322492/13/tempest/common/waiters.py)
>> so that projects with Tempest plugins may adapt and not break voting
>> jobs. The reason projects are using interfaces outside of tempest.lib
>> is that that's all there is, and the alternative of copy/pasting in to
>> the repo isn't amazing.
>
> Yeah, copy/pasting of tempest code which is outside of tempest.lib is
> not amazing.
> However, that is a possible option to continue gate testing on each project.
> We did that to pass Ceilometer gate as a workaround[1], then
> we(QA-team) knew what lib code is necessary and are concentrating on
> making the code as tempest.lib.
> After finishing, we can remove the copy/pasting code from Ceilometer
> by using new tempest.lib code.
>
> During this work, I feel it is nice to add a new hacking rule to block
> importing the local tempest code from other projects.
> From viewpoints of outside of QA team, it would be difficult to know
> the stability of tempest code I guess.
> Then by adding a rule, most projects know that and it is nice to
> ignore it by understanding the stability.

I added a comment on the patch, but when I looked in to this a couple
of months ago, Neutron, Ironic and Heat all imported
tempest.{|test|manager}.

>
> The hacking rule patch is https://review.openstack.org/#/c/328651/
> And tempest itself needs to ignore that if merging the rule ;-) [2]
>
> Thanks
> Ken Ohmichi
> ---
> [1]: https://review.openstack.org/#/c/325727/
> [2]: https://review.openstack.org/#/c/328652/
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [nova] Let me know if you have an approved spec but unapproved blueprint

[Matt Riedemann]

I've come across several changes up for review that are tied to Newton 
blueprints which have specs approved but the blueprints in launchpad are 
not yet approved.


If you have a spec that was approved for Newton but your blueprint in 
launchpad isn't approved yet, please ping me (mriedem) in IRC or reply 
to this thread to get it approved and tracked for the Newton release. 
It's important (at least to me) that we have an accurate representation 
of how much work we're trying to get done this release, especially with 
non-priority feature freeze coming up in three weeks.


--

Thanks,

Matt Riedemann


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [charms] Re-licensing OpenStack charms under Apache 2.0

[Andrey Pavlov]

Hello James,

No problem on my side.

Regards,
Andrey.

On Wed, Jun 8, 2016 at 1:20 PM, James Page  wrote:
> Hi
>
> We're currently blocked on becoming an OpenStack project under the big-tent
> by the licensing of the 26 OpenStack charms under GPL v3.
>
> I'm proposing that we re-license the following code repositories as Apache
> 2.0:
>
>   charm-ceilometer
>   charm-ceilometer-agent
>   charm-ceph
>   charm-ceph-mon
>   charm-ceph-osd
>   charm-ceph-radosgw
>   charm-cinder
>   charm-cinder-backup
>   charm-cinder-ceph
>   charm-glance
>   charm-hacluster
>   charm-heat
>   charm-keystone
>   charm-lxd
>   charm-neutron-api
>   charm-neutron-api-odl
>   charm-neutron-gateway
>   charm-neutron-openvswitch
>   charm-nova-cloud-controller
>   charm-nova-compute
>   charm-odl-controller
>   charm-openstack-dashboard
>   charm-openvswitch-odl
>   charm-percona-cluster
>   charm-rabbitmq-server
>   charm-swift-proxy
>   charm-swift-storage
>
> The majority of contributors are from Canonical (from whom I have permission
> to make this switch) with a further 18 contributors from outside of
> Canonical who I will be directly contacting for approval in gerrit as
> reviews are raised for each repository.
>
> Any new charms and supporting repositories will be licensed under Apache 2.0
> from the outset.
>
> Cheers
>
> James
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Kind regards,
Andrey Pavlov.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev