Re: [openstack-dev] what code in cinder volume driver supports volume migration between two backends of same type but having different volume types?

2015-01-21 Thread Avishay Traeger
On Mon, Jan 19, 2015 at 8:01 PM, Nikesh Kumar Mahalka 
nikeshmaha...@vedams.com wrote:

 do cinder retype (v2) works for lvm?
 How to use cinder retype?


As far as I remember, LVM doesn't really leverage volume types.  What types
did you define, and what command are you running?


 I tried for volume migration from one volume-type LVM backend to
 another volume-type LVM backend.But its failed.
 How can i acheive this?


It should work.  Please provide the commands you ran, the result, and all
relevant logs.


 Similarly i am writing a cinder volume driver for my array and want to
 migrate volume from one volume type to another volume type for my
 array backends.
 so want to know how can i achieve this in cinder driver?


There are several driver APIs that you can implement.  First, you are most
likely inheriting generic migration/retype from the base driver class.
This works by creating a new volume, and moving data from the original to
the new either using the hypervisor (for an attached volume) or by
attaching  both volumes to a server running cinder-volume and running dd.
Your driver may be able to do more optimized migrations/retypes by
implementing the respective APIs.  The IBM storwize/svc driver implements
both, as do several others - I suggest you look at them for examples.

Thanks,
Avishay


-- 
*Avishay Traeger*
*Storage RD*

Mobile: +972 54 447 1475
E-mail: avis...@stratoscale.com



Web http://www.stratoscale.com/ | Blog http://www.stratoscale.com/blog/
 | Twitter https://twitter.com/Stratoscale | Google+
https://plus.google.com/u/1/b/108421603458396133912/108421603458396133912/posts
 | Linkedin https://www.linkedin.com/company/stratoscale
__
OpenStack Development Mailing 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-21 Thread Matthew Farina
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?


On Wed, Jan 21, 2015 at 3:04 AM, Radomir Dopieralski openst...@sheep.art.pl
 wrote:

 On 20/01/15 20:58, Matthew Farina wrote:
  Radomir, maybe you can help me better understand where this would go. I
  have a few questions.
 
  First, can you point me to a time when horizon used system packages
  successfully for JavaScript libraries? When I looked through the Debian
  and Ubuntu packages I couldn't find the libraries horizon is using. I'm
  curious to see this in action.

 Any distribution (perhaps except Ubuntu, which is a little funny in that
 regard) that has packaged the latest release of OpenStack, has those
 libraries.
 For instance, see

 http://pkgs.fedoraproject.org/cgit/python-django-horizon.git/tree/python-django-horizon.spec#n129


  Front-end systems almost never use system packagers like this. Can you
  point me to applications like horizon that use system packages this way?
  If Horizon is going to go it virtually alone in this space, what will
  that mean for our level of work and ability to have updates?

 Certainly. The XStatic system itself is lifted from MoinMoin wiki, for
 example -- it was created to solve exactly this problem there, and is
 used by a couple of other projects too.

 As for our work and updates, using system-wide packages is an excellent
 solution in this regard, as we get maintenance and updates for free. For
 instance, if there is a security issue in one of the JavaScript
 libraries, we don't need to patch Horizon -- the patch that is prepared
 for that specific library and applied system-wide is sufficient.
 --
 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 Development Mailing 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-21 Thread Duncan Thomas
+1 from me

On 21 January 2015 at 20:16, Mike Perez thin...@gmail.com wrote:

 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




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

2015-01-21 Thread Mike Perez
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.

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


Re: [openstack-dev] [third-party] Third-party CI Documentation sprint, January 21-23

2015-01-21 Thread Kurt Taylor
Just a reminder, the third-party documentation sprint is happening now.
Come help if you can!

Kurt Taylor
(krtaylor)

On Sat, Jan 17, 2015 at 5:29 PM, Kurt Taylor kurt.r.tay...@gmail.com
wrote:

 Hello all,

 The OpenStack Third-party CI working group will be hosting a virtual
 sprint for refreshing and improving the related third-party CI
 documentation. We will meet immediately following the working group weekly
 meeting on January 21st and the sprint will run for 48 hours.

 Where: freenode #openstack-sprint
 When: January 21st-23nd (1600UTC for 48 hours)

 Please join us if you would like to help, even if just for a couple of
 hours. I created a etherpad for the sprint here:
 https://etherpad.openstack.org/p/third-party-ci-documentation

 Having some infra core reviewers available during the sprint would be
 great so we could review and close out the patches as they come in.

 Thanks everyone!
 Kurt Taylor (krtaylor)

__
OpenStack Development Mailing 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] [Heat] query property on heat OS::Ceilometer::Alarm for juno/stable

2015-01-21 Thread Karolyn Chambers


In Kilo, with the bug fix from 1326721, I can create an alarm like the
following with the query property. I use this alarm to monitor the health
of a server instance in the pool. In juno/stable, without the query
property, ceilometer alarms can only be created via heat with matching
metadata. This limits the metrics I can create alarms for, as not every
resource has metadata associated with it. Without this bug fix, I've been
unable to find a way to monitor the health of my server in Juno via heat.
I'd like thoughts on back porting 1326721 back to juno/stable, so this can
be work the same as it does in Kilo
https://review.openstack.org/#/c/146624/ .Thanks

gone_alarm:
type: OS::Ceilometer::Alarm
properties:
  description: Detect server being unresponsive
  repeat_actions: False
  meter_name: network.services.lb.member
  statistic: avg
  period: 600
  evaluation_periods: 1
  threshold: 1
  alarm_actions: [ {get_attr: [restart, AlarmUrl]} ]
  query:
  - field: resource_id
op: eq
value: {get_resource: member}
  comparison_operator: lt

  member:
type: OS::Neutron::PoolMember
properties:
  pool_id: {get_param: pool_id}
  address: {get_attr: [server_node, first_address]}
  protocol_port: { get_param: loadbalance_port }


Karolyn Chambers__
OpenStack Development Mailing 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-21 Thread Matthew Farina
Martin,

django_compressor does handles creating aggregated and compressed files for
you. This isn't quite the same as C programs because it's not just due to
file size. For example, if you have 2 files many browsers will make two
separate connections to get each file. That mean negotiating a connection
(can include tls), and pulling down the file dealing with TCP slow-start.
This means one larger file is faster to download then multiple files that
are smaller in overall size.

To get a 304 Not Modified message you'll need to make sure your web server
is handling that. I've encountered horizon instances where 304 Not Modified
messages aren't happening.

Cheers,
Matt Farina


On Wed, Jan 21, 2015 at 5:40 AM, Martin Geisler mar...@geisler.net wrote:

 Matthias Runge mru...@redhat.com writes:

  On 21/01/15 09:59, Martin Geisler wrote:
 
 
  This seems to imply that users will download at least one .js file
  per dependency.
 
 
  Not necessarily. We still use django-compressor, which copies all
  javascript into fewer files. E.g. here in my untweaked juno
  environment, I just get 3 instead of 10-15 following your logic above.
  (at least one js file per xstatic package).

 Cool, I did not know about this!

 Radomir said that this is run in a post-install hook for Horizon and
 that he's unsure how or if the distros re-run the scripts when the
 dependencies are installed. That is, if an updated version of the js-foo
 package is installed, all apps that depend on js-foo would need to have
 their JS bundles refreshed.

 Or maybe it's simply run every time Horizon is started?

  That's probably acceptable for an application like Horizon which
  users will be using again and again, but for most web applications,
  you don't want your users to download 10-20 small .js files, instead
  you want them to download one minified and compressed file with all
  the JavaScript code needed.
 
  see above :D
 
 
  I'm just mentioning this since it's one way that web apps differ from
  how normal Linux apps are typically deployed. Basically, web apps
  prefer static compilation and discourages dynamic linking.
 
  I'm not sure, I can really follow you here.

 I was trying to draw a parallel to how traditional (C) programs use
 dynamic when loading -- perfect for distributions since this allows them
 to patch a security problem just once and know that all programs that
 use the affected library will get the update since they dynamically load
 the library at runtime.

 Contrast this with static linking -- which is normally discouraged or
 forbidden by distributions since you'll have to recompile all dependant
 programs when you patch a library.

 I was thinking that web apps look like statically linked programs when
 they're deployed using compressed and minified sources for maximum
 performance.

 Let me add that this kind of optimization matters the most if your
 visitors who only visit the app once or rarely. With a file per
 dependency, they'll get poor performance since their browser won't have
 cached the files.

 For an app like Horizon it might not be as important: even if it loads a
 little slow on your first visit, you're likely to visit it many times as
 you admin your deployment and those subsequent visits will be faster.
 Still not as fast as they would be if the server could reply with a
 single 304 Not Modified, but probably fast enough.

 --
 Martin Geisler

 http://google.com/+MartinGeisler

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

2015-01-21 Thread Mike Perez
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


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

2015-01-21 Thread Joe Gordon
On Mon, Jan 19, 2015 at 2:32 PM, ZhiQiang Fan aji.zq...@gmail.com wrote:

 @Stefano Maffulli

 Yes, the main point is the conflict of reserved all, and abandon some
 (actually most).

 According to the order the last will take effect IIUC Monty Taylor's
 explaination.

 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.



 On Mon, Jan 19, 2015 at 6:53 AM, Stefano Maffulli stef...@openstack.org
 wrote:

 On Sat, 2015-01-17 at 16:07 -0500, Monty Taylor wrote:
  It's actually a set of words that is no longer necessary as of the year
  2000. It's not communicating anything about a granted license, which is
  what the Apache License does - it's actually just asserting that the
  original copyright holder asserts that they have not waived any of their
  rights as a copyright holder. However, the Berne convention grants this
  automatically without a positive assertion.

 I think ZhiQiang Fan's question is about the sentence all rights
 reserved followed by the implicit some rights not reserved granted by
 the Apache license, rather than the meaning of 'all rights reserved'
 alone. You're right that such sentence by itself is meaningless but in
 the context of the Apache license I think it's confusing at best,
 probably wrong.

 I don't remember seeing this case discussed on legal-discuss and I'm
 quite sure that the right way to apply the Apache license to source code
 is *not* by saying (C) `date +%Y` Foo Corp, All Rights Reserved
 followed by Apache license (see appendix on
 http://www.apache.org/licenses/LICENSE-2.0)

 Maybe a passage on legal-discuss would be better?

 /stef


 __
 OpenStack Development Mailing 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] [neutron] iptables routes are not being injected to router namespace

2015-01-21 Thread Xavier León
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.

 From inside the instance, we try to get some information from the
 metadata service with curl:

 $ curl http://169.254.169.254
 curl: (7) couldn't connect to host

 With the same set up in juno, there was no such problem and
 metadata information is shown.

 The request is not filtered at the instance and hits the router
 namespace (checked with tcpdump). However, when looking
 from the controller at the iptables rules at the router, they appear
 empty.

 stack@devstack: ~$ sudo ip netns exec
 qrouter-d4ec737a-c5fb-4f5b-8bd0-1b5353bbade3 iptables-save
 snip

 # Generated by iptables-save v1.4.21 on Tue Jan 20 14:05:48 2015
 *filter
 :INPUT ACCEPT [5:914]
 :FORWARD ACCEPT [0:0]
 :OUTPUT ACCEPT [10:868]
 COMMIT

 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.

Cheers,
Xavi


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

2015-01-21 Thread Avishay Traeger
+1

On Wed, Jan 21, 2015 at 7:16 PM, Mike Perez thin...@gmail.com wrote:

 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




-- 
*Avishay Traeger*
*Storage RD*

Mobile: +972 54 447 1475
E-mail: avis...@stratoscale.com



Web http://www.stratoscale.com/ | Blog http://www.stratoscale.com/blog/
 | Twitter https://twitter.com/Stratoscale | Google+
https://plus.google.com/u/1/b/108421603458396133912/108421603458396133912/posts
 | Linkedin https://www.linkedin.com/company/stratoscale
__
OpenStack Development Mailing 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-21 Thread Davanum Srinivas
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.

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

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

2015-01-21 Thread Qiming Teng
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


Re: [openstack-dev] [Fuel] 10Gbe performance issue.

2015-01-21 Thread Rick Jones

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


Re: [openstack-dev] [neutron][lbaas] Health Monitor association with pool

2015-01-21 Thread Brandon Logan
Thanks for your quick work on this Anne!

On Tue, 2015-01-20 at 15:54 -0600, Anne Gentle wrote:
 
 
 On Tue, Jan 20, 2015 at 12:49 PM, Brandon Logan
 brandon.lo...@rackspace.com wrote:
 Hmm that is for lbaas v2 docs which shouldn't be in the docs
 yet because
 it is not ready.  We will need to file a bug with the docs
 team to get
 the v1 docs back in until v2 is ready to be used (which should
 be
 relatively soon).  Thanks for letting us know!
 
 
 Hi all,
 
 
 I've fixed the logged
 bug: https://bugs.launchpad.net/openstack-manuals/+bug/1412944
 
 
 Longer explanation, the referenced link [1] is to a source document
 that is going to openstack-attic as soon as the infra team does their
 scheduled gerrit downtime. [2] Also, since our build jobs don't delete
 old files, I had to manually delete the outdated docs. Once this spec
 is complete this particular issue won't happen any more. [3] 
 
 
 
 Thanks,
 Anne
 
 
 1. http://docs.openstack.org/api/openstack-network/2.0/content/lbaas_ext.html
 2. https://review.openstack.org/#/c/145289/
 3. 
 http://specs.openstack.org/openstack-infra/infra-specs/specs/doc-publishing.html
 
 
  
 
 Thanks,
 Brandon
 
 On Tue, 2015-01-20 at 12:03 +0530, Shreshtha Joshi wrote:
  Hi,
 
 
  The openstack documentation for LBaaS Neutron v2 APIs does
 not clearly
  define way to associate a HealthMonitor with a pool.
* Will it be done via pool update - put method at
  /v2.0/pools/{pool_id}.
* Or it will be done via post method at
  /v2.0/lb/pools/{pool_id}/health_monitors
  Any other link detailing LBaaS v2 APIs will be great help.
  Thanks in advance.
 
 
  Regards
  Shreshtha Joshi
 
 
  =-=-=
  Notice: The information contained in this e-mail
  message and/or attachments to it may contain
  confidential or privileged information. If you are
  not the intended recipient, any dissemination, use,
  review, distribution, printing or copying of the
  information contained in this e-mail message
  and/or attachments to it are strictly prohibited. If
  you have received this communication in error,
  please notify us by reply e-mail or telephone and
  immediately and permanently delete the message
  and any attachments. Thank you
 
 
 
 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe:
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 
 
 -- 
 Anne Gentle
 annegen...@justwriteclick.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] [cinder] Request for clarification regarding deadline for new drivers in Kilo

