Re: [openstack-dev] [neutron][devstack][keystone] Devstack failures due to empty service catalogue

[Jakub Libosvar]

It is caused by using old python-openstackclient [1]. We should be using
>= 1.0.2 - fix is about to be merged [2].

Kuba

[1] https://bugs.launchpad.net/devstack/+bug/1413252
[2] https://review.openstack.org/#/c/148951/

On 01/22/2015 04:20 AM, Zhou, Zhenzan wrote:
> Just noticed that your log has “2015-01-21 16:43:24.674 | The service
> catalog is empty.”
> 
>  
> 
> I just met a similar issue: stack.sh aborted with service catalog empty
> error). I
> 
> find errors like below:
> 
>  
> 
> 2015-01-22 14:34:10.048 | ++ get_or_create_service cinder volume 'Cinder
> Volume Service'
> 
> 2015-01-22 14:34:10.049 | +++ openstack service show cinder -f value -c id
> 
> 2015-01-22 14:34:10.607 | +++ openstack service create volume --name
> cinder '--description=Cinder Volume Service' -f value -c id
> 
> 2015-01-22 14:34:11.096 | usage: openstack service create [-h] [-f
> {html,json,shell,table,value,yaml}]
> 
> 2015-01-22 14:34:11.096 | [-c COLUMN]
> [--max-width ]
> 
> 2015-01-22 14:34:11.096 | [--prefix
> PREFIX] --type 
> 
> 2015-01-22 14:34:11.096 | [--description
> ]
> 
> 2015-01-22 14:34:11.097 | 
> 
> 2015-01-22 14:34:11.097 | openstack service create: error: argument
> --type is required
> 
>  
> 
> The reason is that my openstack client is old and not compatible with
> new devstack code. I have to git clone python-openstackclient and
> 
> install it manually.
> 
> I don’t know why devstack doesn’t check this. Any comments from experts?
> Thanks.
> 
>  
> 
> BR
> 
> Zhou Zhenzan
> 
>  
> 
>  
> 
> *From:*Sukhdev Kapur [mailto:sukhdevka...@gmail.com]
> *Sent:* Thursday, January 22, 2015 4:58 AM
> *To:* OpenStack Development Mailing List (not for usage questions);
> openstack-in...@lists.openstack.org
> *Subject:* [openstack-dev] [neutron][devstack][keystone] Devstack
> failures due to empty service catalogue
> 
>  
> 
> Hi All, 
> 
>  
> 
> I noticed that our CI got hit sometime last night. Neutron is unable to
> create "private" network as there is no Tenant ID. 
> 
>  
> 
> Please see the error log here - http://paste.openstack.org/show/159912/
> 
>  
> 
> It appears that keystone is not creating tenant. Keystone screen log did
> not show anything obvious.
> 
>  
> 
> I wonder if others saw the same issue and if anybody has any idea as to
> what could have caused this? I looked at the obvious places and could
> not find anything interesting. 
> 
>  
> 
> Any guidance/help will be appreciated. 
> 
>  
> 
> Thanks
> 
> -Sukhdev
> 
>  
> 
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 


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

[openstack-dev] [nova] Adding new features to Kilo and future releases - DB upgrades

[Kekane, Abhishek]

Hi devs,

With online schema changes/No downtime DB upgrades things would be much lot 
easier for OpenStack deployments.
Big kudos to Johannes who initiated this feature. But as a service provider, 
I'm curious to understand what is the development process of adding new 
features to Kilo and future releases once the online schema changes is in.


1.   Will the committer be responsible of adding new procedures of 
upgrading db with minimal or zero downtime? or the online schema changes 
framework itself will detect whatever db changes are required on its own and 
the decision to apply db changes online or offline will be left solely with the 
service provider?


2.   Is it possible to predict how much time it would take to upgrade db 
(expand/migrate/contract phases) for adding a new column, constraint.
For example, adding a new column with NULL constraint would 
take less time than adding a default value.


Please let us know your valuable opinions for the same.

Thank you,

Abhishek Kekane

__
Disclaimer: This email and any attachments are sent in strictest confidence
for the sole use of the addressee and may contain legally privileged,
confidential, and proprietary data. If you are not the intended recipient,
please advise the sender by replying promptly to this email and then delete
and destroy this email and any attachments without any further use, copying
or forwarding.__
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] [horizon] static files handling, bower/

[Radomir Dopieralski]

On 21/01/15 19:04, Matthew Farina wrote:
> Radomir, thanks for adding some clarity. I do have follow-on questions.
> 
> In your example the packages are managed by xstatic. The proposal for
> horizon, as I understand it, is to move away from xstatic packages and
> instead use bower for development and system packages (for example,
> debian, rpm, and other packages) for production. Right now, we (the
> horizon community) is maintaining some of the xstatic packages. For many
> of these xstatic packages there is no corollary in a system package. Who
> will create and maintain the system packages for the JavaScript libraries?
> 
> You noted that "we get maintenance and updates for free." Since the
> system packages don't exist now and we don't know who will create or
> maintain them I'm not sure how to reconcile this.
> 
> What am I missing?

All of the XStatic packages had to be packaged for the respective
distributions in order to package Horizon. That was a lot of work, but
it has been done my the packagers of the distributions. As far as I
understand, most of those XStatic packages are just dummies, pointing to
the actual system-wide JavaScript packages -- XStatic has such a
capability. So while we are indeed maintaining some of the XStatic
packages for our own convenience, the packages that contain actual code
in the distributions are maintained by those distributions' packagers.

-- 
Radomir Dopieralski

__
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] [horizon] static files handling, bower/

[Matthias Runge]

On 22/01/15 09:48, Radomir Dopieralski wrote:

> All of the XStatic packages had to be packaged for the respective
> distributions in order to package Horizon. That was a lot of work, but
> it has been done my the packagers of the distributions. As far as I
> understand, most of those XStatic packages are just dummies, pointing to
> the actual system-wide JavaScript packages -- XStatic has such a
> capability. So while we are indeed maintaining some of the XStatic
> packages for our own convenience, the packages that contain actual code
> in the distributions are maintained by those distributions' packagers.
> 
Yupp,

poniting to system packages is something, which makes the XStatic
approach way more acceptable.
But, if you don't have them (yet), xstatic packages will bundle js libs
for you.

Matthias

__
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] [horizon] static files handling, bower/

[Martin Geisler]

Matthias Runge  writes:

> On 22/01/15 09:48, Radomir Dopieralski wrote:
>
>> All of the XStatic packages had to be packaged for the respective
>> distributions in order to package Horizon. That was a lot of work, but
>> it has been done my the packagers of the distributions. As far as I
>> understand, most of those XStatic packages are just dummies, pointing to
>> the actual system-wide JavaScript packages -- XStatic has such a
>> capability. So while we are indeed maintaining some of the XStatic
>> packages for our own convenience, the packages that contain actual code
>> in the distributions are maintained by those distributions' packagers.
>> 
> Yupp,
>
> poniting to system packages is something, which makes the XStatic
> approach way more acceptable.

Maybe this is a dumb question, but if there already is a system package
for, say, Angular, why is the XStatic packge needed then? Could the
system package for Horizon not just point directly to where the Angular
package has put its files?

-- 
Martin Geisler

http://google.com/+MartinGeisler


signature.asc
Description: PGP 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] [neutron][devstack][keystone] Devstack failures due to empty service catalogue

[Kashyap Chamarthy]

On Thu, Jan 22, 2015 at 09:42:50AM +0100, Jakub Libosvar wrote:
> It is caused by using old python-openstackclient [1]. We should be using
> >= 1.0.2 - fix is about to be merged [2].

Thanks Jakub for helping me debug this on the IRC yesterday!

I hope these kind of backward incompatible changes can be avoided in
`openstack` client. It's really annoying to guess at these kind of
changes that consumes time for debugging (needlessly).


-- 
/kashyap

__
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] oslo_log/oslo_config initialization

[Davanum Srinivas]

Qiming,

you are reading bits and pieces of my responses."if you checkout the
review" guess i give up!

-- dims

On Wed, Jan 21, 2015 at 11:18 PM, Qiming Teng
 wrote:
> On Wed, Jan 21, 2015 at 10:55:37AM -0500, Davanum Srinivas wrote:
>> Qiming,
>>
>> Guessing you were looking at master. if you checkout the review i
>> pointed to, you will see what others on the thread have pointed you
>> to:
>> https://github.com/openstack/oslo.log/blob/master/doc/source/usage.rst
>>
>> We are using register_options and setup. we should be adding
>> register_options in the future as need arises.
>
> In most files listed below, the 'logging' refers to
> nova/openstack/common/log.py instead of oslo_log/log.py.  No project can
> throw away openstack/common/log.py at the moment, because it breaks
> things in many ways.
>
>> dims@dims-mac:~/openstack/nova$ find . -name "*.py" -exec grep -H
>> logging {} \; | grep -e "\.setup" -e "\.register_options" -e
>> "\.set_defaults"
>> ./nova/cmd/all.py:logging.setup(CONF, "nova")
>> ./nova/cmd/api.py:logging.setup(CONF, "nova")
>> ./nova/cmd/api_ec2.py:logging.setup(CONF, "nova")
>> ./nova/cmd/api_metadata.py:logging.setup(CONF, "nova")
>> ./nova/cmd/api_os_compute.py:logging.setup(CONF, "nova")
>> ./nova/cmd/cells.py:logging.setup(CONF, 'nova')
>> ./nova/cmd/cert.py:logging.setup(CONF, "nova")
>> ./nova/cmd/compute.py:logging.setup(CONF, 'nova')
>> ./nova/cmd/conductor.py:logging.setup(CONF, "nova")
>> ./nova/cmd/console.py:logging.setup(CONF, "nova")
>> ./nova/cmd/consoleauth.py:logging.setup(CONF, "nova")
>> ./nova/cmd/dhcpbridge.py:logging.setup(CONF, "nova")
>> ./nova/cmd/manage.py:logging.setup(CONF, "nova")
>> ./nova/cmd/network.py:logging.setup(CONF, "nova")
>> ./nova/cmd/novncproxy.py:logging.setup(CONF, "nova")
>> ./nova/cmd/novncproxy.py:logging.setup(CONF, "nova")
>> ./nova/cmd/objectstore.py:logging.setup(config.CONF, "nova")
>> ./nova/cmd/scheduler.py:logging.setup(CONF, "nova")
>> ./nova/cmd/serialproxy.py:logging.setup(CONF, "nova")
>> ./nova/cmd/spicehtml5proxy.py:logging.setup(CONF, "nova")
>> ./nova/cmd/xvpvncproxy.py:logging.setup(config.CONF, "nova")
>> ./nova/openstack/common/report/guru_meditation_report.py:
>> logging.setup(CONF, 'blah')
>> ./nova/test.py:logging.register_options(CONF)
>> ./nova/test.py:logging.setup(CONF, 'nova')
>>
>> If you file a review with what you have, maybe we can help, again, pop
>> onto the #openstack-oslo channel to ask
>
> Okay, will do.  Thanks.
>
> Regards,
>   Qiming
>
>> -- dims
>>
>> On Wed, Jan 21, 2015 at 10:25 AM, Qiming Teng
>>  wrote:
>> > On Wed, Jan 21, 2015 at 08:25:57AM -0500, Davanum Srinivas wrote:
>> >> Qiming,
>> >>
>> >> Nova already uses oslo.config. there's a patch against nova to use
>> >> oslo_log. Doug took the effort to do this so we'd not face issues once
>> >> we release oslo_log, so yes, they have been tested together. Please
>> >> hop onto #openstack-oslo to debug in real time.
>> >>
>> >> [1] https://review.openstack.org/#/c/147635/
>> >>
>> >
>> > Well, just checked nova code, it seems openstack.common.log is still
>> > there. That means there are duplicated code such as the
>> > 'common_cli_opts' which resides in both openstack.common.log and
>> > oslo_log._options.
>> >
>> > I was getting the following error if I'm deleting openstack.common.log
>> > module:
>> >
>> > oslo_config.cfg.NoSuchOptError: no such option: log_config_append
>> >
>> > So ... even with oslo_log there, we still need openstack.common.log?
>> > Pretty confused and a little frustrated after two days of digging.
>> >
>> > Regards,
>> >   Qiming
>> >
>
>
>
> __
> 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

Re: [openstack-dev] [horizon] static files handling, bower/

[Radomir Dopieralski]

On 22/01/15 11:27, Martin Geisler wrote:
> Maybe this is a dumb question, but if there already is a system package
> for, say, Angular, why is the XStatic packge needed then? Could the
> system package for Horizon not just point directly to where the Angular
> package has put its files?

Yes, that is *exactly* the change that we want to make now and that we
are discussing! Drop the whole XStatic thing, and have a file in Horizon
that configures all the paths. Then use Bower for downloading the files
in development environments, and system packages in production.

-- 
Radomir Dopieralski


__
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] 10Gbe performance issue.

[Piotr Korthals]

Thanks, Rick looks like GRO was something we was missing in our setup.

Here are some results form my tests

iperf with GRO disabled on server side : 2,5-3Gbps
iperf with GRO enabled on server side :  3,5-4 Gbps (gro was enabled on
eth0, br-eth0, br-storage)

Additionally i used OVS VLAN splinters option "Enable OVS VLAN splinters
hard trunks workaround" of fuel deployment

iperf with GRO disabled using hw VLAN splinters and MTU 1,5k : ~5 Gbps
iperf with GRO disabled using hw VLAN splinters and MTU 9k: 9-10
Gbps
iperf with GRO enabled using hw VLAN splinters and MTU 1,5k  : 9-10 Gbps

Then i tested iperf between machines of 2 different configurations (with
OVS VLAN splinters, and without it),

default->OVS_VLAN_spliters (GRO disabled) : 2,5 Gbps
default->OVS_VLAN_spliters (GRO enabled) : 5 Gbps

OVS_VLAN_spliters->default (GRO disabled) : 2,5-3 Gbps
OVS_VLAN_spliters->default (GRO enabled) : 5-10 Gbps

This looks like OVS is not performing good enough in this setup for
tagged vlans (our br-storage is running on tagged vlan)

any commands?


Dnia 2015-01-21, śro o godzinie 08:47 -0800, Rick Jones pisze:

> On 01/21/2015 03:20 AM, Skamruk, Piotr wrote:
> > On Wed, 2015-01-21 at 10:53 +, Skamruk, Piotr wrote:
> >> On Tue, 2015-01-20 at 17:41 +0100, Tomasz Napierala wrote:
> >>> [...]
> >>> How this was measured? VM to VM? Compute to compute?
> >> [...]
> >> Probably in ~30 minutes we also will have results on plain centos with
> >> mirantis kernel, and on fuel deployed centos with plain centos kernel
> >> (2.6.32 in both cases, but with different patchset subnumber).
> >
> > OK, our test were done little badly. On plain centos iperf were runned
> > directly on physical interfaces, but under fuel deployed nodes... We
> > ware using br-storage interfaces, which in real are openvs based.
> >
> > So this is not a kernel problem, but this is a single stream over ovs
> > issue.
> >
> > So we will investigate this further...
> >
> 
> Not sure if iperf will emit it, but you might look at the bytes per 
> receive on the receiving end.  Or  you can hang a tcpdump off the 
> receiving interface (the br-storage I presume here) and see if you are 
> getting the likes of GRO - if you are getting GRO you will see "large" 
> TCP segments in the packet trace on the receiving side.  You can do the 
> same with the physical interfaces for comparison.
> 
> 2.5 to 3 Gbit/s "feels" rather like what one would get with 10 GbE in 
> the days before GRO/LRO.
> 
> happy benchmarking,
> 
> rick jones
> http://www.netperf.org/


__
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] [Cinder][3rd CI] Confused about “*real* storage backend”requirement for 3rd CI.

[liuxinguo]

Hi Mike,



I received a email named “All Cinder Drivers Must Have a Third Party CI By 
March 19th 2015” and I feel confused about the “*real* storage backend”.



One of the requirements is: Run Tempest [5][6] volume tests against the 
devstack environment that's hooked up to your *real* storage backend.


