[openstack-dev] [Horizon] Horizon takes twice amount of time to upload a image into Glance if configured backend is Swift

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

2015-01-22 Thread Martin Geisler
Radomir Dopieralski openst...@sheep.art.pl 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


Re: [openstack-dev] [all] All rights reserved V.S. Apache license

2015-01-22 Thread Thierry Carrez
Joe Gordon wrote:
 On Mon, Jan 19, 2015 at 2:32 PM, ZhiQiang Fan aji.zq...@gmail.com
 mailto:aji.zq...@gmail.com 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

2015-01-22 Thread Gary Kotton
+1

On 1/22/15, 2:18 AM, Akihiro Motoki amot...@gmail.com wrote:

+1 for Doug

2015-01-20 13:59 GMT+09:00 Aaron Rosen aaronoro...@gmail.com:
 +1

 On Fri, Jan 16, 2015 at 12:03 PM, Carl Baldwin c...@ecbaldwin.net
wrote:

 +1

 On Thu, Jan 15, 2015 at 3:31 PM, Kyle Mestery mest...@mestery.com
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.txtd=AwICAgc=Sqcl0Ez6M0X8aeM6
7LKIiDJAXVeAw-YihVMNtXt-uEsr=VlZxHpZBmzzkWT5jqz9JYBk8YTeq9N3-diTlNj4GyN
cm=wnB98q7iZ33MRx4YfBbDiqXhNykzwMe8k-kvd6hF_wss=5UaM_DNnTPV9ccACNgWx0n
vfNRPXZcjxWjQqIlAtgYse=
 
 
  

__
  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 amot...@gmail.com

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


__
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

2015-01-22 Thread 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
teng...@linux.vnet.ibm.com 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
 teng...@linux.vnet.ibm.com 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] [Fuel] 10Gbe performance issue.

2015-01-22 Thread 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.

2015-01-22 Thread 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” automaticallyapp:ds: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” 
automaticallyapp:ds: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] [Fuel] Cluster replaced deployment of provisioning information

2015-01-22 Thread 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] [neutron][ml2][sqlalchemy] Database table does not exists error

2015-01-22 Thread 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/

2015-01-22 Thread 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


[openstack-dev] [neutron][ml2][sqlalchemy] Database table does not exists error

2015-01-22 Thread 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.

2015-01-22 Thread 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 liuxin...@huawei.com 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] [nova] Adding new features to Kilo and future releases - DB upgrades

2015-01-22 Thread 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/

2015-01-22 Thread 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] [neutron][devstack][keystone] Devstack failures due to empty service catalogue

2015-01-22 Thread 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 integer]
 
 2015-01-22 14:34:11.096 | [--prefix
 PREFIX] --type service-type
 
 2015-01-22 14:34:11.096 | [--description
 service-description]
 
 2015-01-22 14:34:11.097 | service-name
 
 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


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

2015-01-22 Thread 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/

2015-01-22 Thread Martin Geisler
Matthias Runge mru...@redhat.com 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

2015-01-22 Thread 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] [neutron] iptables routes are not being injected to router namespace

2015-01-22 Thread 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 brian.ha...@hp.com
 mailto:brian.ha...@hp.com 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


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

2015-01-22 Thread 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] [stable][neutron] backports vs. vendor decomposition

2015-01-22 Thread 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 ihrac...@redhat.com 
mailto:ihrac...@redhat.com 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] [Nova][Neutron] Thoughts on the nova-neutron interface

2015-01-22 Thread 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


[openstack-dev] [oslo] [nova] [all] potential enginefacade adjustment - can everyone live with this?

2015-01-22 Thread 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

2015-01-22 Thread 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 vkuk...@mirantis.com
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 xar...@gmail.com 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
 sgolovat...@mirantis.com 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 http://www.mirantis.ru/
 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 http://www.mirantis.ru/
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

2015-01-22 Thread 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 xar...@gmail.com 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
 sgolovat...@mirantis.com 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 http://www.mirantis.ru/
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] [Keystone] Nominating Brad Topol for Keystone-Spec core

2015-01-22 Thread 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?

2015-01-22 Thread 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-name, 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


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

2015-01-22 Thread 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 brian.ha...@hp.com
 mailto:brian.ha...@hp.com 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 brian.ha...@hp.com 
 mailto:brian.ha...@hp.com
  mailto:brian.ha...@hp.com mailto:brian.ha...@hp.com 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://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 

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

2015-01-22 Thread 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 brian.ha...@hp.com wrote:
 On 01/21/2015 02:29 PM, Xavier León wrote:
 On Tue, Jan 20, 2015 at 10:32 PM, Brian Haley brian.ha...@hp.com 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.
 snip
 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


Re: [openstack-dev] [neutron][vpnaas] Can we require kernel 3.8+ for use with StrongSwan IPSec VPN for Kilo?

2015-01-22 Thread Kyle Mestery
On Wed, Jan 21, 2015 at 10:27 AM, Ihar Hrachyshka ihrac...@redhat.com
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


