Re: [openstack-dev] [Ironic] backwards compat issue with PXEDeply and AgentDeploy drivers

[Ramakrishnan G]

Well it's nice to fix, but I really don't know if we should be fixing it.
As discussed in one of the Ironic meetings before, we might need to define
what is our driver API or SDK or DDK or whatever we choose to call it .
Please see inline for my thoughts.

On Tue, Oct 6, 2015 at 5:54 AM, Devananda van der Veen <
devananda@gmail.com> wrote:

> tldr; the boot / deploy interface split we did broke an out of tree
> driver. I've proposed a patch. We should get a fix into stable/liberty too.
>
> Longer version...
>
> I was rebasing my AMTTool driver [0] on top of master because the in-tree
> one still does not work for me, only to discover that my driver suddenly
> failed to deploy. I have filed this bug
>   https://bugs.launchpad.net/ironic/+bug/1502980
> because we broke at least one out of tree driver (mine). I highly suspect
> we've broken many other out of tree drivers that relied on either the
> PXEDeploy or AgentDeploy interfaces that were present in Kilo release. Both
> classes in Liberty are making explicit calls to "task.driver.boot" -- and
> kilo-era driver classes did not define this interface.
>


I would like to think more about what really our driver API is ? We have a
couple of well defined interfaces in ironic/drivers/base.py which people
may follow, implement an out-of-tree driver, make it a stevedore entrypoint
and get it working with Ironic.

But

1) Do we promise them that in-tree implementations of these interfaces will
always exist.  For example in boot/deploy work done in Liberty, we removed
the class PxeDeploy [1].  It actually got broken down to PXEBoot and
ISCSIDeploy.  In the first place, do we guarantee that they will exist for
ever in the same place with the same name ? :)

2) Do we really promise the in-tree implementations of these interfaces
will behave the same way ? For example, the broken stuff AgentDeploy which
is an implementation of our DeployInterface.  Do we guarantee that this
implementation will always keep doing what ever it was every time code is
rebased ?

[1] https://review.openstack.org/#/c/166513/19/ironic/drivers/modules/pxe.py



>
> I worked out a patch for the AgentDeploy driver and have proposed it here:
>   https://review.openstack.org/#/c/231215/1
>
> I'd like to ask folks to review it quickly -- we should fix this ASAP and
> backport it to stable/liberty before the next release, if possible. We
> should also make a similar fix for the PXEDeploy class. If anyone gets to
> this before I do, please reply here and let me know so we don't duplicate
> effort.
>


This isn't going to be as same as above as there is no longer a PXEDeploy
class any more.  We might need to create a new class PXEDeploy which
probably inherits from ISCSIDeploy and has task.driver.boot worked around
in the same way as the above patch.



>
> Also, Jim already spotted something in the review that is a bit
> concerning. It seems like the IloVirtualMediaAgentVendorInterface class
> expects the driver it is attached to *not* to have a boot interface and
> *not* to call boot.clean_up_ramdisk. Conversely, other drivers may be
> expecting AgentVendorInterface to call boot.clean_up_ramdisk -- since that
> was its default behavior in Kilo. I'm not sure what the right way to fix
> this is, but I lean towards updating the in-tree driver so we remain
> backwards-compatible for out of tree drivers.
>
>
> -Devananda
>
> [0] https://github.com/devananda/ironic/tree/new-amt-driver
>
>
> __
> 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

Re: [openstack-dev] [neutron] New cycle started. What are you up to, folks?

[Vikram Choudhary]

On my top of mind for Mitaka:


*Introducing common Classifier Model [1]:*Currently, neutron service/s
(e.g. Service Function Chaining, QoS, Tap as a Service, FWaaS, Security
Group etc) which requires traffic classification defines their own
classifier model. This introduces redundancy. In order to address
redundancy and easier code maintenance, we propose to have a common
classifier resource in Neutron which can be leveraged by multiple services
in turn.


*Enhancing QoS functionality [2]:*
It is great to have QoS framework merged to Neutron during last release
cycle. Now it's the time to consolidate and make the existing QoS
functionality richer by implementing few of the simple and important ideas
listed below:
-> Support for Linux-Bridge driver. *[2a]*
-> Adding VLAN priority tagging functionality.* [2b]*
-> Adding ECN functionality. *[2c]*


*Enhancing BGP framework [3]:*
Adding to Carl, I would also like to analyze
-> How we can merge ongoing projects like BGPVPN *[3a]* and Edge VPN *[3b]*
with neutron's BGP framework. Will it be reasonable doing that?
-> Route policing
*[3d]*
-> Advertising VPN routes. *[3e]*

*Stabilizing networking-onos [4]:*
networking-onos was introduced in the last liberty cycle. We eye on the
following items for this project:
-> Enhance current stability and reliability. *[4a]*
-> Introduce devstack support. *[4b]*
-> Develop networking-sfc driver and provide SFC PoC using networking-sfc
and ONOS controller.


*Stabilizing networking-sfc [5]:*
Will work on the current patches*[5a]* and get the code-in.

*References:*
[1].. https://bugs.launchpad.net/neutron/+bug/1476527

[2]..
https://github.com/openstack/neutron/blob/master/doc/source/devref/quality_of_service.rst
[2a]..
https://blueprints.launchpad.net/neutron/+spec/ml2-lb-ratelimit-support
[2b].. https://blueprints.launchpad.net/neutron/+spec/vlan-802.1p-qos
[2c]..
https://blueprints.launchpad.net/neutron/+spec/explicit-congestion-notification

[3].. https://blueprints.launchpad.net/neutron/+spec/bgp-dynamic-routing
[3a].. https://github.com/openstack/networking-bgpvpn
[3b].. https://github.com/stackforge/networking-edge-vpn
[3c]..
https://blueprints.launchpad.net/neutron/+spec/neutron-route-policy-support-for-dynamic-routing-protocol
[3d]..
https://blueprints.launchpad.net/neutron/+spec/prefix-clashing-issue-with-dynamic-routing-protocol

[4].. https://github.com/openstack/networking-onos
[4a].. https://bugs.launchpad.net/networking-onos
[4b].. https://bugs.launchpad.net/networking-onos/+bug/1488907

[5].. https://github.com/openstack/networking-sfc
[5a]..
https://review.openstack.org/#/q/status:open+project:openstack/networking-sfc+branch:master+topic:networking-sfc,n,z

Thanks
Vikram

On Tue, Oct 6, 2015 at 6:08 AM, Carl Baldwin  wrote:

> (Cross-posting to the operators list for feedback)
>
> Thank you Ihar for starting this up.  In the absence of any kind of
> blog or other outlet of my own to disseminate this, let me share my
> plans here...
>
> Routed Networks:
>
> My plans for Mitaka (and beyond) are around routed networks.  During
> Liberty, I saw the request from operators in the form of an RFE [1]
> (one of the first in the new RFE process I think).  The request
> resonated with me because I had been thinking of doing this since
> almost the day I started working on HP's cloud.  We went on to define
> use cases around this to understand what operators are looking for
> [2].  It seemed to me like we were on the right track.
>
> I went to work and put up a spec which proposed using provider
> networks for each of the network segments.  It used one more instance
> of a Network for the routed network and a sort of provider router
> which connected it to the provider Networks for the segments.  This
> was a short cut and the community called me on it [3].  Despite some
> existing leakage of L3 in to the supposedly L2 only Network model, the
> community wants to keep Networks L2 only.  This makes a lot of sense
> and I think we'll end up with a better long-term solution even if we
> need to go through a little more pain to get there.  I've started a
> new proposal [4] which adds two new L3 constructs to the model.  They
> are RoutedNetworkGroup and SubnetGroup.
>
> A RoutedNetworkGroup groups Networks.  It represents a bunch of L2
> segments that are mutually reachable via L3.  In other words, there
> are a bunch of L2 networks, each with its own subnet(s).  All of the
> subnets of the other networks are reachable through the default routes
> of each of the networks.
>
> We will be able to create ports using a group as a hint instead of
> specifying a Network explicitly.  To accomplish this, the proposal
> adds a new mechanism to map hosts to Networks.  In our mid-cycle, we
> talked through a flow where Neutron could filter host candidates given
> a group as a hint based on IP availability on the underlying Networks.
> Port creation would be passed the same group hint and a specific host
> to create a new port.
>
> My 

[openstack-dev] [heat] perfomance benchmark metrics of heat-api

[ESWAR RAO]

Hi all,

Has anyone done any performance tests on heat-api servers on any standard
setup so as to know how many stack requests it can handle before it can
stumble so that we can deploy scaling of heat-servers ??

Thanks
Eswar
__
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] [ironic] weekly subteam status report

[Ruby Loo]

Hi,

Following is the subteam report for Ironic. As usual, this is pulled
directly from the Ironic whiteboard[0] and formatted.

Bugs (dtantsur)

- (diff with Sep 28, no diff for inspector)
- Open: 137 (+2). 4 new (-5), 34 in progress (-2), 0 critical, 7 high
and 13 incomplete (+4)
- Nova bugs with Ironic tag: 25 (+1). 1 new (+1), 0 critical, 1 high
- Inspector bugs: 12. 0 new, 0 critical, 4 high
- Need help with triaging:
- https://bugs.launchpad.net/ironic/+bug/1444631
- https://bugs.launchpad.net/ironic/+bug/1479128
- IPA got its own bug tracker:
https://bugs.launchpad.net/ironic-python-agent
- I moved all bugs I found to be related to the ramdisk part there
- http://ironic-divius.rhcloud.com/ now shows IPA bugs
- http://ironic-divius.rhcloud.com/ got a new revamp, now it should be
easier to spot what requires attention


Neutron/Ironic work (jroll)

- testing is ongoing, working well, just a few things to work out
- we can begin reviewing the patch chain
https://review.openstack.org/#/q/status:open+project:openstack/ironic+branch:master+topic:bp/network_provider,n,z
- nova patch:
https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/ironic-ml2-integration,n,z
- client patch:
https://review.openstack.org/#/q/status:open+project:openstack/python-ironicclient+branch:master+topic:bp/ironic-ml2-integration,n,z
- no work has been done yet on gate testing AFAIK :(
- work etherpad https://etherpad.openstack.org/p/ironic-neutron-mid-cycle


ironic-lib adoption (dtantsur)
==
- There are still patches syncing changes from ironic to ironic-lib, please
land them ASAP
- Patch to Ironic  to make notes in functions that are moving to
ironic-lib: https://review.openstack.org/231092
- ironic patch to use ironic-lib: https://review.openstack.org/#/c/184443/


Testing/Quality (jlvillal/lekha/krtaylor)

- Had IRC meeting with jlvillal/lekha/krtaylor discussing functional
testing.
- Patch submitted and merged to prepare for functional testing.
- Discovered mimic is not yet Python 3 compatible. lekha is working on
Python 3 compatibility as not allowed to add it to global-requierements
until it is.


Inspector (dtansur)
===
- ironic-inspector 2.2.1 was released to fix a critical issue (thanks
TheJulia for reporting)


Bifrost (TheJulia)
=
- Work begining to include support for inspector in a user deployment
process.


webclient (krotscheck / betherly)
=
- work has begun upstream to make the horizon panel for ironic
- Horizon to Ironic API layer in Python has been written
- corresponding Ironic API layer in Angular in progress


Drivers
==

AMT (lintan)

- [deva] in-tree pxe_amt driver still having serious issues with my NUC, so
I've updated https://github.com/devananda/ironic/tree/new-amt-driver for
liberty

iRMC (naohirot)
--
-
https://review.openstack.org//#/q/owner:+naohirot%2540jp.fujitsu.com+status:+open,n,z
- Status: Reactive (solicited for core team's review)
- New boot driver interface for iRMC drivers (bp/new-boot-interface)
- Enhance Power Interface for Soft Reboot and NMI
(bp/enhance-power-interface-for-soft-reboot-and-nmi)
- iRMC out of band inspection (bp/ironic-node-properties-discovery)



Until next week,
--ruby

[0] https://etherpad.openstack.org/p/IronicWhiteBoard
__
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] [TripleO] meeting tomorrow

[Dan Prince]

Our team meeting is tomorrow at 14:00 UTC.

I made a couple changes to the agenda this week and added a new
sections called "Review Highlights" which I hope will help us discuss
and move forward some patches that look promising:

https://wiki.openstack.org/wiki/Meetings/TripleO#Review_Highlights
If this goes well perhaps we can rotate in other reviews each week that
might benefit from team discussion (or simply getting extra attention).

Hope to talk to you all tomorrow.

Dan

__
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] New cycle started. What are you up to, folks?

[Carl Baldwin]

(Cross-posting to the operators list for feedback)

Thank you Ihar for starting this up.  In the absence of any kind of
blog or other outlet of my own to disseminate this, let me share my
plans here...

Routed Networks:

My plans for Mitaka (and beyond) are around routed networks.  During
Liberty, I saw the request from operators in the form of an RFE [1]
(one of the first in the new RFE process I think).  The request
resonated with me because I had been thinking of doing this since
almost the day I started working on HP's cloud.  We went on to define
use cases around this to understand what operators are looking for
[2].  It seemed to me like we were on the right track.

I went to work and put up a spec which proposed using provider
networks for each of the network segments.  It used one more instance
of a Network for the routed network and a sort of provider router
which connected it to the provider Networks for the segments.  This
was a short cut and the community called me on it [3].  Despite some
existing leakage of L3 in to the supposedly L2 only Network model, the
community wants to keep Networks L2 only.  This makes a lot of sense
and I think we'll end up with a better long-term solution even if we
need to go through a little more pain to get there.  I've started a
new proposal [4] which adds two new L3 constructs to the model.  They
are RoutedNetworkGroup and SubnetGroup.

A RoutedNetworkGroup groups Networks.  It represents a bunch of L2
segments that are mutually reachable via L3.  In other words, there
are a bunch of L2 networks, each with its own subnet(s).  All of the
subnets of the other networks are reachable through the default routes
of each of the networks.

We will be able to create ports using a group as a hint instead of
specifying a Network explicitly.  To accomplish this, the proposal
adds a new mechanism to map hosts to Networks.  In our mid-cycle, we
talked through a flow where Neutron could filter host candidates given
a group as a hint based on IP availability on the underlying Networks.
Port creation would be passed the same group hint and a specific host
to create a new port.

My current understanding is that this will meet operators requirements
to allow users to choose where to boot a VM based on the L3 network so
that they don't have to be aware of the segments.  I'm looking to get
confirmation on this.  I've spoken to Kris Lindgren about this and it
seems promising.

A SubnetGroup groups subnets.  I don't think the Subnet model in
Neutron does a good job of representing L3.  First, floating ips
connected to Network instead of Subnet, but floating ips are really an
L3 thing!  Second, an L3 network often has more than just one cidr.
With ipv4 specifically, it is a collection of cidrs together that is
important.  The current model doesn't allow a group of subnets without
a Network.  The SubnetGroup object fills this gap.  It groups Subnets;
floating IPs will hang off of these instead of Networks; and they can
be owned by Networks or RoutedNetworkGroups.  One day, they will also
stand alone to represent a pure L3-only network (e.g. Calico).

This new model will allow Neutron routers to connect to an L3 network,
host floating IPs from the L3 network, and even allow routing directly
to tenant networks without NAT.

BGP:

The BGP work is being led by Ryan Tidwell and Vikram Choudhary and is
discussed weekly in the L3 team meeting [5].  I plan to continue
giving my full support to this effort as it aligns very nicely with
the routed networks work.

Connecting Neutron routers to an L3 network needs one more thing to
work.  The L3 network needs to know the next hop address for any
routes behind them.  This includes floating ips and tenant networks.
This can be accomplished by injecting routes in to the routers, a
dynamic routing protocol, proxy arp, or whatever else.  The BGP work
being done aims to fill this gap.  In short, it turns Neutron in to a
BGP speaker to the L3 network.

Floating IPs:

This is mostly future work.  In Neutron today, a floating IP is an IP
whose traffic goes to a Neutron router and is a 1-1 NAT to a private
IP on the tenant network.  I'd like to generalize this concept.  For
example, DNAT could be done per TCP/UDP port to different internal
ports/addresses.  Gal Sagie has posted a spec something like this [6].

Who says floating ips have to mean NAT?  I've seen how one operator
does floating ips by instructing the VM to accept the floating IP
address as one of its own.  We could also do NAT at the port on the
compute host if the VM instance doesn't understand what to do with it.
The point is, why does the router have to be involved, especially if
we now have routed networks and BGP to work with?

We could also route more than one address to an instance or even whole
subnets.  Floating subnets, heh.  This might be useful for containers
running inside of instances and I actually talked to a few people at
LinuxCon who would like to see this happen.

There is al

Re: [openstack-dev] [magnum] New Core Reviewers

[Adrian Otto]

Team,

In accordance with our consensus and the current date/time, I hereby welcome 
Vilobh and Hua as new core reviewers, and have added them to the magnum-core 
group. I will announce this addition at tomorrow’s team meeting at our new time 
of 1600 UTC (no more alternating schedule, remember?).

Thanks,

Adrian

On Oct 1, 2015, at 7:33 PM, Jay Lau 
mailto:jay.lau@gmail.com>> wrote:

+1 for both! Welcome!

On Thu, Oct 1, 2015 at 7:07 AM, Hongbin Lu 
mailto:hongbin...@huawei.com>> wrote:
+1 for both. Welcome!

From: Davanum Srinivas [mailto:dava...@gmail.com]
Sent: September-30-15 7:00 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [magnum] New Core Reviewers

+1 from me for both Vilobh and Hua.

Thanks,
Dims

On Wed, Sep 30, 2015 at 6:47 PM, Adrian Otto 
mailto:adrian.o...@rackspace.com>> wrote:
Core Reviewers,

I propose the following additions to magnum-core:

+Vilobh Meshram (vilobhmm)
+Hua Wang (humble00)

Please respond with +1 to agree or -1 to veto. This will be decided by either a 
simple majority of existing core reviewers, or by lazy consensus concluding on 
2015-10-06 at 00:00 UTC, in time for our next team meeting.

Thanks,

Adrian Otto
__
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



--
Davanum Srinivas :: https://twitter.com/dims

__
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




--
Thanks,

Jay Lau (Guangya Liu)
__
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] [Ironic] backwards compat issue with PXEDeply and AgentDeploy drivers

[Devananda van der Veen]

tldr; the boot / deploy interface split we did broke an out of tree driver.
I've proposed a patch. We should get a fix into stable/liberty too.

Longer version...

I was rebasing my AMTTool driver [0] on top of master because the in-tree
one still does not work for me, only to discover that my driver suddenly
failed to deploy. I have filed this bug
  https://bugs.launchpad.net/ironic/+bug/1502980
because we broke at least one out of tree driver (mine). I highly suspect
we've broken many other out of tree drivers that relied on either the
PXEDeploy or AgentDeploy interfaces that were present in Kilo release. Both
classes in Liberty are making explicit calls to "task.driver.boot" -- and
kilo-era driver classes did not define this interface.

I worked out a patch for the AgentDeploy driver and have proposed it here:
  https://review.openstack.org/#/c/231215/1

I'd like to ask folks to review it quickly -- we should fix this ASAP and
backport it to stable/liberty before the next release, if possible. We
should also make a similar fix for the PXEDeploy class. If anyone gets to
this before I do, please reply here and let me know so we don't duplicate
effort.

Also, Jim already spotted something in the review that is a bit concerning.
It seems like the IloVirtualMediaAgentVendorInterface class expects the
driver it is attached to *not* to have a boot interface and *not* to call
boot.clean_up_ramdisk. Conversely, other drivers may be expecting
AgentVendorInterface to call boot.clean_up_ramdisk -- since that was its
default behavior in Kilo. I'm not sure what the right way to fix this is,
but I lean towards updating the in-tree driver so we remain
backwards-compatible for out of tree drivers.


-Devananda

[0] https://github.com/devananda/ironic/tree/new-amt-driver
__
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] [cinder][neutron][all] New third-party-ci testing requirements for OpenStack Compatible mark

[Armando M.]

On 29 September 2015 at 08:28, Chris Hoge  wrote:

> On Sep 29, 2015, at 8:04 AM, Erlon Cruz  wrote:
>
>
> Hi Cris,
>
> There are some questions that came to my mind.
>
> Cinder has near zero tolerance to backends that does not have a CI
> running. So, can one assume that all drivers in Cinder will have the
> "OpenStack Compatible" seal?
>
>
> One of the reasons we started with Cinder was because they have
> have an existing program that is well maintained. Any driver passing
> CI becomes eligible for the "OpenStack Compatible” mark. It’s not
> automatic, and still needs a signed agreement with the Foundation.
>

> When you say that the driver have to 'pass' the integration tests, what
> tests do you consider? All tests in tempest? All patches? Do you have any
> criteria to determine if a backend is passing or not?
>
>
> We’re letting the project drive what tests need to be passed. So,
> taking a look at this dashboard[1] (it’s one of many that monitor
> our test systems) the drivers are running the dsvm-tempest-full
> tests. One of the things that the tests exercise, and we’re interested
> in from the driver standpoint, are both the user-facing Cinder APIs
> as well as the driver-facing APIs.
>

> For Neutron, which we would like to help roll out in the coming year,
> this would be a CI run that is defined by the Neutron development
> team. We have no interest in dictating to the developers what should
> be run. Instead, we want to adopt what the community considers
> to be the best-practices and standards for drivers.
>

We've experienced that tracking the CI's outcome on a per-commit basis can
only lead to insanity, at least as far as Neutron is concerned.

I have been mulling over the idea (I am sure I am not the only one) that
compliance should be sought and validated at specific milestones of
interest (when the stable branch is cut? When the milestone RC is ready?
etc). We can then collect the outcome of all the CI's reporting back,
vetting the output, verifying who is bogus and who isn't etc. The
post-processing will inevitably require some degree of manual intervention.
We can also ask for those results to be persistent for longer.

Is it something that would be acceptable?

Obviously the first step for us, Neutron, is to come up with a testing
suite(s) that's representative of all the various flavors of support that a
networking solution can provide when it claims to be integrated with
Neutron.


>
> About this "OpenStack Compatible" flag, how does it work? Will you hold a
> list with the Compatible vendors? Is anything a vendor need to to in order
> to use this?
>
>
> “OpenStack Compatible” is one of the trademark programs that is
> administered by the Foundation. A company that want to apply the
> OpenStack logo to their product needs to sign a licensing agreement,
> which gives them the right to use the logo in their marketing materials.
>
> We also create an entry in the OpenStack Marketplace for their
> product, which has information about the company and the product, but
> also information about tests that the product may have passed. The
> best example I can give right now is with the “OpenStack Powered”
> program, where we display which Defcore guideline a product has
> successfully passed[2].
>
> Chris
>
> [1] http://ci-watch.tintri.com/project?project=cinder&time=24+hours
> [2] For example:
> http://www.openstack.org/marketplace/public-clouds/unitedstack/uos-cloud
>
> Thanks,
> Erlon
>
> On Mon, Sep 28, 2015 at 5:55 PM, Kyle Mestery  wrote:
>
>> The Neutron team also discussed this in Vancouver, you can see the
>> etherpad here [1]. We talked about the idea of creating a validation suite,
>> and it sounds like that's something we should again discuss in Tokyo for
>> the Mitaka cycle. I think a validation suite would be a great step forward
>> for Neutron third-party CI systems to use to validate they work with a
>> release.
>>
>> [1] https://etherpad.openstack.org/p/YVR-neutron-third-party-ci-liberty
>>
>> On Sun, Sep 27, 2015 at 11:39 AM, Armando M.  wrote:
>>
>>>
>>>
>>> On 25 September 2015 at 15:40, Chris Hoge  wrote:
>>>
 In November, the OpenStack Foundation will start requiring vendors
 requesting
 new "OpenStack Compatible" storage driver licenses to start passing the
 Cinder
 third-party integration tests.
>>>
>>> The new program was approved by the Board at
 the July meeting in Austin and follows the improvement of the testing
 standards
 and technical requirements for the "OpenStack Powered" program. This is
 all
 part of the effort of the Foundation to use the OpenStack brand to
 guarantee a
 base-level of interoperability and consistency for OpenStack users and
 to
 protect the work of our community of developers by applying a trademark
 backed
 by their technical efforts.

 The Cinder driver testing is the first step of a larger effort to apply
 community determined standards to the Foundation marke

Re: [openstack-dev] [A Bug of Heat in Stable/Liberty] Stack creation fails when connecting a Nova::Server instance with a created network

[Steve Baker]

Thanks, I'm triaging this now.

On 06/10/15 11:41, Mingyu Li wrote:

Hi all,

There seems a bug in stable/liberty branch.

https://bugs.launchpad.net/heat/+bug/1503060

In an environment installed with Devstack and stable/liberty branch, 
stack creation fails when I use some templates that worked well with 
stable/kilo, such as the following:


heat_template_version: 2014-10-16

resources:
  private_net1:
type: OS::Neutron::Net
properties:
  name: demo_net_a

  private_subnet1:
type: OS::Neutron::Subnet
properties:
  network_id: { get_resource: private_net1 }
  cidr: 192.168.1.0/24 

  server1:
type: OS::Nova::Server
properties:
  name: Server1
  image: cirros-0.3.4-x86_64-uec
  flavor: m1.nano
  networks: [{"network":{ get_resource: private_net1 }}]

The response is " ERROR: Unable to find network with name 'None' ".

It seems that Heat does not find the network { get_resource: 
private_net1 }


Did someone see this before?

Best regards & Thanks,
Mingyu Li


__
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

Re: [openstack-dev] [all] -1 due to line length violation in commit messages

[Steve Baker]

On 06/10/15 06:23, Ben Nemec wrote:

On 10/05/2015 12:12 PM, Jeremy Stanley wrote:

On 2015-10-05 12:00:31 -0500 (-0500), Ben Nemec wrote:
[...]

Note that it's best to do this once the change is ready to be
approved. If you do it earlier and the committer pushes a new
patch set without fixing the commit message, it will revert the
fix made through the web interface.

Well, one workflow tweak which avoids that is to always pull the
latest state of your change from Gerrit before you start modifying
it rather than assuming what is in your filesystem is still current.
It also helps to check Gerrit before pushing a new patchset (or lurk
in an IRC channel where the openstackgerrit bot reports uploads for
that repo), making sure nobody else has updated that change while
you were editing.

That said, a lot of developers probably don't do this.


Yeah, and I'm assuming we shouldn't need to fix commit messages much for
experienced developers who know to do this, but maybe I'm being
optimistic there. :-)

What I generally do is either edit the commit message through gerrit 
just before approving the change, or leave a review comment requesting 
the eventual approver to edit the commit message


__
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] [A Bug of Heat in Stable/Liberty] Stack creation fails when connecting a Nova::Server instance with a created network

[Mingyu Li]

Hi all,

There seems a bug in stable/liberty branch.

https://bugs.launchpad.net/heat/+bug/1503060

In an environment installed with Devstack and stable/liberty branch, stack
creation fails when I use some templates that worked well with stable/kilo,
such as the following:

heat_template_version: 2014-10-16

resources:
  private_net1:
type: OS::Neutron::Net
properties:
  name: demo_net_a

  private_subnet1:
type: OS::Neutron::Subnet
properties:
  network_id: { get_resource: private_net1 }
  cidr: 192.168.1.0/24

  server1:
type: OS::Nova::Server
properties:
  name: Server1
  image: cirros-0.3.4-x86_64-uec
  flavor: m1.nano
  networks: [{"network":{ get_resource: private_net1 }}]

The response is " ERROR: Unable to find network with name 'None' ".

It seems that Heat does not find the network { get_resource: private_net1 }

Did someone see this before?

Best regards & Thanks,
Mingyu Li
__
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] [all] Reviewing code coverage syntax/use across projects

[Jeremy Stanley]

On 2015-10-05 22:14:20 + (+), Jeremy Stanley wrote:
> On 2015-10-05 16:56:50 -0400 (-0400), Ronald Bradford wrote:
> [...]
> > - Anything else relevant regarding code coverage being more consistent
> > for OpenStack.
> 
> I do have https://review.openstack.org/171331 to get PBR to stop
> stepping on the package name if set in .coveragerc, though it's
> still WIP due to not finding time to write a test to exercise it.

Oh, I left out the most relevant part: ...which anyone else is
welcome to take over because I have no idea when I'll get back to
it. ;)
-- 
Jeremy Stanley

__
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] [all] Reviewing code coverage syntax/use across projects

[Jeremy Stanley]

On 2015-10-05 16:56:50 -0400 (-0400), Ronald Bradford wrote:
[...]
> - Anything else relevant regarding code coverage being more consistent
> for OpenStack.

I do have https://review.openstack.org/171331 to get PBR to stop
stepping on the package name if set in .coveragerc, though it's
still WIP due to not finding time to write a test to exercise it.
-- 
Jeremy Stanley

__
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] [fuel] Problems with mcollective offline nodes

[Andrew Woodward]

[ Was: Re: [openstack-dev] OpenStack-dev Digest, Vol 41, Issue 49]

Santosh Parihar,

This implies that the nodes are (in order of most to least likely):
a) currently offline
b) un-accessible from the fuel master node
c) the mcollective agent is not running on them
d) rabbitmq on the fuel node (rabbitmq container) is not functioning
properly

Fuel uses mcollective (MCO) to issue commands to remote nodes.
You can start by pining the nodes, from the CLI you can issue `fuel node`
and it will show the nodes id, and IP address. From there you can use `mco
ping` to determine if mcollective can talk to the nodes. From there you can
triage individual nodes connectivity, or restart them. Alternately you can
investigate and restart the mcollective and or rabbitmq containers.

We are also on IRC #Fuel on irc.freenode.net. We have alot of the European
folks on around when you posted this message so you can drop a line in
there if you would like to get some more interactive help.

-
Andrew
Fuel Community.

On Mon, Oct 5, 2015 at 1:55 AM santosh parihar 
wrote:

> Topic - Fuel
>
> Hi,
>
> My deployment is failing beacuse of following reason :
>
> Verification failed.
> Method verify_networks. Network verification not avaliable because nodes
> ["3", "4", "6", "7"] not avaliable via mcollective. Inspect Astute logs for
> the details
>
> anybody can help here ?
>
> --

--

Andrew Woodward

Mirantis

Fuel Community Ambassador

Ceph Community
__
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] [Fuel][Plugins] add health check for plugins

[Andrey Danin]