· And my confusion is:
· Every time the CI is triggered by a newly came patch, the 3rd CI will 
build a new devstack environment and create a default cinder.conf file whick 
will set the backend to “lvmdriver-1” automatically. And 
the tempest will run against “lvmdriver-1”. So what’s the meaning for a *real* 
storage backend since the cinder.conf will be set to use “lvmdriver-1” 
automatically for every newly came patch ? And how should 
I configure the cinder.conf file to run the tempest for the newly came driver 
patch came from different venders since different venders need different 
configuration for cinder.conf file and need different storage backend. I mean, 
does our CI should run tempest against our *real* storage backend for every 
newly came driver patch in cinder?

Thanks and regards,
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-dev] [neutron][ml2][sqlalchemy] Database table does not exists error

[Ettore zugliani]

I am implementing the precommit part of a mechanism driver (ml2) right now
i'm having problems with sqlalchemy.
I made the class that uses the tables, but when the precommit is called an
error pops up telling that the tables don't exists.
To create the tables should i use a create all on initialize? or is there a
proper way of doing it?
__
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][3rd CI] Confused about “*real* storage backend”requirement for 3rd CI.

[Duncan Thomas]

Please take a look at
https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers to learn how
to configure devstack to use your driver rather than LVM.

On 22 January 2015 at 13:28, liuxinguo  wrote:

>  Hi Mike,
>
>
>
> I received a email named “All Cinder Drivers Must Have a Third Party CI
> By March 19th 2015” and I feel confused about the “*real* storage backend”
> .
>
>
>
> One of the requirements is: Run Tempest [5][6] volume tests against the
> devstack environment that's hooked up to your *real* storage backend.
>
>
>
> · And my confusion is:
>
> · Every time the CI is triggered by a newly came patch, the 3rd
> CI will build a new devstack environment and create a default cinder.conf
> file whick will set the backend to “lvmdriver-1” automatically. And the
> tempest will run against “lvmdriver-1”. So what’s the meaning for a *real*
> storage backend since the cinder.conf will be set to use “lvmdriver-1”
> automatically for every newly came patch ? And how should I configure the
> cinder.conf file to run the tempest for the newly came driver patch came
> from different venders since different venders need different configuration
> for cinder.conf file and need different storage backend. I mean, does our
> CI should run tempest against our *real* storage backend for every newly
> came driver patch in cinder?
>
>
>
> Thanks and regards,
>
> 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
>
>


-- 
Duncan Thomas
__
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] [Horizon] Horizon takes twice amount of time to upload a image into Glance if configured backend is Swift

[Jyoti Ranjan]

I see that https://bugs.launchpad.net/horizon/+bug/1403129 is marked a wish
list. But it affects Glance and hence associated component with it
significantly.


The defect directly influence consumption of Horizon for Glance, especially
concurrency. If user wants to upload 3 images of large size say 40 GB, he
needs to plan for a machine having 120 GB to run horizon. For windows
images, 40 GB is common size. Because, all images need to be copied to /tmp
directory. For a cloud, 3 concurrent request is very low end and number of
concurrent request is likely to be significantly higher.

Considering this aspect, I think that it is a critical defect and streaming
functionality is crucial. Otherwise, usage of Glance in horizon will get
limited. Or, operator will be forced to use cli which does not look good
for Horizon.


Is there any workaround for this?


Regards,

Jyoti Ranjan
__
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][ml2][sqlalchemy] Database table does not exists error

[Jakub Libosvar]

On 01/22/2015 01:00 PM, Ettore zugliani wrote:
> I am implementing the precommit part of a mechanism driver (ml2) right
> now i'm having problems with sqlalchemy. 
> I made the class that uses the tables, but when the precommit is called
> an error pops up telling that the tables don't exists. 
> To create the tables should i use a create all on initialize? or is
> there a proper way of doing it?
Hi Ettore,

you need to make a migration script for your class. More info can be
found here: https://wiki.openstack.org/wiki/Neutron/DatabaseMigration

After autogenerating you can fine-tune it. It's gonna be placed at
neutron/db/migration/alembic_migrations/versions/

Kuba

> 
> 
> __
> 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] [horizon] static files handling, bower/

[Martin Geisler]

Radomir Dopieralski  writes:

> On 22/01/15 11:27, Martin Geisler wrote:
>> Maybe this is a dumb question, but if there already is a system
>> package for, say, Angular, why is the XStatic packge needed then?
>> Could the system package for Horizon not just point directly to where
>> the Angular package has put its files?
>
> Yes, that is *exactly* the change that we want to make now and that we
> are discussing! Drop the whole XStatic thing, and have a file in Horizon
> that configures all the paths. Then use Bower for downloading the files
> in development environments, and system packages in production.

Heh, I see, sorry for not reading carefully enough then!


-- 
Martin Geisler

http://google.com/+MartinGeisler


signature.asc
Description: PGP 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

[openstack-dev] [Fuel] Cluster replaced deployment of provisioning information

[Dmitriy Shulyak]

Hi guys,

I want to discuss the way we are working with deployment configuration that
were redefined for cluster.

In case it was redefined by API - we are using that information instead of
generated.
With one exception, we will generate new repo sources and path to manifest
if we are using update (patching feature in 6.0).

Starting from 6.1 this configuration will be populated by tasks, which is a
part of granular deployment
workflow and replacement of configuration will lead to inability to use
partial graph execution API.
Ofcourse it is possible to hack around and make it work, but imo we need
generic solution.

Next problem - if user will upload replaced information, changes on cluster
attributes, or networks, wont be reflected in deployment anymore and it
constantly leads to problems for deployment engineers that are using fuel.

What if user want to add data, and use generated of networks, attributes,
etc?
- it may be required as a part of manual plugin installation (ha_fencing
requires a lot of configuration to be added into astute.yaml),
- or you need to substitute networking data, e.g add specific parameters
for linux bridges

So given all this, i think that we should not substitute all information,
but only part that is present in
redefined info, and if there is additional parameters they will be simply
merged into generated info
__
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] "All rights reserved" V.S. "Apache license"

[Thierry Carrez]

Joe Gordon wrote:
> On Mon, Jan 19, 2015 at 2:32 PM, ZhiQiang Fan  > wrote:
> I'm thinking that we should remove the "all rights reserved" words
> if we're using Apache license.
> Misleading is not a good thing, especially when it is for legal issue.
> 
> 
> While misleading at first glance, lets just better document the question
> in one place (the wiki?) instead of investing time in changing this
> everywhere in every repository.

+1

https://wiki.openstack.org/wiki/LegalIssuesFAQ sounds like a good place
to document this.


-- 
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] Changes to the core team

[Gary Kotton]

+1

On 1/22/15, 2:18 AM, "Akihiro Motoki"  wrote:

>+1 for Doug
>
>2015-01-20 13:59 GMT+09:00 Aaron Rosen :
>> +1
>>
>> On Fri, Jan 16, 2015 at 12:03 PM, Carl Baldwin 
>>wrote:
>>>
>>> +1
>>>
>>> On Thu, Jan 15, 2015 at 3:31 PM, Kyle Mestery 
>>>wrote:
>>> > The last time we looked at core reviewer stats was in December [1].
>>>In
>>> > looking at the current stats, I'm going to propose some changes to
>>>the
>>> > core
>>> > team. Reviews are the most important part of being a core reviewer,
>>>so
>>> > we
>>> > need to ensure cores are doing reviews. The stats for the 90 day
>>>period
>>> > [2]
>>> > indicate some changes are needed for core reviewers who are no longer
>>> > reviewing on pace with the other core reviewers.
>>> >
>>> > First of all, I'm removing Sumit Naiksatam from neutron-core. Sumit
>>>has
>>> > been
>>> > a core reviewer for a long time, and his past contributions are very
>>> > much
>>> > thanked by the entire OpenStack Neutron team. If Sumit jumps back in
>>> > with
>>> > thoughtful reviews in the future, we can look at getting him back as
>>>a
>>> > Neutron core reviewer. But for now, his stats indicate he's not
>>> > reviewing at
>>> > a level consistent with the rest of the Neutron core reviewers.
>>> >
>>> > As part of the change, I'd like to propose Doug Wiegley as a new
>>>Neutron
>>> > core reviewer. Doug has been actively reviewing code across not only
>>>all
>>> > the
>>> > Neutron projects, but also other projects such as infra. His help and
>>> > work
>>> > in the services split in December were the reason we were so
>>>successful
>>> > in
>>> > making that happen. Doug has also been instrumental in the Neutron
>>>LBaaS
>>> > V2
>>> > rollout, as well as helping to merge code in the other neutron
>>>service
>>> > repositories.
>>> >
>>> > I'd also like to take this time to remind everyone that reviewing
>>>code
>>> > is a
>>> > responsibility, in Neutron the same as other projects. And core
>>> > reviewers
>>> > are especially beholden to this responsibility. I'd also like to
>>>point
>>> > out
>>> > that +1/-1 reviews are very useful, and I encourage everyone to
>>>continue
>>> > reviewing code even if you are not a core reviewer.
>>> >
>>> > Existing neutron cores, please vote +1/-1 for the addition of Doug to
>>> > the
>>> > core team.
>>> >
>>> > Thanks!
>>> > Kyle
>>> >
>>> > [1]
>>> >
>>> > 
>>>http://lists.openstack.org/pipermail/openstack-dev/2014-December/051986.
>>>html
>>> > [2] 
>>>https://urldefense.proofpoint.com/v2/url?u=http-3A__russellbryant.net_op
>>>enstack-2Dstats_neutron-2Dreviewers-2D90.txt&d=AwICAg&c=Sqcl0Ez6M0X8aeM6
>>>7LKIiDJAXVeAw-YihVMNtXt-uEs&r=VlZxHpZBmzzkWT5jqz9JYBk8YTeq9N3-diTlNj4GyN
>>>c&m=wnB98q7iZ33MRx4YfBbDiqXhNykzwMe8k-kvd6hF_ws&s=5UaM_DNnTPV9ccACNgWx0n
>>>vfNRPXZcjxWjQqIlAtgYs&e=
>>> >
>>> >
>>> > 
>>>
>>>__
>>> > 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
>>
>
>
>
>-- 
>Akihiro Motoki 
>
>__
>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] [stable][neutron] backports vs. vendor decomposition

[Sukhdev Kapur]

Hi Ihar,

I have added this on the agenda for next neutron core meeting to discuss.

This email gives an excellent context to the issue at hand. Only one thing
I would like to add is that the deadline for stable/juno is only one week
away - hence, it raises the urgency to call for action.

Thanks

-Sukhdev



On Jan 21, 2015 1:43 PM, "Ihar Hrachyshka"  wrote:
>
> Hi all,
>
> as per:
https://github.com/openstack/neutron-specs/blob/master/specs/kilo/core-vendor-decomposition.rst,
neutron is going to spin off vendor plugins into separate trees outside of
neutron core team control. This raises several questions on how we are
going to handle stable branches that will still include plugin code for
several cycles.
>
> 1) If a plugin is already spinned off and a patch is applicable for
stable branches, there are two cases:
> - patch is not merged into vendor repo;
> - patch is merged into the vendor repo.
>
> My take is:
> - if it's merged in the vendor repo, then we just cherry-pick from there
(it should just work if vendor repo was created with the whole master
history saved).
> - if it's not merged into the repo, I would recommend the author to
propose and merge it there first. If there are any justifiable issues with
proposing it for vendor repo inclusion, then we can consider stable-only
merge.
>
> 2) If a plugin is in the middle of spinning off and a patch is applicable
for stable branch, then there are two options:
> - require plugin to spin off first and then apply the patch to vendor
repo, or
> - allow some types of patches to be merged into master while vendors are
working on spinning off the code.
>
> Examples of those patches are:
> - https://review.openstack.org/#/c/147976/
> - https://review.openstack.org/#/c/148369/
>
> Currently the patches above are blocked for master inclusion assuming the
spin off must take place first, and then bugs should be fixed in vendor
repo. At the same time, we usually avoid backports unless the code is not
in master anymore, but that's not the case here. So the current approach
effectively blocks any bug fixes for plugins in stable branches.
>
> If we would be sure that a plugin is out of the tree till Kilo, then it
would indeed be a waste of time to review the code for neutron/master since
it would be guaranteed to be released as a separate packagr e anyway. In
that case, it would be ok to forbid any patches for the  plugin code till
its spin off from master, and the patch would go directly to stable
branches.
>
> That said, it would potentially introduce regressions if we consider
upgrades from Juno to Kilo + vendor repo. We may say that since the
regression would be on vendor plugin side, and neutron team does not have
anything to do with spinned off plugins, that would be fine for us.
>
> But: we cannot guarantee that a plugin wil leave the neutron tree this
cycle. The spec explicitly gives permission to stay in the tree till
L-cycle, and in that case it will be our responsibility to handle
regressions in Kilo that we may introduce by blocking master fixes.
>
> I think we should try to set procedure that would avoid potential
regressions even if they will come from vendor repos.
>
> We allow fixes that are not applicable for final releases for master if
it's to be backported in stable branches. F.e. see
https://review.openstack.org/#/c/127633/ that was merged into master while
pecan migration should make it useless for Kilo.
>
> It's my belief plugin code bug fixes in stable branches should be treated
the same way.
>
> That said, we should expect vendors to run third party CI for stable
branches if they want to see backports merged in.
>
> ***
> I think the correct approach here is:
> - once a plugin is spinned off, consider it is a 'master' for the code,
and backport to stable branches directly from there;
> - before a plugin is spinned off, assume that it's not going to be
spinned off in Kilo, and hence allow bug fixes in neutron/master (but not
new features);
> - once we get to L release that requires all vendor plugin to go out,
forbid any fixes for the code, assuming they will either spin off or will
be dropped anyway.
> ***
>
> The approach is pretty similar to how oslo project handles new library
spin-offs from oslo-incubator. Yes, there is a difference here: in neutron,
we loose any control on spinned off repos. Though I don't feel it justifies
stable-only fixes while we can easily add value to vendor code by asking
people to consider fixing the bug there first. More importantly, nothing
should justify blocking bug fixing for stable branches.
>
> Thoughts?
>
> /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 (n

Re: [openstack-dev] [neutron] iptables routes are not being injected to router namespace

[Carl Baldwin]

I think this warrants a bug report.  Could you file one with what you
know so far?

Carl

On Wed, Jan 21, 2015 at 2:24 PM, Brian Haley  wrote:
> On 01/21/2015 02:29 PM, Xavier León wrote:
>> On Tue, Jan 20, 2015 at 10:32 PM, Brian Haley  wrote:
>>> On 01/20/2015 09:20 AM, Xavier León wrote:
 Hi all,

 we've been doing some tests with openstack kilo and found
 out a problem: iptables routes are not being injected to the
 router namespace.

 Scenario:
 - a private network NOT connected to the outside world.
 - a router with only one interface connected to the private network.
 - a vm instance connected to the private network as well.
> 
>>> Are you sure the l3-agent is running?  You should have seen wrapped rules 
>>> from
>>> it in most of these tables, for example:
>>>
>>> # Generated by iptables-save v1.4.21 on Tue Jan 20 16:29:19 2015
>>> *filter
>>> :INPUT ACCEPT [34:10882]
>>> :FORWARD ACCEPT [0:0]
>>> :OUTPUT ACCEPT [1:84]
>>> :neutron-filter-top - [0:0]
>>> :neutron-l3-agent-FORWARD - [0:0]
>>> :neutron-l3-agent-INPUT - [0:0]
>>> :neutron-l3-agent-OUTPUT - [0:0]
>>> :neutron-l3-agent-local - [0:0]
>>> [...]
>>
>> Yes, the l3-agent is up and running. I see these rules when executing
>> the same test in juno but not in kilo. FYI, it's a all-in-one devstack
>> deployment.
>>
>>>
>>> I would check the log files for any errors.
>>
>> There are no errors in the logs.
>>
>> After digging a bit more, we have seen that setting the config value
>> of enable_isolated_metadata to True (default: False) in dhcp_agent.ini
>> solves the problem in our scenario.
>> However, this change in configuration was not necessary before (our
>> tests passed in juno for that matter with that setting to False). So
>> we were wondering if there has been a change in how the metadata
>> service is accessed in such scenarios, a new issue because of the l3
>> agent refactoring or any other problem in our setup we haven't
>> narrowed yet.
>
> There have been some changes recently in the code, perhaps:
>
> https://review.openstack.org/#/c/135467/
>
> Or just look at some of the other recent changes in the repository?
>
> -Brian
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[openstack-dev] [Nova][Neutron] Thoughts on the nova<->neutron interface

[Salvatore Orlando]

Hi,

We have attempted several times to start a conversation around the
interface between nova and neutron and its problems, starting with the fact
that it's chatter than two Italians arguing about football (*).
Indeed the first attempt at fixing these problems goes back to the Fall
2012 summit [1]. While we probably don't want to introduce yet another
service to this aim, it might be worth giving another shot at having these
two project communicate in a decent way. I know that other developers are
interested in this and are probably even already actively working on this
topic.

In my opinion it might not be such a bad idea to start this conversation at
the upcoming nova meetup, if there will be enough interest from the
participants. I have started the etherpad [2] for discussing issues of the
current implementation, goals, architecture, and design.

As for timelines, it is very likely already too late for shipping this in
Kilo, but we're probably still on time for completing this work by the "L"
release.

Salvatore

(*) being Italian I am entitled to make jokes about Italians without
offending anyone, I hope.

[1] https://etherpad.openstack.org/p/grizzly-newtonian
[2] https://etherpad.openstack.org/p/nova-neutron-interface-rework
__
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][vpnaas] Can we require kernel 3.8+ for use with StrongSwan IPSec VPN for Kilo?