2015-01-21 Thread Mike Perez
On 11:24 Wed 21 Jan , Eduard Matei wrote:
 Hi,
 
 This weekend our driver [https://review.openstack.org/#/c/130733/] got a -2
 stating that This is past the deadline for release of new drivers in
 Kilo. and the deadline for new drivers passed at the end of Kilo-1. This
 needs to wait for the L release.
 
 But, in another mail on the mailing list we were informed:
 
 If your driver is submitted *LATE* in k-1, and meets *all* the items above,
 but isn't merged, it will be still be considered for merge in k-2 or k-3.
 
 The items above being that the blueprint is submitted, together with cert
 tests and the code is submitted to gerrit and that a CI is working.
 
 We had the blueprint, cert tests and code on gerrit *EARLY* in k-1 (first
 patchset was on Oct 24), blueprint was approved for k-1 and cert tests were
 posted.
 CI is under construction, and will be ready by March deadline.
 
 
 So, can someone from cinder core clarify why the driver is delayed to L
 when all items are met?

Would like to take this off the list. I replied to your review.

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


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

2015-01-21 Thread Ihar Hrachyshka

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).




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 http://irc.freenode.com)
Twitter... @pmichali



__
OpenStack Development Mailing 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] [trove] Confused about nova_proxy_admin_* settings

2015-01-21 Thread Nikhil Manchanda
Hi Mark:

It's been a little while since I looked at this last, but as I recall these
values seem
to be used and needed only by the trove taskmanager. If you have support
for
metering messages turned on, this account gets used to look up instance
details
when sending periodic metering messages to an AMQP exchange.

These aren't needed on the guest-agent, and that's probably the reason why a
non-existing value of radmin seems to work. The fact that this exists in
the guest
configuration as well is probably a bug and should be cleaned up.

Cheers,
Nikhil


On Tue, Jan 20, 2015 at 4:05 PM, Mark Kirkwood 
mark.kirkw...@catalyst.net.nz wrote:

 I've been looking at how the 3 nova_proxy_admin_* settings are used. I'm
 coming to the conclusion that I'm confused:

 E.g I note that a standard devstack (stable/juno branch) with trove
 enabled sets these as follows:

 nova_proxy_admin_pass =
 nova_proxy_admin_tenant_name = trove
 nova_proxy_admin_user = radmin


 However there is no 'radmin' user (or role) created in keystone, so the
 settings above cannot possibly work (if they were needed/used). Some
 experimentation involving removing these three settings from all of the
 trove config files seems to support the idea that they are in fact not
 needed, which has me somewhat puzzled.

 If someone could shed some light here that would be awesome!

 Thanks

 Mark


 __
 OpenStack Development Mailing 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] [neutron][devstack][keystone] Devstack failures due to empty service catalogue

2015-01-21 Thread Sukhdev Kapur
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


Re: [openstack-dev] [Fuel]When will fuel support centos 7?

2015-01-21 Thread Andrew Woodward
approc,

It's awesome to see the interest in getting CentOS 7.0 support. As
Sergii noted, the Mirantis  team doesn't have enough bandwidth to
certify CentOS 7.0 for Fuel 6.1 however I would love to help you get
started with some of this.

The barriers to moving between versions usually are:
a) major changes between releases. In this case the biggest issue will
be systemd
b) changes in the way configured packages behave due to version bumps
c) poorly behaving or performing packages

with regards to a, and b. they usually can be addressed in the
fuel-library manifests, c usually requires packages to be re-built.
I'd encourage you to look at issues from a,b.

how to start:

the most hacker way would be to goto the fuel-main repo and make an
iso with an CentOS 7 mirror

poking though the Makefile and configure.mk, it appears that you
should be able to overwrite MIRROR_CENTOS and MIRROR_CENTOS_KERNEL to
a public EL7 repo and it should start pulling what you need.

You may need to update requiremes-rpm.txt to match packages that might
have moved versions / names from EL6 to EL7

Please feel free to reach out to me on irc (xarses), via the ML or
directly if you need assistance.

On Fri, Jan 16, 2015 at 12:44 PM, Sergii Golovatiuk
sgolovat...@mirantis.com wrote:
 Hi,

 Frankly speaking, Fuel team cares about stability and production readiness.
 That requires a lot of testing, some modification to the packages before
 releasing Fuel with CentOS 7 support. At the moment Fuel Team is focusing on
 Ubuntu 14.04 as it's targeted to 6.1. CentOS 7.0 is targeted to Fuel 7.0.

 --
 Best regards,
 Sergii Golovatiuk,
 Skype #golserge
 IRC #holser

 On Fri, Jan 16, 2015 at 9:04 AM, me,apporc appleorchard2...@gmail.com
 wrote:

 So what's the difficulty of supporting centos ?
 If i want to help to make it happen, do you have some advice?


 On Thu Jan 15 2015 at 8:33:20 PM Mike Scherbakov
 mscherba...@mirantis.com wrote:

 CentOS 7 is not considered as essential / critical priority blueprint for
 Fuel 6.1. There is a plan to support new version of CentOS, and I know some
 folks started a research/move in this direction in some areas, such as
 l23network puppet module for instance.

 It would be great to see help to make it happen in Fuel 7.0, if not in
 6.1.

 On Thu, Jan 15, 2015 at 3:22 PM, Igor Kalnitsky ikalnit...@mirantis.com
 wrote:

 Hi,

 Yes, we do have a plan for CentOS 7, but as far as I know it was
 postponed to MOS 7.0. That means we will not have Cent OS 7 in
 upcoming release.

 - Igor

 On Thu, Jan 15, 2015 at 1:16 PM, me,apporc appleorchard2...@gmail.com
 wrote:
  Hi,
 
  Do we have plan for centos 7 ?
 
 
 
  Regards,
 
  apporc
 
 
 
  __
  OpenStack Development Mailing 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




 --
 Mike Scherbakov
 #mihgen


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


 __
 OpenStack Development Mailing 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


[openstack-dev] New API guideline accepted for Collection Resources

2015-01-21 Thread Everett Toews
I’d like to announce that a new API guideline has been accepted for Collection 
Resources.

http://specs.openstack.org/openstack/api-wg/guidelines/representation_structure.html#collection-resources

JSON request and response representations for collection resources should be 
an object that includes a top-level property to encapsulate the collection of 
resources. The value of this property should be a JSON array whose elements are 
the JSON representations of the resources in the collection…”

The patch that introduced the API guideline is here

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

If you are creating a new API or a new version of an API, we encourage you to 
follow this guideline for Collection Resources. If you have such a patch coming 
up for review, you can use the APIImpact (as discussed in GitCommitMessages 
[1]) for better discoverability.

Thanks,
Everett

[1] 
https://wiki.openstack.org/wiki/GitCommitMessages#Including_external_references


__
OpenStack Development Mailing 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] [stable][neutron] backports vs. vendor decomposition

2015-01-21 Thread Ihar Hrachyshka

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


Re: [openstack-dev] [Ironic] RAID interface - backing disk hints

2015-01-21 Thread Victor Lowther
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:
 Hi All,

 I would like to hear everyone's thoughts and probably reach a conclusion of
 whether be open to include more criteria or not.

 I think these filters make sense. An operator may want to say RAID all
 disks of this model; that's completely reasonable.

It is?  Do you know any operators who have actually done that in
production?  I have never heard of it. In my experience, operators
only care about hard drive mfgr/model/firmware rev for actuarial
reasons, not when building and rebuilding arrays.  When it comes to
creating arrays and rebuilding them, what matters more is media type,
interface type and speed, size, slot#, and spindle speed.  More to the
point, the exact make/model/firmware rev of disks in the system will
change over its lifetime as drives fail and get replaced -- the
default drive replacement policy at Dell (and, I would expect, most
server vendors) is that you get a compatible replacement with the same
or better specs, and getting a drive of the same model from the same
manufacturer with the same firmware rev is not guaranteed -- if you
ask and if any are in stock, it might happen, but when I did support
most people just did not care as long as the replacement was there
within 4 hours.

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#.

 We've already decided we want to implement the same filters for deciding
 which disk to put the root on[0], and so we'll need to write this code
 for most/all drivers anyway. We can simply re-use this code for the RAID
 use case.

Not really -- there is no expectation that the operating system can
see the mfgr/make/firmware of the physical disks that make up a
virtual disk.  What you see instead from the OS side is made up by the
RAID controller (and if you are lucky it will be the same value as
what you see from whatever you are using to manage the RAID array, but
there is no expectation that it works that way), and assuming it
reflects the physical disks making up the array is just wrong.  To
make things even more interesting, you cannot even assume that the
interface you will use to create the virtual disk will return a unique
identifier for that virtual disk that corresponds to anything you will
see on the OS side -- that is an issue that we are having to work
around for the RAID interfaces that the DRAC exposes.  Sad to say, the
only real thing you can count on for picking the right raid volume for
a root device knowing what size it should be (or) always creating the
virtual disk for the root array first, choosing /dev/sda and hoping
your RAID controller exposes devices in the order in which they were
created.

If you are not using RAID then using mfgr/model/firmware/serial#
composed together to make a unique identifier makes sense.  If you are
using RAID it does not because there is no expectation that
information is exposed to the OS at all.

 // jim

 [0] 
 http://specs.openstack.org/openstack/ironic-specs/specs/kilo/root-device-hints.html


 Please pour in your thoughts on the thread

 Regards,
 Ramakrishnan (irc: rameshg87)

 __
 OpenStack Development Mailing 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] [neutron] iptables routes are not being injected to router namespace

2015-01-21 Thread Brian Haley
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] multi-queue virtio-net interface

2015-01-21 Thread Steve Gordon
- Original Message -
 From: Rajagopalan Sivaramakrishnan r...@juniper.net
 To: openstack-dev@lists.openstack.org
 
 Hello,
 We are hitting a performance bottleneck in the Contrail network
 virtualization solution due to the virtio interface having a single
 queue in VMs spawned using Openstack. There seems to be a blueprint to
 address this by enabling multi-queue virtio-net at
 
 https://blueprints.launchpad.net/nova/+spec/libvirt-virtio-net-multiqueue
 
 It is not clear what the current status of this project is. We would be happy
 to contribute towards this effort if required. Could somebody please let us
 know what the next steps should be to get this into an upcoming release?
 
 Thanks,
 
 Raja

The specification is up for review here:

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

There is an associated Feature Freeze Exception (FFE) email for this proposal 
here which would need to be approved for this to be included in Kilo:

http://lists.openstack.org/pipermail/openstack-dev/2015-January/054263.html

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] [all] Cross-project DevRef Was Re: Skipping Cross-Project meeting today

2015-01-21 Thread Nikhil Komawar
From Glance' point of view: We can start off with the modifications needed on 
top of the existing one(s). Prepare a Glance specific doc to share in a Cross 
Project meeting.

Thanks,
-Nikhil


From: Ian Cordasco [ian.corda...@rackspace.com]
Sent: Wednesday, January 21, 2015 3:27 PM
To: jsbry...@electronicjungle.net; OpenStack Development Mailing List (not for 
usage questions)
Subject: Re: [openstack-dev] [all] Cross-project DevRef Was Re: Skipping 
Cross-Project meeting today

On 1/20/15, 21:21, Jay Bryant jsbry...@electronicjungle.net wrote:

+2  This topic had come up in Cinder I believe as well.
Having a common devref for common content would be good and would make it
easier to keep the documentation current.

Jay
On Jan 20, 2015 4:05 PM, Jay Pipes jaypi...@gmail.com wrote:

On 01/20/2015 01:30 PM, Ian Cordasco wrote:
On Jan 20, 2015, at 05:23, Thierry Carrez thie...@openstack.org
wrote:

Hi everyone,

Given that the agenda docket is pretty slim this week, I'd like to
skip this cross-project meeting and have the next one on Jan 27.

sigmavirus24 posted the Cross-project DevRef akin to Nova's item
but I'd prefer if we discussed it on the mailing-list first (not
certain it requires everyone's attention just yet, and could just
be proposed as a spec).

Cheers,

-- Thierry Carrez (ttx)

__






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



Hey all,

First, let me provide some context. The week before last, an update
to sqlalchemy-migrate broke glance’s gate. While helping us fix the
problem, Matt Riedemann noticed that the project doesn’t have a
Developer Reference document. The document helps new developers
determine what system packages they need to build a development
environment for the project.

We discussed the idea of putting one together for glance at the team
meeting last week. While discussing it, we realized a lot of the
steps are similar to Nova’s and it might benefit OpenStack as a whole
to have one common DevRef that links off to individual ones for
further configuration. The list of common steps could be maintained
in one place (rather than synchronized between projects) and then
individual extensions would be maintained with in each project or
wiki.

Before we started duplicating content in our own document, we wanted
to present the idea to the cross-project team and the community as a
whole.

Feedback is greatly appreciated, Ian



I think a common shared developer reference is a great idea, Ian. ++

-jay

__
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


Since no one has expressed distaste for this idea. What’s the best way to
move forward? I genuinely have no idea what the right next step is and
would appreciate some guidance here.

Cheers,
Ian (sigmavirus24)

__
OpenStack Development Mailing 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] multi-queue virtio-net interface

2015-01-21 Thread Rajagopalan Sivaramakrishnan
Hello,
We are hitting a performance bottleneck in the Contrail network 
virtualization solution due to the virtio interface having a single queue in 
VMs spawned using Openstack. There seems to be a blueprint to address this by 
enabling multi-queue virtio-net at

https://blueprints.launchpad.net/nova/+spec/libvirt-virtio-net-multiqueue

It is not clear what the current status of this project is. We would be happy 
to contribute towards this effort if required. Could somebody please let us 
know what the next steps should be to get this into an upcoming release?

Thanks,

Raja

__
OpenStack Development Mailing 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] [api] Re: [Neutron][L3] Stop agent scheduling without topping sevices