Re: [openstack-dev] [stable][neutron] backports vs. vendor decomposition

2015-01-22 Thread 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 ihrac...@redhat.com 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 (not for usage questions)
Unsubscribe: 

[openstack-dev] Wrong Status at the Dashboard - Juno Horizon

2015-01-22 Thread 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


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

2015-01-22 Thread 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 kevin.mitch...@rackspace.com
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] oslo_log/oslo_config initialization

2015-01-22 Thread 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

2015-01-22 Thread Huang Zhiteng
+1

Welcome to the team Ivan!

On Fri, Jan 23, 2015 at 1:23 AM, Walter A. Boring IV
walter.bor...@hp.com 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 thin...@gmail.com 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] [Ironic] RAID interface - backing disk hints

2015-01-22 Thread 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 tim.b...@cern.ch 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 j...@jimrollenhagen.com
 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

2015-01-22 Thread 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


[openstack-dev] penstack Heat- OS::Heat::MultipartMime cannot be used as user_data for OS::Nova::Server

2015-01-22 Thread 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


Re: [openstack-dev] Wrong Status at the Dashboard - Juno Horizon

2015-01-22 Thread 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] [Nova][Neutron] Thoughts on the nova-neutron interface

2015-01-22 Thread Salvatore Orlando
On 22 January 2015 at 17:09, Sean Dague s...@dague.net 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


[openstack-dev] [Glance] New Glance Drivers.

2015-01-22 Thread 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] [Nova][Neutron] Thoughts on the nova-neutron interface

2015-01-22 Thread 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 akilesh1...@gmail.com 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 s...@dague.net 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] [Cinder][3rd CI] Confused about “*real* storage backend”requirement for 3rd CI.

2015-01-22 Thread 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 liuxin...@huawei.com 
mailto:liuxin...@huawei.com 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://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?

2015-01-22 Thread 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 mest...@mestery.com wrote:

 On Wed, Jan 21, 2015 at 10:27 AM, Ihar Hrachyshka ihrac...@redhat.com
 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] [horizon] static files handling, bower/

2015-01-22 Thread 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


[openstack-dev] [cinder] Change reset-state to involve the driver

2015-01-22 Thread 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] [neutron] iptables routes are not being injected to router namespace

2015-01-22 Thread 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 brian.ha...@hp.com 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 brian.ha...@hp.com
  mailto:brian.ha...@hp.com 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


[openstack-dev] [Telco][NFV] Meeting summary and logs - 2015-01-21

2015-01-22 Thread 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] [neutron] Changes to the core team

2015-01-22 Thread 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 mest...@mestery.com
 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


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

2015-01-22 Thread 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 brian.ha...@hp.com wrote:
 On 01/21/2015 02:29 PM, Xavier León wrote:
 On Tue, Jan 20, 2015 at 10:32 PM, Brian Haley brian.ha...@hp.com 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.
 snip
 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


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

2015-01-22 Thread 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 mru...@redhat.com 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] Changes to the core team

2015-01-22 Thread Kyle Mestery
On Thu, Jan 15, 2015 at 4:31 PM, Kyle Mestery mest...@mestery.com 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] [Fuel] Cluster replaced deployment of provisioning information

2015-01-22 Thread 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 dshul...@mirantis.com
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

2015-01-22 Thread 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 brian.ha...@hp.com 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 brian.ha...@hp.com wrote:
  On 01/21/2015 02:29 PM, Xavier León wrote:
  On Tue, Jan 20, 2015 at 10:32 PM, Brian Haley brian.ha...@hp.com
 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.
  snip
  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


 

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

2015-01-22 Thread Richard Jones
On Fri Jan 23 2015 at 4:28:59 AM Matthew Farina m...@mattfarina.com 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] Changes to Cinder Core

2015-01-22 Thread 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 thin...@gmail.com 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/

2015-01-22 Thread 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 m...@mattfarina.com
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 mru...@redhat.com 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?

2015-01-22 Thread 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,


snip





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

2015-01-22 Thread 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 libos...@redhat.com:

 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

2015-01-22 Thread 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 s...@dague.net 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] [horizon] static files handling, bower/

2015-01-22 Thread 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 fu...@yuggoth.org 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/

2015-01-22 Thread 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 r1chardj0...@gmail.com
wrote:

 On Fri Jan 23 2015 at 4:28:59 AM Matthew Farina m...@mattfarina.com
 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

2015-01-22 Thread Victor Lowther
On Thu, Jan 22, 2015 at 1:44 AM, Tim Bell tim.b...@cern.ch 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 j...@jimrollenhagen.com
 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/

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

2015-01-22 Thread 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 blak...@gmail.com 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 mest...@mestery.com wrote:

 On Wed, Jan 21, 2015 at 10:27 AM, Ihar Hrachyshka ihrac...@redhat.com
 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


Re: [openstack-dev] ML2 port binding?

2015-01-22 Thread 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


[openstack-dev] [neutron][lbaas] Object statuses

2015-01-22 Thread 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