[Kyle Mestery]

On Wed, Jan 21, 2015 at 10:27 AM, Ihar Hrachyshka 
wrote:

>  On 01/20/2015 05:40 PM, Paul Michali wrote:
>
> Review https://review.openstack.org/#/c/146508/ is adding support for
> StrongSwan VPN, which needs mount bind to be able to specify different
> paths for config files.
>
>  The code, which used some older patch, does a test for /proc/1/ns/net,
> instead of /proc/1/ns/mnt, because it stated that the latter is only
> supported in kernel 3.8+. That was a while ago, and I'm wondering if the
> condition is still true.  If we know that for Kilo and on, we'll be dealing
> with 3.8+ kernels, we could use the more accurate test.
>
>  Can we require 3.8+ kernel for this?
>
>
> I think we can but it's better to check with distributions. Red Hat wise,
> we ship a kernel that is newer than 3.8.
>
>  If so, how and where do we ensure that is true?
>
>
> Ideally, you would implement a sanity check for the feature you need from
> the kernel. Though it opens a question of whether we want to ship multiple
> sanity check tools for each of repos (neutron + 3 *aas repos).
>
> If we can consolidate that and use a single tool from the master neutron
repository, that would be my vote.

>
>  Also, if you can kindly review the code here:
> https://review.openstack.org/#/c/146508/5/neutron_vpnaas/services/vpn/common/netns_wrapper.py,
> I'd really appreciate it, as I'm not versed in the Linux proc files at all.
>
>  Thanks!
>
>
>   PCM (Paul Michali)
>
>  IRC pc_m (irc.freenode.com)
> Twitter... @pmichali
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://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] [oslo] [nova] [all] potential enginefacade adjustment - can everyone live with this?

[Mike Bayer]

Hey all -

Concerning the enginefacade system, approved blueprint:

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

which will replace the use of oslo_db.sqlalchemy.EngineFacade ultimately across 
all projects that use it (which is, all of them that use a database).

We are struggling to find a solution for the issue of application-defined 
contexts that might do things that the facade needs to know about, namely 1. 
that the object might be copied using deepcopy() or 2. that the object might be 
sent into a new set of worker threads, where its attributes are accessed 
concurrently.

While the above blueprint and the implementations so far have assumed that we 
need to receive this context object and use simple assignment, e.g. 
“context.session = the_session” in order to provide its attributes, in order to 
accommodate 1. and 2. I’ve had to add a significant amount of complexity in 
order to accommodate those needs (see patch set 28 at 
https://review.openstack.org/#/c/138215/).   It all works fine, but 
predictably, people are not comfortable with the extra few yards into the weeds 
it has to go to make all that happen.  In particular, in order to accommodate a 
RequestContext that is running in a different thread, it has to be copied 
first, because we have no ability to make the “.session” or “.connection” 
attributes dynamic without access to the RequestContext class up front.

So, what’s the alternative.   It’s that enginefacade is given just a tiny bit 
of visibility into the *class* used to create your context, such as in Nova, 
the nova.context.RequestContext class, so that we can place dynamic descriptors 
on it before instantiation (or I suppose we could monkeypatch the class on the 
first RequestContext object we see, but that seems even less desirable).   The 
blueprint went out of its way to avoid this.   But with contexts being copied 
and thrown into threads, I didn’t consider these use cases and I’d have 
probably needed to do the BP differently.

So what does the change look like?If you’re not Nova, imagine you’re 
cinder.context.RequestContext, heat.common.context.RequestContext, 
glance.context.RequestContext, etc.We throw a class decorator onto the 
class so that enginefacade can add some descriptors:

diff --git a/nova/context.py b/nova/context.py
index e78636c..205f926 100644
--- a/nova/context.py
+++ b/nova/context.py
@@ -22,6 +22,7 @@ import copy
from keystoneclient import auth
from keystoneclient import service_catalog
from oslo.utils import timeutils
+from oslo_db.sqlalchemy import enginefacade
import six

from nova import exception
@@ -61,6 +62,7 @@ class _ContextAuthPlugin(auth.BaseAuthPlugin):
region_name=region_name)