2015-01-21 Thread Everett Toews
On Jan 9, 2015, at 8:15 AM, Jay Pipes jaypi...@gmail.com wrote:

 Adding [api] topic.
 
 On 01/08/2015 07:47 PM, Kevin Benton wrote:
 Is there another openstack service that allows this so we can make the
 API consistent between the two when this change is made?
 
 Kevin, thank you VERY much for asking the above question and caring about 
 consistency in the APIs!
 
 There was a discussion on the ML about this very area of the APIs, and how 
 there is current inconsistency to resolve:
 
 http://openstack-dev.openstack.narkive.com/UbM1J7dH/horizon-all-status-vs-state
 
 You were involved in that thread, so I know you're very familiar with the 
 problem domain :)
 
 In the above thread, I mentioned that this really was something that the API 
 WG should tackle, and this here ML thread should be a catalyst for getting 
 that done.
 
 What we need is a patch proposed to the openstack/api-wg that proposes some 
 guidelines around the REST API structure for disabling some resource for 
 administrative purposes, with some content that discusses the semantic 
 differences between state and status, and makes recommendations on the 
 naming of resource attributes that indicate an admnistrative state.
 
 Of course, this doesn't really address Jack M's question about whether there 
 should be a separate mode (in Jack's terms) to indicate that some resource 
 can be only manually assigned and not automatically assigned. Personally, I 
 don't feel there is a need for another mode. I think if something has been 
 administratively disabled, that an administrator should still be able to 
 manually alter that thing.
 
 All the best,
 -jay

I did some preliminary analysis of the current design on state vs status.

https://wiki.openstack.org/wiki/API_Working_Group/Current_Design/State_vs_Status

So far it doesn’t get into the semantics but identifies which services use 
state and/or status and counts up how many calls use such a param.

Please feel free to add to the analysis.

Thanks,
Everett
__
OpenStack Development Mailing 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-21 Thread Akihiro Motoki
+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] http://russellbryant.net/openstack-stats/neutron-reviewers-90.txt
 
 
  __
  OpenStack Development Mailing List (not for usage questions)
  Unsubscribe:
  openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 

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



 __
 OpenStack Development Mailing 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-dev] [stable] 2014.2.2 Stable freeze annoucnement

2015-01-21 Thread Chuck Short
Hi All

We will be freezing the stable juno branches next Friday Jun 30 2015. In
order to release on February 6th, 2015. I would like all interested parties
to review current changes and propose new ones as soon as possible so we
can get things ready for release.

If you have any questions please let me know.

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


Re: [openstack-dev] Changes to Cinder Core

2015-01-21 Thread John Griffith
On Wed, Jan 21, 2015 at 12:45 PM, Avishay Traeger avis...@stratoscale.com
wrote:

 +1

 On Wed, Jan 21, 2015 at 7:16 PM, Mike Perez thin...@gmail.com wrote:

 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




 --
 *Avishay Traeger*
 *Storage RD*

 Mobile: +972 54 447 1475
 E-mail: avis...@stratoscale.com



 Web http://www.stratoscale.com/ | Blog
 http://www.stratoscale.com/blog/ | Twitter
 https://twitter.com/Stratoscale | Google+
 https://plus.google.com/u/1/b/108421603458396133912/108421603458396133912/posts
  | Linkedin https://www.linkedin.com/company/stratoscale

 __
 OpenStack Development Mailing 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


Re: [openstack-dev] [neutron] Next week's meeting is cancelled (and some other notes)

2015-01-21 Thread Sridhar Ramaswamy
Lets not forget the reviews from recently split neutron projects where some
of the BPs are targeting K2 as well. Here is a slight modification to
Doug's (head spinning!) URL to include vpn/fw/lb projects,

https://review.openstack.org/#/q/(project:openstack/neutron+OR+project:openstack/neutron-vpnaas+OR+project:openstack/neutron-fwaas+OR+project:neutron-lbaas)+status:open+(topic:bp/wsgi-pecan-switch+OR+topic:bp/plugin-interface-perestroika+OR+topic:bp/reorganize-unit-test-tree+OR+topic:bp/restructure-l2-agent+OR+topic:bp/rootwrap-daemon-mode+OR+topic:bp/retargetable-functional-testing+OR+topic:bp/refactor-iptables-firewall-driver+OR+topic:bp/vsctl-to-ovsdb+OR+topic:bp/lbaas-api-and-objmodel-improvement+OR+topic:bp/restructure-l3-agent+OR+topic:bp/neutron-ovs-dvr-vlan+OR+topic:bp/allow-specific-floating-ip-address+OR+topic:bp/ipset-manager-refactor+OR+topic:bp/agent-child-processes-status+OR+topic:bp/extra-dhcp-opts-ipv4-ipv6+OR+topic:bp/ipsec-strongswan-driver+OR+topic:bp/ofagent-bridge-setup+OR+topic:bp/arp-spoof-patch-ebtables+OR+topic:bp/report-ha-router-master+OR+topic:bp/conntrack-in-security-group+OR+topic:bp/allow-mac-to-be-updated+OR+topic:bp/specify-router-ext-ip+OR+topic:bp/a10-lbaas-v2-driver+OR+topic:bp/brocade-vyatta-fwaas-plugin+OR+topic:bp/netscaler-lbaas-v2-driver+OR+topic:bp/ofagent-sub-driver+OR+topic:bp/ml2-cisco-nexus-mechdriver-providernet+OR+topic:bp/ofagent-flow-based-tunneling+OR+topic:bp/ml2-ovs-portsecurity+OR+topic:bp/fwaas-cisco+OR+topic:bp/freescale-fwaas-plugin+OR+topic:bp/rpc-docs-and-namespace),n,z


- Sridhar

On Mon, Jan 19, 2015 at 1:35 PM, Anita Kuno ante...@anteaya.info wrote:

 On 01/19/2015 01:47 PM, Sean M. Collins wrote:
  Thanks Doug!
 
  It is a big link but I'd rather see the full URL than trust opening a
  URL shortener link. I've been rickrolled too many times to count. :)
 
 I like to add something like:

 label:Code-Review=0,self

 to a URL like this so that after I post a vote to a patch and refresh my
 list, I am only shown patches I haven't yet voted on.

 Nice work Doug,
 Anita.

 __
 OpenStack Development Mailing 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] [trove] Confused about nova_proxy_admin_* settings

2015-01-21 Thread Mark Kirkwood

Thanks Nikhil,

I figured I must have missed something that actually used the proxy - I 
didn't have metering enabled in devstack. I'll enable it and (I guess) 
it should fail until I give it correct proxy admin credentials...


Cheers

Mark

On 22/01/15 05:55, Nikhil Manchanda wrote:

Hi Mark:

It's been a little while since I looked at this last, but as I recall these
values seem
to be used and needed only by the trove taskmanager. If you have support
for
metering messages turned on, this account gets used to look up instance
details
when sending periodic metering messages to an AMQP exchange.

These aren't needed on the guest-agent, and that's probably the reason why a
non-existing value of radmin seems to work. The fact that this exists in
the guest
configuration as well is probably a bug and should be cleaned up.

Cheers,
Nikhil


On Tue, Jan 20, 2015 at 4:05 PM, Mark Kirkwood 
mark.kirkw...@catalyst.net.nz wrote:


I've been looking at how the 3 nova_proxy_admin_* settings are used. I'm
coming to the conclusion that I'm confused:

E.g I note that a standard devstack (stable/juno branch) with trove
enabled sets these as follows:

nova_proxy_admin_pass =
nova_proxy_admin_tenant_name = trove
nova_proxy_admin_user = radmin


However there is no 'radmin' user (or role) created in keystone, so the
settings above cannot possibly work (if they were needed/used). Some
experimentation involving removing these three settings from all of the
trove config files seems to support the idea that they are in fact not
needed, which has me somewhat puzzled.

If someone could shed some light here that would be awesome!

Thanks

Mark


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





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




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


[openstack-dev] [QA] Meeting Thursday Jan 22nd at 22:00 UTC

2015-01-21 Thread GHANSHYAM MANN
Hi everyone,

Just a quick reminder that the weekly OpenStack QA team IRC meeting will be
tomorrow Thursday, Jan 22nd at 22:00 UTC in the #openstack-meeting channel.

The agenda for tomorrow's meeting can be found here:

https://wiki.openstack.org/wiki/Meetings/QATeamMeeting

Anyone is welcome to add an item to the agenda.

To help people figure out what time 22:00 UTC is in other timezones
tomorrow's meeting will be at:

18:00 EDT

07:00 JST

07:30 ACST

0:00 CEST

17:00 CDT

15:00 PDT


-- 
Thanks  Regards
Ghanshyam Mann
__
OpenStack Development Mailing 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] query property on heat OS::Ceilometer::Alarm for juno/stable

2015-01-21 Thread Angus Salkeld
On Thu, Jan 22, 2015 at 5:16 AM, Karolyn Chambers chamb...@us.ibm.com
wrote:

 In Kilo, with the bug fix from 1326721, I can create an alarm like the
 following with the query property. I use this alarm to monitor the health
 of a server instance in the pool. In juno/stable, without the query
 property, ceilometer alarms can only be created via heat with matching
 metadata. This limits the metrics I can create alarms for, as not every
 resource has metadata associated with it. Without this bug fix, I've been
 unable to find a way to monitor the health of my server in Juno via heat. I'd
 like thoughts on back porting 1326721 back to juno/stable, so this can be
 work the same as it does in Kilo https://review.openstack.org/#/c/146624/
 https://review.openstack.org/#/c/146624/ .Thanks


Hi

I appreciate that it is a useful feature for you, but people rely on stable
branches being stable. This is a reasonably big patch (163) for a back port.
So I understand Zane's -1. That said, it is contained within ceilometer
alarm resource and the code now matches master. And the feature has been in
ceilometer for
ages.

I am OK with this going in, if stable branch folk are OK with it. (I'll put
a +1 on the review).

-Angus


 gone_alarm:
type: OS::Ceilometer::Alarm
properties:
  description: Detect server being unresponsive
  repeat_actions: False
  meter_name: network.services.lb.member
  statistic: avg
  period: 600
  evaluation_periods: 1
  threshold: 1
  alarm_actions: [ {get_attr: [restart, AlarmUrl]} ]
  query:
  - field: resource_id
op: eq
value: {get_resource: member}
  comparison_operator: lt

  member:
type: OS::Neutron::PoolMember
properties:
  pool_id: {get_param: pool_id}
  address: {get_attr: [server_node, first_address]}
  protocol_port: { get_param: loadbalance_port }


 Karolyn Chambers

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


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


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

2015-01-21 Thread Andrew Woodward
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


Re: [openstack-dev] [tc][python-clients] More freedom for all python clients

2015-01-21 Thread Robert Collins
On 22 January 2015 at 02:48, Chris Dent chd...@redhat.com wrote:
 On Wed, 21 Jan 2015, Sean Dague wrote:

 On the pip solver side, joe gordon was working on a thing to install a
 fixed set of packages by bypassing the pip resolver... not sure how
 thats progressing.


 I think if we are talking seriously about bypassing the pip resolver, we
 should step back and think about that fact. Because now we're producting
 a custom installation process that will produce an answer for us, which
 is completely different than any answer that anyone else is getting for
 how to get a coherent system.

Actually buildout is precisely that today - you specify exact versions
and get them. pip's inability to duplicate that behaviour is one of
the reasons buildout is still a thing; bypassing the resolver to get
the same behaviour *for the same reasons!* isn't at all odd.
Undesirable perhaps - and we should work on pip upstream too - but not
odd.

 Agreed. Skipping the pip resolver will move OpenStack and friends further
 down into a weird world of its own rather than Python norms.

See above - I disagree. Python norms are -very- broad, and buildout
has a healthy ecosystem within Python web shops, for exactly the
issues we're trying to solve here.

 If possible we should try to resolve the complexity, not bandaid the
 problems caused by the complexity.

 If we can't do that then per service virtualenv (or even containers)
 provides a far more contained[1] bandage.

Per service virtualenvs are good IMO, but orthogonal to the unbounded
thing we have today, which we have largely *because* of pip not having
a resolver. (Thats driven by random things getting upgraded because of
transitive dependencies - caused by the resolver).

 Related: I personally find it completely bewildering that things are
 managed and run in such an unbounded fashion. My intuition is that
 this is the result of many/most projects being on the same release
 cycle and the belief that my master must integrate with your master. We
 should release (far) more often and my master should integrate with your
 lastest release.

Yes, I would like to see that, as a complement to the trunk-trunk
tests. We need to know that something we're about to release won't
break folk as well as knowing that the thing we're about to release
works with the releases of other things that are already out there.

-Rob


-- 
Robert Collins rbtcoll...@hp.com
Distinguished Technologist
HP Converged Cloud

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


Re: [openstack-dev] [all] Cross-project DevRef Was Re: Skipping Cross-Project meeting today

2015-01-21 Thread Anne Gentle
On Wed, Jan 21, 2015 at 2:27 PM, Ian Cordasco ian.corda...@rackspace.com
wrote:



 On 1/20/15, 21:21, Jay Bryant jsbry...@electronicjungle.net wrote:

 +2  This topic had come up in Cinder I believe as well.
 Having a common devref for common content would be good and would make it
 easier to keep the documentation current.
 
 Jay
 On Jan 20, 2015 4:05 PM, Jay Pipes jaypi...@gmail.com wrote:
 
 On 01/20/2015 01:30 PM, Ian Cordasco wrote:
 On Jan 20, 2015, at 05:23, Thierry Carrez thie...@openstack.org
 wrote:
 
 Hi everyone,
 
 Given that the agenda docket is pretty slim this week, I'd like to
 skip this cross-project meeting and have the next one on Jan 27.
 
 sigmavirus24 posted the Cross-project DevRef akin to Nova's item
 but I'd prefer if we discussed it on the mailing-list first (not
 certain it requires everyone's attention just yet, and could just
 be proposed as a spec).
 
 Cheers,
 
 -- Thierry Carrez (ttx)
 
 __
 
 
 
 
 
 
 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
 
 
 
 Hey all,
 
 First, let me provide some context. The week before last, an update
 to sqlalchemy-migrate broke glance’s gate. While helping us fix the
 problem, Matt Riedemann noticed that the project doesn’t have a
 Developer Reference document. The document helps new developers
 determine what system packages they need to build a development
 environment for the project.
 
 We discussed the idea of putting one together for glance at the team
 meeting last week. While discussing it, we realized a lot of the
 steps are similar to Nova’s and it might benefit OpenStack as a whole
 to have one common DevRef that links off to individual ones for
 further configuration. The list of common steps could be maintained
 in one place (rather than synchronized between projects) and then
 individual extensions would be maintained with in each project or
 wiki.
 
 Before we started duplicating content in our own document, we wanted
 to present the idea to the cross-project team and the community as a
 whole.
 
 Feedback is greatly appreciated, Ian
 
 
 
 I think a common shared developer reference is a great idea, Ian. ++
 
 -jay
 
 __
 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


 Since no one has expressed distaste for this idea. What’s the best way to
 move forward? I genuinely have no idea what the right next step is and
 would appreciate some guidance here.


