date:20150121

On Wed, Jan 21, 2015 at 10:55:37AM -0500, Davanum Srinivas wrote:
> Qiming,
> 
> Guessing you were looking at master. if you checkout the review i
> pointed to, you will see what others on the thread have pointed you
> to:
> https://github.com/openstack/oslo.log/blob/master/doc/source/usage.rst
> 
> We are using register_options and setup. we should be adding
> register_options in the future as need arises.

In most files listed below, the 'logging' refers to
nova/openstack/common/log.py instead of oslo_log/log.py.  No project can
throw away openstack/common/log.py at the moment, because it breaks
things in many ways.

> dims@dims-mac:~/openstack/nova$ find . -name "*.py" -exec grep -H
> logging {} \; | grep -e "\.setup" -e "\.register_options" -e
> "\.set_defaults"
> ./nova/cmd/all.py:logging.setup(CONF, "nova")
> ./nova/cmd/api.py:logging.setup(CONF, "nova")
> ./nova/cmd/api_ec2.py:logging.setup(CONF, "nova")
> ./nova/cmd/api_metadata.py:logging.setup(CONF, "nova")
> ./nova/cmd/api_os_compute.py:logging.setup(CONF, "nova")
> ./nova/cmd/cells.py:logging.setup(CONF, 'nova')
> ./nova/cmd/cert.py:logging.setup(CONF, "nova")
> ./nova/cmd/compute.py:logging.setup(CONF, 'nova')
> ./nova/cmd/conductor.py:logging.setup(CONF, "nova")
> ./nova/cmd/console.py:logging.setup(CONF, "nova")
> ./nova/cmd/consoleauth.py:logging.setup(CONF, "nova")
> ./nova/cmd/dhcpbridge.py:logging.setup(CONF, "nova")
> ./nova/cmd/manage.py:logging.setup(CONF, "nova")
> ./nova/cmd/network.py:logging.setup(CONF, "nova")
> ./nova/cmd/novncproxy.py:logging.setup(CONF, "nova")
> ./nova/cmd/novncproxy.py:logging.setup(CONF, "nova")
> ./nova/cmd/objectstore.py:logging.setup(config.CONF, "nova")
> ./nova/cmd/scheduler.py:logging.setup(CONF, "nova")
> ./nova/cmd/serialproxy.py:logging.setup(CONF, "nova")
> ./nova/cmd/spicehtml5proxy.py:logging.setup(CONF, "nova")
> ./nova/cmd/xvpvncproxy.py:logging.setup(config.CONF, "nova")
> ./nova/openstack/common/report/guru_meditation_report.py:
> logging.setup(CONF, 'blah')
> ./nova/test.py:logging.register_options(CONF)
> ./nova/test.py:logging.setup(CONF, 'nova')
> 
> If you file a review with what you have, maybe we can help, again, pop
> onto the #openstack-oslo channel to ask

Okay, will do.  Thanks.

Regards,
  Qiming

> -- dims
> 
> On Wed, Jan 21, 2015 at 10:25 AM, Qiming Teng
>  wrote:
> > On Wed, Jan 21, 2015 at 08:25:57AM -0500, Davanum Srinivas wrote:
> >> Qiming,
> >>
> >> Nova already uses oslo.config. there's a patch against nova to use
> >> oslo_log. Doug took the effort to do this so we'd not face issues once
> >> we release oslo_log, so yes, they have been tested together. Please
> >> hop onto #openstack-oslo to debug in real time.
> >>
> >> [1] https://review.openstack.org/#/c/147635/
> >>
> >
> > Well, just checked nova code, it seems openstack.common.log is still
> > there. That means there are duplicated code such as the
> > 'common_cli_opts' which resides in both openstack.common.log and
> > oslo_log._options.
> >
> > I was getting the following error if I'm deleting openstack.common.log
> > module:
> >
> > oslo_config.cfg.NoSuchOptError: no such option: log_config_append
> >
> > So ... even with oslo_log there, we still need openstack.common.log?
> > Pretty confused and a little frustrated after two days of digging.
> >
> > Regards,
> >   Qiming
> >
 


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

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
six>1
taskflow<0.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
six>1
taskflow>1

$ python pippin.py -r test.txt
Initial package set:
- six ['>1']
- taskflow ['>1']
Traceback (most recent call last):
File "pippin.py", line 168, in 
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
'taskflow>1' (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 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 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 in

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 ]
2015-01-22 14:34:11.096 | [--prefix PREFIX] 
--type 
2015-01-22 14:34:11.096 | [--description 
]
2015-01-22 14:34:11.097 | 
2015-01-22 14:34:11.097 | openstack service create: error: argument --type is 
required

The reason is that my openstack client is old and not compatible with new 
devstack code. I have to git clone python-openstackclient and
install it manually.
I don’t know why devstack doesn’t check this. Any comments from experts? Thanks.