OSTF was designed to be a post-deployment test framework. We may introduce
pre- and post-deployment tests in Fuel, but from an implementation point of
view the "pre-" should be done by Nailgun/Astute and the "post-" by OSTF. I
don't think we should mix both in OSTF.

On Tue, Sep 29, 2015 at 10:02 AM, Samuel Bartel  wrote:

> it makes sense.
> We have two intersting use cases here:
> -to extend sanity test to validate plugins (see example in my previous
> email)
> -to extend OSTF test to add pre-deployment check. verify network tests are
> not enough to ensure that a deployment will be successfull or not. there
> are lot of other external parameters which can impact the deployment.
> VMWare credentials as mentionned by sheena is a good example but there is
> also check DNS, NTP, Netapp credentials , Netapp or NFS server ip is
> reachable, external Elasticsearch or Influxdb server is reachable (in case
> of using  external servers for LMA) and so one. It would be very
> interesting to be able to add those tests for core components and plugins.
> it would help us to ensure user that if your tests are ok so no external
> elements would interfere with you deployment. it can be a verify settings
> test as the verify network one
>
>
>
> 2015-09-28 11:06 GMT+02:00 Sheena Gregson :
>
>> I just realized I missed this thread when Andrey responded to it –
>> apologies!
>>
>>
>>
>> I was thinking of things like – confirming VMware username and password
>> are accurate, confirming that SSL certificate chain is valid, etc. – some
>> of these are not plugin based, but I think there is value in enabling both
>> core components and plugins to specify tests that can be run prior to
>> deployment that will help ensure the deployment will not fail.
>>
>>
>>
>> Does that make sense?  In this case, it is not confirming the deployment
>> was successful (post-deployment), it is checking known parameters for
>> validity prior to attempting to deploy (pre-deployment).
>>
>>
>>
>> *From:* Samuel Bartel [mailto:samuel.bartel@gmail.com]
>> *Sent:* Monday, September 28, 2015 11:13 AM
>>
>> *To:* OpenStack Development Mailing List (not for usage questions) <
>> openstack-dev@lists.openstack.org>
>> *Subject:* Re: [openstack-dev] [Fuel][Plugins] add health check for
>> plugins
>>
>>
>>
>> Hi,
>>
>> Totally agree with you Andrey,
>>
>> other use cases could be :
>>
>> -for Ironic plugin, add test to validate that Ironic is properly deploy
>>
>> -for LMA plugin check that metric and log are properly collect, that elk,
>> nagios or grafana dashboard are accessible
>>
>> -for cinder netapp multi backend, check that different type of backend
>> can be crreated
>>
>> and so on
>>
>> So it would be very intersting to have enxtensibility ofr OSTF test
>>
>>
>>
>>
>>
>> Samuel
>>
>>
>>
>> 2015-09-08 0:05 GMT+02:00 Andrey Danin :
>>
>> Hi.
>>
>> Sorry for bringing this thread back from the grave but it look quite
>> interesting to me.
>>
>> Sheena, could you please explain how pre-deployment sanity checks should
>> look like? I don't get what it is.
>>
>> From the Health Check point of view plugins may be divided to two groups:
>>
>>
>> 1) A plugin that doesn't change an already covered functionality thus
>> doesn't require extra tests implemented. Such plugins may be Contrail and
>> almost all SDN plugins, Glance or Cinder backend plugins, and others which
>> don't bring any changes in OSt API or any extra OSt components.
>>
>>
>> 2) A plugin that adds new elements into OSt or changes API or a standard
>> behavior. Such plugins may be Contrail (because it actually adds Contrail
>> Controller which may be covered by Health Check too), Cisco ASR plugin
>> (because it always creates HA routers), some Swift plugins (we don't have
>> Swift/S3 API covered by Health Check now at all), SR-IOV plugins (because
>> they require special network preparation and extra drivers to be presented
>> in an image), when a combination of different ML2 plugins or hypervisors
>> deployed (because you need to test all network underlayers or HVs).
>>
>> So, all that means we need to make OSTF extendible by Fuel plugin's tests
>> eventually.
>>
>>
>>
>> On Mon, Aug 10, 2015 at 5:17 PM, Sheena Gregson 
>> wrote:
>>
>> I like that idea a lot – I also think there would be value in adding
>> pre-deployment sanity checks that could be called from the Health Check
>> screen prior to deployment.  Thoughts?
>>
>>
>>
>> *From:* Simon Pasquier [mailto:spasqu...@mirantis.com]
>> *Sent:* Monday, August 10, 2015 9:00 AM
>> *To:* OpenStack Development Mailing List (not for usage questions) <
>> openstack-dev@lists.openstack.org>
>> *Subject:* Re: [openstack-dev] [Fuel][Plugins] add health check for
>> plugins
>>
>>
>>
>> Hello Samuel,
>>
>> This looks like an interesting idea. Do you have any concrete example to
>> illustrate your point (with one of your plugins maybe)?
>>
>> BR,
>>
>> Simon
>>
>>
>>
>> On Mon, Aug 10, 2015 at 12:04 PM, Samuel Bartel <
>> samuel.bartel@gmail.com>

Re: [openstack-dev] [all] Reviewing code coverage syntax/use across projects

[Doug Hellmann]