One approach comes to mind. For the Infrastructure User Manual [1] to come
to life, which has a similar readership, they held a quick sprint with
remote work done over IRC and a repo at openstack-infra/infra-manual. [2]
You'll need to recruit a group of reviewers who can review new content as
it comes in. I'd also recommend starting with an outline and assigning
people to certain topics (especially if they've got notes already written).

I'd imagine the outline something like this:

Setting up an OpenStack development environment
-- Considerations for using DevStack
-- Considerations for using system packages
-- Understanding the architecture and components
-- Building the documentation
-- Running unit tests
-- When to use fakes
-- Internal API references
-- REST API references
-- Debugging locally
-- Debugging within continuous integration gate
Configuring a development environment for individual projects
-- processes or policies or debugging or testing or special considerations

Hope this helps -
Anne

1. http://docs.openstack.org/infra/manual/
2. https://git.openstack.org/cgit/openstack-infra/infra-manual


 Cheers,
 Ian (sigmavirus24)

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




-- 
Anne Gentle
annegen...@justwriteclick.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-dev] ML2 port binding?

2015-01-21 Thread Harish Patil
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


Re: [openstack-dev] oslo_log/oslo_config initialization

2015-01-21 Thread Qiming Teng
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


Re: [openstack-dev] [QA] Moving tempest clients to tempest-lib (was Meeting Thursday January 8th at 22:00 UTC)

2015-01-21 Thread Ken'ichi Ohmichi
2015-01-21 12:08 GMT+09:00 Matthew Treinish mtrein...@kortar.org:
 On Wed, Jan 21, 2015 at 11:20:12AM +0900, Ken'ichi Ohmichi wrote:
 Hi David,

 As we told today, I tried Neutron service client migration to tempest-lib.
 but I found some blocking thing for it and I'd like to share it.

 I thought that the base service_client module and neutron service client
 are migrated to tempest-lib without other service clients as the first step.
 For doing that, we need to remove all CONF values from the base
 service_client module and neutron service client. We can remove all CONF
 values from neutron one but cannot do from the base service client before
 removing all CONF values from the other service clients due to:

 https://github.com/openstack/tempest/blob/master/tempest/common/service_client.py#L31

 So we need to remove all CONF values from all service clients before neutron
 service client migration.

 The first thing that I feel we should be migrating before we start handling 
 the
 service clients is the auth/credential code in tempest/auth.py. Right now the
 way tempest-lib is handling the auth layer is by passing in an auth provider 
 as
 an arg, which is fine but the only examples of a working auth provider is in 
 the
 tempest tree, not in the library. This isn't really useful for external
 consumers of tempest-lib. Before we start working on migrating other service
 clients I'd like to have the auth provider layer (and anything that requires)
 migrated into tempest-lib. I don't see much value in having other service
 clients migrated if this isn't sorted first.

I agree.
These works would depend on auth/credential parts, and that is a consensus
of Paris summit[1].
but we can work for these tasks in parallel, and I will work for service client
code cleanup as possible before migrating them to tempest-lib.

Thanks
Ken Ohmichi
---
[1]: https://etherpad.openstack.org/p/kilo-summit-tempest-lib-moving-forward

__
OpenStack Development Mailing 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-21 Thread Joshua Harlow

Another thing that I just started whipping together:

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

The idea for the above is to use pip to download dependencies, but 
figure out what versions will work using our own resolver (and our own 
querying of 'http://pypi.python.org/pypi/%s/json') that just does a very 
deep search of all requirements (and requirements of requirements...).


The idea for that is that the probe() function in that gist will 
'freeze' a single requirement then dive down into further requirements 
and ensure compatibility while that 'diving' (aka, recursion into 
further requirements) is underway. If a incompatibility is found then 
the recursion will back-track and try a to freeze a different version of 
a desired package (and repeat...).


To me this kind of deep finding would be a potential way of making this 
work in a way that basically only uses pip for downloading (and does the 
deep matching/probing) on our own since once the algorithm above doesn't 
backtrack and finds a matching set of requirements that will all work 
together the program can exit (and this set can then be used as the 
master set for openstack; at that point we might have to tell people to 
not use pip, or to only use pip --download to fetch the compatible 
versions).


It's not completed but it could be complementary to what others are 
working on; feel free to hack away :)


So far the following works:

$ cat test.txt
six1
taskflow1

$ python pippin.py  -r test.txt
Initial package set:
- six ['1']
- taskflow ['1']
Traceback (most recent call last):
  File pippin.py, line 168, in module
main()
  File pippin.py, line 162, in main
matches = probe(initial, {})
  File pippin.py, line 139, in probe
result = probe(requirements, gathered)
  File pippin.py, line 129, in probe
m = find_match(pkg_name, req)
  File pippin.py, line 112, in find_match
return match_available(req.req, find_versions(pkg_name))
  File pippin.py, line 108, in match_available
 matches '%s' (tried %s) % (req, looked_in))
__main__.NotFoundException: No requirement found that matches 
'taskflow1' (tried ['0.6.1', '0.6.0', '0.5.0', '0.4.0', '0.3.21', 
'0.2', '0.1.3', '0.1.2', '0.1.1', '0.1'])


I suspect all that is needed to add is the code that is marked with 
FIXME/TODO there and this kind of recursive back-tracking might just do 
the trick...


-Josh

Joe Gordon wrote:



On Fri, Jan 16, 2015 at 12:25 PM, Joe Gordon joe.gord...@gmail.com
mailto:joe.gord...@gmail.com wrote:

We can side step the dependency graphing and ordering issue by
looking at the list of curently installed packages via pip freeze
and not installing dependencies (pip install --no-deps)

After looking into this further here are the known issues:

* Partial capping won't work [0], so we need to pin all
dependencies, we can generate this list per file via pip install
-r and pip freeze, but this doesn't address the issue of apt-get
vs pip install. For example in the stable gate we use suds 0.4.1 but
only suds 0.4.0 is available via pip.
* Not all packages are installed in are standard dsvm-tempest env,
so using pip-freeze from that isn't enough
* We need to run this per requirements file and move to using pip
install --no-deps everywhere. As the global-requirements sync
wouldn't work the first time since files don't list all transient
dependencies yet.
* We can still break if a package version is removed from pypi
* in pip-freeze we sometimes install versions lower then our minimum
version (python-libvirt!)


Exploring a few ideas here: https://review.openstack.org/#/c/147451/4



[0]
http://lists.openstack.org/pipermail/openstack-dev/2015-January/054156.html

On Fri, Jan 16, 2015 at 5:07 AM, Jeremy Stanley fu...@yuggoth.org
mailto:fu...@yuggoth.org wrote:

On 2015-01-15 08:44:58 -0500 (-0500), Sean Dague wrote:
[...]
  The other thing that happened was partial capping doesn't work,
  because something else moves forward and breaks you from below. So
  the patch will need to hit everything at once.

Right, and we _have_ to start using stable branches on all
clients/libraries to backport fixes as part of that. This means that
the stable branch management workflow is about to become pervasive
across some teams who were previously (blissfully?) ignorant of it.

  Unresolved entirely is the tertiary dependencies (not direct
  dependencies of any OpenStack project). That will need another
  mechanism to seed them before any installation happens.
[...]

I won't go so far as to call it intractable, but I took a stab at it
about a year ago and building the dependency graph properly to be
able to do a depth-first ordering is nontrivial (enough that after
about a week hacking on possible solutions I gave up and switched to

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

2015-01-21 Thread Joshua Harlow

A run that shows more of the happy/desired path:

$ cat test.txt
six1
taskflow0.5
$ python pippin.py  -r test.txt
Initial package set:
- six ['1']
- taskflow ['0.5']
Deep package set:
- six ['==1.9.0']
- taskflow ['==0.4.0']

-Josh

Joshua Harlow wrote:

Another thing that I just started whipping together:

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

The idea for the above is to use pip to download dependencies, but
figure out what versions will work using our own resolver (and our own
querying of 'http://pypi.python.org/pypi/%s/json') that just does a very
deep search of all requirements (and requirements of requirements...).

The idea for that is that the probe() function in that gist will
'freeze' a single requirement then dive down into further requirements
and ensure compatibility while that 'diving' (aka, recursion into
further requirements) is underway. If a incompatibility is found then
the recursion will back-track and try a to freeze a different version of
a desired package (and repeat...).

To me this kind of deep finding would be a potential way of making this
work in a way that basically only uses pip for downloading (and does the
deep matching/probing) on our own since once the algorithm above doesn't
backtrack and finds a matching set of requirements that will all work
together the program can exit (and this set can then be used as the
master set for openstack; at that point we might have to tell people to
not use pip, or to only use pip --download to fetch the compatible
versions).

It's not completed but it could be complementary to what others are
working on; feel free to hack away :)

So far the following works:

$ cat test.txt
six1
taskflow1

$ python pippin.py -r test.txt
Initial package set:
- six ['1']
- taskflow ['1']
Traceback (most recent call last):
File pippin.py, line 168, in module
main()
File pippin.py, line 162, in main
matches = probe(initial, {})
File pippin.py, line 139, in probe
result = probe(requirements, gathered)
File pippin.py, line 129, in probe
m = find_match(pkg_name, req)
File pippin.py, line 112, in find_match
return match_available(req.req, find_versions(pkg_name))
File pippin.py, line 108, in match_available
 matches '%s' (tried %s) % (req, looked_in))
__main__.NotFoundException: No requirement found that matches
'taskflow1' (tried ['0.6.1', '0.6.0', '0.5.0', '0.4.0', '0.3.21',
'0.2', '0.1.3', '0.1.2', '0.1.1', '0.1'])

I suspect all that is needed to add is the code that is marked with
FIXME/TODO there and this kind of recursive back-tracking might just do
the trick...

-Josh

Joe Gordon wrote:



On Fri, Jan 16, 2015 at 12:25 PM, Joe Gordon joe.gord...@gmail.com
mailto:joe.gord...@gmail.com wrote:

We can side step the dependency graphing and ordering issue by
looking at the list of curently installed packages via pip freeze
and not installing dependencies (pip install --no-deps)

After looking into this further here are the known issues:

* Partial capping won't work [0], so we need to pin all
dependencies, we can generate this list per file via pip install
-r and pip freeze, but this doesn't address the issue of apt-get
vs pip install. For example in the stable gate we use suds 0.4.1 but
only suds 0.4.0 is available via pip.
* Not all packages are installed in are standard dsvm-tempest env,
so using pip-freeze from that isn't enough
* We need to run this per requirements file and move to using pip
install --no-deps everywhere. As the global-requirements sync
wouldn't work the first time since files don't list all transient
dependencies yet.
* We can still break if a package version is removed from pypi
* in pip-freeze we sometimes install versions lower then our minimum
version (python-libvirt!)


Exploring a few ideas here: https://review.openstack.org/#/c/147451/4



[0]
http://lists.openstack.org/pipermail/openstack-dev/2015-January/054156.html


On Fri, Jan 16, 2015 at 5:07 AM, Jeremy Stanley fu...@yuggoth.org
mailto:fu...@yuggoth.org wrote:

On 2015-01-15 08:44:58 -0500 (-0500), Sean Dague wrote:
[...]
 The other thing that happened was partial capping doesn't work,
 because something else moves forward and breaks you from below. So
 the patch will need to hit everything at once.

Right, and we _have_ to start using stable branches on all
clients/libraries to backport fixes as part of that. This means that
the stable branch management workflow is about to become pervasive
across some teams who were previously (blissfully?) ignorant of it.

 Unresolved entirely is the tertiary dependencies (not direct
 dependencies of any OpenStack project). That will need another
 mechanism to seed them before any installation happens.
[...]

I won't go so far as to call it intractable, but I took a stab at it
about a year ago and building the dependency graph properly to be
able to do a depth-first ordering is nontrivial (enough that after
about a week hacking on possible solutions I gave up and switched to
more productive tasks). The primary 

Re: [openstack-dev] ML2 port binding?

2015-01-21 Thread Robert Kukura

Hi Harish,

Port binding in ML2 is the process by which a mechanism driver (or once
https://blueprints.launchpad.net/openstack/?searchtext=ml2-hierarchical-port-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,

-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


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

2015-01-21 Thread Kevin Benton
One thing that hits the CI I work on is when an incompatible change happens
to one of those libraries but the requirements.txt constraint is not
updated so the latest version does not get installed.
On Jan 21, 2015 7:23 PM, Zhou, Zhenzan zhenzan.z...@intel.com 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] Changes to Cinder Core

2015-01-21 Thread yang, xing
+1




On Jan 21, 2015, at 8:11 PM, John Griffith 
john.griffi...@gmail.commailto:john.griffi...@gmail.com wrote:



On Wed, Jan 21, 2015 at 12:45 PM, Avishay Traeger 
avis...@stratoscale.commailto:avis...@stratoscale.com wrote:
+1

On Wed, Jan 21, 2015 at 7:16 PM, Mike Perez 
thin...@gmail.commailto:thin...@gmail.com wrote:
On Wed, Jan 21, 2015 at 10:14 AM, Mike Perez 
thin...@gmail.commailto: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:unsubscribehttp://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



--
Avishay Traeger
Storage RD

Mobile: +972 54 447 1475
E-mail: avis...@stratoscale.commailto:avis...@stratoscale.com

[http://www.stratoscale.com/wp-content/uploads/Logo-Signature-Stratoscale-230.jpg]


Webhttp://www.stratoscale.com/ | Bloghttp://www.stratoscale.com/blog/ | 
Twitterhttps://twitter.com/Stratoscale | 
Google+https://plus.google.com/u/1/b/108421603458396133912/108421603458396133912/posts
 | Linkedinhttps://www.linkedin.com/company/stratoscale

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://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.orgmailto: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] Changes to Cinder Core

2015-01-21 Thread Jay Bryant
+1

Ivan had been doing a great job!  Will be glad to have him (officially) on
the team!

Jay
On Jan 21, 2015 10:18 AM, Mike Perez thin...@gmail.com wrote:

 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] The constraints from flavor and image metadata

2015-01-21 Thread Tripp, Travis S
JYH,

Are you asking for this to be a blanket rule?  It seems to me that this
could be a case by case basis, but I question making it a blanket rule.

For example, the os_shutdown_timeout property [1] seems very workload
specific. In your proposal, this would mean that the operator would have
to add that property with a max value to every single flavor in order for
it to be taken advantage of, right? Is that really the desired behavior?

Or what about the watchdog behavior (hw_watchdog_action)?  It supports an
enum of possibilities:

disabled,reset,poweroff,
   pause,none²

If the flavor provides a default value what would it even mean for an
image to specify something different?