BR
Zhou Zhenzan


From: Sukhdev Kapur [mailto:sukhdevka...@gmail.com]
Sent: Thursday, January 22, 2015 4:58 AM
To: OpenStack Development Mailing List (not for usage questions); 
openstack-in...@lists.openstack.org
Subject: [openstack-dev] [neutron][devstack][keystone] Devstack failures due to 
empty service catalogue

Hi All,

I noticed that our CI got hit sometime last night. Neutron is unable to create 
"private" network as there is no Tenant ID.

Please see the error log here - http://paste.openstack.org/show/159912/

It appears that keystone is not creating tenant. Keystone screen log did not 
show anything obvious.

I wonder if others saw the same issue and if anybody has any idea as to what 
could have caused this? I looked at the obvious places and could not find 
anything interesting.

Any guidance/help will be appreciated.

Thanks
-Sukhdev

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

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] [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
six>1
taskflow<0.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
six>1
taskflow>1

$ python pippin.py -r test.txt
Initial package set:
- six ['>1']
- taskflow ['>1']
Traceback (most recent call last):
File "pippin.py", line 168, in 
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
'taskflow>1' (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 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 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 complications I ran

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
six>1
taskflow>1

$ python pippin.py  -r test.txt
Initial package set:
- six ['>1']
- taskflow ['>1']
Traceback (most recent call last):
  File "pippin.py", line 168, in 
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 
'taskflow>1' (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 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 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 tas

[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] 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"  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 Mai

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"  wrote:

> On Wed, Jan 21, 2015 at 10:14 AM, Mike Perez  wrote:
> > It gives me great pleasure to nominate Ivan Kolodyazhny (e0ne) for
> > Cinder core. Ivan's reviews have been valuable in decisions, and his
> > contributions to Cinder core code have been greatly appreciated.
> >
> > Reviews:
> >
> https://review.openstack.org/#/q/reviewer:%22Ivan+Kolodyazhny+%253Ce0ne%2540e0ne.info%253E%22,n,z
> >
> > Contributions:
> >
> https://review.openstack.org/#/q/owner:%22Ivan+Kolodyazhny%22+project:+openstack/cinder,n,z
> >
> > 30/90 day review stats:
> > http://stackalytics.com/report/contribution/cinder-group/30
> > http://stackalytics.com/report/contribution/cinder-group/90
> >
> > As new contributors step up to help in the project, some move onto
> > other things. I would like to recognize Josh Durgin for his early
> > contributions to Nova volume, early involvement with Cinder, and now
> > unfortunately departure from the Cinder core team.
> >
> > Cinder core, please reply with a +1 for approval. This will be left
> > open until Jan 26th. Assuming there are no objections, this will go
> > forward after voting is closed.
>
> And apologies for missing the [cinder] subject prefix.
>
> --
> Mike Perez
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Changes to Cinder Core

2015-01-21 Thread yang, xing

+1




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



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

On Wed, Jan 21, 2015 at 7:16 PM, Mike Perez 
mailto:thin...@gmail.com>> wrote:
On Wed, Jan 21, 2015 at 10:14 AM, Mike Perez 
mailto: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 R&D

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

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


Web | Blog | 
Twitter | 
Google+
 | Linkedin

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

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

2015-01-21 Thread John Griffith

On Wed, Jan 21, 2015 at 12:45 PM, Avishay Traeger 
wrote:

> +1
>
> On Wed, Jan 21, 2015 at 7:16 PM, Mike Perez  wrote:
>
>> On Wed, Jan 21, 2015 at 10:14 AM, Mike Perez  wrote:
>> > It gives me great pleasure to nominate Ivan Kolodyazhny (e0ne) for
>> > Cinder core. Ivan's reviews have been valuable in decisions, and his
>> > contributions to Cinder core code have been greatly appreciated.
>> >
>> > Reviews:
>> >
>> https://review.openstack.org/#/q/reviewer:%22Ivan+Kolodyazhny+%253Ce0ne%2540e0ne.info%253E%22,n,z
>> >
>> > Contributions:
>> >
>> https://review.openstack.org/#/q/owner:%22Ivan+Kolodyazhny%22+project:+openstack/cinder,n,z
>> >
>> > 30/90 day review stats:
>> > http://stackalytics.com/report/contribution/cinder-group/30
>> > http://stackalytics.com/report/contribution/cinder-group/90
>> >
>> > As new contributors step up to help in the project, some move onto
>> > other things. I would like to recognize Josh Durgin for his early
>> > contributions to Nova volume, early involvement with Cinder, and now
>> > unfortunately departure from the Cinder core team.
>> >
>> > Cinder core, please reply with a +1 for approval. This will be left
>> > open until Jan 26th. Assuming there are no objections, this will go
>> > forward after voting is closed.
>>
>> And apologies for missing the [cinder] subject prefix.
>>
>> --
>> Mike Perez
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
>
> --
> *Avishay Traeger*
> *Storage R&D*
>
> Mobile: +972 54 447 1475
> E-mail: avis...@stratoscale.com
>
>
>
> Web  | Blog
>  | Twitter
>  | Google+
> 
>  | Linkedin 
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> +1
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [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

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

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

__
OpenStack Development Mailing 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 
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/
>  .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
 wrote:
> Hi,
>
> Puppet OpenStack community uses Beaker for acceptance testing. I would
> consider it as option [2]
>
> [2] https://github.com/puppetlabs/beaker
>
> --
> Best regards,
> Sergii Golovatiuk,
> Skype #golserge
> IRC #holser
>
> On Mon, Jan 12, 2015 at 2:53 PM, Bogdan Dobrelya 
> wrote:
>>
>> Hello.
>>
>> We are working on the modularization of Openstack deployment by puppet
>> manifests in Fuel library [0].
>>
>> Each deploy step should be post-verified with some testing framework as
>> well.
>>
>> I believe the framework should:
>> * be shipped as a part of Fuel library for puppet manifests instead of
>> orchestration or Nailgun backend logic;
>> * allow the deployer to verify results right in-place, at the node being
>> deployed, for example, with a rake tool;
>> * be compatible / easy to integrate with the existing orchestration in
>> Fuel and Mistral as an option?
>>
>> It looks like test resources provided by Serverspec [1] are a good
>> option, what do you think?
>>
>> What plans have Fuel Nailgun team for testing the results of deploy
>> steps aka tasks? The spec for blueprint gives no a clear answer.
>>
>> [0]
>> https://blueprints.launchpad.net/fuel/+spec/fuel-library-modularization
>> [1] http://serverspec.org/resource_types.html
>>
>> --
>> Best regards,
>> Bogdan Dobrelya,
>> Skype #bogdando_at_yahoo.com
>> Irc #bogdando
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Andrew
Mirantis
Ceph community

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

[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

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

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] multi-queue virtio-net interface

2015-01-21 Thread Steve Gordon

- Original Message -
> From: "Rajagopalan Sivaramakrishnan" 
> 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] [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  wrote:
>> On 01/20/2015 09:20 AM, Xavier León wrote:
>>> Hi all,
>>>
>>> we've been doing some tests with openstack kilo and found
>>> out a problem: iptables routes are not being injected to the
>>> router namespace.
>>>
>>> Scenario:
>>> - a private network NOT connected to the outside world.
>>> - a router with only one interface connected to the private network.
>>> - a vm instance connected to the private network as well.

>> Are you sure the l3-agent is running?  You should have seen wrapped rules 
>> from
>> it in most of these tables, for example:
>>
>> # Generated by iptables-save v1.4.21 on Tue Jan 20 16:29:19 2015
>> *filter
>> :INPUT ACCEPT [34:10882]
>> :FORWARD ACCEPT [0:0]
>> :OUTPUT ACCEPT [1:84]
>> :neutron-filter-top - [0:0]
>> :neutron-l3-agent-FORWARD - [0:0]
>> :neutron-l3-agent-INPUT - [0:0]
>> :neutron-l3-agent-OUTPUT - [0:0]
>> :neutron-l3-agent-local - [0:0]
>> [...]
> 
> Yes, the l3-agent is up and running. I see these rules when executing
> the same test in juno but not in kilo. FYI, it's a all-in-one devstack
> deployment.
> 
>>
>> I would check the log files for any errors.
> 
> There are no errors in the logs.
> 
> After digging a bit more, we have seen that setting the config value
> of enable_isolated_metadata to True (default: False) in dhcp_agent.ini
> solves the problem in our scenario.
> However, this change in configuration was not necessary before (our
> tests passed in juno for that matter with that setting to False). So
> we were wondering if there has been a change in how the metadata
> service is accessed in such scenarios, a new issue because of the l3
> agent refactoring or any other problem in our setup we haven't
> narrowed yet.

There have been some changes recently in the code, perhaps:

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

Or just look at some of the other recent changes in the repository?

-Brian

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

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"  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"  wrote:
>
>On 01/20/2015 01:30 PM, Ian Cordasco wrote:
>On Jan 20, 2015, at 05:23, Thierry Carrez 
>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://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://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] [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] [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"  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"  wrote:
>
>On 01/20/2015 01:30 PM, Ian Cordasco wrote:
>On Jan 20, 2015, at 05:23, Thierry Carrez 
>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://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://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

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"  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"  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
 . Currently
 I am
  working in moving all the backend l

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

2015-01-21 Thread Victor Lowther

On Tue, Jan 20, 2015 at 8:36 AM, Jim Rollenhagen  
wrote:
> On Tue, Jan 20, 2015 at 07:28:46PM +0530, Ramakrishnan G wrote:
>> 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] 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 R&D*

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

Web  | Blog 
 | Twitter  | Google+

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

> On Wed, Jan 21, 2015 at 10:14 AM, Mike Perez  wrote:
> > It gives me great pleasure to nominate Ivan Kolodyazhny (e0ne) for
> > Cinder core. Ivan's reviews have been valuable in decisions, and his
> > contributions to Cinder core code have been greatly appreciated.
> >
> > Reviews:
> >
> https://review.openstack.org/#/q/reviewer:%22Ivan+Kolodyazhny+%253Ce0ne%2540e0ne.info%253E%22,n,z
> >
> > Contributions:
> >
> https://review.openstack.org/#/q/owner:%22Ivan+Kolodyazhny%22+project:+openstack/cinder,n,z
> >
> > 30/90 day review stats:
> > http://stackalytics.com/report/contribution/cinder-group/30
> > http://stackalytics.com/report/contribution/cinder-group/90
> >
> > As new contributors step up to help in the project, some move onto
> > other things. I would like to recognize Josh Durgin for his early
> > contributions to Nova volume, early involvement with Cinder, and now
> > unfortunately departure from the Cinder core team.
> >
> > Cinder core, please reply with a +1 for approval. This will be left
> > open until Jan 26th. Assuming there are no objections, this will go
> > forward after voting is closed.
>
> And apologies for missing the [cinder] subject prefix.
>
> --
> Mike Perez
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
*Avishay Traeger*
*Storage R&D*

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



Web  | Blog 
 | Twitter  | Google+

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

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

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

2015-01-21 Thread Duncan Thomas

+1 from me

On 21 January 2015 at 20:16, Mike Perez  wrote:

> On Wed, Jan 21, 2015 at 10:14 AM, Mike Perez  wrote:
> > It gives me great pleasure to nominate Ivan Kolodyazhny (e0ne) for
> > Cinder core. Ivan's reviews have been valuable in decisions, and his
> > contributions to Cinder core code have been greatly appreciated.
> >
> > Reviews:
> >
> https://review.openstack.org/#/q/reviewer:%22Ivan+Kolodyazhny+%253Ce0ne%2540e0ne.info%253E%22,n,z
> >
> > Contributions:
> >
> https://review.openstack.org/#/q/owner:%22Ivan+Kolodyazhny%22+project:+openstack/cinder,n,z
> >
> > 30/90 day review stats:
> > http://stackalytics.com/report/contribution/cinder-group/30
> > http://stackalytics.com/report/contribution/cinder-group/90
> >
> > As new contributors step up to help in the project, some move onto
> > other things. I would like to recognize Josh Durgin for his early
> > contributions to Nova volume, early involvement with Cinder, and now
> > unfortunately departure from the Cinder core team.
> >
> > Cinder core, please reply with a +1 for approval. This will be left
> > open until Jan 26th. Assuming there are no objections, this will go
> > forward after voting is closed.
>
> And apologies for missing the [cinder] subject prefix.
>
> --
> Mike Perez
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



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

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

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

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

2015-01-21 Thread Mike Perez

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

And apologies for missing the [cinder] subject prefix.

--
Mike Perez

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

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

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

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 )
Twitter... @pmichali

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

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] [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 :
> 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

[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

Re: [openstack-dev] oslo_log/oslo_config initialization

2015-01-21 Thread Vasudevan, Swaminathan (PNB Roseville)

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

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

[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+Meeting&iso=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] 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] 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  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 
>> 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] oslo_log/oslo_config initialization

On Wed, Jan 21, 2015 at 12:27:15PM +0200, Denis Makogon wrote:
> On Wed, Jan 21, 2015 at 12:16 PM, Qiming Teng 
> 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] [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  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] [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] [Fuel] [webui] Setting one dns server address in ui.

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

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

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

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

On Wed, Jan 21, 2015 at 12:27:15PM +0200, Denis Makogon wrote:
> On Wed, Jan 21, 2015 at 12:16 PM, Qiming Teng 
> 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 
exec(compile(open(__file__).read(), __file__, 'exec'))
  File "/opt/stack/proj/bin/test-engine", line 50, in 
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] [neutron] Question on functional tests

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

[openstack-dev] [Fuel] [webui] Setting one dns server address in ui.

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

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


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

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

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

> On 21 January 2015 at 10:21, Clark Boylan  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 
> 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] [horizon] static files handling, bower/

2015-01-21 Thread Martin Geisler

Matthias Runge  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 Denis Makogon

On Wed, Jan 21, 2015 at 12:16 PM, Qiming Teng 
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] oslo_log/oslo_config initialization