Excerpts from Ronald Bradford's message of 2015-10-05 16:56:50 -0400:
> As part of reviewing the code coverage on various projects I have found
> that a number had failing coverage jobs when not configured correctly (many
> also work just fine).  Starting initially in various Oslo projects my goal
> has been to just ensure coverage is defined, runs without errors and is
> generally consistent with existing syntax. [1]   This investigation has
> been part of looking at projects when building a general code coverage
> index and historical statistics. [2]
> 
> My initial minimum focus is to ensure the following (when either not
> defined or partially defined):
> 
>- A [tox:cover] section
> 
> 
>- The use of  python setup.py test --coverage syntax when not defined.
>Note this is "test" and not "testr"
> 
> 
>- The definition of an applicable .coveragerc to including branches and
>omit unit tests from coverage results.
> 
> 
>- Applicable .gitignore of various artifacts.
> 
> 
> I would also like to start the larger discussion on several points I have
> come across (for the wider community of projects) including:
> 
>- The removal in  .coveragerc  omit= option of  [project]/openstack/*
>when the source tree no longer has this directory. Thanks to an explanation
>from dhellmann this seems to be an incubator artifact that is no longer
>generally used (but does exist in some projects).

To clarify, that's where files from the incubator end up when a
project copies incubated code into its source tree. Not all projects
do this, and the ones that do copy different bits of the code. That
code is all tested in the openstack/oslo-incubator repository where
it is being developed, but we don't copy the tests with the main
part of the source so we don't want to hurt the coverage metrics
for a project while it is using incubated code.

Doug

> 
> 
>- The use of  python setup "test" syntax rather then "testr" for
>coverage usage.
> 
> 
>- the testr command for setuptools is deprecated (via lifeless)
> 
> 
>- There seems a lack of clearly defined Openstack docs around what is
>generally found, e.g. [3],[4],[5]. Hopefully the outcome of this discussion
>can be some updating of docs.
> 
> 
>- Anything else relevant regarding code coverage being more consistent
>for OpenStack.
> 
> 
> Regards
> 
> 
> Ronald
> 
> 
> 
> 
> [1] https://review.openstack.org/#/q/topic:fix_coverage,n,z
> [2] https://review.openstack.org/#/c/221494/
> [3] https://wiki.openstack.org/wiki/Testr
> [4] https://wiki.openstack.org/wiki/CoverageTesting
> [5] http://docs.openstack.org/developer/cinder/devref/unit_tests.html

__
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] [all] Reviewing code coverage syntax/use across projects

[Ronald Bradford]

As part of reviewing the code coverage on various projects I have found
that a number had failing coverage jobs when not configured correctly (many
also work just fine).  Starting initially in various Oslo projects my goal
has been to just ensure coverage is defined, runs without errors and is
generally consistent with existing syntax. [1]   This investigation has
been part of looking at projects when building a general code coverage
index and historical statistics. [2]

My initial minimum focus is to ensure the following (when either not
defined or partially defined):

   - A [tox:cover] section


   - The use of  python setup.py test --coverage syntax when not defined.
   Note this is "test" and not "testr"


   - The definition of an applicable .coveragerc to including branches and
   omit unit tests from coverage results.


   - Applicable .gitignore of various artifacts.


I would also like to start the larger discussion on several points I have
come across (for the wider community of projects) including:

   - The removal in  .coveragerc  omit= option of  [project]/openstack/*
   when the source tree no longer has this directory. Thanks to an explanation
   from dhellmann this seems to be an incubator artifact that is no longer
   generally used (but does exist in some projects).


   - The use of  python setup "test" syntax rather then "testr" for
   coverage usage.


   - the testr command for setuptools is deprecated (via lifeless)


   - There seems a lack of clearly defined Openstack docs around what is
   generally found, e.g. [3],[4],[5]. Hopefully the outcome of this discussion
   can be some updating of docs.


   - Anything else relevant regarding code coverage being more consistent
   for OpenStack.


Regards


Ronald




[1] https://review.openstack.org/#/q/topic:fix_coverage,n,z
[2] https://review.openstack.org/#/c/221494/
[3] https://wiki.openstack.org/wiki/Testr
[4] https://wiki.openstack.org/wiki/CoverageTesting
[5] http://docs.openstack.org/developer/cinder/devref/unit_tests.html
__
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] [fuel] What to do when a controller runs out of space

[Eugene Nikanorov]

>
>
>>
> Mirantis does control neither Rabbitmq or Galera. Mirantis cannot assure
> their quality as well.
>

Correct, and rabbitmq was always the pain in the back, preventing any *real
*enterprise usage of openstack where reliability does matter.


> > 2) it has terrible UX
>>
>
> It looks like personal opinion. I'd like to see surveys or operators
> feedbacks. Also, this statement is not constructive as it doesn't have
> alternative solutions.
>

The solution is to get rid of terrible UX wherever possible (i'm not saying
it is always possible, of course)
upstart is just so much better.
And yes, this is my personal opinion and is a summary of escalation team's
experience.


>
>> > 3) it is not reliable
>>
>
> I would say openstack services are not HA reliable. So OCF scripts are
> reaction of operators on these problems. Many of them have child-ish issues
> from release to release. Operators made OCF scripts to fix these problems.
> A lot of openstack are stateful, so they require some kind of stickiness or
> synchronization. Openstack services doesn't have simple health-check
> functionality so it's hard to say it's running well or not. Sighup is still
> a problem for many of openstack services. Etc/etc So, let's be constructive
> here.
>

Well, I prefer to be responsible for what I know and maintain. Thus, I
state that neutron doesn't need to be managed by pacemaker, neither server,
nor all kinds of agents, and that's the path that neutron team will be
taking.

Thanks,
Eugene.

>
>
>> >
>>
>> I disagree with #1 as I do not agree that should be a criteria for an
>> open-source project.  Considering pacemaker is at the core of our
>> controller setup, I would argue that if these are in fact true we need
>> to be using something else.  I would agree that it is a terrible UX
>> but all the clustering software I've used fall in this category.  I'd
>> like more information on how it is not reliable. Do we have numbers to
>> backup these claims?
>>
>> > (3) is not evaluation of the project itself, but just a logical
>> consequence
>> > of (1) and (2).
>> > As a part of escalation team I can say that it has cost our team
>> thousands
>> > of man hours of head-scratching, staring at pacemaker logs which value
>> are
>> > usually slightly below zero.
>> >
>> > Most of openstack services (in fact, ALL api servers) are stateless,
>> they
>> > don't require any cluster management (also, they don't need to be moved
>> in
>> > case of lack of space).
>> > Statefull services like neutron agents have their states being a
>> function of
>> > db state and are able to syncronize it with the server without external
>> > "help".
>> >
>>
>> So it's not an issue with moving services so much as being able to
>> stop the services when a condition is met. Have we tested all OS
>> services to ensure they do function 100% when out of disk space?  I
>> would assume that glance might have issues with image uploads if there
>> is no space to handle a request.
>>
>> > So now usage of pacemaker can be only justified for cases where
>> service's
>> > clustering mechanism requires active monitoring (rabbitmq, galera)
>> > But even there, examples when we are better off without pacemaker are
>> all
>> > around.
>> >
>> > Thanks,
>> > Eugene.
>> >
>>
>> After I sent this email, I had further discussions around the issues
>> that I'm facing and it may not be completely related to disk space. I
>> think we might be relying on the expectation that the local rabbitmq
>> is always available but I need to look into that. Either way, I
>> believe we still should continue to discuss this issue as we are
>> managing services in multiple ways on a single host. Additionally I do
>> not believe that we really perform quality health checks on our
>> services.
>>
>> Thanks,
>> -Alex
>>
>>
>> >
>> > On Mon, Oct 5, 2015 at 1:34 PM, Sergey Vasilenko <
>> svasile...@mirantis.com>
>> > wrote:
>> >>
>> >>
>> >> On Mon, Oct 5, 2015 at 12:22 PM, Eugene Nikanorov
>> >>  wrote:
>> >>>
>> >>> No pacemaker for os services, please.
>> >>> We'll be moving out neutron agents from pacemaker control in 8.0,
>> other
>> >>> os services don't need it too.
>> >>
>> >>
>> >> could you please provide your arguments.
>> >>
>> >>
>> >> /sv
>> >>
>> >>
>> __
>> >> 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 Development Mailing L

[openstack-dev] [searchlight] Liberty release finalization

[Tripp, Travis S]

Note: I sent a message to Thierry and Doug for help with the specifics of 
running the release and after Theirry’s response it seemed we should include 
the mailing list.

>Tripp, Travis S wrote:
>>Theirry and Doug,
>>We are down to a single patch that needs one more +2 and then we believe 
>>we’ll be ready to run the first Searchlight RC. We have a core reviewer who 
>>will be done going through it by Monday AM US. Can you please let me know 
>>what will be needed from us to run the release?
>>https://launchpad.net/searchlight/+milestone/liberty-rc1
>>(note, the BP under code review and bug in progress are both solved in the 
>>same patch).
>



On 10/5/15, 1:35 AM, "Thierry Carrez"  wrote:

>Hi Travis,
>
>Searchlight is currently registered in the governance as following the
>release cycle with intermediary releases (rather than milestones and
>RCs). It is also *not* directly managed by the release team (yet).
>
>That means you have two options. You can stay with the intermediary
>releases model and just push a tag (1.0.0 or 0.1.0 or...) when you're
>ready for release.
>
>You can switch to a milestone-based model and do a RC: in which case you
>should push a 1.0.0.0rc1 tag.
>
>In both cases you should cut a stable/liberty branch from that (we can
>help with that part).
>
>Then in the milestone-based model case you would re-tag the 1.0.0.0rc1
>with a 1.0.0 tag as we get nearer to final release day. In the
>intermediary model you would only reissue a tag if you detect an issue
>which warrants a 1.0.1 (or 0.1.1) point release.
>
>Try first to decide which model you'd like to follow: the one registered
>in the governance (intermediary) or the one with RCs that you seem to
>follow (milestone-based). Those are described in the project team guide:
>
>http://docs.openstack.org/project-team-guide/release-management.html
>
>-- 
>Thierry Carrez (ttx)
>



Hi Thierry,

Thanks for the info! We had discussed the release models a couple times in our 
IRC meeting and we thought that the release cycle with intermediary releases 
sounded good to us.  One reason is that we actually wanted to be able to 
release more frequently if needed support deployers and developers interested 
in moving searchlight into production more quickly. Possibly we would be 
looking to release whenever we improve an integration with an existing project, 
support an integration with a new project, enable a new feature, address major 
bugs, or to address UI integration needs.

As far as the version number, we feel that we have a good basis for the 
functionality and API at this point. We’re wanting to start getting deployer 
feedback and want to be able to make changes needed without getting too hung up 
on major vs minor version changes. So we’ve voted to go with 0.1.0 to allow us 
time to solidify based on that with a goal of going to 1.0 by the end of the 
Mitaka release cycle.

 
However, in reading the page you sent below it says the following about common 
cycle with intermediary releases.

"This is especially suitable to more stable projects which add a limited set of 
new features and don’t plan to go through large architectural changes. Getting 
the latest and greatest out as often as possible, while ensuring stability and 
upgradeability."

This description of the release model sounds a bit dissimilar from our ideas 
above, so is this okay with you that we stay on that release model?


Thanks,
Travis








__
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] [Neutron] Remdiner: Team meeting on Tuesday at 1400 UTC

[Armando M.]

A kind reminder for tomorrow's meeting.

Please add agenda items to the meeting here [1].

See you all tomorrow!

Armando

[1] https://wiki.openstack.org/wiki/Network/Meetings
__
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] [Neutron] Effective guide

[Armando M.]

Hi neutrinos,

One of the areas I would like to work on during the Mitaka cycle is
'consistency' [1].

We've grown quite a bit during the last cycle and we need to make sure we
are on the same page when it comes to code quality and reviews, and at the
same time speeding up review velocity without compromising stability [2].

This is the reason why I started the 'Effective Neutron' guide [3], with
the hope that we could start collating pills of wisdom that we identify
during Neutron reviews, and capture lessons learned from regressions we may
experience post merge.

To this aim, I would invite people to start collectively add content to the
guide. If you use the 'effective' tag [4], then it's easier to set them
apart from the rest, for speedy review.

If you are stumbling upon a bad pattern and you want to clean that up (like
Cedric did in [5]), adding a tip at the same time of the patch is also ok,
unless you pinky-swear you'll do that as follow up (the effective guide is
available from Liberty, so backports may cause a conflict should you want
to go back to Kilo).

Cheers,
Armando

[1]
http://git.openstack.org/cgit/openstack/election/tree/candidates/mitaka/Neutron/Armando_Migliaccio.txt#n33
[2]
http://git.openstack.org/cgit/openstack/election/tree/candidates/mitaka/Neutron/Armando_Migliaccio.txt#n25
[3]
http://docs.openstack.org/developer/neutron/devref/effective_neutron.html
[4]
https://review.openstack.org/#/q/project:openstack/neutron+topic:effective,n,z
[5] https://review.openstack.org/#/c/230823/
__
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] Merging DVR-HA into Liberty release

[Assaf Muller]

On Mon, Oct 5, 2015 at 2:15 PM, Korzeniewski, Artur <
artur.korzeniew...@intel.com> wrote:

> Hi Code Reviewers,
>
> I would like to ask if DVR-HA patches can be merged into Liberty release:
>
> https://bugs.launchpad.net/neutron/+bug/1365473
>
> https://review.openstack.org/#/c/196893
>
> https://review.openstack.org/#/c/143169
>
>
>
> The proper patches has been implemented, the reviews has been addressed,
> the patches are working and all found issues has been fixed.
>
>
>
> Would it be possible to merge it into Liberty release?
>

Here's the OpenStack backport policy:
https://wiki.openstack.org/wiki/StableBranch#Stable_branch_policy

The relevant part:
"Some types of changes are completely forbidden:

   - New features"


So, per our policy, the answer is sadly no.


>
>
> Regards,
>
> Artur Korzeniewski
>
> 
>
> Intel Technology Poland sp. z o.o.
>
> KRS 101882
>
> ul. Slowackiego 173, 80-298 Gdansk
>
>
>
__
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] [Trove][Barbican] Liberty RC2 available

[Thierry Carrez]

Hello everyone,

Due to release-critical issues spotted in Trove and Barbican during RC1
testing, new release candidates were created for Liberty. The list of
RC2 fixes, as well as RC2 tarballs are available at:

https://launchpad.net/trove/liberty/liberty-rc2
https://launchpad.net/barbican/liberty/liberty-rc2

Unless new release-critical issues are found that warrant a last-minute
release candidate respin, these tarballs will be formally released as
final "Liberty" versions on October 15. You are therefore strongly
encouraged to test and validate these tarballs !

Alternatively, you can directly test the stable/liberty branch at:
http://git.openstack.org/cgit/openstack/trove/log/?h=stable/liberty
http://git.openstack.org/cgit/openstack/barbican/log/?h=stable/liberty

If you find an issue that could be considered release-critical, please
file it at:

https://bugs.launchpad.net/trove/+filebug
or
https://bugs.launchpad.net/barbican/+filebug

and tag it *liberty-rc-potential* to bring it to the release crew's
attention.

Thanks!

-- 
Thierry Carrez (ttx)

__
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 + ovn] Does neutron ovn plugin support to setup multiple neutron networks for one container?

[Murali R]

Cool. That works.

On Mon, Oct 5, 2015 at 9:05 AM, Russell Bryant  wrote:

> On 10/05/2015 04:28 PM, Murali R wrote:
> > Yes. So we can define multiple logical switches per network and ovn
> > keeps vlan maps that ovs agent used to maintain and do the tunneling. My
> > confusion was from lport-add command that did not have host info, so if
> > there is no neutron, the cms has to maintain the host to lport
> > association and we can't query from NB-DB. Makes sense.
>
> The host to lport mappings are maintained by ovn-controller in the Port
> Binding table of the OVN Southbound database.
>
> --
> Russell Bryant
>
> __
> 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] Merging DVR-HA into Liberty release

[Korzeniewski, Artur]

Hi Code Reviewers,
I would like to ask if DVR-HA patches can be merged into Liberty release:

https://bugs.launchpad.net/neutron/+bug/1365473

https://review.openstack.org/#/c/196893

https://review.openstack.org/#/c/143169

The proper patches has been implemented, the reviews has been addressed, the 
patches are working and all found issues has been fixed.

Would it be possible to merge it into Liberty release?

Regards,
Artur Korzeniewski

Intel Technology Poland sp. z o.o.
KRS 101882
ul. Slowackiego 173, 80-298 Gdansk

__
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] [Infra] Meeting Tuesday October 6th at 19:00 UTC

[Elizabeth K. Joseph]

Hi everyone,

The OpenStack Infrastructure (Infra) team is having our next weekly
meeting on Tuesday October 6th, at 19:00 UTC in #openstack-meeting

Meeting agenda available here:
https://wiki.openstack.org/wiki/Meetings/InfraTeamMeeting (anyone is
welcome to to add agenda items)

Everyone interested in infrastructure and process surrounding
automated testing and deployment is encouraged to attend.

In case you missed it or would like a refresher, the meeting minutes
and full logs from our last meeting are available:

Minutes: 
http://eavesdrop.openstack.org/meetings/infra/2015/infra.2015-09-29-19.01.html
Minutes (text):
http://eavesdrop.openstack.org/meetings/infra/2015/infra.2015-09-29-19.01.txt
Log: 
http://eavesdrop.openstack.org/meetings/infra/2015/infra.2015-09-29-19.01.log.html

-- 
Elizabeth Krumbach Joseph || Lyz || pleia2

__
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] [Fuel] py.test vs testrepository

[Robert Collins]

On 6 October 2015 at 03:34, Roman Prykhodchenko  wrote:
> Disclaimer:
> I didn’t want to fire up this war but it silently hit one of my patches so 
> now I think it’s better to spread it to a wide audience.
>
>
> When I was dealing with one of the regular dependency hell in Fuel Client I 
> noticed, that stuff which is not in global requirements may make the 
> mentioned hell hotter, even if those requirements are test requirements. 
> After that discovery I started aligning all *requirements.txt to Kilo’s 
> global requirements and trying to remove everything which it not there. A 
> special dependency is of course py.test: replacing it is a very controversial 
> thing which I’d like to discuss here.
>
> Atm I have the following pros. and cons. regarding testrepository:
>
> pros.:
>
> 1. It’s ”standard" in OpenStack so using it gives Fuel more karma and moves 
> it more under big tent
> 2. It’s in global requirements, so it doesn’t cause dependency hell

I'd also add that it enables the big data approach to test analysis
that the subunit2sql and test dashboard folk are building up, and
thats pretty important. A subunit py.test plugin would enable that for
py.test test authors (and in fact that would enable testing via
py.test under testrepository - test repository is *not* a test runner
- its a data-store + a meta-runner).

> cons.:
>
> 1. Debugging is really hard

It is really hard indeed, and I'd like love to fix that. In fact I'd
like to make it as nice as it is in py.test - I have a plan, and I'd
be delighted to turn it into a spec that someone can follow if anyone
would like to fix this - I think it would be quite high leverage a
thing. OTOH, because its an exercise in distributed systems
programming, its not truely trivial.

-Rob


-- 
Robert Collins 
Distinguished Technologist
HP Converged Cloud

__
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] [all] -1 due to line length violation in commit messages

[Ben Nemec]

On 10/05/2015 12:12 PM, Jeremy Stanley wrote:
> On 2015-10-05 12:00:31 -0500 (-0500), Ben Nemec wrote:
> [...]
>> Note that it's best to do this once the change is ready to be
>> approved. If you do it earlier and the committer pushes a new
>> patch set without fixing the commit message, it will revert the
>> fix made through the web interface.
> 
> Well, one workflow tweak which avoids that is to always pull the
> latest state of your change from Gerrit before you start modifying
> it rather than assuming what is in your filesystem is still current.
> It also helps to check Gerrit before pushing a new patchset (or lurk
> in an IRC channel where the openstackgerrit bot reports uploads for
> that repo), making sure nobody else has updated that change while
> you were editing.
> 
> That said, a lot of developers probably don't do this.
> 

Yeah, and I'm assuming we shouldn't need to fix commit messages much for
experienced developers who know to do this, but maybe I'm being
optimistic there. :-)

__
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] [all] -1 due to line length violation in commit messages

[Jeremy Stanley]

On 2015-10-05 12:00:31 -0500 (-0500), Ben Nemec wrote:
[...]
> Note that it's best to do this once the change is ready to be
> approved. If you do it earlier and the committer pushes a new
> patch set without fixing the commit message, it will revert the
> fix made through the web interface.

Well, one workflow tweak which avoids that is to always pull the
latest state of your change from Gerrit before you start modifying
it rather than assuming what is in your filesystem is still current.
It also helps to check Gerrit before pushing a new patchset (or lurk
in an IRC channel where the openstackgerrit bot reports uploads for
that repo), making sure nobody else has updated that change while
you were editing.

That said, a lot of developers probably don't do this.
-- 
Jeremy Stanley

__
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] [all] -1 due to line length violation in commit messages

[Ben Nemec]

On 10/01/2015 02:56 AM, Ghe Rivero wrote:
> If anyone disagrees with the commit format, please, go ahead and fix it (It's
> really easy using the gerrit web) For such cosmetic changes (and others
> similars), we should not wait for the author to do it. Sometimes, for a stupid
> comma, and with all the TZ, a change can need more than a day to be fixed and
> approved.

Note that it's best to do this once the change is ready to be approved.
 If you do it earlier and the committer pushes a new patch set without
fixing the commit message, it will revert the fix made through the web
interface.

> 
> Ghe Rivero
> 
> Quoting Ihar Hrachyshka (2015-09-29 18:05:37)
>>> On 25 Sep 2015, at 16:44, Ihar Hrachyshka  wrote:
>>>
>>> Hi all,
>>>
>>> releases are approaching, so it’s the right time to start some bike 
>>> shedding on the mailing list.
>>>
>>> Recently I got pointed out several times [1][2] that I violate our commit 
>>> message requirement [3] for the message lines that says: "Subsequent lines 
>>> should be wrapped at 72 characters.”
>>>
>>> I agree that very long commit message lines can be bad, f.e. if they are 
>>> 200+ chars. But <= 79 chars?.. Don’t think so. Especially since we have 79 
>>> chars limit for the code.
>>>
>>> We had a check for the line lengths in openstack-dev/hacking before but it 
>>> was killed [4] as per openstack-dev@ discussion [5].
>>>
>>> I believe commit message lines of <=80 chars are absolutely fine and should 
>>> not get -1 treatment. I propose to raise the limit for the guideline on 
>>> wiki accordingly.
>>>
>>> Comments?
>>>
>>> [1]: https://review.openstack.org/#/c/224728/6//COMMIT_MSG
>>> [2]: https://review.openstack.org/#/c/227319/2//COMMIT_MSG
>>> [3]: 
>>> https://wiki.openstack.org/wiki/GitCommitMessages#Summary_of_Git_commit_message_structure
>>> [4]: https://review.openstack.org/#/c/142585/
>>> [5]: 
>>> http://lists.openstack.org/pipermail/openstack-dev/2014-December/thread.html#52519
>>>
>>> Ihar
>>
>> Thanks everyone for replies.
>>
>> Now I realize WHY we do it with 72 chars and not 80 chars (git log output). 
>> :) I updated the wiki page with how to configure Vim to enforce the rule. I 
>> also removed the notion of gating on commit messages because we have them 
>> removed since recently.
>>
>> Ihar
>>
>>
>> __
>> 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 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] I love csv output in openstackclient, please never removed it

[Doug Hellmann]

Excerpts from Dean Troyer's message of 2015-10-05 11:18:55 -0500:
> On Mon, Oct 5, 2015 at 11:03 AM, Doug Hellmann 
> wrote:
> 
> > Devstack should also look at using the shell output formatter,
> > especially for show commands. Combining that formatter with eval means
> > no parsing in a lot of cases.
> >
> 
> It may in places, but it turns out the 'value' formatter is most useful,
> especially in the get_or_create_* functions where you really only need a
> single value, avoids an eval or extra subshell.
> 
> group_id=$(
> # Creates new group with --or-show
> openstack --os-token=$OS_TOKEN --os-url=$os_url \
> --os-identity-api-version=3 group create $1 \
> --domain $2 --description "$desc" --or-show \
> -f value -c id
> )
> echo $group_id
> 
> dt
> 

Yep, that's another good tip.

Doug

__
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] I love csv output in openstackclient, please never removed it

[Dean Troyer]

On Mon, Oct 5, 2015 at 11:03 AM, Doug Hellmann 
wrote:

> Devstack should also look at using the shell output formatter,
> especially for show commands. Combining that formatter with eval means
> no parsing in a lot of cases.
>

It may in places, but it turns out the 'value' formatter is most useful,
especially in the get_or_create_* functions where you really only need a
single value, avoids an eval or extra subshell.

group_id=$(
# Creates new group with --or-show
openstack --os-token=$OS_TOKEN --os-url=$os_url \
--os-identity-api-version=3 group create $1 \
--domain $2 --description "$desc" --or-show \
-f value -c id
)
echo $group_id

dt

-- 

Dean Troyer
dtro...@gmail.com
__
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 + ovn] Does neutron ovn plugin support to setup multiple neutron networks for one container?

[Russell Bryant]

On 10/05/2015 04:28 PM, Murali R wrote:
> Yes. So we can define multiple logical switches per network and ovn
> keeps vlan maps that ovs agent used to maintain and do the tunneling. My
> confusion was from lport-add command that did not have host info, so if
> there is no neutron, the cms has to maintain the host to lport
> association and we can't query from NB-DB. Makes sense.

The host to lport mappings are maintained by ovn-controller in the Port
Binding table of the OVN Southbound database.

-- 
Russell Bryant

__
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] I love csv output in openstackclient, please never removed it

[Doug Hellmann]

Excerpts from Sean Dague's message of 2015-10-05 06:57:06 -0400:
> On 10/05/2015 12:16 AM, Steve Martinelli wrote:
> > I loved reading this email as much as zigo loves csv output, great
> > feedback is an amazing motivator!
> > 
> > And don't worry, the csv output was never going away :)
> > 
> > stevemar
> 
> It might be nice to change some of the devstack usage into that. It
> would help spread the word about it, and be a bit easier to understand.
> 
> -Sean
> 

Devstack should also look at using the shell output formatter,
especially for show commands. Combining that formatter with eval means
no parsing in a lot of cases.

Doug

__
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] [all][stable][release] 2015.1.2

[Thierry Carrez]

Chuck Short wrote:
> I would like to freeze the branches on Wednesday and get a release out
> early next week. Are we okay with that?

Next week is Liberty release week so that might be confusing...
But if it's the only option, as long as it's *early* next week, I guess
that won't hurt.

-- 
Thierry Carrez (ttx)

__
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] [Zaqar] Liberty RC2 available

[Thierry Carrez]

Hello everyone,

In order to include last-minute translations updates, a new liberty
release candidate was created for Zaqar. RC2 tarballs are available at:

https://launchpad.net/zaqar/liberty/liberty-rc2

Unless new release-critical issues are found that warrant a last-minute
release candidate respin, this tarball will be formally released as the
final "Liberty" version on October 15. You are therefore strongly
encouraged to test and validate this tarball !

Alternatively, you can directly test the stable/liberty branch at:
http://git.openstack.org/cgit/openstack/zaqar/log/?h=stable/liberty

If you find an issue that could be considered release-critical, please
file it at:

https://bugs.launchpad.net/zaqar/+filebug

and tag it *liberty-rc-potential* to bring it to the release crew's
attention.

Thanks!

-- 
Thierry Carrez (ttx)

__
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 + ovn] Does neutron ovn plugin support to setup multiple neutron networks for one container?

[Murali R]

Yes. So we can define multiple logical switches per network and ovn keeps
vlan maps that ovs agent used to maintain and do the tunneling. My
confusion was from lport-add command that did not have host info, so if
there is no neutron, the cms has to maintain the host to lport association
and we can't query from NB-DB. Makes sense.

-Murali

On Fri, Oct 2, 2015 at 11:46 AM, Russell Bryant  wrote:

> On 10/02/2015 02:26 PM, Murali R wrote:
> > Hi Russell,
> >
> > Thank you these are really good. Had a quick question. When you create a
> > logical switch in your first script (line 23) - at what point is it
> > associated with br-int ? Is it on line 45? So I can create any switch
> > and when I associated logical port it associates logical switch ? Or is
> > there a different way we can associate logical-phy switches? I was
> > looking to get the logical associations during startup initialization.
>
> To clarify, I believe you're talking about the first script from the
> tutorial [1], which is:
>
>
> https://github.com/openvswitch/ovs/blob/master/tutorial/ovn/env1/setup.sh
>
> Most of that script is all configuring logical topology.  OVN does
> nothing to the network until ovn-controller sees a port appear on br-int
> that maps to a logical port.  This mapping is done by setting the
> "iface-id" to the name of the logical port.
>
> Once ovn-controller has mapped a port on br-int to a logical port, it
> can configure the switch appropriately for that port.
>
> Does that make sense?
>
> [1]
> https://github.com/openvswitch/ovs/blob/master/tutorial/OVN-Tutorial.md
>
> --
> Russell Bryant
>
> __
> 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

Re: [openstack-dev] [Neutron] Defect management

[Armando M.]

On 5 October 2015 at 03:14, Ihar Hrachyshka  wrote:

> > On 02 Oct 2015, at 02:37, Armando M.  wrote:
> >
> > Hi neutrinos,
> >
> > Whilst we go down the path of revising the way we manage/process bugs in
> Neutron, and transition to the proposed model [1], I was wondering if I can
> solicit some volunteers to screen the bugs outlined in [2]. It's only 24
> bugs so it should be quick ;)
>
> I am fine to be a guinea pig, though I don’t have edit access to the
> spreadsheet.
>
> Ihar
>

Thanks Ihar, the sheet is editable now. Polishing Launchpad should suffice
though.

Cheers,
Armando


>
> __
> 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

Re: [openstack-dev] [all] [ptls] Proposed Design Summit track/room/time allocation

[Thierry Carrez]

Thierry Carrez wrote:
> [...] Here is the resulting proposed room/time layout result:
> 
> http://tinyurl.com/mitaka-design-summit

OK, I just pushed this track layout to the official Design Summit
schedule at:

https://mitakadesignsummit.sched.org/

> [...]
> I'll push this proposed layout to Cheddar early next week (probably on
> Monday) so you can start scheduling, so please comment before then. The
> site is not up yet, but I already pushed instructions on how to do the
> scheduling at:
> 
> https://wiki.openstack.org/wiki/Design_Summit/SchedulingForPTLs

The scheduling website for the PTLs is up now, so you should be able to
start pushing more details. See wiki page above for instructions, and
feel free to hit me or thingee on IRC if Cheddar doesn't behave.

Note that the Ops just kindly gave back a number of workrooms that they
were allocated, so there are extra slots up for grabs, if your team
really feels that they could use some extra time.

Those unallocated slots show up in red in
http://tinyurl.com/mitaka-design-summit (a few workroom slots Wednesday
afternoon in small 15-seat and 8-seat rooms, and a very small 8-seat
meetup room for the Friday afternoon). If the time works well for you
and you'd be interested in that room, let me know.

-- 
Thierry Carrez (ttx)

__
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] Please add your timezone to your Launchpad account (voluntarily)

[Andreas Scheuring]

Hi together, 
I think it would be very helpful if you all could update your launchpad
profile with your timezone information. This makes it more easy to
figure out the timeframe when a person can be reached in theory. 

To update your account, use this link

https://launchpad.net/people/+me/+editlocation


Of course you need not to provide this information. It's NOT "mandatory"
or so, but it helps to improve collaboration!

Thanks

-- 
Andreas
(IRC: scheuran)





__
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] [Fuel] py.test vs testrepository

[Roman Prykhodchenko]

Disclaimer:
I didn’t want to fire up this war but it silently hit one of my patches so now 
I think it’s better to spread it to a wide audience.


When I was dealing with one of the regular dependency hell in Fuel Client I 
noticed, that stuff which is not in global requirements may make the mentioned 
hell hotter, even if those requirements are test requirements. After that 
discovery I started aligning all *requirements.txt to Kilo’s global 
requirements and trying to remove everything which it not there. A special 
dependency is of course py.test: replacing it is a very controversial thing 
which I’d like to discuss here.

Atm I have the following pros. and cons. regarding testrepository:

pros.:

1. It’s ”standard" in OpenStack so using it gives Fuel more karma and moves it 
more under big tent
2. It’s in global requirements, so it doesn’t cause dependency hell

cons.:

1. Debugging is really hard


I’d like to head your thoughts.


- romcheg



signature.asc
Description: Message signed with OpenPGP using GPGMail
__
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] [fuel] What to do when a controller runs out of space

[Sergii Golovatiuk]

Hi,


On Mon, Oct 5, 2015 at 3:03 PM, Alex Schultz  wrote:

> On Mon, Oct 5, 2015 at 5:56 AM, Eugene Nikanorov
>  wrote:
> > Ok,
> >
> > Project-wise:
> > 1) Pacemaker is not under our company's control, we can't assure its
> quality
>

Mirantis does control neither Rabbitmq or Galera. Mirantis cannot assure
their quality as well.

> 2) it has terrible UX
>

It looks like personal opinion. I'd like to see surveys or operators
feedbacks. Also, this statement is not constructive as it doesn't have
alternative solutions.


> > 3) it is not reliable
>

I would say openstack services are not HA reliable. So OCF scripts are
reaction of operators on these problems. Many of them have child-ish issues
from release to release. Operators made OCF scripts to fix these problems.
A lot of openstack are stateful, so they require some kind of stickiness or
synchronization. Openstack services doesn't have simple health-check
functionality so it's hard to say it's running well or not. Sighup is still
a problem for many of openstack services. Etc/etc So, let's be constructive
here.



> >
>
> I disagree with #1 as I do not agree that should be a criteria for an
> open-source project.  Considering pacemaker is at the core of our
> controller setup, I would argue that if these are in fact true we need
> to be using something else.  I would agree that it is a terrible UX
> but all the clustering software I've used fall in this category.  I'd
> like more information on how it is not reliable. Do we have numbers to
> backup these claims?
>
> > (3) is not evaluation of the project itself, but just a logical
> consequence
> > of (1) and (2).
> > As a part of escalation team I can say that it has cost our team
> thousands
> > of man hours of head-scratching, staring at pacemaker logs which value
> are
> > usually slightly below zero.
> >
> > Most of openstack services (in fact, ALL api servers) are stateless, they
> > don't require any cluster management (also, they don't need to be moved
> in
> > case of lack of space).
> > Statefull services like neutron agents have their states being a
> function of
> > db state and are able to syncronize it with the server without external
> > "help".
> >
>
> So it's not an issue with moving services so much as being able to
> stop the services when a condition is met. Have we tested all OS
> services to ensure they do function 100% when out of disk space?  I
> would assume that glance might have issues with image uploads if there
> is no space to handle a request.
>
> > So now usage of pacemaker can be only justified for cases where service's
> > clustering mechanism requires active monitoring (rabbitmq, galera)
> > But even there, examples when we are better off without pacemaker are all
> > around.
> >
> > Thanks,
> > Eugene.
> >
>
> After I sent this email, I had further discussions around the issues
> that I'm facing and it may not be completely related to disk space. I
> think we might be relying on the expectation that the local rabbitmq
> is always available but I need to look into that. Either way, I
> believe we still should continue to discuss this issue as we are
> managing services in multiple ways on a single host. Additionally I do
> not believe that we really perform quality health checks on our
> services.
>
> Thanks,
> -Alex
>
>
> >
> > On Mon, Oct 5, 2015 at 1:34 PM, Sergey Vasilenko <
> svasile...@mirantis.com>
> > wrote:
> >>
> >>
> >> On Mon, Oct 5, 2015 at 12:22 PM, Eugene Nikanorov
> >>  wrote:
> >>>
> >>> No pacemaker for os services, please.
> >>> We'll be moving out neutron agents from pacemaker control in 8.0, other
> >>> os services don't need it too.
> >>
> >>
> >> could you please provide your arguments.
> >>
> >>
> >> /sv
> >>
> >>
> __
> >> 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 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

Re: [openstack-dev] [Solum] Proposal to change weekly IRC meeting time

[Devdatta Kulkarni]

Hi team,

Last week I had sent out an email proposing changes to our weekly IRC meeting 
time
(see below for reference). There was no objection to this proposal.

The patch that makes this change official is now merged.
https://review.openstack.org/#/c/228441/

Starting tomorrow (October 6), our weekly IRC meeting will be held at 1700 UTC
in openstack-meeting-3 channel.

I will update project wiki to reflect this change.

Regards,
Devdatta


From: Devdatta Kulkarni 
Sent: Monday, September 28, 2015 8:12 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [Solum] Proposal to change weekly IRC meeting time

Hi team,

In last week's IRC meeting [1], we discussed about changing our weekly IRC
meeting time from current time of 2100 UTC to 1700 UTC to,
(a) avoid conflict with the cross-project meeting, and (b) accommodate 
participants from India/Asia.

I have submitted a WIP review [2] to make this change. Please provide your 
votes (+1/-1) on the review.
I will remove WIP once majority of our contributors have voted on it.
Note that we have to change the meeting channel as our current channel 
(openstack-meeting-alt) is not available at 1700 UTC on Tuesdays.

I am thinking that if majority of our team members agree, we can move to this
new time starting October 6 meeting.

Thanks,
Devdatta

[1] 
http://eavesdrop.openstack.org/meetings/solum_team_meeting/2015/solum_team_meeting.2015-09-22-21.00.log.html

[2] https://review.openstack.org/#/c/228441/
__
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

Re: [openstack-dev] [Neutron] AZ Support

[Ihar Hrachyshka]

> On 05 Oct 2015, at 15:32, Gary Kotton  wrote:
> 
> 
> 
> On 10/5/15, 3:21 AM, "Ihar Hrachyshka"  wrote:
> 
>>> On 04 Oct 2015, at 19:21, Gary Kotton  wrote:
>>> 
>>> Sorry, it is not a result of the AZ support (humble apologies)
>>> 
>>> It is a result of https://review.openstack.org/#/c/226362/
>> 
>> So you use DHCP agent with non-ml2 plugin, and it broke you. Do you think
>> it¹s ok for you to change the RPC topic to work with Mitaka, or we¹ll
>> need to handle it more gracefully, f.e. by detecting the reply timeout
>> and switching back to the old topic?
> 
> My thinking is that we should fail to use the old topic. But then again, I
> would expect that the Neutron service would first be upgraded and then the
> agents. Updating the agents first would be a recipe for disaster.

Yes, controller first, then agents. That’s why there was no fallback mechanism 
in that patch that broke you, while we looked into backwards compatibility. 
Though no one considered the case of 3party plugins that may rely on some 
in-tree agents. We can accommodate for them, if it seems too much effort for 
them to change the topic name they report on. But note that it would also mean 
that those plugins don’t utilize the separate threads to handle reports, which 
can be bad for their scalability.

Ihar


signature.asc
Description: Message signed with OpenPGP using GPGMail
__
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] AZ Support

[Gary Kotton]

From: Akihiro MOTOKI mailto:amot...@gmail.com>>
Reply-To: OpenStack List 
mailto:openstack-dev@lists.openstack.org>>
Date: Monday, October 5, 2015 at 3:48 PM
To: OpenStack List 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [Neutron] AZ Support

Hi,

2015-10-05 15:54 GMT+09:00 Gary Kotton 
mailto:gkot...@vmware.com>>:
Hi,
Yes, you are correct. That patch is the culprit (my bad and once again humble 
apologies)

Regarding the AZ support I think that we need to do the following:

  1.  Have this in a separate topic until it is complete. I have a number of 
concerns here:
 *   The upgrade impact on Nova. Today in Nova one can have N AZ’s and they 
will all work on the same virtual networks. It is not clear how this will work 
here and if the networks can be shared across AZ’s (maybe this was discussed 
and I am missing somehing)

The proposed "AZ support" feature in Neutron is the really initial step and we 
have many points which can be improved.
The first step of AZ support is only related to the agent scheduling andit just 
tries to assign agent(s) from AZ(s) which users want.
Networks are still shared across AZs, so I don't think there are upgrade 
impacts on Nova.

[Gary] Thanks for that clarification. From 
https://review.openstack.org/#/c/204436/ is did not really seem like that is 
the case, but I need to go over that in more detail. When will Nova know when 
to pass the AZ to Neutron? Will this be if the extension is supported? I am 
just failing to understand  the nova side of the integrations.


  1.
 *   A few weeks ago Monty raised concerns about floating IP support. I 
think that this will be required for AZ support. In the past one could have a 
shared network between AZ’s and now they will need two isolated networks

I think Floating IP pool per AZ is a straight forward approach.
However, this does not necessarily mean an external network should limit to a 
specific AZ.
Of course, it is better that VMs in AZ1 connect to a network (whose dhcp-agent 
lives in AZ1)

[Gary] So each time a new AZ is created the admin will need to update the 
Neutron configuration file - 
https://review.openstack.org/#/c/183369/40/etc/neutron.conf,cm?

and the network is connected to router in AZ1.
The question is how users can select floating IP pool but in this case users 
can know which FIP pool belongs to which AZ.

There are other approaches. One possible option is to have one external network 
and
a router supports multiple upstream links using routing protocols.

I just wrote approaches in my mind and there must be more options.


  1.  In Nova on of the top priority features over the last few cycles has been 
cells. At the moment there is no cell support for Neutron. I feel that the AZ 
support is someone what related and maybe we should try and kill 2 birds with 
one stone here and have the cell support combined if possible. I think that 
this is certainly something that should be a cross project summit discussion.

I agree that Cells support is one of missing areas in Neutron.
I think AZ support and Cells support are different things though they are 
similar.
AZ support is visible to users and Cells are not.

Thanks,
Akihiro


Thanks
Gary

From: "Armando M." mailto:arma...@gmail.com>>
Reply-To: OpenStack List 
mailto:openstack-dev@lists.openstack.org>>
Date: Sunday, October 4, 2015 at 8:18 PM

To: OpenStack List 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [Neutron] AZ Support



On 4 October 2015 at 10:00, Gary Kotton 
mailto:gkot...@vmware.com>> wrote:
The DHCP agent has the following exception:

2015-10-02 23:57:05.787 ERROR neutron.agent.dhcp.agent 
[req-17c3aa12-41fd-41f8-8e23-2f9740e50746 None None] Failed reporting state!
2015-10-02 23:57:05.787 TRACE neutron.agent.dhcp.agent Traceback (most recent 
call last):
2015-10-02 23:57:05.787 TRACE neutron.agent.dhcp.agent   File 
"/opt/stack/neutron/neutron/agent/dhcp/agent.py", line 572, in _report_state
2015-10-02 23:57:05.787 TRACE neutron.agent.dhcp.agent 
self.state_rpc.report_state(ctx, self.agent_state, self.use_call)
2015-10-02 23:57:05.787 TRACE neutron.agent.dhcp.agent   File 
"/opt/stack/neutron/neutron/agent/rpc.py", line 86, in report_state
2015-10-02 23:57:05.787 TRACE neutron.agent.dhcp.agent return 
method(context, 'report_state', **kwargs)
2015-10-02 23:57:05.787 TRACE neutron.agent.dhcp.agent   File 
"/usr/local/lib/python2.7/dist-packages/oslo_messaging/rpc/client.py", line 
158, in call
2015-10-02 23:57:05.787 TRACE neutron.agent.dhcp.agent retry=self.retry)
2015-10-02 23:57:05.787 TRACE neutron.agent.dhcp.agent   File 
"/usr/local/lib/python2.7/dist-packages/oslo_messaging/transport.py", line 90, 
in _send
2015-10-02 23:57:05.787 TRACE neutron.agent.dhcp.agent timeout=timeout, 
retry=retry)
2015-10-02 23:57:05.787 TRACE neutron.agent.dhcp.agent   File 
"/usr/local/lib/python2.7/dist-packages/oslo_messaging/_drivers/amqpdriver.py", 
line 431, in send
2015-10

Re: [openstack-dev] [Neutron] AZ Support

[Gary Kotton]

On 10/5/15, 3:21 AM, "Ihar Hrachyshka"  wrote:

>> On 04 Oct 2015, at 19:21, Gary Kotton  wrote:
>> 
>> Sorry, it is not a result of the AZ support (humble apologies)
>> 
>> It is a result of https://review.openstack.org/#/c/226362/
>
>So you use DHCP agent with non-ml2 plugin, and it broke you. Do you think
>it¹s ok for you to change the RPC topic to work with Mitaka, or we¹ll
>need to handle it more gracefully, f.e. by detecting the reply timeout
>and switching back to the old topic?

My thinking is that we should fail to use the old topic. But then again, I
would expect that the Neutron service would first be upgraded and then the
agents. Updating the agents first would be a recipe for disaster.

>
>Ihar


__
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] [cloudkitty] No IRC meeting today

[Stéphane Albert]

Hi,

Most of the people involved in the project won't be able to attend
today's meeting. Meeting is canceled.

__
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] [fuel] What to do when a controller runs out of space

[Alex Schultz]

On Mon, Oct 5, 2015 at 5:56 AM, Eugene Nikanorov
 wrote:
> Ok,
>
> Project-wise:
> 1) Pacemaker is not under our company's control, we can't assure its quality
> 2) it has terrible UX
> 3) it is not reliable
>

I disagree with #1 as I do not agree that should be a criteria for an
open-source project.  Considering pacemaker is at the core of our
controller setup, I would argue that if these are in fact true we need
to be using something else.  I would agree that it is a terrible UX
but all the clustering software I've used fall in this category.  I'd
like more information on how it is not reliable. Do we have numbers to
backup these claims?

> (3) is not evaluation of the project itself, but just a logical consequence
> of (1) and (2).
> As a part of escalation team I can say that it has cost our team thousands
> of man hours of head-scratching, staring at pacemaker logs which value are
> usually slightly below zero.
>
> Most of openstack services (in fact, ALL api servers) are stateless, they
> don't require any cluster management (also, they don't need to be moved in
> case of lack of space).
> Statefull services like neutron agents have their states being a function of
> db state and are able to syncronize it with the server without external
> "help".
>

So it's not an issue with moving services so much as being able to
stop the services when a condition is met. Have we tested all OS
services to ensure they do function 100% when out of disk space?  I
would assume that glance might have issues with image uploads if there
is no space to handle a request.

> So now usage of pacemaker can be only justified for cases where service's
> clustering mechanism requires active monitoring (rabbitmq, galera)
> But even there, examples when we are better off without pacemaker are all
> around.
>
> Thanks,
> Eugene.
>

After I sent this email, I had further discussions around the issues
that I'm facing and it may not be completely related to disk space. I
think we might be relying on the expectation that the local rabbitmq
is always available but I need to look into that. Either way, I
believe we still should continue to discuss this issue as we are
managing services in multiple ways on a single host. Additionally I do
not believe that we really perform quality health checks on our
services.

Thanks,
-Alex


>
> On Mon, Oct 5, 2015 at 1:34 PM, Sergey Vasilenko 
> wrote:
>>
>>
>> On Mon, Oct 5, 2015 at 12:22 PM, Eugene Nikanorov
>>  wrote:
>>>
>>> No pacemaker for os services, please.
>>> We'll be moving out neutron agents from pacemaker control in 8.0, other
>>> os services don't need it too.
>>
>>
>> could you please provide your arguments.
>>
>>
>> /sv
>>
>> __
>> 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 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] [mistral] Team meeting - 10/05/2015

[Renat Akhmerov]

Hi,

This is a reminder that we’ll hold a team meeting today at #openstack-meeting 
at 16.00 UTC.

Agenda:
Review action items
Current status (progress, issues, roadblocks, further plans)
UI progress
Official Liberty Release health
Bugfixing progress
Documentation progress
Open discussion

Feel free to add your own topics.

[1] https://wiki.openstack.org/wiki/Meetings/MistralAgenda 


Renat Akhmerov
@ Mirantis Inc.



__
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] AZ Support

[Akihiro Motoki]

Hi,

2015-10-05 15:54 GMT+09:00 Gary Kotton :

> Hi,
> Yes, you are correct. That patch is the culprit (my bad and once again
> humble apologies)
>
> Regarding the AZ support I think that we need to do the following:
>
>1. Have this in a separate topic until it is complete. I have a number
>of concerns here:
>   1. The upgrade impact on Nova. Today in Nova one can have N AZ’s
>   and they will all work on the same virtual networks. It is not clear how
>   this will work here and if the networks can be shared across AZ’s (maybe
>   this was discussed and I am missing somehing)
>
> The proposed "AZ support" feature in Neutron is the really initial step
and we have many points which can be improved.
The first step of AZ support is only related to the agent scheduling andit
just tries to assign agent(s) from AZ(s) which users want.
Networks are still shared across AZs, so I don't think there are upgrade
impacts on Nova.


>1.
>   1. A few weeks ago Monty raised concerns about floating IP support.
>   I think that this will be required for AZ support. In the past one could
>   have a shared network between AZ’s and now they will need two isolated
>   networks
>
> I think Floating IP pool per AZ is a straight forward approach.
However, this does not necessarily mean an external network should limit to
a specific AZ.
Of course, it is better that VMs in AZ1 connect to a network (whose
dhcp-agent lives in AZ1)
and the network is connected to router in AZ1.
The question is how users can select floating IP pool but in this case
users can know which FIP pool belongs to which AZ.

There are other approaches. One possible option is to have one external
network and
a router supports multiple upstream links using routing protocols.

I just wrote approaches in my mind and there must be more options.


>1. In Nova on of the top priority features over the last few cycles
>has been cells. At the moment there is no cell support for Neutron. I feel
>that the AZ support is someone what related and maybe we should try and
>kill 2 birds with one stone here and have the cell support combined if
>possible. I think that this is certainly something that should be a cross
>project summit discussion.
>
>
I agree that Cells support is one of missing areas in Neutron.
I think AZ support and Cells support are different things though they are
similar.
AZ support is visible to users and Cells are not.

Thanks,
Akihiro



> Thanks
> Gary
>
> From: "Armando M." 
> Reply-To: OpenStack List 
> Date: Sunday, October 4, 2015 at 8:18 PM
>
> To: OpenStack List 
> Subject: Re: [openstack-dev] [Neutron] AZ Support
>
>
>
> On 4 October 2015 at 10:00, Gary Kotton  wrote:
>
>> The DHCP agent has the following exception:
>>
>> 2015-10-02 23:57:05.787 ERROR neutron.agent.dhcp.agent
>> [req-17c3aa12-41fd-41f8-8e23-2f9740e50746 None None] Failed reporting state!
>> 2015-10-02 23:57:05.787 TRACE neutron.agent.dhcp.agent Traceback (most
>> recent call last):
>> 2015-10-02 23:57:05.787 TRACE neutron.agent.dhcp.agent   File
>> "/opt/stack/neutron/neutron/agent/dhcp/agent.py", line 572, in _report_state
>> 2015-10-02 23:57:05.787 TRACE neutron.agent.dhcp.agent
>> self.state_rpc.report_state(ctx, self.agent_state, self.use_call)
>> 2015-10-02 23:57:05.787 TRACE neutron.agent.dhcp.agent   File
>> "/opt/stack/neutron/neutron/agent/rpc.py", line 86, in report_state
>> 2015-10-02 23:57:05.787 TRACE neutron.agent.dhcp.agent return
>> method(context, 'report_state', **kwargs)
>> 2015-10-02 23:57:05.787 TRACE neutron.agent.dhcp.agent   File
>> "/usr/local/lib/python2.7/dist-packages/oslo_messaging/rpc/client.py", line
>> 158, in call
>> 2015-10-02 23:57:05.787 TRACE neutron.agent.dhcp.agent
>> retry=self.retry)
>> 2015-10-02 23:57:05.787 TRACE neutron.agent.dhcp.agent   File
>> "/usr/local/lib/python2.7/dist-packages/oslo_messaging/transport.py", line
>> 90, in _send
>> 2015-10-02 23:57:05.787 TRACE neutron.agent.dhcp.agent
>> timeout=timeout, retry=retry)
>> 2015-10-02 23:57:05.787 TRACE neutron.agent.dhcp.agent   File
>> "/usr/local/lib/python2.7/dist-packages/oslo_messaging/_drivers/amqpdriver.py",
>> line 431, in send
>> 2015-10-02 23:57:05.787 TRACE neutron.agent.dhcp.agent retry=retry)
>> 2015-10-02 23:57:05.787 TRACE neutron.agent.dhcp.agent   File
>> "/usr/local/lib/python2.7/dist-packages/oslo_messaging/_drivers/amqpdriver.py",
>> line 420, in _send
>> 2015-10-02 23:57:05.787 TRACE neutron.agent.dhcp.agent result =
>> self._waiter.wait(msg_id, timeout)
>> 2015-10-02 23:57:05.787 TRACE neutron.agent.dhcp.agent   File
>> "/usr/local/lib/python2.7/dist-packages/oslo_messaging/_drivers/amqpdriver.py",
>> line 318, in wait
>> 2015-10-02 23:57:05.787 TRACE neutron.agent.dhcp.agent message =
>> self.waiters.get(msg_id, timeout=timeout)
>> 2015-10-02 23:57:05.787 TRACE neutron.agent.dhcp.agent   File
>> "/usr/local/lib/python2.7/dist-packages/oslo_messaging/_drivers/amqpdriver.py",
>> li

[openstack-dev] [puppet] weekly meeting #54

[Emilien Macchi]

Hello!

Here's an initial agenda for our weekly meeting, tomorrow at 1500 UTC
in #openstack-meeting-4:

https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20151006

Feel free to add any additional items you'd like to discuss.
If our schedule allows it, we'll make bug triage during the meeting.

Note: I'll be at the airport for my trip to Portland (Puppetconf 2015).
Colleen will lead the meeting if my flight is on-time and I'll be
probably afk.

Regards,
-- 
Emilien Macchi



signature.asc
Description: OpenPGP digital signature
__
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] [all][stable][release] 2015.1.2

[Chuck Short]

Hi,

I would like to freeze the branches on Wednesday and get a release out
early next week. Are we okay with that?

Thanks
chuck

On Wed, Sep 23, 2015 at 8:47 PM, Chuck Short 
wrote:

> Hi,
>
> We would like to do a stable/kilo branch release, next Thursday. In order
> to do that I would like to freeze the branches on Friday. Cut some test
> tarballs on Tuesday and release on Thursday. Does anyone have an opinnon on
> this?
>
> Thanks
> chuck
>
__
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] I love csv output in openstackclient, please never removed it

[Sean Dague]

On 10/05/2015 12:16 AM, Steve Martinelli wrote:
> I loved reading this email as much as zigo loves csv output, great
> feedback is an amazing motivator!
> 
> And don't worry, the csv output was never going away :)
> 
> stevemar

It might be nice to change some of the devstack usage into that. It
would help spread the word about it, and be a bit easier to understand.

-Sean

-- 
Sean Dague
http://dague.net

__
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] Fwd: [nova] live migration in Mitaka

[Pavel Boldin]

OK, I propose to move further discussions of the topic to this particular
changeset review.

Pavel

On Mon, Oct 5, 2015 at 1:25 PM, Daniel P. Berrange 
wrote:

> On Mon, Oct 05, 2015 at 01:10:45PM +0300, Pavel Boldin wrote:
> > Daniel,
> >
> > It is done already in the proposed patch.
> >
> > But this one is about Wily having libvirt 1.2.16 and libvirt-python
> 1.2.15.
>
> Assuming you are refering to this patch:
>
> https://review.openstack.org/#/c/227278/3/nova/virt/libvirt/driver.py
>
> that code is only checking the libvirt daemon version, it is not checking
> the libvirt-python version.
>
>
> Regards,
> Daniel
> --
> |: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/
> :|
> |: http://libvirt.org  -o- http://virt-manager.org
> :|
> |: http://autobuild.org   -o- http://search.cpan.org/~danberr/
> :|
> |: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc
> :|
>
__
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] [fuel] What to do when a controller runs out of space

[Eugene Nikanorov]

Ok,

Project-wise:
1) Pacemaker is not under our company's control, we can't assure its quality
2) it has terrible UX
3) it is not reliable

(3) is not evaluation of the project itself, but just a logical consequence
of (1) and (2).
As a part of escalation team I can say that it has cost our team thousands
of man hours of head-scratching, staring at pacemaker logs which value are
usually slightly below zero.

Most of openstack services (in fact, ALL api servers) are stateless, they
don't require any cluster management (also, they don't need to be moved in
case of lack of space).
Statefull services like neutron agents have their states being a function
of db state and are able to syncronize it with the server without external
"help".

So now usage of pacemaker can be only justified for cases where service's
clustering mechanism requires active monitoring (rabbitmq, galera)
But even there, examples when we are better off without pacemaker are all
around.

Thanks,
Eugene.


On Mon, Oct 5, 2015 at 1:34 PM, Sergey Vasilenko 
wrote:

>
> On Mon, Oct 5, 2015 at 12:22 PM, Eugene Nikanorov  > wrote:
>
>> No pacemaker for os services, please.
>> We'll be moving out neutron agents from pacemaker control in 8.0, other
>> os services don't need it too.
>>
>
> could you please provide your arguments.
>
>
> /sv
>
> __
> 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

Re: [openstack-dev] [fuel] What to do when a controller runs out of space

[Sergey Vasilenko]

On Mon, Oct 5, 2015 at 12:22 PM, Eugene Nikanorov 
wrote:

> No pacemaker for os services, please.
> We'll be moving out neutron agents from pacemaker control in 8.0, other os
> services don't need it too.
>

could you please provide your arguments.


/sv
__
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] Fwd: [nova] live migration in Mitaka

[Daniel P. Berrange]

On Mon, Oct 05, 2015 at 01:10:45PM +0300, Pavel Boldin wrote:
> Daniel,
> 
> It is done already in the proposed patch.
> 
> But this one is about Wily having libvirt 1.2.16 and libvirt-python 1.2.15.

Assuming you are refering to this patch:

https://review.openstack.org/#/c/227278/3/nova/virt/libvirt/driver.py

that code is only checking the libvirt daemon version, it is not checking
the libvirt-python version.


Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

__
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] [tripleo] How to selectively enable new services?

[marios]

On 01/10/15 20:34, Dan Prince wrote:
> On Wed, 2015-09-30 at 21:05 +0100, Steven Hardy wrote:
>> Hi all,
>>
>> So I wanted to start some discussion on $subject, because atm we have
>> a
>> couple of patches adding support for new services (which is great!):
>>
>> Manila: https://review.openstack.org/#/c/188137/
>> Sahara: https://review.openstack.org/#/c/220863/
>>
>> So, firstly I am *not* aiming to be any impediment to those landing,
>> and I
>> know they have been in-progress for some time.  These look pretty
>> close to
>> being ready to land and overall I think new service integration is a
>> very
>> good thing for TripleO.
>>
>> However, given the recent evolution towards the "big tent" of
>> OpenStack, I
>> wanted to get some ideas on what an effective way to selectively
>> enable
>> services would look like, as I can imagine not all users of TripleO
>> want to
>> deploy all-the-services all of the time.
>>
>> I was initially thinking we simply have e.g "EnableSahara" as a
>> boolean in
>> overcloud-without-mergepy, and wire that in to the puppet manifests,
>> such
>> that the services are not configured/started.  However comments in
>> the
>> Sahara patch indicate it may be more complex than that, in particular
>> requiring changes to the loadbalancer puppet code and os-cloud
>> -config.
>>
>> This is all part of the more general "composable roles" problem, but
>> is
>> there an initial step we can take, which will make it easy to simply
>> disable services (and ideally not pay the cost of configuring them at
>> all)
>> on deployment?
>>
>> Interested in peoples thoughts on this - has anyone already looked
>> into it,
>> or is there any existing pattern we can reuse?
> 
> A couple of ideas I would throw out that might help us pair down the
> larger controller role into more composable roles.
> 
> On the Heat side we could individual role templates directly. So new
> nested stack templates for Sahara and Manilla (or any service really).
> These templates would still wire into the controller.yaml in much the
> same way... but we would compose the resulting configuration metadata
> based on what was configured in the resource registry. So if Sahara or
> Manilla is set to a noop resource we would essentially get a controller
> without those service. If it is enabled then we would pull in the extra
> configuration metadata (hiera) and wire it into the structured config
> as normal. Perhaps a new 'roles' directory would help organize these
> services... The mechanism for composability on the Heat side is really
> the resource registry so we need to be careful to name and document
> these things correctly.
> 
> 
> 
> On the Puppet side the initial goal was to avoid creating what we
> called a composition layer, which is basically a new set of puppet
> modules that act as a front end for all of your roles etc. This isn't
> to say that we don't want composability with the Puppet (we do) but
> just that our preference was to write role manifests that used direct
> include statements to OpenStack Puppet modules. This proved to be a
> more hackable set of templates and forces us to use (as much as
> possible) OpenStack puppet or add functionality there rather than go
> and write our own puppet-tripleo to rule the world.
> 
> In practice that didn't fully work out and we do have a small bit of
> Puppet code in puppet-tripleo. I consider much of this to be technical
> debt and over the mid to long term would prefer to refactor and add the
> puppet-tripleo bits elsewhere.
> 
> One area we could improve our puppet architecture might be with regards
> to how we actually deploy the puppet manifests themselves. Currently we
> deploy the manifests with Heat directly by using get_file to deploy the
> manifest alongside of the SoftwareConfig (looks something like this htt
> p://git.openstack.org/cgit/openstack/tripleo-heat
> -templates/tree/puppet/compute-post.yaml#n23). This works really nicely
> in that our puppet manifests can live alongside of the (lightly)
> coupled Heat templates which pass in parameters via Hiera. However the
> approach is limited in that we can only deploy a single manifest (not a
> directory of roles that could be dynamically assembled or included on
> the fly). Perhaps we could expand this capability a bit so that we
> could structure the puppet a bit more freely into decomposed role
> manifests. We already have a similar thing going on w/ the Hiera
> element where we can deploy multiple Hiera files for each role. So
> perhaps a script step to deploy multiple puppet files (generic so it
> could be used in multiple templates), or perhaps we could use Swift to
> deploy these alongside of Heat (I'm not sure we have the required
> OS::Swift heat resources for this ATM though).
> 
> Again we've already got mechanisms to compose puppet Hiera, we just
> need a few more tricks to more easily compose the role manifests
> themselves...
> 
> Dan
> 
> 
> 
>>
>> As mentioned above, not aiming to block 

Re: [openstack-dev] [Neutron] AZ Support

[Ihar Hrachyshka]

> On 04 Oct 2015, at 19:21, Gary Kotton  wrote:
> 
> Sorry, it is not a result of the AZ support (humble apologies)
> 
> It is a result of https://review.openstack.org/#/c/226362/

So you use DHCP agent with non-ml2 plugin, and it broke you. Do you think it’s 
ok for you to change the RPC topic to work with Mitaka, or we’ll need to handle 
it more gracefully, f.e. by detecting the reply timeout and switching back to 
the old topic?

Ihar


signature.asc
Description: Message signed with OpenPGP using GPGMail
__
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] Fwd: [nova] live migration in Mitaka

[Pavel Boldin]

Daniel,

It is done already in the proposed patch.

But this one is about Wily having libvirt 1.2.16 and libvirt-python 1.2.15.

Pavel

On Mon, Oct 5, 2015 at 11:25 AM, Daniel P. Berrange 
wrote:

> On Fri, Oct 02, 2015 at 04:38:30PM -0400, Mathieu Gagné wrote:
> > On 2015-10-02 4:18 PM, Pavel Boldin wrote:
> > >
> > > You have to pass device names from /dev/, e.g., if a VM has
> > > ephemeral disk
> > > attached at /dev/vdb you need to pass in 'vdb'. Format expected by
> > > migrate_disks is ",...".
> > >
> > >
> > > This is the format expected by the `virsh' utility and will not work in
> > > Python.
> > >
> > > The libvirt-python has now support for passing lists to a parameter
> [1].
> > >
> > > [1]
> > >
> http://libvirt.org/git/?p=libvirt-python.git;a=commit;h=9896626b8277e2ffba1523d2111c96b08fb799e8
> > >
> >
> > Thanks for the info. I was banging my head against the wall, trying to
> > understand why it didn't accept my list of strings.
> >
> > Now the next challenge is with Ubuntu packages, only python-libvirt
> > 1.2.15 is available in Ubuntu Willy. :-/
>
> You already need a runtime version check for libvirt to see if the new
> migration API is available. You just need to extend that to also check
> the libvirt client version
>
>
> Regards,
> Daniel
> --
> |: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/
> :|
> |: http://libvirt.org  -o- http://virt-manager.org
> :|
> |: http://autobuild.org   -o- http://search.cpan.org/~danberr/
> :|
> |: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc
> :|
>
> __
> 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

Re: [openstack-dev] [neutron] New cycle started. What are you up to, folks?

[Rossella Sblendido]

Very nice thread Ihar!

Here are my plans:

1. Get the last patches of the blueprint restructure-l2-agent  merged
and keep working on improving the agent. Some code refactor is
definitely needed and I'd like to add multiple workers.

2. Introducing oslo versioned objects

3. Make it easier to get started in Neutron.
   - mentor people
   - write docs/blog posts
   - in general simplify the current code when possible

4. Getting some performance data and store them for future reference


cheers,

Rossella

On Mon, 2015-10-05 at 18:29 +0900, Hirofumi Ichihara wrote:
> Hi,
> 
> 
> I have some plans in Mitaka cycle.
> 
> 
> 1. AZ support[1]
>  - I proposed AZ support in Liberty but the millstone is Mitaka now.
> The spec has been merged in Mitaka.
>I keep to propose the patches on Gerrit.
> 2. LinuxbrideDVR
>  - I'm trying to create concrete implementation and then I achieve it
> nearly. I will propose BP or RFE bug ASAP.
> 3. Router status update[2]
>  - I proposed it as bug[3] but some folks disagreed with this. I will
> classify the requirements and propose the implementation.
> 4. Devstack
>  - In Liberty cycle, I was aimed at removing plugin restriction from
> devstack so that vendor plugin maintainers easily keep to maintain the
> code in their tree.
>And also I tried to improve the quality for neutron. I’ve already
> finished some works.
>I will keep to contribute to devstack for neutron in Mitaka cycle
> including discussion about neutron repo vs devstack repo.
>If you have trouble with devstack related to neutron(especially
> devstack plugin), I can help you.
> 5. More
>  - I keep to contribute something else(especially logic for operators)
> for neutron :)
> 
> 
> [1]: https://blueprints.launchpad.net/neutron/+spec/add-availability-zone
> [2]: https://blueprints.launchpad.net/neutron/+spec/l3-router-status
> [3]: https://bugs.launchpad.net/neutron/+bug/1341290
> 
> 
> Thanks,
> Hirofumi
> 
> > On 2015/10/01, at 23:02, Ihar Hrachyshka 
> > wrote:
> > 
> > > On 01 Oct 2015, at 15:45, Ihar Hrachyshka 
> > > wrote:
> > > 
> > > Hi all,
> > > 
> > > I talked recently with several contributors about what each of us
> > > plans for the next cycle, and found it’s quite useful to share
> > > thoughts with others, because you have immediate yay/nay feedback,
> > > and maybe find companions for next adventures, and what not. So
> > > I’ve decided to ask everyone what you see the team and you
> > > personally doing the next cycle, for fun or profit.
> > > 
> > > That’s like a PTL nomination letter, but open to everyone! :) No
> > > commitments, no deadlines, just list random ideas you have in mind
> > > or in your todo lists, and we’ll all appreciate the huge pile of
> > > awesomeness no one will ever have time to implement even if
> > > scheduled for Xixao release.
> > > 
> > > To start the fun, I will share my silly ideas in the next email.
> > 
> > Here is my silly list of stuff to do.
> > 
> > - start adopting NeutronDbObject for core resources (ports,
> > networks) [till now, it’s used in QoS only];
> > 
> > - introduce a so called ‘core resource extender manager’ that would
> > be able to replace ml2 extension mechanism and become a plugin
> > agnostic way of extending core resources by additional plugins
> > (think of port security or qos available for ml2 only - that sucks!
> > );
> > 
> > - more changes with less infra tinkering! neutron devs should not
> > need to go to infra projects so often to make an impact;
> > -- make our little neat devstack plugin used for qos and sr-iov only
> > a huge pile of bash code that is currently stored in devstack and is
> > proudly called neutron-legacy now; and make the latter obsolete and
> > eventually removed from devstack;
> > -- make tempest jobs use a gate hook as we already do for api jobs;
> > 
> > - qos:
> > -- once we have gate hook triggered, finally introduce qos into
> > tempest runs to allow first qos scenarios merged;
> > -- remove RPC upgrade tech debt that we left in L (that should open
> > path for new QoS rules that are currently blocked by it);
> > -- look into races in rpc.callbacks notification pattern (Kevin
> > mentioned he had ideas in mind around that);
> > 
> > - oslo:
> > -- kill the incubator: we have a single module consumed from there
> > (cache); Mitaka is the time for the witch to die in pain;
> > -- adopt oslo.reports: that is something I failed to do in Liberty
> > so that I would have a great chance to do the same in Mitaka;
> > basically, allow neutron services to dump ‘useful info’ on SIGUSR2
> > sent; hopefully will make debugging a bit easier;
> > 
> > - upgrades:
> > -- we should return to partial job for neutron; it’s not ok our
> > upgrade strategy works by pure luck;
> > -- overall, I feel that it’s needed to provide more details about
> > how upgrades are expected to work in OpenStack (the order of service
> > upgrades; constraints; managing RPC versions and deprecations; etc.)
> > Probably devref should b

Re: [openstack-dev] [Neutron] Defect management

[Ihar Hrachyshka]

> On 02 Oct 2015, at 02:37, Armando M.  wrote:
> 
> Hi neutrinos,
> 
> Whilst we go down the path of revising the way we manage/process bugs in 
> Neutron, and transition to the proposed model [1], I was wondering if I can 
> solicit some volunteers to screen the bugs outlined in [2]. It's only 24 bugs 
> so it should be quick ;)

I am fine to be a guinea pig, though I don’t have edit access to the 
spreadsheet.

Ihar


signature.asc
Description: Message signed with OpenPGP using GPGMail
__
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] New cycle started. What are you up to, folks?

[Hirofumi Ichihara]

Hi,

I have some plans in Mitaka cycle.

1. AZ support[1]
 - I proposed AZ support in Liberty but the millstone is Mitaka now. The spec 
has been merged in Mitaka.
   I keep to propose the patches on Gerrit.
2. LinuxbrideDVR
 - I'm trying to create concrete implementation and then I achieve it nearly. I 
will propose BP or RFE bug ASAP.
3. Router status update[2]
 - I proposed it as bug[3] but some folks disagreed with this. I will classify 
the requirements and propose the implementation.
4. Devstack
 - In Liberty cycle, I was aimed at removing plugin restriction from devstack 
so that vendor plugin maintainers easily keep to maintain the code in their 
tree.
   And also I tried to improve the quality for neutron. I’ve already finished 
some works.
   I will keep to contribute to devstack for neutron in Mitaka cycle including 
discussion about neutron repo vs devstack repo.
   If you have trouble with devstack related to neutron(especially devstack 
plugin), I can help you.
5. More
 - I keep to contribute something else(especially logic for operators) for 
neutron :)

[1]: https://blueprints.launchpad.net/neutron/+spec/add-availability-zone 

[2]: https://blueprints.launchpad.net/neutron/+spec/l3-router-status 

[3]: https://bugs.launchpad.net/neutron/+bug/1341290 


Thanks,
Hirofumi

> On 2015/10/01, at 23:02, Ihar Hrachyshka  wrote:
> 
>> On 01 Oct 2015, at 15:45, Ihar Hrachyshka  wrote:
>> 
>> Hi all,
>> 
>> I talked recently with several contributors about what each of us plans for 
>> the next cycle, and found it’s quite useful to share thoughts with others, 
>> because you have immediate yay/nay feedback, and maybe find companions for 
>> next adventures, and what not. So I’ve decided to ask everyone what you see 
>> the team and you personally doing the next cycle, for fun or profit.
>> 
>> That’s like a PTL nomination letter, but open to everyone! :) No 
>> commitments, no deadlines, just list random ideas you have in mind or in 
>> your todo lists, and we’ll all appreciate the huge pile of awesomeness no 
>> one will ever have time to implement even if scheduled for Xixao release.
>> 
>> To start the fun, I will share my silly ideas in the next email.
> 
> Here is my silly list of stuff to do.
> 
> - start adopting NeutronDbObject for core resources (ports, networks) [till 
> now, it’s used in QoS only];
> 
> - introduce a so called ‘core resource extender manager’ that would be able 
> to replace ml2 extension mechanism and become a plugin agnostic way of 
> extending core resources by additional plugins (think of port security or qos 
> available for ml2 only - that sucks!);
> 
> - more changes with less infra tinkering! neutron devs should not need to go 
> to infra projects so often to make an impact;
> -- make our little neat devstack plugin used for qos and sr-iov only a huge 
> pile of bash code that is currently stored in devstack and is proudly called 
> neutron-legacy now; and make the latter obsolete and eventually removed from 
> devstack;
> -- make tempest jobs use a gate hook as we already do for api jobs;
> 
> - qos:
> -- once we have gate hook triggered, finally introduce qos into tempest runs 
> to allow first qos scenarios merged;
> -- remove RPC upgrade tech debt that we left in L (that should open path for 
> new QoS rules that are currently blocked by it);
> -- look into races in rpc.callbacks notification pattern (Kevin mentioned he 
> had ideas in mind around that);
> 
> - oslo:
> -- kill the incubator: we have a single module consumed from there (cache); 
> Mitaka is the time for the witch to die in pain;
> -- adopt oslo.reports: that is something I failed to do in Liberty so that I 
> would have a great chance to do the same in Mitaka; basically, allow neutron 
> services to dump ‘useful info’ on SIGUSR2 sent; hopefully will make debugging 
> a bit easier;
> 
> - upgrades:
> -- we should return to partial job for neutron; it’s not ok our upgrade 
> strategy works by pure luck;
> -- overall, I feel that it’s needed to provide more details about how 
> upgrades are expected to work in OpenStack (the order of service upgrades; 
> constraints; managing RPC versions and deprecations; etc.) Probably devref 
> should be a good start. I talked to some nova folks involved in upgrades 
> there, and we may join the armies on that since general upgrade strategy 
> should be similar throughout the meta-project.
> 
> - stable:
> -- with a stadium of the size we have, it becomes a burden for 
> neutron-stable-maint to track backports for all projects; we should think of 
> opening doors for more per-sub-project stable cores for those subprojects 
> that seem sane in terms of development practices and stable awareness side; 
> that way we offload neutron-stable-maint folks for stuff with greater impact 
> (

Re: [openstack-dev] [fuel] What to do when a controller runs out of space

[Eugene Nikanorov]

No pacemaker for os services, please.
We'll be moving out neutron agents from pacemaker control in 8.0, other os
services don't need it too.

E.
5 окт. 2015 г. 12:01 пользователь "Sergii Golovatiuk" <
sgolovat...@mirantis.com> написал:

> Good morning gentlemen!
>
> Alex raised very good question. Thank you very much! We have 3 init
> systems right now. Some services use SystemV, some services use upstart,
> some services are under pacemaker. Personally, I would like to have
> pacemaker as pid 1 to replace init [1]. However, I would like to remove
> custom scripts as much as possible to leave only upstart/systemd classes
> [2] only. That move will give fantastic flexibility to operators to control
> their services.
>
> Concerning Haproxy checker, I think it should be done in different way. If
> pacemaker/corosyunc has an issue the node should be fenced.
>
> Also, I would like to have pacemaker remote to control services on compute
> nodes. It's very good replacement for monit.
>
> [1] https://www.youtube.com/watch?v=yq5nYPKxBCo
> [2]
> http://clusterlabs.org/doc/en-US/Pacemaker/1.1/html/Pacemaker_Explained/s-resource-supported.html
>
>
>
> --
> Best regards,
> Sergii Golovatiuk,
> Skype #golserge
> IRC #holser
>
> __
> 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

Re: [openstack-dev] [fuel] What to do when a controller runs out of space

[Sergii Golovatiuk]

Good morning gentlemen!

Alex raised very good question. Thank you very much! We have 3 init systems
right now. Some services use SystemV, some services use upstart, some
services are under pacemaker. Personally, I would like to have pacemaker as
pid 1 to replace init [1]. However, I would like to remove custom scripts
as much as possible to leave only upstart/systemd classes [2] only. That
move will give fantastic flexibility to operators to control their services.

Concerning Haproxy checker, I think it should be done in different way. If
pacemaker/corosyunc has an issue the node should be fenced.

Also, I would like to have pacemaker remote to control services on compute
nodes. It's very good replacement for monit.

[1] https://www.youtube.com/watch?v=yq5nYPKxBCo
[2]
http://clusterlabs.org/doc/en-US/Pacemaker/1.1/html/Pacemaker_Explained/s-resource-supported.html



--
Best regards,
Sergii Golovatiuk,
Skype #golserge
IRC #holser
__
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] Fwd: [nova] live migration in Mitaka

[Daniel P. Berrange]

On Fri, Oct 02, 2015 at 04:38:30PM -0400, Mathieu Gagné wrote:
> On 2015-10-02 4:18 PM, Pavel Boldin wrote:
> > 
> > You have to pass device names from /dev/, e.g., if a VM has
> > ephemeral disk
> > attached at /dev/vdb you need to pass in 'vdb'. Format expected by
> > migrate_disks is ",...".
> > 
> > 
> > This is the format expected by the `virsh' utility and will not work in
> > Python.
> > 
> > The libvirt-python has now support for passing lists to a parameter [1].
> > 
> > [1]
> > http://libvirt.org/git/?p=libvirt-python.git;a=commit;h=9896626b8277e2ffba1523d2111c96b08fb799e8
> >  
> 
> Thanks for the info. I was banging my head against the wall, trying to
> understand why it didn't accept my list of strings.
> 
> Now the next challenge is with Ubuntu packages, only python-libvirt
> 1.2.15 is available in Ubuntu Willy. :-/

You already need a runtime version check for libvirt to see if the new
migration API is available. You just need to extend that to also check
the libvirt client version


Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

__
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] AZ Support

[Hirofumi Ichihara]

Hi Gary,

Thank you for your suggestion.
In Liberty cycle[1], I have discussed about these points with neutron folks and 
network operators.


> On 2015/10/05, at 15:54, Gary Kotton  wrote:
> 
> Hi,
> Yes, you are correct. That patch is the culprit (my bad and once again humble 
> apologies)
> 
> Regarding the AZ support I think that we need to do the following:
> Have this in a separate topic until it is complete. I have a number of 
> concerns here:
> The upgrade impact on Nova. Today in Nova one can have N AZ’s and they will 
> all work on the same virtual networks. It is not clear how this will work 
> here and if the networks can be shared across AZ’s (maybe this was discussed 
> and I am missing somehing)
> A few weeks ago Monty raised concerns about floating IP support. I think that 
> this will be required for AZ support. In the past one could have a shared 
> network between AZ’s and now they will need two isolated networks
I guess that this is similar to “Segment” discussion[2].
I tried to include this point to Availability Zone spec so that we can deploy 
an environment has network unreachable AZs.
However, some folks disagreed with this because availability zone must be 
something to give users High Availability not manage isolated network with AZ.

> 
> In Nova on of the top priority features over the last few cycles has been 
> cells. At the moment there is no cell support for Neutron. I feel that the AZ 
> support is someone what related and maybe we should try and kill 2 birds with 
> one stone here and have the cell support combined if possible. I think that 
> this is certainly something that should be a cross project summit discussion.
I think too that Neutron Cell Support is important. However, neutron quite 
depends on the backend unlike nova.
It’s hard to combine it and it will take a long time. AZ support is also 
different from Cell support.
We should not discuss these to connect Neutron AZ support with Cell support 
because I’m afraid to fall between two stools.
I agree that we have a cross project summit discussion to connect Nova Cell 
support with Neutron Cell support.

[1]: https://review.openstack.org/#/c/169612/ 

[2]: https://bugs.launchpad.net/neutron/+bug/1458890 


Thanks,
Hirofumi


> Thanks
> Gary
> 
> From: "Armando M." mailto:arma...@gmail.com>>
> Reply-To: OpenStack List  >
> Date: Sunday, October 4, 2015 at 8:18 PM
> To: OpenStack List  >
> Subject: Re: [openstack-dev] [Neutron] AZ Support
> 
> 
> 
> On 4 October 2015 at 10:00, Gary Kotton  > wrote:
>> The DHCP agent has the following exception:
>> 
>> 2015-10-02 23:57:05.787 ERROR neutron.agent.dhcp.agent 
>> [req-17c3aa12-41fd-41f8-8e23-2f9740e50746 None None] Failed reporting state!
>> 2015-10-02 23:57:05.787 TRACE neutron.agent.dhcp.agent Traceback (most 
>> recent call last):
>> 2015-10-02 23:57:05.787 TRACE neutron.agent.dhcp.agent   File 
>> "/opt/stack/neutron/neutron/agent/dhcp/agent.py", line 572, in _report_state
>> 2015-10-02 23:57:05.787 TRACE neutron.agent.dhcp.agent 
>> self.state_rpc.report_state(ctx, self.agent_state, self.use_call)
>> 2015-10-02 23:57:05.787 TRACE neutron.agent.dhcp.agent   File 
>> "/opt/stack/neutron/neutron/agent/rpc.py", line 86, in report_state
>> 2015-10-02 23:57:05.787 TRACE neutron.agent.dhcp.agent return 
>> method(context, 'report_state', **kwargs)
>> 2015-10-02 23:57:05.787 TRACE neutron.agent.dhcp.agent   File 
>> "/usr/local/lib/python2.7/dist-packages/oslo_messaging/rpc/client.py", line 
>> 158, in call
>> 2015-10-02 23:57:05.787 TRACE neutron.agent.dhcp.agent retry=self.retry)
>> 2015-10-02 23:57:05.787 TRACE neutron.agent.dhcp.agent   File 
>> "/usr/local/lib/python2.7/dist-packages/oslo_messaging/transport.py", line 
>> 90, in _send
>> 2015-10-02 23:57:05.787 TRACE neutron.agent.dhcp.agent timeout=timeout, 
>> retry=retry)
>> 2015-10-02 23:57:05.787 TRACE neutron.agent.dhcp.agent   File 
>> "/usr/local/lib/python2.7/dist-packages/oslo_messaging/_drivers/amqpdriver.py",
>>  line 431, in send
>> 2015-10-02 23:57:05.787 TRACE neutron.agent.dhcp.agent retry=retry)
>> 2015-10-02 23:57:05.787 TRACE neutron.agent.dhcp.agent   File 
>> "/usr/local/lib/python2.7/dist-packages/oslo_messaging/_drivers/amqpdriver.py",
>>  line 420, in _send
>> 2015-10-02 23:57:05.787 TRACE neutron.agent.dhcp.agent result = 
>> self._waiter.wait(msg_id, timeout)
>> 2015-10-02 23:57:05.787 TRACE neutron.agent.dhcp.agent   File 
>> "/usr/local/lib/python2.7/dist-packages/oslo_messaging/_drivers/amqpdriver.py",
>>  line 318, in wait
>> 2015-10-02 23:57:05.787 TRACE neutron.agent.dhcp.agent message = 
>> self.waiters.get(msg_id, timeout=timeout)
>> 2015-10-02 23:57:05.787 TRACE neutron.agent.dhcp.agent   File 
>> "/usr/local/lib/python2.7/dist-packages/oslo_messaging/_driv

[openstack-dev] [nova-compute][libvirt] permission problems

[Joseph Park]

Hi all,

I have permission-related errors when creating instances.

In Kilo,

since my local disk is  small, newly attaching a new disk, /data1 as
following.

root@cn2:/var/lib/nova# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda5 23G 1.7G 20G 8% /
...
/dev/mapper/vg_data-lv_data1 356G 703M 338G 1% /data1

and add a setting 'instances_path=/data1/instances' in nova.conf at compute
node.

root@cn2:/data1# ls -la
total 28
drwxr-xr-x 4 nova nova 4096 16:51 .
drwxr-xr-x 25 root root 4096 10:07 ..
drwxr-xr-x 2 nova nova 4096 16:50 instances drwx-- 2 nova nova 16384
13:51 lost+found root@cn2:/data1# pwd
/data1
root@cn2:/data1# ls -la instances/
total 8
drwxr-xr-x 2 nova nova 4096 16:50 .
drwxr-xr-x 4 nova nova 4096 16:51 .. root@cn2:/data1#

but whenever creating an instance, nova-compute.log shows libvirt error as
below:

libvirtError: internal error: process exited while connecting to monitor:
2015-10-02T07:02:25.031125Z qemu-system-x86_64: -drive
file=/data1/instances/03e58fd3-b555-4aa3-91fa-5e6fcc15978a/disk,if=none,id=drive-virtio-disk0,format=qcow2,cache=none:
could not open disk image
/data1/instances/03e58fd3-b555-4aa3-91fa-5e6fcc15978a/disk: Could not open
backing file: Could not open
'/data1/instances/_base/d7607a887a4e5b41ec4b9ccdbf16d356ca6c9c0f':
Permission denied

instead of a setting 'instances_path=/data1/instances' in nova.conf at
compute node,

symbolic link 'ln -s /data1/instances /var/lib/nova/' also shows the same
errors.

no changes in /etc/libvirt/qemu.conf libvirt-bin.conf ...

what's the matter in this situation? plz help me...
__
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