[1](https://review.openstack.org/#/c/89650/12)


George,

Regarding constraints, you should take a look at this:
http://docs.openstack.org/developer/glance/metadefs-concepts.html

Almost all of the available nova properties with constraint enforcement
can be viewed by getting a current devstack, going into horizon, and
launching the Update Metadata action on flavors / Host Aggregates, or
Images.

-Travis


On 1/17/15, 7:41 AM, George Shuklin george.shuk...@gmail.com wrote:

When I played with metadata, I had have constant feeling it had mess
together few things:

1. H/W requirements for images.
2. Accounting requirements (good CPU for good price, HDD for cheap)
3. Licensing restrictions (run this one only on the hosts with licenses)
4. Administrative management (like 'flavors of tenant X should be run
only on hosts Y')
5. OS information (like inherited metadata on images)

All that together is called 'metadata'. Some metadata have special
meaning in one context (like 'availability_zone' for hosts, or CPU
limitation), some is used by administrator in other context.

All together it looks like pre-datastructure code (if someone remembers
that). No data types, no type restrictions, you can assign letter to
instruction address and pointer to string to float.

Same with current metadata in nova/glance. Raw namespace of key-value
items without any meaningful restriction and specific expression. It
gives flexibility, but cause a huge strain on operators.

I think it needs more expressive representation.

On 01/13/2015 11:39 PM, Jiang, Yunhong wrote:
 Hi,
  There are some discussion and disagreement on the requirement from
flavor and image metadata at nova spec
https://review.openstack.org/#/c/138937/ and I want to get more input
from the community.
  When launch a VM, some requirements may come from image metadata and
flavor. There are a lot of such cases like serial_port_count,
memory_pagesize, hw_numa_nodes, hw:cpu_max_sockets etc. Most of them are
done in nova/virt/hardware.py.

  Both the nova-spec and the current implementation seems agree that if
flavor has the requirement, the image's metadata should not require more
than the flavor requirement.

  However, the disagreement comes when no requirement from flavor, i.e.
only image has the resource requirement. For example, for
serial_port_count, If flavor extra specs is not set, then any image
meta value is permitted. For hw_mem_page_size, it's forbidden if only
image request and no flavor request
(https://github.com/openstack/nova/blob/master/nova/virt/hardware.py#L873
 ), and hw_numa_nodes will fail if both flavor and image metadata are
specified 
(https://github.com/openstack/nova/blob/master/nova/virt/hardware.py#L852
 ).

  As to this nova spec at https://review.openstack.org/#/c/138937/ ,
someone (Don, Malini) think if image requires some feature/resource that
is not specified in flavor, it should be ok, while I think it should be
forbidden.

  I discussed with Jay Pipe on IRC before and he thought if flavor has
no requirement, image requirement should be failed, and I created a bug
at https://bugs.launchpad.net/nova/+bug/1403276 at that time.  But
according to the discussion on this BP, seems this is not always
accepted by others.

  I hope to get feedback from the mailing list on the relationship of
requirement from image/flavor. Possibly we should take different policy
for different resource requirement, but some general rule and the reason
for those rules will be helpful.

  BTW, This topic was sent to the operator ML yesterday by Malini at
   This 
http://lists.openstack.org/pipermail/openstack-operators/2015-January/005
882.html and I raise it here to cover both lists.

 Thanks
 --jyh

 
_
_
 OpenStack Development Mailing 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

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

2015-01-21 Thread Zhou, Zhenzan
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


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

2015-01-21 Thread Joshua Harlow
A slightly better version that starts to go deeper (and downloads 
dependencies of dependencies and extracts there egg_info to get at these 
dependencies...)


https://gist.github.com/harlowja/555ea019aef4e901897b

Output @ http://paste.ubuntu.com/9813919/

When ran on the same 'test.txt' mentioned below...

Happy hacking!

-Josh

Joshua Harlow wrote:

A run that shows more of the happy/desired path:

$ cat test.txt
six1
taskflow0.5
$ python pippin.py -r test.txt
Initial package set:
- six ['1']
- taskflow ['0.5']
Deep package set:
- six ['==1.9.0']
- taskflow ['==0.4.0']

-Josh

Joshua Harlow wrote:

Another thing that I just started whipping together:

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

The idea for the above is to use pip to download dependencies, but
figure out what versions will work using our own resolver (and our own
querying of 'http://pypi.python.org/pypi/%s/json') that just does a very
deep search of all requirements (and requirements of requirements...).

The idea for that is that the probe() function in that gist will
'freeze' a single requirement then dive down into further requirements
and ensure compatibility while that 'diving' (aka, recursion into
further requirements) is underway. If a incompatibility is found then
the recursion will back-track and try a to freeze a different version of
a desired package (and repeat...).

To me this kind of deep finding would be a potential way of making this
work in a way that basically only uses pip for downloading (and does the
deep matching/probing) on our own since once the algorithm above doesn't
backtrack and finds a matching set of requirements that will all work
together the program can exit (and this set can then be used as the
master set for openstack; at that point we might have to tell people to
not use pip, or to only use pip --download to fetch the compatible
versions).

It's not completed but it could be complementary to what others are
working on; feel free to hack away :)

So far the following works:

$ cat test.txt
six1
taskflow1

$ python pippin.py -r test.txt
Initial package set:
- six ['1']
- taskflow ['1']
Traceback (most recent call last):
File pippin.py, line 168, in module
main()
File pippin.py, line 162, in main
matches = probe(initial, {})
File pippin.py, line 139, in probe
result = probe(requirements, gathered)
File pippin.py, line 129, in probe
m = find_match(pkg_name, req)
File pippin.py, line 112, in find_match
return match_available(req.req, find_versions(pkg_name))
File pippin.py, line 108, in match_available
 matches '%s' (tried %s) % (req, looked_in))
__main__.NotFoundException: No requirement found that matches
'taskflow1' (tried ['0.6.1', '0.6.0', '0.5.0', '0.4.0', '0.3.21',
'0.2', '0.1.3', '0.1.2', '0.1.1', '0.1'])

I suspect all that is needed to add is the code that is marked with
FIXME/TODO there and this kind of recursive back-tracking might just do
the trick...

-Josh

Joe Gordon wrote:



On Fri, Jan 16, 2015 at 12:25 PM, Joe Gordon joe.gord...@gmail.com
mailto:joe.gord...@gmail.com wrote:

We can side step the dependency graphing and ordering issue by
looking at the list of curently installed packages via pip freeze
and not installing dependencies (pip install --no-deps)

After looking into this further here are the known issues:

* Partial capping won't work [0], so we need to pin all
dependencies, we can generate this list per file via pip install
-r and pip freeze, but this doesn't address the issue of apt-get
vs pip install. For example in the stable gate we use suds 0.4.1 but
only suds 0.4.0 is available via pip.
* Not all packages are installed in are standard dsvm-tempest env,
so using pip-freeze from that isn't enough
* We need to run this per requirements file and move to using pip
install --no-deps everywhere. As the global-requirements sync
wouldn't work the first time since files don't list all transient
dependencies yet.
* We can still break if a package version is removed from pypi
* in pip-freeze we sometimes install versions lower then our minimum
version (python-libvirt!)


Exploring a few ideas here: https://review.openstack.org/#/c/147451/4



[0]
http://lists.openstack.org/pipermail/openstack-dev/2015-January/054156.html



On Fri, Jan 16, 2015 at 5:07 AM, Jeremy Stanley fu...@yuggoth.org
mailto:fu...@yuggoth.org wrote:

On 2015-01-15 08:44:58 -0500 (-0500), Sean Dague wrote:
[...]
 The other thing that happened was partial capping doesn't work,
 because something else moves forward and breaks you from below. So
 the patch will need to hit everything at once.

Right, and we _have_ to start using stable branches on all
clients/libraries to backport fixes as part of that. This means that
the stable branch management workflow is about to become pervasive
across some teams who were previously (blissfully?) ignorant of it.

 Unresolved entirely is the tertiary dependencies (not direct
 dependencies of any OpenStack project). That will need another
 mechanism to seed them 

Re: [openstack-dev] [Ironic] RAID interface - backing disk hints

2015-01-21 Thread Tim Bell
 -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.



__
OpenStack Development Mailing 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][Horizon] User self registration and management

2015-01-21 Thread Brad Pokorny
Thanks for the info, David.

Yes, it sounds like the VO roles code would be useful for us to authorize
the user to a project, which would simplify things for us to not have to
make an explicit call from a script to add the role for the user.

On 1/20/15, 10:54 AM, David Chadwick d.w.chadw...@kent.ac.uk wrote:

Hi Brad

in your scenario the users are already registered - in your corporate
LDAP. So this is not too dissimilar to the federation case, where the
users are already registered in a remote IDP.

You get the user to present his LDAP credentials, which are validated by
LDAP.
Federation gets the user to enter his IDP credentials, which are
validated by the IDP.

Once either of these are done, you now have a valid authenticated user
who you can give a keystone token to.

So the next thing you need to decide, is what is this user authorised to
do, which is what our VO roles code does. I therefore see that our VO
roles code can work perfectly well with your LDAP authn code.

regards

David

On 20/01/2015 17:43, Brad Pokorny wrote:
 At Symantec, we provide a simple signup button on the Horizon login page
 for self registration.  Our goal is to not only make it easy for the
user
 to register but to also set up some basic things to make it easy for
them
 to start using OpenStack services.  We don't use federated Keystone, so
 users have to go through the registration to access OpenStack services,
 but they can then manage their user accounts via existing corporate
 management tools.  Having the signup button on the Horizon login page
 unifies the experience of working with OpenStack - to sign up, they go
to
 Horizon, and then they log in to Horizon after signup.

 In our case the users are already in the corporate LDAP, so the user
 clicks the signup button and is redirected to a page to enter their LDAP
 credentials.  A script behind the page validates the LDAP username and
 password and sets up the user with their own project and a network for
the
 project (with quota restrictions on the project).

 So we enable self registration and also set a few extra things up to
make
 it easy for users to start doing real work.

 Regards,
 Brad


 On 1/19/15, 10:03 AM, David Chadwick d.w.chadw...@kent.ac.uk wrote:

 Hi Enrique

 You are right in that we have been addressing different problems. There
 are three aspects to managing users: registration, assigning
 authentication credentials, and assigning authorisation credentials.
You
 appear to be primarily concerned with the first two. I have only
 concentrated on the latter, assuming that the users have already been
 registered somewhere (with an identity provider) and already have their
 authn tokens. In a federated infrastructure the authn and authz are
 split between the IdP and SP, so I have only concentrated on the authz
 aspects, assuming the authn is already sorted out.

 If you are interested in a centralised Keystone system, there is no
need
 to split the functionality up, as Keystone can register users, assigns
 their passwords and their roles. The only place our work would overlap
 with yours, is in the assignment of roles to users. Our solution,
though
 designed for a federated keystone, can equally well be used with a
 centralised keystone, since once the user is authenticated, he can then
 request to join a VO role regardless of who authenticated him (and we
 have demonstrated that local login works just as well as federated
login
 in our prototype). So you may wish to use our work, once you have
sorted
 out user registration and the assignment of authn credentials

 regards

 David


 On 19/01/2015 15:15, Enrique Garcia wrote:
 Hi everyone,

 Enrique, if you have a github repo or some project pages you can
 point
 me to that would be wonderful. I'm currently in the very early
 stages of
 our proof of concept/prototype, so it would be great to see some
 work
 others have done to solve similar issues. If I can find something
 that
 works for a few of our use cases it might be a better starting
 point or
 good to see what an approach others might find useful is.
 I'd much rather not duplicate work, nor build something only
useful
 for
 our use cases, so collaboration towards a community variant would
be
 ideal.


 ​Adrian, first of all we are currently working in this functionality
so
 we don't have a final version yet, that's why we are also interested
in
 joining efforts and collaborate in a community variant. Anyway,
 our first prototype was to do it all in Horizon, implementing a django
 app similar to what you can find in django registration
 https://django-registration.readthedocs.org/en/latest/. Currently
 ​I am
  working in moving all the backend logic to a keystone extension and
 keeping the views and form handling in a django app to make something
 similar to the current authentication system ​
 https://github.com/openstack/django_openstack_auth
 ​.​

 You can check here



Re: [openstack-dev] [all] Cross-project DevRef Was Re: Skipping Cross-Project meeting today

2015-01-21 Thread Ian Cordasco


On 1/20/15, 21:21, Jay Bryant jsbry...@electronicjungle.net wrote:

+2  This topic had come up in Cinder I believe as well.
Having a common devref for common content would be good and would make it
easier to keep the documentation current.

Jay
On Jan 20, 2015 4:05 PM, Jay Pipes jaypi...@gmail.com wrote:

On 01/20/2015 01:30 PM, Ian Cordasco wrote:
On Jan 20, 2015, at 05:23, Thierry Carrez thie...@openstack.org
wrote:

Hi everyone,

Given that the agenda docket is pretty slim this week, I'd like to
skip this cross-project meeting and have the next one on Jan 27.

sigmavirus24 posted the Cross-project DevRef akin to Nova's item
but I'd prefer if we discussed it on the mailing-list first (not
certain it requires everyone's attention just yet, and could just
be proposed as a spec).

Cheers,

-- Thierry Carrez (ttx)

__






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



Hey all,

First, let me provide some context. The week before last, an update
to sqlalchemy-migrate broke glance’s gate. While helping us fix the
problem, Matt Riedemann noticed that the project doesn’t have a
Developer Reference document. The document helps new developers
determine what system packages they need to build a development
environment for the project.

We discussed the idea of putting one together for glance at the team
meeting last week. While discussing it, we realized a lot of the
steps are similar to Nova’s and it might benefit OpenStack as a whole
to have one common DevRef that links off to individual ones for
further configuration. The list of common steps could be maintained
in one place (rather than synchronized between projects) and then
individual extensions would be maintained with in each project or
wiki.

Before we started duplicating content in our own document, we wanted
to present the idea to the cross-project team and the community as a
whole.

Feedback is greatly appreciated, Ian



I think a common shared developer reference is a great idea, Ian. ++

-jay

__
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


Since no one has expressed distaste for this idea. What’s the best way to
move forward? I genuinely have no idea what the right next step is and
would appreciate some guidance here.

Cheers,
Ian (sigmavirus24)

__
OpenStack Development Mailing 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_log/oslo_config initialization

2015-01-21 Thread Qiming Teng
Hi,

In the oslo_log 0.1.0 release, the setup() function demands for a conf
parameter, but I have failed to find any hint about setting this up.

The problem is cfg.CONF() returns None, so the following code fails:

  conf = cfg.CONF(name='prog', project='project')
  # conf is always None here, so the following call fails
  log.setup(conf, 'project')

Another attempt also failed, because it cannot find any options:

  log.setup(cfg.CONF, 'project')

Any hint or sample code to setup logging if I'm abandoning the log
module from oslo.incubator?

Thanks!

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

2015-01-21 Thread Martin Geisler
Matthias Runge mru...@redhat.com writes:

 On 21/01/15 09:59, Martin Geisler wrote:

 
 This seems to imply that users will download at least one .js file
 per dependency.
 

 Not necessarily. We still use django-compressor, which copies all
 javascript into fewer files. E.g. here in my untweaked juno
 environment, I just get 3 instead of 10-15 following your logic above.
 (at least one js file per xstatic package).