+@enginefacade.transaction_context_provider
class RequestContext(object):
"""Security context and request information.


the implementation of this one can be seen here: 
https://review.openstack.org/#/c/149289/.   In particular we can see all the 
lines of code removed from oslo’s approach, and in fact there’s a lot more 
nasties I can take out once I get to work on that some more.

so what’s controversial about this?   It’s that there’s an “oslo_db.sqlalchemy” 
import up front in the XYZ/context.py module of every participating project, 
outside of where anything else “sqlalchemy” happens.  

There’s potentially other ways to do this - subclasses of RequestContext that 
are generated by abstract factories, for one.   As I left my Java gigs years 
ago I’m hesitant to go there either :).   Perhaps projects can opt to run their 
RequestContext class through this decorator conditionally, wherever it is that 
it gets decided they are about to use their db/sqlalchemy/api.py module.

So can I please get +1 / -1 from the list on, “oslo_db.sqlalchemy wants an 
up-front patch on everyone’s RequestContext class”  ?  thanks!

- mike








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

Re: [openstack-dev] [Fuel] [Puppet] Manifests for granular deploy steps and testing results against the host OS

[Vladimir Kuklin]

Moreover I would suggest to use server spec as beaker is already
duplicating part of our infrastructure automatization.

On Thu, Jan 22, 2015 at 6:44 PM, Vladimir Kuklin 
wrote:

> Guys, I suggest that we create a blueprint how to integrate beaker with
> our existing infrastructure to increase test coverage. My optimistic
> estimate is that we can see its implementation in 7.0.
>
> On Thu, Jan 22, 2015 at 2:07 AM, Andrew Woodward  wrote:
>
>> My understanding is serverspec is not going to work well / going to be
>> supported. I think it was discusssed on IRC (as i cant find it in my
>> email). Stackforge/puppet-ceph moved from ?(something)spec to beaker,
>> as its more functional and actively developed.
>>
>> On Mon, Jan 12, 2015 at 6:10 AM, Sergii Golovatiuk
>>  wrote:
>> > Hi,
>> >
>> > Puppet OpenStack community uses Beaker for acceptance testing. I would
>> > consider it as option [2]
>> >
>> > [2] https://github.com/puppetlabs/beaker
>> >
>> > --
>> > Best regards,
>> > Sergii Golovatiuk,
>> > Skype #golserge
>> > IRC #holser
>> >
>> > On Mon, Jan 12, 2015 at 2:53 PM, Bogdan Dobrelya <
>> bdobre...@mirantis.com>
>> > wrote:
>> >>
>> >> Hello.
>> >>
>> >> We are working on the modularization of Openstack deployment by puppet
>> >> manifests in Fuel library [0].
>> >>
>> >> Each deploy step should be post-verified with some testing framework as
>> >> well.
>> >>
>> >> I believe the framework should:
>> >> * be shipped as a part of Fuel library for puppet manifests instead of
>> >> orchestration or Nailgun backend logic;
>> >> * allow the deployer to verify results right in-place, at the node
>> being
>> >> deployed, for example, with a rake tool;
>> >> * be compatible / easy to integrate with the existing orchestration in
>> >> Fuel and Mistral as an option?
>> >>
>> >> It looks like test resources provided by Serverspec [1] are a good
>> >> option, what do you think?
>> >>
>> >> What plans have Fuel Nailgun team for testing the results of deploy
>> >> steps aka tasks? The spec for blueprint gives no a clear answer.
>> >>
>> >> [0]
>> >>
>> https://blueprints.launchpad.net/fuel/+spec/fuel-library-modularization
>> >> [1] http://serverspec.org/resource_types.html
>> >>
>> >> --
>> >> Best regards,
>> >> Bogdan Dobrelya,
>> >> Skype #bogdando_at_yahoo.com
>> >> Irc #bogdando
>> >>
>> >>
>> __
>> >> 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
>> >
>>
>>
>>
>> --
>> Andrew
>> Mirantis
>> 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
>>
>
>
>
> --
> Yours Faithfully,
> Vladimir Kuklin,
> Fuel Library Tech Lead,
> Mirantis, Inc.
> +7 (495) 640-49-04
> +7 (926) 702-39-68
> Skype kuklinvv
> 45bk3, Vorontsovskaya Str.
> Moscow, Russia,
> www.mirantis.com 
> www.mirantis.ru
> vkuk...@mirantis.com
>



-- 
Yours Faithfully,
Vladimir Kuklin,
Fuel Library Tech Lead,
Mirantis, Inc.
+7 (495) 640-49-04
+7 (926) 702-39-68
Skype kuklinvv
45bk3, Vorontsovskaya Str.
Moscow, Russia,
www.mirantis.com 
www.mirantis.ru
vkuk...@mirantis.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] [Fuel] [Puppet] Manifests for granular deploy steps and testing results against the host OS

[Vladimir Kuklin]

Guys, I suggest that we create a blueprint how to integrate beaker with our
existing infrastructure to increase test coverage. My optimistic estimate
is that we can see its implementation in 7.0.

On Thu, Jan 22, 2015 at 2:07 AM, Andrew Woodward  wrote:

> My understanding is serverspec is not going to work well / going to be
> supported. I think it was discusssed on IRC (as i cant find it in my
> email). Stackforge/puppet-ceph moved from ?(something)spec to beaker,
> as its more functional and actively developed.
>
> On Mon, Jan 12, 2015 at 6:10 AM, Sergii Golovatiuk
>  wrote:
> > Hi,
> >
> > Puppet OpenStack community uses Beaker for acceptance testing. I would
> > consider it as option [2]
> >
> > [2] https://github.com/puppetlabs/beaker
> >
> > --
> > Best regards,
> > Sergii Golovatiuk,
> > Skype #golserge
> > IRC #holser
> >
> > On Mon, Jan 12, 2015 at 2:53 PM, Bogdan Dobrelya  >
> > wrote:
> >>
> >> Hello.
> >>
> >> We are working on the modularization of Openstack deployment by puppet
> >> manifests in Fuel library [0].
> >>
> >> Each deploy step should be post-verified with some testing framework as
> >> well.
> >>
> >> I believe the framework should:
> >> * be shipped as a part of Fuel library for puppet manifests instead of
> >> orchestration or Nailgun backend logic;
> >> * allow the deployer to verify results right in-place, at the node being
> >> deployed, for example, with a rake tool;
> >> * be compatible / easy to integrate with the existing orchestration in
> >> Fuel and Mistral as an option?
> >>
> >> It looks like test resources provided by Serverspec [1] are a good
> >> option, what do you think?
> >>
> >> What plans have Fuel Nailgun team for testing the results of deploy
> >> steps aka tasks? The spec for blueprint gives no a clear answer.
> >>
> >> [0]
> >> https://blueprints.launchpad.net/fuel/+spec/fuel-library-modularization
> >> [1] http://serverspec.org/resource_types.html
> >>
> >> --
> >> Best regards,
> >> Bogdan Dobrelya,
> >> Skype #bogdando_at_yahoo.com
> >> Irc #bogdando
> >>
> >>
> __
> >> 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
> >
>
>
>
> --
> Andrew
> Mirantis
> 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
>



-- 
Yours Faithfully,
Vladimir Kuklin,
Fuel Library Tech Lead,
Mirantis, Inc.
+7 (495) 640-49-04
+7 (926) 702-39-68
Skype kuklinvv
45bk3, Vorontsovskaya Str.
Moscow, Russia,
www.mirantis.com 
www.mirantis.ru
vkuk...@mirantis.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] [stable][neutron] backports vs. vendor decomposition

[Ihar Hrachyshka]

There is a proposal from Armando to clear this up:
https://review.openstack.org/#/c/148745/

On 01/22/2015 03:53 PM, Sukhdev Kapur wrote:


Hi Ihar,

I have added this on the agenda for next neutron core meeting to discuss.

This email gives an excellent context to the issue at hand. Only one 
thing I would like to add is that the deadline for stable/juno is only 
one week away - hence, it raises the urgency to call for action.


Thanks

-Sukhdev



On Jan 21, 2015 1:43 PM, "Ihar Hrachyshka" > wrote:

>
> Hi all,
>
> as per: 
https://github.com/openstack/neutron-specs/blob/master/specs/kilo/core-vendor-decomposition.rst, 
neutron is going to spin off vendor plugins into separate trees 
outside of neutron core team control. This raises several questions on 
how we are going to handle stable branches that will still include 
plugin code for several cycles.

>
> 1) If a plugin is already spinned off and a patch is applicable for 
stable branches, there are two cases:

> - patch is not merged into vendor repo;
> - patch is merged into the vendor repo.
>
> My take is:
> - if it's merged in the vendor repo, then we just cherry-pick from 
there (it should just work if vendor repo was created with the whole 
master history saved).
> - if it's not merged into the repo, I would recommend the author to 
propose and merge it there first. If there are any justifiable issues 
with proposing it for vendor repo inclusion, then we can consider 
stable-only merge.

>
> 2) If a plugin is in the middle of spinning off and a patch is 
applicable for stable branch, then there are two options:
> - require plugin to spin off first and then apply the patch to 
vendor repo, or
> - allow some types of patches to be merged into master while vendors 
are working on spinning off the code.

>
> Examples of those patches are:
> - https://review.openstack.org/#/c/147976/
> - https://review.openstack.org/#/c/148369/
>
> Currently the patches above are blocked for master inclusion 
assuming the spin off must take place first, and then bugs should be 
fixed in vendor repo. At the same time, we usually avoid backports 
unless the code is not in master anymore, but that's not the case 
here. So the current approach effectively blocks any bug fixes for 
plugins in stable branches.

>
> If we would be sure that a plugin is out of the tree till Kilo, then 
it would indeed be a waste of time to review the code for 
neutron/master since it would be guaranteed to be released as a 
separate packagr e anyway. In that case, it would be ok to forbid any 
patches for the  plugin code till its spin off from master, and the 
patch would go directly to stable branches.

>
> That said, it would potentially introduce regressions if we consider 
upgrades from Juno to Kilo + vendor repo. We may say that since the 
regression would be on vendor plugin side, and neutron team does not 
have anything to do with spinned off plugins, that would be fine for us.

>
> But: we cannot guarantee that a plugin wil leave the neutron tree 
this cycle. The spec explicitly gives permission to stay in the tree 
till L-cycle, and in that case it will be our responsibility to handle 
regressions in Kilo that we may introduce by blocking master fixes.

>
> I think we should try to set procedure that would avoid potential 
regressions even if they will come from vendor repos.

>
> We allow fixes that are not applicable for final releases for master 
if it's to be backported in stable branches. F.e. see 
https://review.openstack.org/#/c/127633/ that was merged into master 
while pecan migration should make it useless for Kilo.

>
> It's my belief plugin code bug fixes in stable branches should be 
treated the same way.

>
> That said, we should expect vendors to run third party CI for stable 
branches if they want to see backports merged in.

>
> ***
> I think the correct approach here is:
> - once a plugin is spinned off, consider it is a 'master' for the 
code, and backport to stable branches directly from there;
> - before a plugin is spinned off, assume that it's not going to be 
spinned off in Kilo, and hence allow bug fixes in neutron/master (but 
not new features);
> - once we get to L release that requires all vendor plugin to go 
out, forbid any fixes for the code, assuming they will either spin off 
or will be dropped anyway.

> ***
>
> The approach is pretty similar to how oslo project handles new 
library spin-offs from oslo-incubator. Yes, there is a difference 
here: in neutron, we loose any control on spinned off repos. Though I 
don't feel it justifies stable-only fixes while we can easily add 
value to vendor code by asking people to consider fixing the bug there 
first. More importantly, nothing should justify blocking bug fixing 
for stable branches.

>
> Thoughts?
>
> /Ihar
>
> 
__

> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 
open

Re: [openstack-dev] [Nova][Neutron] Thoughts on the nova<->neutron interface

[Sean Dague]

On 01/22/2015 10:28 AM, Salvatore Orlando wrote:
> Hi,
> 
> We have attempted several times to start a conversation around the
> interface between nova and neutron and its problems, starting with the
> fact that it's chatter than two Italians arguing about football (*).
> Indeed the first attempt at fixing these problems goes back to the Fall
> 2012 summit [1]. While we probably don't want to introduce yet another
> service to this aim, it might be worth giving another shot at having
> these two project communicate in a decent way. I know that other
> developers are interested in this and are probably even already actively
> working on this topic.
> 
> In my opinion it might not be such a bad idea to start this conversation
> at the upcoming nova meetup, if there will be enough interest from the
> participants. I have started the etherpad [2] for discussing issues of
> the current implementation, goals, architecture, and design.
> 
> As for timelines, it is very likely already too late for shipping this
> in Kilo, but we're probably still on time for completing this work by
> the "L" release.
> 
> Salvatore
> 
> (*) being Italian I am entitled to make jokes about Italians without
> offending anyone, I hope.
> 
> [1] https://etherpad.openstack.org/p/grizzly-newtonian
> [2] https://etherpad.openstack.org/p/nova-neutron-interface-rework

Interesting stuff. I conceptually like the idea of nova-compute doing
the leg work for sub resources (like the network) as it feels like error
handling is simpler given it's closeness to the actual VMs that are
running.

I also like the idea of considering the RPC interface. What kind of
stability / versioning exists on the Neutron RPC interface?

-Sean

-- 
Sean Dague
http://dague.net



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] [horizon] static files handling, bower/

[Matthew Farina]

Radomir and Matthias,

Has anyone done an inventory of xstatic packages that are available as
system packages? I ask because I started asking these questions after doing
a cursory inventory and finding few xstatic packages as system packages. It
appeared to me that the common case was the one Matthias noted where the
xstatic package bundles the js libs. That we're actually getting them from
pypi or a mirror. Can someone show me there really are system packages to
replace the xstatic packages?


On Thu, Jan 22, 2015 at 5:15 AM, Matthias Runge  wrote:

> On 22/01/15 09:48, Radomir Dopieralski wrote:
>
> > All of the XStatic packages had to be packaged for the respective
> > distributions in order to package Horizon. That was a lot of work, but
> > it has been done my the packagers of the distributions. As far as I
> > understand, most of those XStatic packages are just dummies, pointing to
> > the actual system-wide JavaScript packages -- XStatic has such a
> > capability. So while we are indeed maintaining some of the XStatic
> > packages for our own convenience, the packages that contain actual code
> > in the distributions are maintained by those distributions' packagers.
> >
> Yupp,
>
> poniting to system packages is something, which makes the XStatic
> approach way more acceptable.
> But, if you don't have them (yet), xstatic packages will bundle js libs
> for you.
>
> Matthias
>
> __
> 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] iptables routes are not being injected to router namespace

[Brian Haley]

On 01/22/2015 10:17 AM, Carl Baldwin wrote:
> I think this warrants a bug report.  Could you file one with what you
> know so far?

Carl,

Seems as though a recent change introduced a bug.  This is on a devstack
I just created today, at l3/vpn-agent startup:

2015-01-22 11:55:07.961 4203 TRACE neutron.agent.l3.agent Traceback (most 
recent call last):
2015-01-22 11:55:07.961 4203 TRACE neutron.agent.l3.agent   File 
"/opt/stack/neutron/neutron/common/utils.py", line 342, in call
2015-01-22 11:55:07.961 4203 TRACE neutron.agent.l3.agent return 
func(*args, **kwargs)
2015-01-22 11:55:07.961 4203 TRACE neutron.agent.l3.agent   File 
"/opt/stack/neutron/neutron/agent/l3/agent.py", line 584, in process_router
2015-01-22 11:55:07.961 4203 TRACE neutron.agent.l3.agent 
self._process_external(ri)
2015-01-22 11:55:07.961 4203 TRACE neutron.agent.l3.agent   File 
"/opt/stack/neutron/neutron/agent/l3/agent.py", line 576, in _process_external
2015-01-22 11:55:07.961 4203 TRACE neutron.agent.l3.agent 
self._update_fip_statuses(ri, existing_floating_ips, fip_statuses)
2015-01-22 11:55:07.961 4203 TRACE neutron.agent.l3.agent UnboundLocalError: 
local variable 'existing_floating_ips' referenced before assignment
2015-01-22 11:55:07.961 4203 TRACE neutron.agent.l3.agent
Traceback (most recent call last):
  File "/usr/local/lib/python2.7/dist-packages/eventlet/greenpool.py", line 82, 
in _spawn_n_impl
func(*args, **kwargs)
  File "/opt/stack/neutron/neutron/agent/l3/agent.py", line 1093, in 
_process_router_update
self._process_router_if_compatible(router)
  File "/opt/stack/neutron/neutron/agent/l3/agent.py", line 1047, in 
_process_router_if_compatible
self._process_added_router(router)
  File "/opt/stack/neutron/neutron/agent/l3/agent.py", line 1056, in 
_process_added_router
self.process_router(ri)
  File "/opt/stack/neutron/neutron/common/utils.py", line 345, in call
self.logger(e)
  File "/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 
82, in __exit__
six.reraise(self.type_, self.value, self.tb)
  File "/opt/stack/neutron/neutron/common/utils.py", line 342, in call
return func(*args, **kwargs)
  File "/opt/stack/neutron/neutron/agent/l3/agent.py", line 584, in 
process_router
self._process_external(ri)
  File "/opt/stack/neutron/neutron/agent/l3/agent.py", line 576, in 
_process_external
self._update_fip_statuses(ri, existing_floating_ips, fip_statuses)
UnboundLocalError: local variable 'existing_floating_ips' referenced before 
assignment

Since that's happening while we're holding the iptables lock I'm assuming
no rules are being applied.

I'm looking into it now, will file a bug if there isn't already one.

-Brian


> On Wed, Jan 21, 2015 at 2:24 PM, Brian Haley  wrote:
>> On 01/21/2015 02:29 PM, Xavier León wrote:
>>> On Tue, Jan 20, 2015 at 10:32 PM, Brian Haley  wrote:
 On 01/20/2015 09:20 AM, Xavier León wrote:
> Hi all,
>
> we've been doing some tests with openstack kilo and found
> out a problem: iptables routes are not being injected to the
> router namespace.
>
> Scenario:
> - a private network NOT connected to the outside world.
> - a router with only one interface connected to the private network.
> - a vm instance connected to the private network as well.
>> 
 Are you sure the l3-agent is running?  You should have seen wrapped rules 
 from
 it in most of these tables, for example:

 # Generated by iptables-save v1.4.21 on Tue Jan 20 16:29:19 2015
 *filter
 :INPUT ACCEPT [34:10882]
 :FORWARD ACCEPT [0:0]
 :OUTPUT ACCEPT [1:84]
 :neutron-filter-top - [0:0]
 :neutron-l3-agent-FORWARD - [0:0]
 :neutron-l3-agent-INPUT - [0:0]
 :neutron-l3-agent-OUTPUT - [0:0]
 :neutron-l3-agent-local - [0:0]
 [...]
>>>
>>> Yes, the l3-agent is up and running. I see these rules when executing
>>> the same test in juno but not in kilo. FYI, it's a all-in-one devstack
>>> deployment.
>>>

 I would check the log files for any errors.
>>>
>>> There are no errors in the logs.
>>>
>>> After digging a bit more, we have seen that setting the config value
>>> of enable_isolated_metadata to True (default: False) in dhcp_agent.ini
>>> solves the problem in our scenario.
>>> However, this change in configuration was not necessary before (our
>>> tests passed in juno for that matter with that setting to False). So
>>> we were wondering if there has been a change in how the metadata
>>> service is accessed in such scenarios, a new issue because of the l3
>>> agent refactoring or any other problem in our setup we haven't
>>> narrowed yet.
>>
>> There have been some changes recently in the code, perhaps:
>>
>> https://review.openstack.org/#/c/135467/
>>
>> Or just look at some of the other recent changes in the repository?
>>
>> -Brian


__
OpenStack Development Mailing List (not for usage qu

Re: [openstack-dev] [neutron] Changes to the core team

[Kyle Mestery]

On Thu, Jan 15, 2015 at 4:31 PM, Kyle Mestery  wrote:

> The last time we looked at core reviewer stats was in December [1]. In
> looking at the current stats, I'm going to propose some changes to the core
> team. Reviews are the most important part of being a core reviewer, so we
> need to ensure cores are doing reviews. The stats for the 90 day period [2]
> indicate some changes are needed for core reviewers who are no longer
> reviewing on pace with the other core reviewers.
>
> First of all, I'm removing Sumit Naiksatam from neutron-core. Sumit has
> been a core reviewer for a long time, and his past contributions are very
> much thanked by the entire OpenStack Neutron team. If Sumit jumps back in
> with thoughtful reviews in the future, we can look at getting him back as a
> Neutron core reviewer. But for now, his stats indicate he's not reviewing
> at a level consistent with the rest of the Neutron core reviewers.
>
> As part of the change, I'd like to propose Doug Wiegley as a new Neutron
> core reviewer. Doug has been actively reviewing code across not only all
> the Neutron projects, but also other projects such as infra. His help and
> work in the services split in December were the reason we were so
> successful in making that happen. Doug has also been instrumental in the
> Neutron LBaaS V2 rollout, as well as helping to merge code in the other
> neutron service repositories.
>
> I'd also like to take this time to remind everyone that reviewing code is
> a responsibility, in Neutron the same as other projects. And core reviewers
> are especially beholden to this responsibility. I'd also like to point out
> that +1/-1 reviews are very useful, and I encourage everyone to continue
> reviewing code even if you are not a core reviewer.
>
> Existing neutron cores, please vote +1/-1 for the addition of Doug to the
> core team.
>
> It's been a week, and Doug has received plenty of support. Welcome to the
Neutron Core Review team Doug!

Kyle


> Thanks!
> Kyle
>
> [1]
> http://lists.openstack.org/pipermail/openstack-dev/2014-December/051986.html
> [2] http://russellbryant.net/openstack-stats/neutron-reviewers-90.txt
>
__
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] Changes to Cinder Core

[Walter A. Boring IV]

sorry I didn't see this earlier.

I'd welcome Ivan to the team!

+1


Walt

On Wed, Jan 21, 2015 at 10:14 AM, Mike Perez  wrote:

It gives me great pleasure to nominate Ivan Kolodyazhny (e0ne) for
Cinder core. Ivan's reviews have been valuable in decisions, and his
contributions to Cinder core code have been greatly appreciated.

Reviews:
https://review.openstack.org/#/q/reviewer:%22Ivan+Kolodyazhny+%253Ce0ne%2540e0ne.info%253E%22,n,z

Contributions:
https://review.openstack.org/#/q/owner:%22Ivan+Kolodyazhny%22+project:+openstack/cinder,n,z

30/90 day review stats:
http://stackalytics.com/report/contribution/cinder-group/30
http://stackalytics.com/report/contribution/cinder-group/90

As new contributors step up to help in the project, some move onto
other things. I would like to recognize Josh Durgin for his early
contributions to Nova volume, early involvement with Cinder, and now
unfortunately departure from the Cinder core team.

Cinder core, please reply with a +1 for approval. This will be left
open until Jan 26th. Assuming there are no objections, this will go
forward after voting is closed.

And apologies for missing the [cinder] subject prefix.

--
Mike Perez

__
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] [horizon] static files handling, bower/

[Matthew Farina]

I would like to add one more nuance to this discussion that I don't
remember seeing.

JavaScript libraries run in web browser in their JavaScript engines (like
v8) rather than on the server. A version of a JS library may be fine on a
system, without any security issues, but contain browser issues. The
version used matters more to the application and the web browsers consuming
the application than to the system it's on.

Some of the libraries exist as packages. For example, there are some debian
packages. These have older versions of libraries than those that will work
in Horizon. The libraries need to integrate for horizon and the browsers.
So, supporting varying versions of a js library, their interactions
together, and creating a usable interface will be a real problem. For
example the debian packages of old or varying versions will a problem for
those of us attempting to craft a UI. What's there isn't practically usable
today. Some things are missing.

Does that help add clarity?

On Thu, Jan 22, 2015 at 11:53 AM, Matthew Farina 
wrote:

> Radomir and Matthias,
>
> Has anyone done an inventory of xstatic packages that are available as
> system packages? I ask because I started asking these questions after doing
> a cursory inventory and finding few xstatic packages as system packages. It
> appeared to me that the common case was the one Matthias noted where the
> xstatic package bundles the js libs. That we're actually getting them from
> pypi or a mirror. Can someone show me there really are system packages to
> replace the xstatic packages?
>
>
> On Thu, Jan 22, 2015 at 5:15 AM, Matthias Runge  wrote:
>
>> On 22/01/15 09:48, Radomir Dopieralski wrote:
>>
>> > All of the XStatic packages had to be packaged for the respective
>> > distributions in order to package Horizon. That was a lot of work, but
>> > it has been done my the packagers of the distributions. As far as I
>> > understand, most of those XStatic packages are just dummies, pointing to
>> > the actual system-wide JavaScript packages -- XStatic has such a
>> > capability. So while we are indeed maintaining some of the XStatic
>> > packages for our own convenience, the packages that contain actual code
>> > in the distributions are maintained by those distributions' packagers.
>> >
>> Yupp,
>>
>> poniting to system packages is something, which makes the XStatic
>> approach way more acceptable.
>> But, if you don't have them (yet), xstatic packages will bundle js libs
>> for you.
>>
>> Matthias
>>
>> __
>> 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] [Heat] Where to keep data about stack breakpoints?

[Tomas Sedovic]

On 01/14/2015 01:47 AM, Ton Ngo wrote:

Hi Tomas,
  I think your patch is a great start so we can prototype quickly;  I am
trying it out right now.  We can break up the implementation into several
parts that can be updated more or less independently based on the feedback.
Ton,








Hey everyone,

I've sent another revision, this time something that I think can 
actually be mergeable (sans the missing tests, I'll add some tomorrow).


There are two patches now:

https://review.openstack.org/#/c/146123/ (heat-engine)

https://review.openstack.org/#/c/149319/ (python-heatclient)

They're using the environment to determine which resources should have 
breakpoints (python-hetaclient converts the convenient CLI invocation to 
appropriate environment entries).


Both stack-create and stack-update support breakpoints and you can run 
stack-update on a stack that's waiting on a breakpoint and things should 
just work.


Breakpoints on resources in nested stacks are supported. The spec 
mentioned prefixing such resources with the nested template name but 
that's not sufficient to resolve all the conflits so we check the 
absolute path up the nested stacks instead. Both heatclient and the 
environment offer a bit of syntactic sugar to make this less tedious.


You can clear active breakpoints by calling `heat clear-breakpoint 
mystack resource_1 resource_2 ...`.



Feedback is much appreciated!

Tomas

__
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][ml2][sqlalchemy] Database table does not exists error

[Ettore zugliani]

Thank you! I managed to do it following your tip and the guide you sent.

2015-01-22 10:54 GMT-02:00 Jakub Libosvar :

> On 01/22/2015 01:00 PM, Ettore zugliani wrote:
> > I am implementing the precommit part of a mechanism driver (ml2) right
> > now i'm having problems with sqlalchemy.
> > I made the class that uses the tables, but when the precommit is called
> > an error pops up telling that the tables don't exists.
> > To create the tables should i use a create all on initialize? or is
> > there a proper way of doing it?
> Hi Ettore,
>
> you need to make a migration script for your class. More info can be
> found here: https://wiki.openstack.org/wiki/Neutron/DatabaseMigration
>
> After autogenerating you can fine-tune it. It's gonna be placed at
> neutron/db/migration/alembic_migrations/versions/
>
> Kuba
>
> >
> >
> >
> __
> > 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] [Nova][Neutron] Thoughts on the nova<->neutron interface

[Akilesh K]

I had always wanted this to happen. It is really frustrating when nova
throws wierd python exceptions and difficult to comprehend log messages.

If the developers do agree to clean up the interface I would suggest they
make use of some well knows protocol (mpls/rsvp) to do this, instead of
relying on custom south-bound api calls.

regards,
Ageeleshwar K

On Thu, Jan 22, 2015 at 9:39 PM, Sean Dague  wrote:

> On 01/22/2015 10:28 AM, Salvatore Orlando wrote:
> > Hi,
> >
> > We have attempted several times to start a conversation around the
> > interface between nova and neutron and its problems, starting with the
> > fact that it's chatter than two Italians arguing about football (*).
> > Indeed the first attempt at fixing these problems goes back to the Fall
> > 2012 summit [1]. While we probably don't want to introduce yet another
> > service to this aim, it might be worth giving another shot at having
> > these two project communicate in a decent way. I know that other
> > developers are interested in this and are probably even already actively
> > working on this topic.
> >
> > In my opinion it might not be such a bad idea to start this conversation
> > at the upcoming nova meetup, if there will be enough interest from the
> > participants. I have started the etherpad [2] for discussing issues of
> > the current implementation, goals, architecture, and design.
> >
> > As for timelines, it is very likely already too late for shipping this
> > in Kilo, but we're probably still on time for completing this work by
> > the "L" release.
> >
> > Salvatore
> >
> > (*) being Italian I am entitled to make jokes about Italians without
> > offending anyone, I hope.
> >
> > [1] https://etherpad.openstack.org/p/grizzly-newtonian
> > [2] https://etherpad.openstack.org/p/nova-neutron-interface-rework
>
> Interesting stuff. I conceptually like the idea of nova-compute doing
> the leg work for sub resources (like the network) as it feels like error
> handling is simpler given it's closeness to the actual VMs that are
> running.
>
> I also like the idea of considering the RPC interface. What kind of
> stability / versioning exists on the Neutron RPC interface?
>
> -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
>
>
__
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] Cluster replaced deployment of provisioning information

[Evgeniy L]

Hi Dmitry,

The problem with merging is usually it's not clear how system performs
merging.
For example you have the next hash {'list': [{'k': 1}, {'k': 2}, {'k':
3}]}, and I want
{'list': [{'k': 4}]} to be merged, what system should do? Replace the list
or add {'k': 4}?
Both cases should be covered.

Most of the users don't remember all of the keys, usually user gets the
defaults, and
changes some values in place, in this case we should ask user to remove the
rest
of the fields.

The only solution which I see is to separate the data from the graph, not
to send
this information to user.

Thanks,

On Thu, Jan 22, 2015 at 5:18 PM, Dmitriy Shulyak 
wrote:

> Hi guys,
>
> I want to discuss the way we are working with deployment configuration
> that were redefined for cluster.
>
> In case it was redefined by API - we are using that information instead of
> generated.
> With one exception, we will generate new repo sources and path to manifest
> if we are using update (patching feature in 6.0).
>
> Starting from 6.1 this configuration will be populated by tasks, which is
> a part of granular deployment
> workflow and replacement of configuration will lead to inability to use
> partial graph execution API.
> Ofcourse it is possible to hack around and make it work, but imo we need
> generic solution.
>
> Next problem - if user will upload replaced information, changes on
> cluster attributes, or networks, wont be reflected in deployment anymore
> and it constantly leads to problems for deployment engineers that are using
> fuel.
>
> What if user want to add data, and use generated of networks, attributes,
> etc?
> - it may be required as a part of manual plugin installation (ha_fencing
> requires a lot of configuration to be added into astute.yaml),
> - or you need to substitute networking data, e.g add specific parameters
> for linux bridges
>
> So given all this, i think that we should not substitute all information,
> but only part that is present in
> redefined info, and if there is additional parameters they will be simply
> merged into generated info
>
> __
> 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] iptables routes are not being injected to router namespace

[Kevin Benton]

There was a bug for this already.
https://bugs.launchpad.net/bugs/1413111

On Thu, Jan 22, 2015 at 9:07 AM, Brian Haley  wrote:

> On 01/22/2015 10:17 AM, Carl Baldwin wrote:
> > I think this warrants a bug report.  Could you file one with what you
> > know so far?
>
> Carl,
>
> Seems as though a recent change introduced a bug.  This is on a devstack
> I just created today, at l3/vpn-agent startup:
>
> 2015-01-22 11:55:07.961 4203 TRACE neutron.agent.l3.agent Traceback (most
> recent call last):
> 2015-01-22 11:55:07.961 4203 TRACE neutron.agent.l3.agent   File
> "/opt/stack/neutron/neutron/common/utils.py", line 342, in call
> 2015-01-22 11:55:07.961 4203 TRACE neutron.agent.l3.agent return
> func(*args, **kwargs)
> 2015-01-22 11:55:07.961 4203 TRACE neutron.agent.l3.agent   File
> "/opt/stack/neutron/neutron/agent/l3/agent.py", line 584, in process_router
> 2015-01-22 11:55:07.961 4203 TRACE neutron.agent.l3.agent
>  self._process_external(ri)
> 2015-01-22 11:55:07.961 4203 TRACE neutron.agent.l3.agent   File
> "/opt/stack/neutron/neutron/agent/l3/agent.py", line 576, in
> _process_external
> 2015-01-22 11:55:07.961 4203 TRACE neutron.agent.l3.agent
>  self._update_fip_statuses(ri, existing_floating_ips, fip_statuses)
> 2015-01-22 11:55:07.961 4203 TRACE neutron.agent.l3.agent
> UnboundLocalError: local variable 'existing_floating_ips' referenced before
> assignment
> 2015-01-22 11:55:07.961 4203 TRACE neutron.agent.l3.agent
> Traceback (most recent call last):
>   File "/usr/local/lib/python2.7/dist-packages/eventlet/greenpool.py",
> line 82, in _spawn_n_impl
> func(*args, **kwargs)
>   File "/opt/stack/neutron/neutron/agent/l3/agent.py", line 1093, in
> _process_router_update
> self._process_router_if_compatible(router)
>   File "/opt/stack/neutron/neutron/agent/l3/agent.py", line 1047, in
> _process_router_if_compatible
> self._process_added_router(router)
>   File "/opt/stack/neutron/neutron/agent/l3/agent.py", line 1056, in
> _process_added_router
> self.process_router(ri)
>   File "/opt/stack/neutron/neutron/common/utils.py", line 345, in call
> self.logger(e)
>   File "/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py",
> line 82, in __exit__
> six.reraise(self.type_, self.value, self.tb)
>   File "/opt/stack/neutron/neutron/common/utils.py", line 342, in call
> return func(*args, **kwargs)
>   File "/opt/stack/neutron/neutron/agent/l3/agent.py", line 584, in
> process_router
> self._process_external(ri)
>   File "/opt/stack/neutron/neutron/agent/l3/agent.py", line 576, in
> _process_external
> self._update_fip_statuses(ri, existing_floating_ips, fip_statuses)
> UnboundLocalError: local variable 'existing_floating_ips' referenced
> before assignment
>
> Since that's happening while we're holding the iptables lock I'm assuming
> no rules are being applied.
>
> I'm looking into it now, will file a bug if there isn't already one.
>
> -Brian
>
>
> > On Wed, Jan 21, 2015 at 2:24 PM, Brian Haley  wrote:
> >> On 01/21/2015 02:29 PM, Xavier León wrote:
> >>> On Tue, Jan 20, 2015 at 10:32 PM, Brian Haley 
> wrote:
>  On 01/20/2015 09:20 AM, Xavier León wrote:
> > Hi all,
> >
> > we've been doing some tests with openstack kilo and found
> > out a problem: iptables routes are not being injected to the
> > router namespace.
> >
> > Scenario:
> > - a private network NOT connected to the outside world.
> > - a router with only one interface connected to the private network.
> > - a vm instance connected to the private network as well.
> >> 
>  Are you sure the l3-agent is running?  You should have seen wrapped
> rules from
>  it in most of these tables, for example:
> 
>  # Generated by iptables-save v1.4.21 on Tue Jan 20 16:29:19 2015
>  *filter
>  :INPUT ACCEPT [34:10882]
>  :FORWARD ACCEPT [0:0]
>  :OUTPUT ACCEPT [1:84]
>  :neutron-filter-top - [0:0]
>  :neutron-l3-agent-FORWARD - [0:0]
>  :neutron-l3-agent-INPUT - [0:0]
>  :neutron-l3-agent-OUTPUT - [0:0]
>  :neutron-l3-agent-local - [0:0]
>  [...]
> >>>
> >>> Yes, the l3-agent is up and running. I see these rules when executing
> >>> the same test in juno but not in kilo. FYI, it's a all-in-one devstack
> >>> deployment.
> >>>
> 
>  I would check the log files for any errors.
> >>>
> >>> There are no errors in the logs.
> >>>
> >>> After digging a bit more, we have seen that setting the config value
> >>> of enable_isolated_metadata to True (default: False) in dhcp_agent.ini
> >>> solves the problem in our scenario.
> >>> However, this change in configuration was not necessary before (our
> >>> tests passed in juno for that matter with that setting to False). So
> >>> we were wondering if there has been a change in how the metadata
> >>> service is accessed in such scenarios, a new issue because of the l3
> >>> agent refactoring or any other problem in our setup we haven't
> >>> narrowed yet.
> >>
>

Re: [openstack-dev] [neutron] iptables routes are not being injected to router namespace

[Brian Haley]

On 01/22/2015 01:06 PM, Kevin Benton wrote:
> There was a bug for this already.
> https://bugs.launchpad.net/bugs/1413111

Thanks Kevin.  I added more info to it, but don't think the patch proposed there
is correct.  Something in the iptables manager defer_apply() code isn't quite 
right.

-Brian


> On Thu, Jan 22, 2015 at 9:07 AM, Brian Haley  > wrote:
> 
> On 01/22/2015 10:17 AM, Carl Baldwin wrote:
> > I think this warrants a bug report.  Could you file one with what you
> > know so far?
> 
> Carl,
> 
> Seems as though a recent change introduced a bug.  This is on a devstack
> I just created today, at l3/vpn-agent startup:
> 
> 2015-01-22 11:55:07.961 4203 TRACE neutron.agent.l3.agent Traceback (most
> recent call last):
> 2015-01-22 11:55:07.961 4203 TRACE neutron.agent.l3.agent   File
> "/opt/stack/neutron/neutron/common/utils.py", line 342, in call
> 2015-01-22 11:55:07.961 4203 TRACE neutron.agent.l3.agent return
> func(*args, **kwargs)
> 2015-01-22 11:55:07.961 4203 TRACE neutron.agent.l3.agent   File
> "/opt/stack/neutron/neutron/agent/l3/agent.py", line 584, in 
> process_router
> 2015-01-22 11:55:07.961 4203 TRACE neutron.agent.l3.agent   
>  self._process_external(ri)
> 2015-01-22 11:55:07.961 4203 TRACE neutron.agent.l3.agent   File
> "/opt/stack/neutron/neutron/agent/l3/agent.py", line 576, in 
> _process_external
> 2015-01-22 11:55:07.961 4203 TRACE neutron.agent.l3.agent   
>  self._update_fip_statuses(ri, existing_floating_ips, fip_statuses)
> 2015-01-22 11:55:07.961 4203 TRACE neutron.agent.l3.agent 
> UnboundLocalError:
> local variable 'existing_floating_ips' referenced before assignment
> 2015-01-22 11:55:07.961 4203 TRACE neutron.agent.l3.agent
> Traceback (most recent call last):
>   File "/usr/local/lib/python2.7/dist-packages/eventlet/greenpool.py", 
> line
> 82, in _spawn_n_impl
> func(*args, **kwargs)
>   File "/opt/stack/neutron/neutron/agent/l3/agent.py", line 1093, in
> _process_router_update
> self._process_router_if_compatible(router)
>   File "/opt/stack/neutron/neutron/agent/l3/agent.py", line 1047, in
> _process_router_if_compatible
> self._process_added_router(router)
>   File "/opt/stack/neutron/neutron/agent/l3/agent.py", line 1056, in
> _process_added_router
> self.process_router(ri)
>   File "/opt/stack/neutron/neutron/common/utils.py", line 345, in call
> self.logger(e)
>   File "/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", 
> line
> 82, in __exit__
> six.reraise(self.type_, self.value, self.tb)
>   File "/opt/stack/neutron/neutron/common/utils.py", line 342, in call
> return func(*args, **kwargs)
>   File "/opt/stack/neutron/neutron/agent/l3/agent.py", line 584, in
> process_router
> self._process_external(ri)
>   File "/opt/stack/neutron/neutron/agent/l3/agent.py", line 576, in
> _process_external
> self._update_fip_statuses(ri, existing_floating_ips, fip_statuses)
> UnboundLocalError: local variable 'existing_floating_ips' referenced 
> before
> assignment
> 
> Since that's happening while we're holding the iptables lock I'm assuming
> no rules are being applied.
> 
> I'm looking into it now, will file a bug if there isn't already one.
> 
> -Brian


__
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] [Telco][NFV] Meeting summary and logs - 2015-01-21

[Steve Gordon]

Hi all,

Please find minutes and logs from this week's OpenStack Telco Working Group 
meeting at the locations linked below:

* Minutes (HTML): 
http://eavesdrop.openstack.org/meetings/telcowg/2015/telcowg.2015-01-21-22.00.html
* Log (HTML): 
http://eavesdrop.openstack.org/meetings/telcowg/2015/telcowg.2015-01-21-22.00.log.html
* Minutes (TXT): 
http://eavesdrop.openstack.org/meetings/telcowg/2015/telcowg.2015-01-21-22.00.txt
* Log (TXT): 
http://eavesdrop.openstack.org/meetings/telcowg/2015/telcowg.2015-01-21-22.00.log.txt

In particular please take some time to review and comment on these use case 
outlines in the coming week (comments directly in the etherpads are fine):

* https://etherpad.openstack.org/p/telcowg-usecase-Virtual_IMS_Core
* https://etherpad.openstack.org/p/telcowg-usecase-VPN_Instantiation

Finally, I am attending the product working group midcycle next Monday/Tuesday 
and on checking my return flight have realized I will not quite be back on the 
ground before the telco working group meeting on Wednesday the 28th. As such I 
need a lucky volunteer (!) to facilitate the meeting.

Thanks,

Steve

__
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] [horizon] static files handling, bower/

[Jeremy Stanley]

On 2015-01-22 11:53:10 -0500 (-0500), Matthew Farina wrote:
> Has anyone done an inventory of xstatic packages that are
> available as system packages? I ask because I started asking these
> questions after doing a cursory inventory and finding few xstatic
> packages as system packages.
[...]

https://packages.debian.org/xstatic

"Found 41 matching packages."

I believe the majority are due to distro efforts around packaging
OpenStack.
-- 
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] [neutron] iptables routes are not being injected to router namespace

[Kevin Benton]

Right, there are two bugs here. One is in whatever went wrong with
defer_apply and one is with this exception handling code. I would allow the
fix to go in for the exception handling and then file another bug for the
actual underlying defer_apply bug.

On Thu, Jan 22, 2015 at 10:32 AM, Brian Haley  wrote:

> On 01/22/2015 01:06 PM, Kevin Benton wrote:
> > There was a bug for this already.
> > https://bugs.launchpad.net/bugs/1413111
>
> Thanks Kevin.  I added more info to it, but don't think the patch proposed
> there
> is correct.  Something in the iptables manager defer_apply() code isn't
> quite right.
>
> -Brian
>
>
> > On Thu, Jan 22, 2015 at 9:07 AM, Brian Haley  > > wrote:
> >
> > On 01/22/2015 10:17 AM, Carl Baldwin wrote:
> > > I think this warrants a bug report.  Could you file one with what
> you
> > > know so far?
> >
> > Carl,
> >
> > Seems as though a recent change introduced a bug.  This is on a
> devstack
> > I just created today, at l3/vpn-agent startup:
> >
> > 2015-01-22 11:55:07.961 4203 TRACE neutron.agent.l3.agent Traceback
> (most
> > recent call last):
> > 2015-01-22 11:55:07.961 4203 TRACE neutron.agent.l3.agent   File
> > "/opt/stack/neutron/neutron/common/utils.py", line 342, in call
> > 2015-01-22 11:55:07.961 4203 TRACE neutron.agent.l3.agent return
> > func(*args, **kwargs)
> > 2015-01-22 11:55:07.961 4203 TRACE neutron.agent.l3.agent   File
> > "/opt/stack/neutron/neutron/agent/l3/agent.py", line 584, in
> process_router
> > 2015-01-22 11:55:07.961 4203 TRACE neutron.agent.l3.agent
> >  self._process_external(ri)
> > 2015-01-22 11:55:07.961 4203 TRACE neutron.agent.l3.agent   File
> > "/opt/stack/neutron/neutron/agent/l3/agent.py", line 576, in
> _process_external
> > 2015-01-22 11:55:07.961 4203 TRACE neutron.agent.l3.agent
> >  self._update_fip_statuses(ri, existing_floating_ips, fip_statuses)
> > 2015-01-22 11:55:07.961 4203 TRACE neutron.agent.l3.agent
> UnboundLocalError:
> > local variable 'existing_floating_ips' referenced before assignment
> > 2015-01-22 11:55:07.961 4203 TRACE neutron.agent.l3.agent
> > Traceback (most recent call last):
> >   File
> "/usr/local/lib/python2.7/dist-packages/eventlet/greenpool.py", line
> > 82, in _spawn_n_impl
> > func(*args, **kwargs)
> >   File "/opt/stack/neutron/neutron/agent/l3/agent.py", line 1093, in
> > _process_router_update
> > self._process_router_if_compatible(router)
> >   File "/opt/stack/neutron/neutron/agent/l3/agent.py", line 1047, in
> > _process_router_if_compatible
> > self._process_added_router(router)
> >   File "/opt/stack/neutron/neutron/agent/l3/agent.py", line 1056, in
> > _process_added_router
> > self.process_router(ri)
> >   File "/opt/stack/neutron/neutron/common/utils.py", line 345, in
> call
> > self.logger(e)
> >   File
> "/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line
> > 82, in __exit__
> > six.reraise(self.type_, self.value, self.tb)
> >   File "/opt/stack/neutron/neutron/common/utils.py", line 342, in
> call
> > return func(*args, **kwargs)
> >   File "/opt/stack/neutron/neutron/agent/l3/agent.py", line 584, in
> > process_router
> > self._process_external(ri)
> >   File "/opt/stack/neutron/neutron/agent/l3/agent.py", line 576, in
> > _process_external
> > self._update_fip_statuses(ri, existing_floating_ips,
> fip_statuses)
> > UnboundLocalError: local variable 'existing_floating_ips' referenced
> before
> > assignment
> >
> > Since that's happening while we're holding the iptables lock I'm
> assuming
> > no rules are being applied.
> >
> > I'm looking into it now, will file a bug if there isn't already one.
> >
> > -Brian
>
>
> __
> 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
>



-- 
Kevin Benton
__
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] Changes to the core team

[Brandon Logan]

Congratulations Doug!

On Thu, 2015-01-22 at 11:21 -0600, Kyle Mestery wrote:
> On Thu, Jan 15, 2015 at 4:31 PM, Kyle Mestery 
> wrote:
> The last time we looked at core reviewer stats was in December
> [1]. In looking at the current stats, I'm going to propose
> some changes to the core team. Reviews are the most important
> part of being a core reviewer, so we need to ensure cores are
> doing reviews. The stats for the 90 day period [2] indicate
> some changes are needed for core reviewers who are no longer
> reviewing on pace with the other core reviewers.
> 
> 
> First of all, I'm removing Sumit Naiksatam from neutron-core.
> Sumit has been a core reviewer for a long time, and his past
> contributions are very much thanked by the entire OpenStack
> Neutron team. If Sumit jumps back in with thoughtful reviews
> in the future, we can look at getting him back as a Neutron
> core reviewer. But for now, his stats indicate he's not
> reviewing at a level consistent with the rest of the Neutron
> core reviewers.
> 
> 
> As part of the change, I'd like to propose Doug Wiegley as a
> new Neutron core reviewer. Doug has been actively reviewing
> code across not only all the Neutron projects, but also other
> projects such as infra. His help and work in the services
> split in December were the reason we were so successful in
> making that happen. Doug has also been instrumental in the
> Neutron LBaaS V2 rollout, as well as helping to merge code in
> the other neutron service repositories.
> 
> I'd also like to take this time to remind everyone that
> reviewing code is a responsibility, in Neutron the same as
> other projects. And core reviewers are especially beholden to
> this responsibility. I'd also like to point out that +1/-1
> reviews are very useful, and I encourage everyone to continue
> reviewing code even if you are not a core reviewer.
> 
> Existing neutron cores, please vote +1/-1 for the addition of
> Doug to the core team.
> 
> 
> It's been a week, and Doug has received plenty of support. Welcome to
> the Neutron Core Review team Doug!
> 
> Kyle
>  
> 
> Thanks!
> Kyle
> 
> [1]
> 
> http://lists.openstack.org/pipermail/openstack-dev/2014-December/051986.html
> [2]
> http://russellbryant.net/openstack-stats/neutron-reviewers-90.txt
> 
> 
> 
> __
> 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] [cinder] Change reset-state to involve the driver

[D'Angelo, Scott]

Thanks to everyone who commented on the spec to change reset-state to involve 
the driver: https://review.openstack.org/#/c/134366/

I've put some comments in reply, and I'm going to attempt to capture the 
various ideas here. I hope we can discuss this at the Mid-Cycle in Austin.
1) The existing reset-state python-cinderclient command should not change in 
unexpected ways and shouldn't have any new parameters (general consensus here). 
It should not fail if the driver does not implement my proposed changes (my 
opinion).
2) The existing reset-state is broken for some use cases (my UseCase2, for 
example, when stuck in 'attaching' but volume is still attached to instance). 
Existing reset-state will work for other situations (my UseCase1, when stuck in 
'attaching' but not really attached.
3)MikeP pointed out that moving _reset_status() would break clients. I could 
use help with understanding some of the API code here.
4) Xing had noted that this doesn't fix Nova. I hope we can do that separately, 
since this is proving contentious enough. Some cases such as a timeout during 
initialize_connection() could be fixed in Nova with a bug once this change is 
in. Other Nova changes might require a new Nova API to call for cleanup during 
reset-state, and that sounds much more difficult to get through the Nova change 
process.
5) Walt suggested a new driver method reset_state(). This seems fine, although 
I had hoped terminate_connection() and detach_volume() would cover all possible 
cleanup in the driver.
6) MikeP pointed out that difficulty of getting 30+ drivers to implement a 
change. I hope that this can be done in such a way that the reset-state 
commands works exactly as it does today if this is not implemented in the 
driver. Putting code in the driver to improve what exists today would be 
strictly optional.

Thanks again. See you in Austin.
scottda

__
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] [horizon] static files handling, bower/

[Richard Jones]

On Fri Jan 23 2015 at 4:28:59 AM Matthew Farina  wrote:

> I would like to add one more nuance to this discussion that I don't
> remember seeing.
>
> JavaScript libraries run in web browser in their JavaScript engines (like
> v8) rather than on the server. A version of a JS library may be fine on a
> system, without any security issues, but contain browser issues. The
> version used matters more to the application and the web browsers consuming
> the application than to the system it's on.
>

I think you're confusing Javascript in the browser vs. Javascript for
node.js

Those are two separate things. Javascript used in the browser is rarely
(never in our case) used also for node.js development. There are even two
separate packaging systems: bower is all about components for browsers,
whereas npm is all about packages for node.js. Our discussion is about
bower, and definitely not about npm or the node.js programming language.



> Some of the libraries exist as packages. For example, there are some
> debian packages. These have older versions of libraries than those that
> will work in Horizon.
>

Thanks to packagers working with OpenStack we are able to get newer
versions of the components we need once we have pinned them in our code.



> The libraries need to integrate for horizon and the browsers. So,
> supporting varying versions of a js library, their interactions together,
> and creating a usable interface will be a real problem. For example the
> debian packages of old or varying versions will a problem for those of us
> attempting to craft a UI. What's there isn't practically usable today. Some
> things are missing.
>

It's entirely up to us to specify a pinned set of component versions that
we need, which we then need the system packagers to ensure are available as
deb or rpm. Gaps will be filled as part of the usual packaging efforts that
go on during the OpenStack release cycle.


 Richard
__
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] [horizon] static files handling, bower/

[Matthew Farina]

Jeremy, thanks for sharing this. I do have a couple more questions and
comments based on this.

When there is an update to our requirements, such as the recent version
increment in the version of angular used, a new package version doesn't
automatically show up as evident from that list. How would that process be
kicked off so we don't end up with a missing dependency? Does that have to
wait for a release cycle?

Many of the xstatic packages are maintained by the OpenStack community.
Just see the list in stackforge (
https://github.com/stackforge/?query=xstatic). Right now we need to update
the xstatic package ourselves and then start using it. It also feels a
little odd to maintain xstatic packages for pypi that we don't consume that
way.

This appears to affect the testing setup as well. When we start to use a
new version of a JavaScript dependency no package will exist for it. I
believe this would mean the testing environment needs to use the
development setup, in the proposal, of bower. IIRC, bower goes out to the
Internet and there isn't a mirror of packages (just a mirror of the
registry). That means we'll loose the ability to run testing installs from
local mirrors for these dependencies. I imagine a solution has been thought
of for this. Can you share any details?

Thanks,

On Thu, Jan 22, 2015 at 2:35 PM, Jeremy Stanley  wrote:

> On 2015-01-22 11:53:10 -0500 (-0500), Matthew Farina wrote:
> > Has anyone done an inventory of xstatic packages that are
> > available as system packages? I ask because I started asking these
> > questions after doing a cursory inventory and finding few xstatic
> > packages as system packages.
> [...]
>
> https://packages.debian.org/xstatic
>
> "Found 41 matching packages."
>
> I believe the majority are due to distro efforts around packaging
> OpenStack.
> --
> 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
>
__
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] [horizon] static files handling, bower/

[Matthew Farina]

Richard,

I'm quite familiar with node.js and browser development. I think some of
the issue here may be a lack of detailed explanations and assumptions. By
asking questions here I, and some others, have been learning details that
we didn't know before. And, we're getting to follow from the intent from
start to finish. I'm finding this to be incredibly revealing.

Thanks,

On Thu, Jan 22, 2015 at 3:47 PM, Richard Jones 
wrote:

> On Fri Jan 23 2015 at 4:28:59 AM Matthew Farina 
> wrote:
>
>> I would like to add one more nuance to this discussion that I don't
>> remember seeing.
>>
>> JavaScript libraries run in web browser in their JavaScript engines (like
>> v8) rather than on the server. A version of a JS library may be fine on a
>> system, without any security issues, but contain browser issues. The
>> version used matters more to the application and the web browsers consuming
>> the application than to the system it's on.
>>
>
> I think you're confusing Javascript in the browser vs. Javascript for
> node.js
>
> Those are two separate things. Javascript used in the browser is rarely
> (never in our case) used also for node.js development. There are even two
> separate packaging systems: bower is all about components for browsers,
> whereas npm is all about packages for node.js. Our discussion is about
> bower, and definitely not about npm or the node.js programming language.
>
>
>
>> Some of the libraries exist as packages. For example, there are some
>> debian packages. These have older versions of libraries than those that
>> will work in Horizon.
>>
>
> Thanks to packagers working with OpenStack we are able to get newer
> versions of the components we need once we have pinned them in our code.
>
>
>
>> The libraries need to integrate for horizon and the browsers. So,
>> supporting varying versions of a js library, their interactions together,
>> and creating a usable interface will be a real problem. For example the
>> debian packages of old or varying versions will a problem for those of us
>> attempting to craft a UI. What's there isn't practically usable today. Some
>> things are missing.
>>
>
> It's entirely up to us to specify a pinned set of component versions that
> we need, which we then need the system packagers to ensure are available as
> deb or rpm. Gaps will be filled as part of the usual packaging efforts that
> go on during the OpenStack release cycle.
>
>
>  Richard
>
>
> __
> 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] [Ironic] RAID interface - backing disk hints

[Victor Lowther]

On Thu, Jan 22, 2015 at 1:44 AM, Tim Bell  wrote:
>> -Original Message-
>> From: Victor Lowther [mailto:victor.lowt...@gmail.com]
>> Sent: 21 January 2015 21:06
>> To: OpenStack Development Mailing List (not for usage questions)
>> Subject: Re: [openstack-dev] [Ironic] RAID interface - backing disk hints
>>
>> On Tue, Jan 20, 2015 at 8:36 AM, Jim Rollenhagen 
>> wrote:
>> > On Tue, Jan 20, 2015 at 07:28:46PM +0530, Ramakrishnan G wrote:
> ...
>>
>> Given that, deciding to build and manage arrays based on drive
>> mfgr/model/firmware is a lot less useful than deciding to build and manage
>> them based on interface type/media type/size/spindle speed/slot#.
>>
>
> +1 - How about using the /dev/disk/by-path information which says to install 
> the system onto the disks by their device location.
>
> Have a look at how kickstart does it.  It's the same problem so we don't need 
> to re-invent the wheel.

I am aware of how kickstart detects disks and how we can pass
information about which disk to install on, and that is only
tangentially related to what I am talking about.

What I have been talking about is how to decide which physical disks
attached to a hardware RAID controller should be used to create a RAID
volume, and the relative usefulness of the properties of the physical
disks in doing so.  My contention is that drive mfgr/model/firmware is
not used in practice to make that decision -- other factors, such as
disk size, spindle speed, media type, and interface type are what are
used in a production setting.

>
> __
> 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] [horizon] static files handling, bower/

[Jeremy Stanley]

On 2015-01-22 16:06:55 -0500 (-0500), Matthew Farina wrote:
[...]
> When there is an update to our requirements, such as the recent
> version increment in the version of angular used, a new package
> version doesn't automatically show up as evident from that list.
> How would that process be kicked off so we don't end up with a
> missing dependency? Does that have to wait for a release cycle?

I don't want to speak for the distro package maintainers, but from
what I've seen they generally wait until close enough to an
integrated release that they can be pretty sure the requirements are
close to frozen, so as not to waste effort packaging things which
will end up not being used.

> Many of the xstatic packages are maintained by the OpenStack
> community. Just see the list in stackforge
> (https://github.com/stackforge/?query=xstatic). Right now we need
> to update the xstatic package ourselves and then start using it.
> It also feels a little odd to maintain xstatic packages for pypi
> that we don't consume that way.

I assume (perhaps incorrectly?) that we do use those in CI jobs, so
that we can download the things a given project needs in an
automated fashion--for us handling pip requirements lists is a
solved problem (well, for some definitions of solved at least).

> This appears to affect the testing setup as well. When we start to
> use a new version of a JavaScript dependency no package will exist
> for it. I believe this would mean the testing environment needs to
> use the development setup, in the proposal, of bower. IIRC, bower
> goes out to the Internet and there isn't a mirror of packages
> (just a mirror of the registry). That means we'll loose the
> ability to run testing installs from local mirrors for these
> dependencies. I imagine a solution has been thought of for this.
> Can you share any details?

I am not aware of what the solution for this would be, but it will
be a show-stopper for the plan and so I (Infra hat on) would expect
the horizon developers to come up with an implementation which
solves that. Perhaps some routine to retrieve and pre-cache the
necessary files like we do with a lot of the random files devstack
uses, and then run that during image build time so that it's already
present on the filesystems of the machines which will run the jobs
needing 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] [neutron] iptables routes are not being injected to router namespace

[Brian Haley]

On 01/22/2015 02:35 PM, Kevin Benton wrote:
> Right, there are two bugs here. One is in whatever went wrong with defer_apply
> and one is with this exception handling code. I would allow the fix to go in 
> for
> the exception handling and then file another bug for the actual underlying
> defer_apply bug.

What went wrong with defer_apply() was caused by oslo.concurrency - version
1.4.1 seems to fix the problem, see https://review.openstack.org/#/c/149400/
(thanks Ihar!)

Xavier - can you update your oslo.concurrency to that version and verify it
helps?  It seems to work in my config.

Then the change in the other patchset could be applied, along with a test that
triggers exceptions so this gets caught.

Thanks,

-Brian

> On Thu, Jan 22, 2015 at 10:32 AM, Brian Haley  > wrote:
> 
> On 01/22/2015 01:06 PM, Kevin Benton wrote:
> > There was a bug for this already.
> > https://bugs.launchpad.net/bugs/1413111
> 
> Thanks Kevin.  I added more info to it, but don't think the patch 
> proposed there
> is correct.  Something in the iptables manager defer_apply() code isn't
> quite right.
> 
> -Brian
> 
> 
> > On Thu, Jan 22, 2015 at 9:07 AM, Brian Haley  
> > >> wrote:
> >
> > On 01/22/2015 10:17 AM, Carl Baldwin wrote:
> > > I think this warrants a bug report.  Could you file one with what 
> you
> > > know so far?
> >
> > Carl,
> >
> > Seems as though a recent change introduced a bug.  This is on a 
> devstack
> > I just created today, at l3/vpn-agent startup:
> >
> > 2015-01-22 11:55:07.961 4203 TRACE neutron.agent.l3.agent Traceback 
> (most
> > recent call last):
> > 2015-01-22 11:55:07.961 4203 TRACE neutron.agent.l3.agent   File
> > "/opt/stack/neutron/neutron/common/utils.py", line 342, in call
> > 2015-01-22 11:55:07.961 4203 TRACE neutron.agent.l3.agent return
> > func(*args, **kwargs)
> > 2015-01-22 11:55:07.961 4203 TRACE neutron.agent.l3.agent   File
> > "/opt/stack/neutron/neutron/agent/l3/agent.py", line 584, in
> process_router
> > 2015-01-22 11:55:07.961 4203 TRACE neutron.agent.l3.agent
> >  self._process_external(ri)
> > 2015-01-22 11:55:07.961 4203 TRACE neutron.agent.l3.agent   File
> > "/opt/stack/neutron/neutron/agent/l3/agent.py", line 576, in
> _process_external
> > 2015-01-22 11:55:07.961 4203 TRACE neutron.agent.l3.agent
> >  self._update_fip_statuses(ri, existing_floating_ips, fip_statuses)
> > 2015-01-22 11:55:07.961 4203 TRACE neutron.agent.l3.agent
> UnboundLocalError:
> > local variable 'existing_floating_ips' referenced before assignment
> > 2015-01-22 11:55:07.961 4203 TRACE neutron.agent.l3.agent
> > Traceback (most recent call last):
> >   File 
> "/usr/local/lib/python2.7/dist-packages/eventlet/greenpool.py",
> line
> > 82, in _spawn_n_impl
> > func(*args, **kwargs)
> >   File "/opt/stack/neutron/neutron/agent/l3/agent.py", line 1093, in
> > _process_router_update
> > self._process_router_if_compatible(router)
> >   File "/opt/stack/neutron/neutron/agent/l3/agent.py", line 1047, in
> > _process_router_if_compatible
> > self._process_added_router(router)
> >   File "/opt/stack/neutron/neutron/agent/l3/agent.py", line 1056, in
> > _process_added_router
> > self.process_router(ri)
> >   File "/opt/stack/neutron/neutron/common/utils.py", line 345, in 
> call
> > self.logger(e)
> >   File
> "/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line
> > 82, in __exit__
> > six.reraise(self.type_, self.value, self.tb)
> >   File "/opt/stack/neutron/neutron/common/utils.py", line 342, in 
> call
> > return func(*args, **kwargs)
> >   File "/opt/stack/neutron/neutron/agent/l3/agent.py", line 584, in
> > process_router
> > self._process_external(ri)
> >   File "/opt/stack/neutron/neutron/agent/l3/agent.py", line 576, in
> > _process_external
> > self._update_fip_statuses(ri, existing_floating_ips, 
> fip_statuses)
> > UnboundLocalError: local variable 'existing_floating_ips' referenced
> before
> > assignment
> >
> > Since that's happening while we're holding the iptables lock I'm 
> assuming
> > no rules are being applied.
> >
> > I'm looking into it now, will file a bug if there isn't already one.
> >
> > -Brian
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.o

Re: [openstack-dev] [Keystone] Nominating Brad Topol for Keystone-Spec core

[Adam Young]

On 01/18/2015 02:11 PM, Morgan Fainberg wrote:

Hello all,

I would like to nominate Brad Topol for Keystone Spec core (core 
reviewer for Keystone specifications and API-Specification only: 
https://git.openstack.org/cgit/openstack/keystone-specs ). Brad has 
been a consistent voice advocating for well defined specifications, 
use of existing standards/technology, and ensuring the UX of all 
projects under the Keystone umbrella continue to improve. Brad brings 
to the table a significant amount of insight to the needs of the many 
types and sizes of OpenStack deployments, especially what real-world 
customers are demanding when integrating with the services. Brad is a 
core contributor on pycadf (also under the Keystone umbrella) and has 
consistently contributed code and reviews to the Keystone projects 
since the Grizzly release.


Please vote with +1/-1 on adding Brad to as core to the Keystone Spec 
repo. Voting will remain open until Friday Jan 23.


Cheers,
Morgan Fainberg



__
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

+1
__
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] Plugins for Fuel: repo, doc, spec - where?

[Mike Scherbakov]

Hi Fuelers,
we've implemented pluggable architecture piece in 6.0, and got a number of
plugins already. Overall development process for plugins is still not fully
defined.
We initially thought that having all the plugins in one repo on stackforge
is Ok, we also put some docs into existing fuel-docs repo, and specs to
fuel-specs.

We might need a change here. Plugins are not tight to any particular
release date, and they can also be separated each from other in terms of
committers and core reviewers. Also, it seems to be pretty natural to keep
all docs and design specs associated with particular plugin.

With all said, following best dev practices, it is suggested to:

   1. Have a separate stackforge repo per Fuel plugin in format
   "fuel-plugin-", with separate core-reviewers group which should have
   plugin contributor initially
   2. Have docs folder in the plugin, and ability to build docs out of it
  - do we want Sphinx or simple Github docs format is Ok? So people can
  just go to github/stackforge to see docs
   3. Have specification in the plugin repo
  - also, do we need Sphinx here?
   4. Have plugins tests in the repo

Ideas / suggestions / comments?
Thanks,
-- 
Mike Scherbakov
#mihgen
__
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] penstack Heat- OS::Heat::MultipartMime cannot be used as user_data for OS::Nova::Server

[Vignesh Kumar]

Hi all,



I am new to heat orchestration and am trying to create a coreOS cluster
with it. I have a OS::Heat::SoftwareConfig resource and a
OS::Heat::CloudConfig resource and I have joined them both in a
OS::Heat::MultipartMime resource which is then used as a user_data for a
OS::Nova::Server resource. Unfortunately I am not able to see the
configurations happening in my server resource using cloud-init. When I
give the OS::Heat::SoftwareConfig resource and the OS::Heat::CloudConfig
resource individually to the user_data of server resource it is working
fine. Any inputs are appreciated.





These are my resources



  coreOS_cloudconfig:

type: OS::Heat::CloudConfig

properties:

  cloud_config:

write_files:

- path: /etc/sysconfig/docker

  owner: core:core

  permissions: 0644

  content: |

   ulimit -l unlimited

   ulimit -n 10240

   ulimit -c unlimited

coreos:

  etcd:

discovery: { get_param: Tokenurl }

addr: $private_ipv4:4001

peer-addr: $private_ipv4:7001

#peer-heartbeat-interval: 100

#peer-election-timeout: 500

  fleet:

public-ip: $private_ipv4

etcd-request-timeout: 15

  units:

- name: etcd.service

  command: start

- name: fleet.service

  command: start



sample_shscript:

type: OS::Heat::SoftwareConfig

properties:

  group: ungrouped

  config: |

#!/bin/bash

echo "The three is bar" > /tmp/three





server_init:

type: OS::Heat::MultipartMime

properties:

  parts:

  - config: {get_resource: coreOS_cloudconfig}

  - config: {get_resource: sample_shscript}





tvecoreos01:

type: OS::Nova::Server

properties:

  key_name: newkey

  image: { get_param: ImageID }

  flavor: m1.medium

  networks:

- network: { get_param: NetID }

  security_groups: [default]

  user_data_format: RAW

  user_data:

get_resource: server_init



Thanks and Regards,

Vignesh Kumar Kathiresan
__
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] Wrong Status at the Dashboard - Juno Horizon

[Fox, Kevin M]

There was a thread named "Wrong Status at the Dashboard - IceHouse Horizon" mid 
last year.
Thread archived here:
http://www.gossamer-threads.com/lists/openstack/dev/38332

I seem to have hit the same issue using Juno.

I had some bad passwords on a hypervisor while I was figuring out the deploy 
scripts, and had launched a few vm's that errored. Now overview for a tenant 
shows 5 vm's used, when only two exist.

This bug still seems to be there. Any ideas how to fix the accounting?

Thanks,
Kevin
__
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] [Glance] New Glance Drivers.

[Nikhil Komawar]

Hi all,

Please join me in welcoming Flavio and Ian to the Glance Drivers team.

They have been doing some quality work in Glance; each of them brings in his 
own skill set to the team. We would be happy to rely on the two main traits of 
these individuals - they are aware about general workings of OpenStack and are 
quite active on the Images program. Their feedback on the features as well as 
bugs has been a motivating factor for the developers and the criticism has been 
constructive. Their help in the releases of python-glanceclient and 
glance_store libraries has been great as well.

Welcome Ian and Flavio!

P.S. You both would soon be added to the launchpad team.

Thanks,
-Nikhil
__
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] Wrong Status at the Dashboard - Juno Horizon

[Ben Nemec]

On 01/22/2015 05:08 PM, Fox, Kevin M wrote:
> There was a thread named "Wrong Status at the Dashboard - IceHouse Horizon" 
> mid last year.
> Thread archived here:
> http://www.gossamer-threads.com/lists/openstack/dev/38332
> 
> I seem to have hit the same issue using Juno.
> 
> I had some bad passwords on a hypervisor while I was figuring out the deploy 
> scripts, and had launched a few vm's that errored. Now overview for a tenant 
> shows 5 vm's used, when only two exist.
> 
> This bug still seems to be there. Any ideas how to fix the accounting?

I believe the bug open for this is
https://bugs.launchpad.net/tripleo/+bug/1284424

If you have a scenario that reproduces the problem then adding that to
the bug might help.

> 
> Thanks,
> Kevin


__
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] [Ironic] RAID interface - backing disk hints

[Fox, Kevin M]

For reference, most of our kickstart scripts for storage bricks go by size. The 
little disks are system disks to be assembled into a software raid. The big 
ones are raid arrays to be preserved.

Kickstart's ability to let you run a shell script on the host to build the 
partitioning instructions that kickstart uses is a very handy feature.

Thanks,
Kevin

From: Victor Lowther [victor.lowt...@gmail.com]
Sent: Thursday, January 22, 2015 1:18 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Ironic] RAID interface - backing disk hints

On Thu, Jan 22, 2015 at 1:44 AM, Tim Bell  wrote:
>> -Original Message-
>> From: Victor Lowther [mailto:victor.lowt...@gmail.com]
>> Sent: 21 January 2015 21:06
>> To: OpenStack Development Mailing List (not for usage questions)
>> Subject: Re: [openstack-dev] [Ironic] RAID interface - backing disk hints
>>
>> On Tue, Jan 20, 2015 at 8:36 AM, Jim Rollenhagen 
>> wrote:
>> > On Tue, Jan 20, 2015 at 07:28:46PM +0530, Ramakrishnan G wrote:
> ...
>>
>> Given that, deciding to build and manage arrays based on drive
>> mfgr/model/firmware is a lot less useful than deciding to build and manage
>> them based on interface type/media type/size/spindle speed/slot#.
>>
>
> +1 - How about using the /dev/disk/by-path information which says to install 
> the system onto the disks by their device location.
>
> Have a look at how kickstart does it.  It's the same problem so we don't need 
> to re-invent the wheel.

I am aware of how kickstart detects disks and how we can pass
information about which disk to install on, and that is only
tangentially related to what I am talking about.

What I have been talking about is how to decide which physical disks
attached to a hardware RAID controller should be used to create a RAID
volume, and the relative usefulness of the properties of the physical
disks in doing so.  My contention is that drive mfgr/model/firmware is
not used in practice to make that decision -- other factors, such as
disk size, spindle speed, media type, and interface type are what are
used in a production setting.

>
> __
> 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] [nova][gate][stable] How eventlet 0.16.1 broke the gate

[Kevin L. Mitchell]

On Wed, 2015-01-21 at 18:48 -0800, Joshua Harlow wrote:
> Another thing that I just started whipping together:
> 
> https://gist.github.com/harlowja/5e39ec5ca9e3f0d9a21f

One problem, though, is that parse_requirements() now requires the
session keyword argument.  In version 6.0.6, parse_requirements() begins
with:

def parse_requirements(filename, finder=None, comes_from=None, 
options=None,
   session=None):
if session is None:
raise TypeError(
"parse_requirements() missing 1 required keyword argument: "
"'session'"
)
-- 
Kevin L. Mitchell 
Rackspace


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

Re: [openstack-dev] [Nova][Neutron] Thoughts on the nova<->neutron interface

[Salvatore Orlando]

On 22 January 2015 at 17:09, Sean Dague  wrote:

> On 01/22/2015 10:28 AM, Salvatore Orlando wrote:
> > Hi,
> >
> > We have attempted several times to start a conversation around the
> > interface between nova and neutron and its problems, starting with the
> > fact that it's chatter than two Italians arguing about football (*).
> > Indeed the first attempt at fixing these problems goes back to the Fall
> > 2012 summit [1]. While we probably don't want to introduce yet another
> > service to this aim, it might be worth giving another shot at having
> > these two project communicate in a decent way. I know that other
> > developers are interested in this and are probably even already actively
> > working on this topic.
> >
> > In my opinion it might not be such a bad idea to start this conversation
> > at the upcoming nova meetup, if there will be enough interest from the
> > participants. I have started the etherpad [2] for discussing issues of
> > the current implementation, goals, architecture, and design.
> >
> > As for timelines, it is very likely already too late for shipping this
> > in Kilo, but we're probably still on time for completing this work by
> > the "L" release.
> >
> > Salvatore
> >
> > (*) being Italian I am entitled to make jokes about Italians without
> > offending anyone, I hope.
> >
> > [1] https://etherpad.openstack.org/p/grizzly-newtonian
> > [2] https://etherpad.openstack.org/p/nova-neutron-interface-rework
>
> Interesting stuff. I conceptually like the idea of nova-compute doing
> the leg work for sub resources (like the network) as it feels like error
> handling is simpler given it's closeness to the actual VMs that are
> running.
>

That's true for the nova-network use case. In the neutron case instead
nova-compute ends up calling the neutron server which then operates on the
host through its agent. So we probably have different workflows, and the
one currently performed when using neutron is a bit "erratic" since it goes
from nova-api to nova-compute where the instance is built; then it calls
into neutron-server whose network configuration is picked up by the agent
which configures networking on the same host where nova-compute is running!


>
> I also like the idea of considering the RPC interface. What kind of
> stability / versioning exists on the Neutron RPC interface?
>

Even if Neutron does not have fancy things such as objects with remotable
method, I think its RPC interfaces are versioned exactly in the same way as
Nova. On REST vs AMQP I do not have a strong opinion. This topic comes up
quite often; on the one hand REST provides a cleaner separation of concerns
between the two projects; on the other hand RPC will enable us to design an
optimised interface specific to Nova. While REST over HTTP is not as
bandwidth-efficient as RPC over AMQP it however allow deployers to use
off-the-shelf tools for HTTP optimisation, such as load balancing, or
caching.



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

Re: [openstack-dev] [nova][gate][stable] How eventlet 0.16.1 broke the gate

[Joshua Harlow]

Seems like a simple fix?

https://github.com/pypa/pip/blob/1.5.6/pip/req.py#L1536

Make a new session somewhere in that gist/code and profit?

Kevin L. Mitchell wrote:

On Wed, 2015-01-21 at 18:48 -0800, Joshua Harlow wrote:

Another thing that I just started whipping together:

https://gist.github.com/harlowja/5e39ec5ca9e3f0d9a21f


One problem, though, is that parse_requirements() now requires the
session keyword argument.  In version 6.0.6, parse_requirements() begins
with:

 def parse_requirements(filename, finder=None, comes_from=None, 
options=None,
session=None):
 if session is None:
 raise TypeError(
 "parse_requirements() missing 1 required keyword argument: 
"
 "'session'"
 )


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

Re: [openstack-dev] [Nova][Neutron] Thoughts on the nova<->neutron interface

[Kevin Benton]

I can't imagine how MPLS/RSVP is suitable for the communications between
Nova and Neutron. Can you elaborate on what you meant?

On Thu, Jan 22, 2015 at 9:36 AM, Akilesh K  wrote:

> I had always wanted this to happen. It is really frustrating when nova
> throws wierd python exceptions and difficult to comprehend log messages.
>
> If the developers do agree to clean up the interface I would suggest they
> make use of some well knows protocol (mpls/rsvp) to do this, instead of
> relying on custom south-bound api calls.
>
> regards,
> Ageeleshwar K
>
> On Thu, Jan 22, 2015 at 9:39 PM, Sean Dague  wrote:
>
>> On 01/22/2015 10:28 AM, Salvatore Orlando wrote:
>> > Hi,
>> >
>> > We have attempted several times to start a conversation around the
>> > interface between nova and neutron and its problems, starting with the
>> > fact that it's chatter than two Italians arguing about football (*).
>> > Indeed the first attempt at fixing these problems goes back to the Fall
>> > 2012 summit [1]. While we probably don't want to introduce yet another
>> > service to this aim, it might be worth giving another shot at having
>> > these two project communicate in a decent way. I know that other
>> > developers are interested in this and are probably even already actively
>> > working on this topic.
>> >
>> > In my opinion it might not be such a bad idea to start this conversation
>> > at the upcoming nova meetup, if there will be enough interest from the
>> > participants. I have started the etherpad [2] for discussing issues of
>> > the current implementation, goals, architecture, and design.
>> >
>> > As for timelines, it is very likely already too late for shipping this
>> > in Kilo, but we're probably still on time for completing this work by
>> > the "L" release.
>> >
>> > Salvatore
>> >
>> > (*) being Italian I am entitled to make jokes about Italians without
>> > offending anyone, I hope.
>> >
>> > [1] https://etherpad.openstack.org/p/grizzly-newtonian
>> > [2] https://etherpad.openstack.org/p/nova-neutron-interface-rework
>>
>> Interesting stuff. I conceptually like the idea of nova-compute doing
>> the leg work for sub resources (like the network) as it feels like error
>> handling is simpler given it's closeness to the actual VMs that are
>> running.
>>
>> I also like the idea of considering the RPC interface. What kind of
>> stability / versioning exists on the Neutron RPC interface?
>>
>> -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
>>
>>
>
> __
> 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
>
>


-- 
Kevin Benton
__
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] oslo_log/oslo_config initialization

[Qiming Teng]

On Thu, Jan 22, 2015 at 06:06:54AM -0500, Davanum Srinivas wrote:
> Qiming,
> 
> you are reading bits and pieces of my responses."if you checkout the
> review" guess i give up!
> 
> -- dims

Ah, I see. I jumped directly into the code review dashboard without realizing
that patch is still WIP.  That was my confusion.  Sorry.

Regards,
  Qiming


__
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] Changes to Cinder Core

[Huang Zhiteng]

+1

Welcome to the team Ivan!

On Fri, Jan 23, 2015 at 1:23 AM, Walter A. Boring IV
 wrote:
> sorry I didn't see this earlier.
>
> I'd welcome Ivan to the team!
>
> +1
>
>
> Walt
>
>> On Wed, Jan 21, 2015 at 10:14 AM, Mike Perez  wrote:
>>>
>>> It gives me great pleasure to nominate Ivan Kolodyazhny (e0ne) for
>>> Cinder core. Ivan's reviews have been valuable in decisions, and his
>>> contributions to Cinder core code have been greatly appreciated.
>>>
>>> Reviews:
>>>
>>> https://review.openstack.org/#/q/reviewer:%22Ivan+Kolodyazhny+%253Ce0ne%2540e0ne.info%253E%22,n,z
>>>
>>> Contributions:
>>>
>>> https://review.openstack.org/#/q/owner:%22Ivan+Kolodyazhny%22+project:+openstack/cinder,n,z
>>>
>>> 30/90 day review stats:
>>> http://stackalytics.com/report/contribution/cinder-group/30
>>> http://stackalytics.com/report/contribution/cinder-group/90
>>>
>>> As new contributors step up to help in the project, some move onto
>>> other things. I would like to recognize Josh Durgin for his early
>>> contributions to Nova volume, early involvement with Cinder, and now
>>> unfortunately departure from the Cinder core team.
>>>
>>> Cinder core, please reply with a +1 for approval. This will be left
>>> open until Jan 26th. Assuming there are no objections, this will go
>>> forward after voting is closed.
>>
>> And apologies for missing the [cinder] subject prefix.
>>
>> --
>> Mike Perez
>>
>> __
>> 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



-- 
Regards
Huang Zhiteng

__
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][3rd CI] Confused about “*real* storage backend”requirement for 3rd CI.

[Bharat Kumar]

On 01/22/2015 05:39 PM, Duncan Thomas wrote:
Please take a look at 
https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers to 
learn how to configure devstack to use your driver rather than LVM.


On 22 January 2015 at 13:28, liuxinguo > wrote:


Hi Mike,

I received a email named “All Cinder Drivers Must Have a Third
Party CI By March 19th 2015”and I feel confused about the “*real*
storage backend”.

One of the requirements is: Run Tempest [5][6] volume tests
against the devstack environment that's hooked up to your *real*
storage backend.

·And my confusion is:

·Every time the CI is triggered by a newly came patch, the 3rd CI
will build a new devstack environment and create a default
cinder.conf file whick will set the backend to
“lvmdriver-1”automatically. And the tempest will run against
“lvmdriver-1”. So what’s the meaning for a *real*storage backend
since the cinder.conf will be set to use
“lvmdriver-1”automatically for every newly came patch ? And how
should I configure the cinder.conf file to run the tempest for the
newly came driver patch came from different venders since
different venders need different configuration for cinder.conf
file and need different storage backend. I mean, does our CI
should run tempest against our *real* storage backend for every
newly came driver patch in cinder?


Liu,

Yes, by default DevStack configures cinder with "LVM". But we can 
customize DevStack to configure cinder with our own backend ("real 
storage backend").


Below is the link to the path, enables Automatic Configuration of 
GlusterFS for Cinder using devstack:

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

And also below it the link to Configure CEPH with Cinder using devstack:
https://review.openstack.org/#/c/65113/

Above two are old way of "real storage" plugin implementation. Sean 
Dague proposed a new way of devstack plugin implementation. Have a look 
at below two links:

https://review.openstack.org/#/c/142805/
https://review.openstack.org/#/c/142805/7/doc/source/plugins.rst


Thanks and regards,

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




--
Duncan Thomas


__
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


--
Warm Regards,
Bharat Kumar Kobagana
Software Engineer
OpenStack Storage – RedHat India
Mobile - +91 9949278005

__
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][vpnaas] Can we require kernel 3.8+ for use with StrongSwan IPSec VPN for Kilo?

[Kevin Benton]

>If we can consolidate that and use a single tool from the master neutron
repository, that would be my vote.

+1 with a hook mechanism so the sanity checks stay in the *aas repos and
they are only run if installed.

>
On Thu, Jan 22, 2015 at 7:30 AM, Kyle Mestery  wrote:

> On Wed, Jan 21, 2015 at 10:27 AM, Ihar Hrachyshka 
> wrote:
>
>>  On 01/20/2015 05:40 PM, Paul Michali wrote:
>>
>> Review https://review.openstack.org/#/c/146508/ is adding support for
>> StrongSwan VPN, which needs mount bind to be able to specify different
>> paths for config files.
>>
>>  The code, which used some older patch, does a test for /proc/1/ns/net,
>> instead of /proc/1/ns/mnt, because it stated that the latter is only
>> supported in kernel 3.8+. That was a while ago, and I'm wondering if the
>> condition is still true.  If we know that for Kilo and on, we'll be dealing
>> with 3.8+ kernels, we could use the more accurate test.
>>
>>  Can we require 3.8+ kernel for this?
>>
>>
>> I think we can but it's better to check with distributions. Red Hat wise,
>> we ship a kernel that is newer than 3.8.
>>
>>  If so, how and where do we ensure that is true?
>>
>>
>> Ideally, you would implement a sanity check for the feature you need from
>> the kernel. Though it opens a question of whether we want to ship multiple
>> sanity check tools for each of repos (neutron + 3 *aas repos).
>>
>> If we can consolidate that and use a single tool from the master neutron
> repository, that would be my vote.
>
>>
>>  Also, if you can kindly review the code here:
>> https://review.openstack.org/#/c/146508/5/neutron_vpnaas/services/vpn/common/netns_wrapper.py,
>> I'd really appreciate it, as I'm not versed in the Linux proc files at all.
>>
>>  Thanks!
>>
>>
>>   PCM (Paul Michali)
>>
>>  IRC pc_m (irc.freenode.com)
>> Twitter... @pmichali
>>
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: 
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://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
>
>


-- 
Kevin Benton
__
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][vpnaas] Can we require kernel 3.8+ for use with StrongSwan IPSec VPN for Kilo?

[Joshua Zhang]

pls note that actually this patch doesn't have minumum kernel requirement
because it only uses 'mount --bind' and 'net namespace', not use 'mount
namespace'. ('mount --bind' is since linux 2.4, 'net namespace' is since
Linux 3.0, 'mount namespace' is since Linux 3.8).

so I think sanity checks for 3.8 is not need, any thoughts ?

thanks.


On Fri, Jan 23, 2015 at 2:12 PM, Kevin Benton  wrote:

> >If we can consolidate that and use a single tool from the master neutron
> repository, that would be my vote.
>
> +1 with a hook mechanism so the sanity checks stay in the *aas repos and
> they are only run if installed.
>
>>
> On Thu, Jan 22, 2015 at 7:30 AM, Kyle Mestery  wrote:
>
>> On Wed, Jan 21, 2015 at 10:27 AM, Ihar Hrachyshka 
>> wrote:
>>
>>>  On 01/20/2015 05:40 PM, Paul Michali wrote:
>>>
>>> Review https://review.openstack.org/#/c/146508/ is adding support for
>>> StrongSwan VPN, which needs mount bind to be able to specify different
>>> paths for config files.
>>>
>>>  The code, which used some older patch, does a test for /proc/1/ns/net,
>>> instead of /proc/1/ns/mnt, because it stated that the latter is only
>>> supported in kernel 3.8+. That was a while ago, and I'm wondering if the
>>> condition is still true.  If we know that for Kilo and on, we'll be dealing
>>> with 3.8+ kernels, we could use the more accurate test.
>>>
>>>  Can we require 3.8+ kernel for this?
>>>
>>>
>>> I think we can but it's better to check with distributions. Red Hat
>>> wise, we ship a kernel that is newer than 3.8.
>>>
>>>  If so, how and where do we ensure that is true?
>>>
>>>
>>> Ideally, you would implement a sanity check for the feature you need
>>> from the kernel. Though it opens a question of whether we want to ship
>>> multiple sanity check tools for each of repos (neutron + 3 *aas repos).
>>>
>>> If we can consolidate that and use a single tool from the master neutron
>> repository, that would be my vote.
>>
>>>
>>>  Also, if you can kindly review the code here:
>>> https://review.openstack.org/#/c/146508/5/neutron_vpnaas/services/vpn/common/netns_wrapper.py,
>>> I'd really appreciate it, as I'm not versed in the Linux proc files at all.
>>>
>>>  Thanks!
>>>
>>>
>>>   PCM (Paul Michali)
>>>
>>>  IRC pc_m (irc.freenode.com)
>>> Twitter... @pmichali
>>>
>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: 
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://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
>>
>>
>
>
> --
> Kevin Benton
>
> __
> 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
>
>


-- 
Best Regards
Zhang Hua(张华）
Software Engineer | Canonical
IRC:  zhhuabj
__
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][lbaas] Object statuses

[Brandon Logan]

So I am resurrecting this topic now because we put this discussion on a a brief 
hold,
but are now discussing it again and need to decide asap. We've all agreed we 
need a
provisioning_status and operating_status fields. We now need to decide where to 
show
these statuses to the user.

Option 1:
Show the statuses directly on the entity.

Option 2-A:
Show a status tree only on the load balancer object, but not on any entities.

Option 2-B:
Expose a resource for a GET request that will return that status tree.

Example:
GET /lbaas/loadbalancers/{LB_UUID}/statuses


Option 1 is probably what most people are used to but it doesn't allow for 
sharing of
objects, and when/if sharing is enabled, it will cause a break in contract and 
a new
version of the API.  So it would essentially disallow object sharing.  This 
requires
a lot less work to implement.

Option 2-* can be done with or without sharing, and when/if object sharing is 
enabled
it wont break contract.  This will require more work to implement.

My personal opinion is in favor of Option 2-B, but wouldn't argue with 2-A 
either.

Thanks,
Brandon


__
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] ML2 port binding?

[Harish Patil]

>

>Hi Harish,
>
>Port binding in ML2 is the process by which a mechanism driver (or once
>https://blueprints.launchpad.net/openstack/?searchtext=ml2-hierarchical-po
>rt-binding
>is merged, potentially a set of mechanism drivers) is selected for the
>port, determining how connectivity is provided for that port. Since ML2
>is designed to support heterogeneous deployments, its possible for
>different ports to be bound using different mechanism drivers.
>
>The end results of port binding visible outside ML2 are the values of
>the binding:vif_type and binding:vif_details port attributes that
>control the Nova VIF driver behavior.  The inputs to the port binding
>process are the port and the network to which the port belongs,
>including the network's set of segments, as well as the values of the
>binding:host_id, binding:vnic_type, and binding:profile port attributes.
>Nova (or any L3, DHCP, or service agent owning the port) sets
>binding:host_id to indicate the host on which the port is being bound.
>The setting of this attribute triggers the port binding process.
>
>During port binding, the bind_port() method is called by ML2 on each
>registered mechanism driver until one driver indicates it has succeeded
>by calling PortContext.set_binding(). The driver calls
>PortContext.set_binding()  with the identity of the network segment it
>bound, and the values for the binding:vif_type and binding:vif_details
>attributes. Typical mechanism drivers for L2 agents decide whether they
>can bind the port by looking through the list of network segment for one
>with a network_type value that the agent on the host identified by
>binding:host_id can handle, and if relevant, a physical_network value
>for which that agent has connectivity. The current L2 agent mechanism
>drivers use agents_db info sent from the agents to the service via RPC,
>including the agent's health and the bridge_mappings or
>interface_mappings value that describes its connectivity to
>physical_networks.
>
>The doc strings in neutron.plugins.ml2.driver_api provide more detail on
>port binding and the classes and methods involved.
>
>Hope this helps,

Sure it does, thanks very much Bob.

>
>-Bob
>
>On 1/21/15 9:42 PM, Harish Patil wrote:
>> Hello,
>> I’m a newbie here. Can someone please explain to me as to what exactly
>>is
>> involved in ‘port_binding’ in ML2 mechanism driver and any specific
>> pointers? Is it just an association with its corresponding L2 agent?
>>What
>> is mechanism driver expected to return back to port_bind?
>>
>> Thanks
>>
>> Harish
>>
>>
>>
>>
>> 
>>
>> This message and any attached documents contain information from the
>>sending company or its parent company(s), subsidiaries, divisions or
>>branch offices that may be confidential. If you are not the intended
>>recipient, you may not read, copy, distribute, or use this information.
>>If you have received this transmission in error, please notify the
>>sender immediately by reply e-mail and then delete this 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 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
>





This message and any attached documents contain information from the sending 
company or its parent company(s), subsidiaries, divisions or branch offices 
that may be confidential. If you are not the intended recipient, you may not 
read, copy, distribute, or use this information. If you have received this 
transmission in error, please notify the sender immediately by reply e-mail and 
then delete this 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