Cool, I did not know about this!

Radomir said that this is run in a post-install hook for Horizon and
that he's unsure how or if the distros re-run the scripts when the
dependencies are installed. That is, if an updated version of the js-foo
package is installed, all apps that depend on js-foo would need to have
their JS bundles refreshed.

Or maybe it's simply run every time Horizon is started?

 That's probably acceptable for an application like Horizon which
 users will be using again and again, but for most web applications,
 you don't want your users to download 10-20 small .js files, instead
 you want them to download one minified and compressed file with all
 the JavaScript code needed.

 see above :D

 
 I'm just mentioning this since it's one way that web apps differ from
 how normal Linux apps are typically deployed. Basically, web apps
 prefer static compilation and discourages dynamic linking.

 I'm not sure, I can really follow you here.

I was trying to draw a parallel to how traditional (C) programs use
dynamic when loading -- perfect for distributions since this allows them
to patch a security problem just once and know that all programs that
use the affected library will get the update since they dynamically load
the library at runtime.

Contrast this with static linking -- which is normally discouraged or
forbidden by distributions since you'll have to recompile all dependant
programs when you patch a library.

I was thinking that web apps look like statically linked programs when
they're deployed using compressed and minified sources for maximum
performance.

Let me add that this kind of optimization matters the most if your
visitors who only visit the app once or rarely. With a file per
dependency, they'll get poor performance since their browser won't have
cached the files.

For an app like Horizon it might not be as important: even if it loads a
little slow on your first visit, you're likely to visit it many times as
you admin your deployment and those subsequent visits will be faster.
Still not as fast as they would be if the server could reply with a
single 304 Not Modified, but probably fast enough.

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

2015-01-21 Thread Qiming Teng
On Wed, Jan 21, 2015 at 12:27:15PM +0200, Denis Makogon wrote:
 On Wed, Jan 21, 2015 at 12:16 PM, Qiming Teng teng...@linux.vnet.ibm.com
 wrote:
 
  Hi,
 
  In the oslo_log 0.1.0 release, the setup() function demands for a conf
  parameter, but I have failed to find any hint about setting this up.
 
  The problem is cfg.CONF() returns None, so the following code fails:
 
conf = cfg.CONF(name='prog', project='project')
# conf is always None here, so the following call fails
log.setup(conf, 'project')
 
  Another attempt also failed, because it cannot find any options:
 
log.setup(cfg.CONF, 'project')
 
  Any hint or sample code to setup logging if I'm abandoning the log
  module from oslo.incubator?
 
 
 You might take a look at
 https://github.com/openstack/oslo.log/blob/master/oslo_log/_options.py
 Those options are what oslo_log expects to find in service configuration
 files.

Yes. The configuration file I have them. In the usage.rst file I found
here: https://review.openstack.org/#/c/147312/1/doc/source/usage.rst

The 'changes to app initiliaztion' section is very confusing. I still
need a configuration object, so I did it:

  cfg.CONF(name='prog', project='project')

Then I explicitly register the logging options as suggested:

  log.register_options(cfg.CONF)


Finally, I pass the same object to setup, as suggested:

  log.setup(cfg.CONF, 'prog')

Then I'm getting the following error:

Traceback (most recent call last):
  File /usr/bin/test-engine, line 6, in module
exec(compile(open(__file__).read(), __file__, 'exec'))
  File /opt/stack/proj/bin/test-engine, line 50, in module
log.register_options(cfg.CONF)
  File /usr/lib/python2.6/site-packages/oslo_log/log.py, line 185, in 
register_options
conf.register_cli_opts(_options.common_cli_opts)
  File /usr/lib/python2.6/site-packages/oslo_config/cfg.py, line 1679, in 
__inner
result = f(self, *args, **kwargs)
  File /usr/lib/python2.6/site-packages/oslo_config/cfg.py, line 1860, in 
register_cli_opts
self.register_cli_opt(opt, group, clear_cache=False)
  File /usr/lib/python2.6/site-packages/oslo_config/cfg.py, line 1683, in 
__inner
return f(self, *args, **kwargs)
  File /usr/lib/python2.6/site-packages/oslo_config/cfg.py, line 1852, in 
register_cli_opt
raise ArgsAlreadyParsedError(cannot register CLI option)
oslo_config.cfg.ArgsAlreadyParsedError: arguments already parsed: cannot 
register CLI option

  Thanks!
 
  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
 
 
 
 Kind regards,
 Denis M.

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


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


Re: [openstack-dev] [Fuel] 10Gbe performance issue.

2015-01-21 Thread Skamruk, Piotr
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... 

-- 
  Regards,
  jell
__
OpenStack Development Mailing 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] [webui] Setting one dns server address in ui.

2015-01-21 Thread Vladimir Kuklin
Piotr, the easiest workaround is to patch neutron_subnet type to perform
munge operation that uses uniq function somewhere here:
https://github.com/stackforge/puppet-neutron/blob/master/lib/puppet/type/neutron_subnet.rb#L56-L60.
We would also appreciate if you filed a bug to Fuel launchpad.

On Wed, Jan 21, 2015 at 2:09 PM, Skamruk, Piotr piotr.skam...@intel.com
wrote:

 Hi.

 In time of environment setup, there is a place in webui to provide dns
 servers addresses on network tab, in neutron l3 configuration. There is
 no way to set only one address.
 Setting same ip in both input fields is permitted by webui, but later,
 in time of deploy - neutron called from puppet files fails to setup
 internal network (Net04 in my setup).

 If two addresses are mandatory, there should be check if they are
 different?

 Or should be there a way to setup only one address?

 --
   Regards,
   jell
 __
 OpenStack Development Mailing 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] [tc][python-clients] More freedom for all python clients

2015-01-21 Thread Boris Pavlovic
Clarkb,

As Robert said, you are missing the point.

I didn't say that Rally wants this lib so it should be in global
requirements.

I asked only about python clients of stackforge projects that are regarding
all rules:
(Like py3k support, license, are in projects.txt and so on).  From my point
of view, if clients are regarding all reules there is no compatibility
issues = it is easy to add them to g-r. Am I wrong?


All,

Sorry I wasn't able to be on meeting yesterday.


First of all, we don't have any issues with having Murano/Mistral
benchmarks and testing them in gates and supporting them in our tree. (We
already have rally-dsvm-murano and rally-dsvm-mistral dsvm jobs that works
well)

The real issue is very bad user  dev experience caused by soft decencies.

Let's take a look at actions of typical user (running Murano benchamrk):
1) Try to run tests for Murano
2) Input validation error: MuranoClient is missing please install it
3) WTF???

Let's take a look at actions of end developer (writing Murano benchmark):
1) Try to make new Murano benchmark
2) Need to import some exceptions from Murano client
3) All unit tests are failing..
4) WTF???

Adding extra steps/conditions that are required for using product are
adding exponential complexity to it. So having 5 such steps/conditions will
make product inconsumable.

So the only thing that I would like is to remove one extra step by adding
good python clients to g-r.


Best regards,
Boris Pavlovic




On Wed, Jan 21, 2015 at 4:15 AM, Robert Collins robe...@robertcollins.net
wrote:

 On 21 January 2015 at 10:21, Clark Boylan cboy...@sapwetik.org wrote:
 ...
  This ml thread came up in the TC meeting today and I am responding here
  to catch the thread up with the meeting. The soft update option is the
  suggested fix for non openstack projects that want to have most of their
  requirements managed by global requirements.
 
  For the project structure reform opening things up we should consider
  loosening the criteria to get on the list and make it primarily based on
  technical criteria such as py3k support, license compatibility, upstream
  support/activity, and so on (basically the current criteria with less of
  a focus on where the project comes from if it is otherwise healthy).
  Then individual projects would choose the subset they need to depend on.
  This model should be viable with different domains as well if we go that
  route.
 
  The following is not from the TC meeting but addressing other portions
  of this conversation:
 
  At least one concern with this option is that as the number of total
  requirements goes up is the difficulty in debugging installation
  conflicts becomes more difficult too. I have suggested that we could
  write tools to help with this. Install bisection based on pip logs for
  example, but these tools are still theoretical so I may be
  overestimating their usefulness.
 
  To address the community scaling aspect I think you push a lot of work
  back on deployers/users if we don't curate requirements for anything
  that ends up tagged as production ready (or whatever the equivalent
  tag becomes). Essentially we are saying this doesn't scale for us so
  now you deal with the fallout. Have fun, which isn't very friendly to
  people consuming the software. We already have an absurd number of
  requirements and management of them has appeared to scale. I don't
  foresee my workload going up if we open up the list as suggested.

 Perhaps I missed something, but the initial request wasn't about
 random packages, it was about other stackforge clients - these are
 things in the ecosystem! I'm glad we have technical solutions, but it
 just seems odd to me that adding them would ever have been
 controversial.

 On the pip solver side, joe gordon was working on a thing to install a
 fixed set of packages by bypassing the pip resolver... not sure how
 thats progressing.

 -Rob

 --
 Robert Collins rbtcoll...@hp.com
 Distinguished Technologist
 HP Converged Cloud

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

__
OpenStack Development Mailing 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-21 Thread Skamruk, Piotr
On Tue, 2015-01-20 at 17:41 +0100, Tomasz Napierala wrote:
[...]
 How this was measured? VM to VM? Compute to compute? 
iperf between compute/ceph-compute/ceph nodes.

 In any case, what is your deployment configuration, especially VLAND or GRE, 
 networking gear, etc.
We have almost default setup from clean fuel 6.0, vlan based.
We are doing iperf based on 82599ES 10-Gigabit SFP+ interfaces (used in
our setup only for storage network) connected by fibre through Arista
7150.

Results on centos 6.5 deployed from fuel:
 0.0-10.0 sec  3.09 GBytes  2.65 Gbits/sec

Results on centos 6.5 from official site:
 0.0-10.0 sec  10.9 GBytes  9.38 Gbits/sec

In both cases tests were done with default tcp window size - 19.3KByte.
In both cases default mtu was with value 1500.

Commands used in test (after adding iperf tool from rpm):
  on one node:
iperf -s -p 8777 
  on other node:
iperf -c ip_address_of_server_in_storage_network -p 8777 -t 10

(port 8777 is one of passed as ACCEPT in iptables setup from fuel)

Differences are in kernel (from centos or from mirantis), values
in /etc/sysctl.conf (plain or from mirantis) and probably in cgroups
settings.

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).

-- 
  Regards,
  jell
__
OpenStack Development Mailing 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] [webui] Setting one dns server address in ui.

2015-01-21 Thread Skamruk, Piotr
Hi.

In time of environment setup, there is a place in webui to provide dns
servers addresses on network tab, in neutron l3 configuration. There is
no way to set only one address.
Setting same ip in both input fields is permitted by webui, but later,
in time of deploy - neutron called from puppet files fails to setup
internal network (Net04 in my setup).

If two addresses are mandatory, there should be check if they are
different?

Or should be there a way to setup only one address?

-- 
  Regards,
  jell
__
OpenStack Development Mailing 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-21 Thread Denis Makogon
On Wed, Jan 21, 2015 at 12:16 PM, Qiming Teng teng...@linux.vnet.ibm.com
wrote:

 Hi,

 In the oslo_log 0.1.0 release, the setup() function demands for a conf
 parameter, but I have failed to find any hint about setting this up.

 The problem is cfg.CONF() returns None, so the following code fails:

   conf = cfg.CONF(name='prog', project='project')
   # conf is always None here, so the following call fails
   log.setup(conf, 'project')

 Another attempt also failed, because it cannot find any options:

   log.setup(cfg.CONF, 'project')

 Any hint or sample code to setup logging if I'm abandoning the log
 module from oslo.incubator?


You might take a look at
https://github.com/openstack/oslo.log/blob/master/oslo_log/_options.py
Those options are what oslo_log expects to find in service configuration
files.


 Thanks!

 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



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


[openstack-dev] [infra] Re: [stable] Stable check of openstack/nova failed - EnvironmentError: mysql_config not found

2015-01-21 Thread Ihar Hrachyshka

Hi all,

Any updates from infra on why it occurs? It's still one of the issues 
that make periodic stable jobs fail.


We also have other failures due to missing packages on nodes. F.e.,

keystone python-ldap installation failing due to missing devel files for 
openldap:

http://logs.openstack.org/periodic-stableperiodicx-keystone-docs-icehouse/30c89e8/console.html
http://logs.openstack.org/periodic-stableperiodic-keystone-python27-icehouse/2a77792/console.html

/Ihar

On 01/19/2015 09:17 AM, Alan Pevec wrote:

- periodic-nova-docs-icehouse 
http://logs.openstack.org/periodic-stableperiodic-nova-docs-icehouse/a3d88ed/ : 
FAILURE in 1m 15s

Same symptom as https://bugs.launchpad.net/openstack-ci/+bug/1336161
which is marked as Fix released, could infra team check if all images
are alright?
This showed up in 3 periodic icehouse jobs over weekend, all on
bare-precise-hpcloud-b2 nodes, I've listed them in
https://etherpad.openstack.org/p/stable-tracker


Cheers,
Alan

__
OpenStack Development Mailing 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] Question on functional tests

2015-01-21 Thread Ihar Hrachyshka
Unit tests should run successfully in a very limited environment, with 
no sudo, namespaces etc. Some packagers even run unit tests as part of 
their build process in hardened environment (I know Debian does, and 
some teams from Red Hat consider it too, like Neutron).


So if it really needs to interact with outside world like that, please 
implement it in functional test namespace.


On 01/20/2015 09:02 PM, Kevin Benton wrote:
I don't believe we have any unit tests that create namespaces or veth 
pairs. This sounds like it belongs with functional tests.


On Tue, Jan 20, 2015 at 10:20 AM, Numan Siddique 
numan.siddi...@enovance.com mailto:numan.siddi...@enovance.com wrote:


Hello,

I am working on a bug [1] on neutron vpnaas and submitted the
patch here [2].

The test code to test the fix does the following
- creates a namespace
- creates a veth pair and add one interface into the namespace
- configures the interface with an ip address and
- adds a default gateway
- and of course tests the code.

This test code only tests a specific function
(OpenSwanProcess._get_nexthop())

Reviewers of this patch are not clear if this should be part of
functional tests or unit tests.
Can unit tests create linux namespaces, interfaces etc or it falls
under functional tests?

Please let me know your thoughts on this.

[1] - https://bugs.launchpad.net/neutron/+bug/1405413
[2] - https://review.openstack.org/#/c/145005/5


Regards
Numan


__
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




--
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 Development Mailing 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-21 Thread Radomir Dopieralski
On 20/01/15 20:58, Matthew Farina wrote:
 Radomir, maybe you can help me better understand where this would go. I
 have a few questions.
 
 First, can you point me to a time when horizon used system packages
 successfully for JavaScript libraries? When I looked through the Debian
 and Ubuntu packages I couldn't find the libraries horizon is using. I'm
 curious to see this in action.

Any distribution (perhaps except Ubuntu, which is a little funny in that
regard) that has packaged the latest release of OpenStack, has those
libraries.
For instance, see
http://pkgs.fedoraproject.org/cgit/python-django-horizon.git/tree/python-django-horizon.spec#n129


 Front-end systems almost never use system packagers like this. Can you
 point me to applications like horizon that use system packages this way?
 If Horizon is going to go it virtually alone in this space, what will
 that mean for our level of work and ability to have updates?

Certainly. The XStatic system itself is lifted from MoinMoin wiki, for
example -- it was created to solve exactly this problem there, and is
used by a couple of other projects too.

As for our work and updates, using system-wide packages is an excellent
solution in this regard, as we get maintenance and updates for free. For
instance, if there is a security issue in one of the JavaScript
libraries, we don't need to patch Horizon -- the patch that is prepared
for that specific library and applied system-wide is sufficient.
-- 
Radomir Dopieralski


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


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

2015-01-21 Thread Radomir Dopieralski
On 21/01/15 09:21, david.co...@oracle.com wrote:
 As for our work and updates, using system-wide packages is an excellent
 solution in this regard, as we get maintenance and updates for free. For
 instance, if there is a security issue in one of the JavaScript
 libraries, we don't need to patch Horizon -- the patch that is prepared
 for that specific library and applied system-wide is sufficient.
 
 But for distributions that package Horizon itself, don't they
 effectively need to patch Horizon? Namely, don't they need to install
 on their build systems fixed JavaScript distribution packages to
 address the security issue and then they need to rebuild Horizon itself
 even if there are no Horizon source code changes.
 
 From a Horizon end-user perspective who relies on the distribution's
 packages to get Horizon, they'll get the security fix but it seems
 distributors will still need to rebuild and deliver Horizon for every
 upstream JavaScript fix whether the files come from XStatic, Bower, or
 some other method.

No, why would they? They don't copy the static files into the Horizon's
package. That's the whole point, Horizon only has paths to them. The
files themselves are provided by the system-wide packages.

-- 
Radomir Dopieralski


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


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

2015-01-21 Thread Martin Geisler
Radomir Dopieralski openst...@sheep.art.pl writes:

 On 21/01/15 09:21, david.co...@oracle.com wrote:
 As for our work and updates, using system-wide packages is an
 excellent solution in this regard, as we get maintenance and updates
 for free. For instance, if there is a security issue in one of the
 JavaScript libraries, we don't need to patch Horizon -- the patch
 that is prepared for that specific library and applied system-wide
 is sufficient.
 
 But for distributions that package Horizon itself, don't they
 effectively need to patch Horizon? Namely, don't they need to install
 on their build systems fixed JavaScript distribution packages to
 address the security issue and then they need to rebuild Horizon
 itself even if there are no Horizon source code changes.
 
 From a Horizon end-user perspective who relies on the distribution's
 packages to get Horizon, they'll get the security fix but it seems
 distributors will still need to rebuild and deliver Horizon for every
 upstream JavaScript fix whether the files come from XStatic, Bower,
 or some other method.

 No, why would they? They don't copy the static files into the
 Horizon's package. That's the whole point, Horizon only has paths to
 them. The files themselves are provided by the system-wide packages.

This seems to imply that users will download at least one .js file per
dependency.

That's probably acceptable for an application like Horizon which users
will be using again and again, but for most web applications, you don't
want your users to download 10-20 small .js files, instead you want them
to download one minified and compressed file with all the JavaScript
code needed.

I'm just mentioning this since it's one way that web apps differ from
how normal Linux apps are typically deployed. Basically, web apps prefer
static compilation and discourages dynamic linking.

-- 
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] Question on functional tests

2015-01-21 Thread Numan Siddique

Yes. That's right.

Also there is a unit test here [1] which mocks ip netns exec.

[1] - 
https://review.openstack.org/#/c/145005/5/neutron_vpnaas/tests/unit/services/vpn/device_drivers/test_ipsec.py


Thanks
Numan

On 01/21/2015 02:22 PM, Kevin Benton wrote:
So the test wouldn't make much sense then without the creation of the 
namespace, right? If that's the case, it sounds like it is a very low 
level functional test making sure that routes can be installed into 
namespaces.


On Wed, Jan 21, 2015 at 12:19 AM, Numan Siddique 
numan.siddi...@enovance.com mailto:numan.siddi...@enovance.com wrote:


It is asserting the return value of ip netns exec ns ip route
get ip_address.


Thanks
Numan


On 01/21/2015 12:34 PM, Kevin Benton wrote:

Is the test asserting things about interactions with the system,
or does it just happen to use a system call as a side effect of
one of the setups?

On Tue, Jan 20, 2015 at 1:24 PM, Paul Michali p...@michali.net
mailto:p...@michali.net wrote:

My question is whether the tests proposed should be unit
tests or functional tests. They only test one method, and
it's not a complete piece of functionality - like creating a
VPN connection.

If that one system call is mocked, these could all be treated
as unit tests. So I'm wondering if there is an advantage in
actually testing the system call (getaddrinfo), as part of
this work?


Thoughts?

PCM (Paul Michali)

IRC pc_m (irc.freenode.com http://irc.freenode.com)
Twitter... @pmichali


On Tue, Jan 20, 2015 at 3:02 PM, Kevin Benton
blak...@gmail.com mailto:blak...@gmail.com wrote:

I don't believe we have any unit tests that create
namespaces or veth pairs. This sounds like it belongs
with functional tests.

On Tue, Jan 20, 2015 at 10:20 AM, Numan Siddique
numan.siddi...@enovance.com
mailto:numan.siddi...@enovance.com wrote:

Hello,

I am working on a bug [1] on neutron vpnaas and
submitted the patch here [2].

The test code to test the fix does the following
- creates a namespace
- creates a veth pair and add one interface into
the namespace
- configures the interface with an ip address and
- adds a default gateway
- and of course tests the code.

This test code only tests a specific function
(OpenSwanProcess._get_nexthop())

Reviewers of this patch are not clear if this should
be part of functional tests or unit tests.
Can unit tests create linux namespaces, interfaces
etc or it falls under functional tests?

Please let me know your thoughts on this.

[1] - https://bugs.launchpad.net/neutron/+bug/1405413
[2] - https://review.openstack.org/#/c/145005/5


Regards
Numan



__
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




-- 
Kevin Benton



__
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




__
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




-- 
Kevin Benton



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



__

[openstack-dev] [cinder] Request for clarification regarding deadline for new drivers in Kilo

2015-01-21 Thread Eduard Matei
Hi,

This weekend our driver [https://review.openstack.org/#/c/130733/] got a -2
stating that This is past the deadline for release of new drivers in
Kilo. and the deadline for new drivers passed at the end of Kilo-1. This
needs to wait for the L release.

But, in another mail on the mailing list we were informed:

If your driver is submitted *LATE* in k-1, and meets *all* the items above,
but isn't merged, it will be still be considered for merge in k-2 or k-3.

The items above being that the blueprint is submitted, together with cert
tests and the code is submitted to gerrit and that a CI is working.

We had the blueprint, cert tests and code on gerrit *EARLY* in k-1 (first
patchset was on Oct 24), blueprint was approved for k-1 and cert tests were
posted.
CI is under construction, and will be ready by March deadline.


So, can someone from cinder core clarify why the driver is delayed to L
when all items are met?

Thanks,
Eduard
-- 

*Eduard Biceri Matei, Senior Software Developer*
www.cloudfounders.com
 | eduard.ma...@cloudfounders.com



*CloudFounders, The Private Cloud Software Company*

Disclaimer:
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed.
If you are not the named addressee or an employee or agent responsible
for delivering this message to the named addressee, you are hereby
notified that you are not authorized to read, print, retain, copy or
disseminate this message or any part of it. If you have received this
email in error we request you to notify us by reply e-mail and to
delete all electronic files of the message. If you are not the
intended recipient you are notified that disclosing, copying,
distributing or taking any action in reliance on the contents of this
information is strictly prohibited.
E-mail transmission cannot be guaranteed to be secure or error free as
information could be intercepted, corrupted, lost, destroyed, arrive
late or incomplete, or contain viruses. The sender therefore does not
accept liability for any errors or omissions in the content of this
message, and shall have no liability for any loss or damage suffered
by the user, which arise as a result of e-mail transmission.
__
OpenStack Development Mailing 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-21 Thread Matthias Runge
On 21/01/15 09:59, Martin Geisler wrote:

 
 This seems to imply that users will download at least one .js file per
 dependency.
 

Not necessarily. We still use django-compressor, which copies all
javascript into fewer files. E.g. here in my untweaked juno environment,
I just get 3 instead of 10-15 following your logic above. (at least one
js file per xstatic package).

 That's probably acceptable for an application like Horizon which users
 will be using again and again, but for most web applications, you don't
 want your users to download 10-20 small .js files, instead you want them
 to download one minified and compressed file with all the JavaScript
 code needed.
see above :D

 
 I'm just mentioning this since it's one way that web apps differ from
 how normal Linux apps are typically deployed. Basically, web apps prefer
 static compilation and discourages dynamic linking.

I'm not sure, I can really follow you here.

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-21 Thread david . comay

As for our work and updates, using system-wide packages is an excellent
solution in this regard, as we get maintenance and updates for free. For
instance, if there is a security issue in one of the JavaScript
libraries, we don't need to patch Horizon -- the patch that is prepared
for that specific library and applied system-wide is sufficient.


But for distributions that package Horizon itself, don't they
effectively need to patch Horizon? Namely, don't they need to install
on their build systems fixed JavaScript distribution packages to
address the security issue and then they need to rebuild Horizon itself
even if there are no Horizon source code changes.


From a Horizon end-user perspective who relies on the distribution's

packages to get Horizon, they'll get the security fix but it seems
distributors will still need to rebuild and deliver Horizon for every
upstream JavaScript fix whether the files come from XStatic, Bower, or
some other method.

__
OpenStack Development Mailing 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] Question on functional tests

2015-01-21 Thread Numan Siddique
It is asserting the return value of ip netns exec ns ip route get 
ip_address.



Thanks
Numan


On 01/21/2015 12:34 PM, Kevin Benton wrote:
Is the test asserting things about interactions with the system, or 
does it just happen to use a system call as a side effect of one of 
the setups?


On Tue, Jan 20, 2015 at 1:24 PM, Paul Michali p...@michali.net 
mailto:p...@michali.net wrote:


My question is whether the tests proposed should be unit tests or
functional tests. They only test one method, and it's not a
complete piece of functionality - like creating a VPN connection.

If that one system call is mocked, these could all be treated as
unit tests. So I'm wondering if there is an advantage in actually
testing the system call (getaddrinfo), as part of this work?


Thoughts?

PCM (Paul Michali)

IRC pc_m (irc.freenode.com http://irc.freenode.com)
Twitter... @pmichali


On Tue, Jan 20, 2015 at 3:02 PM, Kevin Benton blak...@gmail.com
mailto:blak...@gmail.com wrote:

I don't believe we have any unit tests that create namespaces
or veth pairs. This sounds like it belongs with functional tests.

On Tue, Jan 20, 2015 at 10:20 AM, Numan Siddique
numan.siddi...@enovance.com
mailto:numan.siddi...@enovance.com wrote:

Hello,

I am working on a bug [1] on neutron vpnaas and submitted
the patch here [2].

The test code to test the fix does the following
- creates a namespace
- creates a veth pair and add one interface into the
namespace
- configures the interface with an ip address and
- adds a default gateway
- and of course tests the code.

This test code only tests a specific function
(OpenSwanProcess._get_nexthop())

Reviewers of this patch are not clear if this should be
part of functional tests or unit tests.
Can unit tests create linux namespaces, interfaces etc or
it falls under functional tests?

Please let me know your thoughts on this.

[1] - https://bugs.launchpad.net/neutron/+bug/1405413
[2] - https://review.openstack.org/#/c/145005/5


Regards
Numan



__
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




-- 
Kevin Benton



__
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



__
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




--
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 Development Mailing 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] Question on functional tests

2015-01-21 Thread Kevin Benton
So the test wouldn't make much sense then without the creation of the
namespace, right? If that's the case, it sounds like it is a very low level
functional test making sure that routes can be installed into namespaces.

On Wed, Jan 21, 2015 at 12:19 AM, Numan Siddique 
numan.siddi...@enovance.com wrote:

  It is asserting the return value of ip netns exec ns ip route get
 ip_address.


 Thanks
 Numan


 On 01/21/2015 12:34 PM, Kevin Benton wrote:

 Is the test asserting things about interactions with the system, or does
 it just happen to use a system call as a side effect of one of the setups?

 On Tue, Jan 20, 2015 at 1:24 PM, Paul Michali p...@michali.net wrote:

 My question is whether the tests proposed should be unit tests or
 functional tests. They only test one method, and it's not a complete piece
 of functionality - like creating a VPN connection.

  If that one system call is mocked, these could all be treated as unit
 tests. So I'm wondering if there is an advantage in actually testing the
 system call (getaddrinfo), as part of this work?


  Thoughts?

   PCM (Paul Michali)

  IRC pc_m (irc.freenode.com)
 Twitter... @pmichali


 On Tue, Jan 20, 2015 at 3:02 PM, Kevin Benton blak...@gmail.com wrote:

 I don't believe we have any unit tests that create namespaces or veth
 pairs. This sounds like it belongs with functional tests.

  On Tue, Jan 20, 2015 at 10:20 AM, Numan Siddique 
 numan.siddi...@enovance.com wrote:

   Hello,

 I am working on a bug [1] on neutron vpnaas and submitted the patch
 here [2].

 The test code to test the fix does the following
 - creates a namespace
 - creates a veth pair and add one interface into the namespace
 - configures the interface with an ip address and
 - adds a default gateway
 - and of course tests the code.

 This test code only tests a specific function ( OpenSwanProcess.
 _get_nexthop())

 Reviewers of this patch are not clear if this should be part of
 functional tests or unit tests.
 Can unit tests create linux namespaces, interfaces etc or it falls
 under functional tests?

 Please let me know your thoughts on this.

 [1] - https://bugs.launchpad.net/neutron/+bug/1405413
 [2] - https://review.openstack.org/#/c/145005/5


 Regards
 Numan



 __
 OpenStack Development Mailing 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 Development Mailing 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: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




-- 
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] some questions about neutron

2015-01-21 Thread Kevin Benton
I'm not sure what the latest scaling numbers are. But to answer your second
question, many neutron servers can be launched to support extra compute
nodes. They all connect into the same message bus and service requests off
of it.

On Tue, Jan 20, 2015 at 11:56 PM, wujiangtaoh...@163.com 
wujiangtaoh...@163.com wrote:

 hi,all:

 I have some questions about neutron:

 1、how many compute nodes can be supported by one neutron-server ?
 2、If one neutron-server can't support two many nodes , for example
 1000 servers, can two neutron-servers work together in active-active mode ?

 Thans a lot !

 --
 gentle wu
 china mobile



 __
 OpenStack Development Mailing 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] tooz 0.12 released

2015-01-21 Thread Julien Danjou
Hi,

The Oslo team is pleased to announce the release of tooz 0.12

This release includes several bug fixes:

 5edf2b3 retry: fix decorator
 27ab08c file: fix typo in errno.EACCES

For more details, please see the git log history and
  https://launchpad.net/python-tooz/+milestone/0.12

Please report issues through launchpad:
  https://launchpad.net/python-tooz

Cheers,
-- 
Julien Danjou
# Free Software hacker
# http://julien.danjou.info


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

2015-01-21 Thread Qiming Teng
On Wed, Jan 21, 2015 at 12:27:15PM +0200, Denis Makogon wrote:
 On Wed, Jan 21, 2015 at 12:16 PM, Qiming Teng teng...@linux.vnet.ibm.com
 wrote:
 
  Hi,
 
  In the oslo_log 0.1.0 release, the setup() function demands for a conf
  parameter, but I have failed to find any hint about setting this up.
 
  The problem is cfg.CONF() returns None, so the following code fails:
 
conf = cfg.CONF(name='prog', project='project')
# conf is always None here, so the following call fails
log.setup(conf, 'project')
 
  Another attempt also failed, because it cannot find any options:
 
log.setup(cfg.CONF, 'project')
 
  Any hint or sample code to setup logging if I'm abandoning the log
  module from oslo.incubator?
 
 
 You might take a look at
 https://github.com/openstack/oslo.log/blob/master/oslo_log/_options.py
 Those options are what oslo_log expects to find in service configuration
 files.

Okay, my guess is that both oslo_config and oslo_log are trying to
register_cli_options. I have to create a configuration object for
oslo_log to work, and it means CLI options are registered once.
Later on, when I'm calling log.register_options(), it is conflicting
with previous registration.

So, I'm doubting whether these two packages have been tested together?

Regards,
  Qiming

  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
 
 
 
 Kind regards,
 Denis M.

 __
 OpenStack Development Mailing 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-21 Thread Davanum Srinivas
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/

On Wed, Jan 21, 2015 at 8:11 AM, Qiming Teng teng...@linux.vnet.ibm.com wrote:
 On Wed, Jan 21, 2015 at 12:27:15PM +0200, Denis Makogon wrote:
 On Wed, Jan 21, 2015 at 12:16 PM, Qiming Teng teng...@linux.vnet.ibm.com
 wrote:

  Hi,
 
  In the oslo_log 0.1.0 release, the setup() function demands for a conf
  parameter, but I have failed to find any hint about setting this up.
 
  The problem is cfg.CONF() returns None, so the following code fails:
 
conf = cfg.CONF(name='prog', project='project')
# conf is always None here, so the following call fails
log.setup(conf, 'project')
 
  Another attempt also failed, because it cannot find any options:
 
log.setup(cfg.CONF, 'project')
 
  Any hint or sample code to setup logging if I'm abandoning the log
  module from oslo.incubator?
 
 
 You might take a look at
 https://github.com/openstack/oslo.log/blob/master/oslo_log/_options.py
 Those options are what oslo_log expects to find in service configuration
 files.

 Okay, my guess is that both oslo_config and oslo_log are trying to
 register_cli_options. I have to create a configuration object for
 oslo_log to work, and it means CLI options are registered once.
 Later on, when I'm calling log.register_options(), it is conflicting
 with previous registration.

 So, I'm doubting whether these two packages have been tested together?

 Regards,
   Qiming

  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
 


 Kind regards,
 Denis M.

 __
 OpenStack Development Mailing 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



-- 
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] [webui] Setting one dns server address in ui.

2015-01-21 Thread Skamruk, Piotr
On Wed, 2015-01-21 at 15:50 +0400, Vladimir Kuklin wrote:
 Piotr, the easiest workaround is to patch neutron_subnet type to
 perform munge operation that uses uniq function somewhere here:
 https://github.com/stackforge/puppet-neutron/blob/master/lib/puppet/type/neutron_subnet.rb#L56-L60.
  We would also appreciate if you filed a bug to Fuel launchpad.
Filled bug lies under https://bugs.launchpad.net/fuel/+bug/1413182 link.

-- 
  Regards,
  jell

__
OpenStack Development Mailing 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][announce] Community project website is launched

2015-01-21 Thread Igor Shishkin
Hello everyone,

We have finally done our community web site(codename “landing page” on our 
weekly meetings in IRC) which is going to become main entrance to the Fuel 
Community.

It’s brand new project for Fuel DevOps team and we want to make it really cool 
as developers for developers.

Please check it out here: https://www.fuel-infra.org/
And don’t hesitate to contact us in any forms: #fuel-dev @ freenode, 
fuel-devops in LP or simply by replying to this email.

Welcome to the Fuel world!
-- 
Igor Shishkin
DevOps




__
OpenStack Development Mailing 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-21 Thread Mehdi Abaakouk


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

Le 2015-01-21 11:16, Qiming Teng a écrit :

Any hint or sample code to setup logging if I'm abandoning the log
module from oslo.incubator?


You need to do:

  cfg.CONF(name='prog', project='project')
  log.setup(cfg.CONF, 'project')

Example of project that already use both: 
https://github.com/stackforge/gnocchi/blob/master/gnocchi/service.py#L25


Cheers,
- ---
Mehdi Abaakouk
mail: sil...@sileht.net
irc: sileht

-BEGIN PGP SIGNATURE-
Version: OpenPGP.js v.1.20131017
Comment: http://openpgpjs.org

wkYEAREIABAFAlS/qU4JEJZbdE7sD8foAAAQQwCfYN9jFNWp4OsxJts7Elmy
8taVKfYAn1uDtfn0aEJVDzXXbLdACzVxXEsB
=lHLc
-END 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] [Rally] New awesome Rally Docs available on ReadTheDocs now!

2015-01-21 Thread Lingxian Kong
Nice job! Thanks for the effort, really helpful to the beginners!

2015-01-20 23:20 GMT+08:00 Mikhail Dubov mdu...@mirantis.com:
 Hi stackers,

 on behalf of the Rally team, I am happy to announce that we have completely
 redesigned our Rally documentation in ReadTheDocs. The docs have now
 received a simpler structure and have become much easier to get through!

 One of the nicest new things is the Rally step-by-step tutorial that
 explains, in a series of lessons, how to explore the power of Rally in
 benchmarking your OpenStack clouds.

 You are also welcome to take a look at the updated tutorial on how to set up
 a Rally gate job in your project.


 Best regards,
 Mikhail Dubov

 Engineering OPS
 Mirantis, Inc.
 E-Mail: mdu...@mirantis.com
 Skype: msdubov

 __
 OpenStack Development Mailing 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!
---
Lingxian Kong

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


Re: [openstack-dev] [tc][python-clients] More freedom for all python clients

2015-01-21 Thread Sean Dague
On 01/20/2015 08:15 PM, Robert Collins wrote:
 On 21 January 2015 at 10:21, Clark Boylan cboy...@sapwetik.org wrote:
 ...
 This ml thread came up in the TC meeting today and I am responding here
 to catch the thread up with the meeting. The soft update option is the
 suggested fix for non openstack projects that want to have most of their
 requirements managed by global requirements.

 For the project structure reform opening things up we should consider
 loosening the criteria to get on the list and make it primarily based on
 technical criteria such as py3k support, license compatibility, upstream
 support/activity, and so on (basically the current criteria with less of
 a focus on where the project comes from if it is otherwise healthy).
 Then individual projects would choose the subset they need to depend on.
 This model should be viable with different domains as well if we go that
 route.

 The following is not from the TC meeting but addressing other portions
 of this conversation:

 At least one concern with this option is that as the number of total
 requirements goes up is the difficulty in debugging installation
 conflicts becomes more difficult too. I have suggested that we could
 write tools to help with this. Install bisection based on pip logs for
 example, but these tools are still theoretical so I may be
 overestimating their usefulness.

 To address the community scaling aspect I think you push a lot of work
 back on deployers/users if we don't curate requirements for anything
 that ends up tagged as production ready (or whatever the equivalent
 tag becomes). Essentially we are saying this doesn't scale for us so
 now you deal with the fallout. Have fun, which isn't very friendly to
 people consuming the software. We already have an absurd number of
 requirements and management of them has appeared to scale. I don't
 foresee my workload going up if we open up the list as suggested.
 
 Perhaps I missed something, but the initial request wasn't about
 random packages, it was about other stackforge clients - these are
 things in the ecosystem! I'm glad we have technical solutions, but it
 just seems odd to me that adding them would ever have been
 controversial.

Well, I think Clark and I have different opinions of how much of a pain
unwinding the requirements are, and how long these tend to leave the
gate broken. I am happy to also put it in a somebody elses problem
field for resolving the issues. :)

Honestly, I think we're actually at a different point, where we need to
stop assuming that the sane way to deal with python is to install it
into system libraries, and just put every service in a venv and get rid
of global requirements entirely. Global requirements was a scaling fix
for getting to 10 coexisting projects. I don't think it actually works
well with 50 ecosystem projects. Which is why I proposed the domains
solution instead.

 On the pip solver side, joe gordon was working on a thing to install a
 fixed set of packages by bypassing the pip resolver... not sure how
 thats progressing.

I think if we are talking seriously about bypassing the pip resolver, we
should step back and think about that fact. Because now we're producting
a custom installation process that will produce an answer for us, which
is completely different than any answer that anyone else is getting for
how to get a coherent system.

-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-dev] No DVR Meeting today.

2015-01-21 Thread Vasudevan, Swaminathan (PNB Roseville)
Hi Folks,
There will not be DVR meeting this week.
See you all next week.

Thanks.

Swaminathan Vasudevan
Systems Software Engineer (TC)


HP Networking
Hewlett-Packard
8000 Foothills Blvd
M/S 5541
Roseville, CA - 95747
tel: 916.785.0937
fax: 916.785.1815
email: swaminathan.vasude...@hp.commailto:swaminathan.vasude...@hp.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] oslo_log/oslo_config initialization

2015-01-21 Thread Qiming Teng
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/

Thanks, glad to know some projects already took the adventure and it
works.

Regards,
  Qiming

 On Wed, Jan 21, 2015 at 8:11 AM, Qiming Teng teng...@linux.vnet.ibm.com 
 wrote:
  On Wed, Jan 21, 2015 at 12:27:15PM +0200, Denis Makogon wrote:
  On Wed, Jan 21, 2015 at 12:16 PM, Qiming Teng teng...@linux.vnet.ibm.com
  wrote:
 
   Hi,
  
   In the oslo_log 0.1.0 release, the setup() function demands for a conf
   parameter, but I have failed to find any hint about setting this up.
  
   The problem is cfg.CONF() returns None, so the following code fails:
  
 conf = cfg.CONF(name='prog', project='project')
 # conf is always None here, so the following call fails
 log.setup(conf, 'project')
  
   Another attempt also failed, because it cannot find any options:
  
 log.setup(cfg.CONF, 'project')
  
   Any hint or sample code to setup logging if I'm abandoning the log
   module from oslo.incubator?
  
  
  You might take a look at
  https://github.com/openstack/oslo.log/blob/master/oslo_log/_options.py
  Those options are what oslo_log expects to find in service configuration
  files.
 
  Okay, my guess is that both oslo_config and oslo_log are trying to
  register_cli_options. I have to create a configuration object for
  oslo_log to work, and it means CLI options are registered once.
  Later on, when I'm calling log.register_options(), it is conflicting
  with previous registration.
 
  So, I'm doubting whether these two packages have been tested together?
 
  Regards,
Qiming
 
   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
  
 
 
  Kind regards,
  Denis M.
 
 


__
OpenStack Development Mailing 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] [magnum] Schedule for rest of Kilo

2015-01-21 Thread Steven Dake

TLDR; moving Magnum to match upstream release scheduling intersecting k3

As discussed in our last IRC meeting we want to merge our Magnum 
milestone schedules with the upstream OpenStack schedules as soon as 
feasible.  We think it is feasible to merge release schedules for K3.  
As such, We have picked the following dates for our schedules:


Milestone #2:February 16th
Milestone #3 - merging with all OpenStack K3: March 19th
magnum rcs April 9th-23rd
magnum-2015.1 release - April 30th

From k3 forward, we will follow the Kilo release schedule here:

https://wiki.openstack.org/wiki/Kilo_Release_Schedule

__
OpenStack Development Mailing 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] [sahara] team meeting Jan 22 1800 UTC

2015-01-21 Thread Sergey Lukjanov
Hi folks,

We'll be having the Sahara team meeting as usual in
#openstack-meeting-alt channel.

Agenda: https://wiki.openstack.org/wiki/Meetings/SaharaAgenda#Next_meetings

http://www.timeanddate.com/worldclock/fixedtime.html?msg=Sahara+Meetingiso=20150122T18

-- 
Sincerely yours,
Sergey Lukjanov
Sahara Technical Lead
(OpenStack Data Processing)
Principal Software Engineer
Mirantis Inc.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [tc][python-clients] More freedom for all python clients

2015-01-21 Thread Chris Dent

On Wed, 21 Jan 2015, Sean Dague wrote:

On the pip solver side, joe gordon was working on a thing to install a
fixed set of packages by bypassing the pip resolver... not sure how
thats progressing.


I think if we are talking seriously about bypassing the pip resolver, we
should step back and think about that fact. Because now we're producting
a custom installation process that will produce an answer for us, which
is completely different than any answer that anyone else is getting for
how to get a coherent system.


Agreed. Skipping the pip resolver will move OpenStack and friends further
down into a weird world of its own rather than Python norms.

If possible we should try to resolve the complexity, not bandaid the
problems caused by the complexity.

If we can't do that then per service virtualenv (or even containers)
provides a far more contained[1] bandage.

Related: I personally find it completely bewildering that things are
managed and run in such an unbounded fashion. My intuition is that
this is the result of many/most projects being on the same release
cycle and the belief that my master must integrate with your master. We
should release (far) more often and my master should integrate with your
lastest release.

[1] Oh, my sides.

--
Chris Dent tw:@anticdent freenode:cdent
https://tank.peermore.com/tanks/cdent

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