Re: [openstack-dev] [Manila]Rename driver mode

[Li, Chen]

Hi list,



After study  https://wiki.openstack.org/wiki/Manila/Kilo_Network_Spec

I’d like to change my proposal.



Since driver mode is actually decide by its network situation, how about:

  static_network_mode

  ⇨ No share server

  ⇨ import share server from other place



  dynamic_network_mode

  ⇨ flat network

  ⇨ segmented network

  o share server at the same subnet of share network

  o share server connect to tenant subnet using router



The usecase would like this:



enabled_backends=generic1,generic2,glusterfs1



[generic1]

driver=manila.share.drivers.generic.GenericShareDriver

mode=dynamic_network_mode

network=network1



[generic2]

driver=manila.share.drivers.generic.GenericShareDriver

mode=static_network_mode

enable_share_server=True

share_server=server1



[glusterfs1]

share_driver = manila.share.drivers.glusterfs.GlusterfsShareDriver

glusterfs_target = manila:/manila-volume0

mode=static_network_mode

enable_share_server=False



[network1]

plugin=manila.network.Neutron

network_type=flat

network=192.168.10.0

netmask=255.255.255.0

gateway=192.168.10.1

ip_range=192.168.10.50-192.168.10.99



[server1]

server_type=nova

is_deletable=False

id=x


From: Li, Chen [mailto:chen...@intel.com]
Sent: Tuesday, December 30, 2014 5:27 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [Manila]Rename driver mode

Hi list,

There are two driver modes in manila currently, “multi_svm_mode” and 
“single_svm_mode”.

"multi_svm_mode" means usage of share-networks that contain network information 
for dynamic creation of share-servers (SVMs).
"single_svm_mode" means usage of predefined some endpoint, without need to 
provide share-network and without creation of share-servers (SVMs).

Currently, the name of driver mode describes how many servers the driver can 
handle.
For "multi", it says that share driver can handle more than one server.
And,  if someone share server is just already exist from share driver, but it 
uses some server anyway with host address, username, password, NFS daemon, 
etc... are defined as works in "single_svm" mode too.

But, as a new user to manila, these names make me really confusing.
Because I thought the driver mode names describe how drivers works with 
share-servers.
I thought “multi-” and “single-” indicate the number of share-servers would 
been created when we create a share, if we are using the driver.
Obviously, my understanding is wrong.

When we’re working under driver generic, one share-server would be created for 
one share-network.
When we’re working under driver glusterfs, no share-server would be created at 
all.

I believe I would not be the only one who is making this mistake.
To make code more readable, I’d like to suggest to rename driver mode names.

Name them based on behavior but not ability.

I think three driver modes are needed:


-  dynamic_svm_mode :

  Usage of share-networks that contain network 
information for dynamic creation of share-servers (SVMs).

  This is how current generic driver works.

  Under this mode, driver manages share servers 
itself,  and share-server would be created and deleted with related shares.



-  static_svm_mode:   Using pre-create share servers.

  The case as 
https://review.openstack.org/#/c/144342/

  Under this mode, driver do not manage share 
servers, but work with them.



-  no_svm_mode:  the case as driver glusterfs working currently, no 
share-server would be created.


Thanks.
-chen


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [cinder bug commit] How to commit a bug which depends on another bug that have not been merged?

[liuxinguo]

Hi all,

* I have commit a bug and it is not yet merged. Now I want to commit 
another bug but this bug is depends on the previous one which 
have not been merged?
* So how should I do? Should I commit the latter bug 
directly or wait the previous bug to be merged?

Any input will be appreciated, thanks!

liu

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Keystone] Is anyone working on the following patch?

[Ajaya Agrawal]

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

Two of my patches depend on this patch.
https://review.openstack.org/#/c/113277/
https://review.openstack.org/#/c/110575/


Cheers,
Ajaya
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova][api]do we need to have a spec for all api related changes?

[Alex Xu]

2015-01-07 11:43 GMT+08:00 Eli Qiao :

>  hi all:
> I have a patch [1], just did slight changes on api, do I need to write a
> spec(kinds of wasting time to get approved)?
> since api-microversion[2] is almost done, can we just feel free to add
> changes as micro-version api?
>

We definitely can't 'feel free' to change API even we have micro-version,
special for back-incompatibility change. The spec is for avoid we break the
API accidentally.



> like bump version , write down changes in rest_api_version_history.rst
>
> [1] https://review.openstack.org/#/c/144914/
> [2]
> https://review.openstack.org/#/q/status:merged+project:openstack/nova+branch:master+topic:bp/api-microversions,n,z
>
> --
> Thanks,
> Eli (Li Yong) Qiao
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Refstack] Refstack mid cycle meet up in Santa Clara, CA Jan 12-14 2015

[Rochelle Grober]

Refstack is having its midcycle F2F meetup January 12-14, 2015 in Santa Clara, 
CA

Etherpad is:  https://etherpad.openstack.org/p/refstack-january-2015-midcycle

Everyone is welcome to join in, but please add your list to the etherpad if you 
will be attending in person.

We are hoping to do a sprint on getting the Refstack website back up and 
running, and are inviting local infra folks to suggest a session time and date 
for possibly doing this F2F, too.  We hope we can quickly identify what infra 
needs to make this happen, and get the site up and action items for what else 
is needed during the session.  The Refstack team is flexible in shifting 
sessions to accommodate the Infra team.

We also will be working on  the test UUID and would love any local QA team 
members to join for a session or two.

And, just to round this out, are there any Docs folks who might want to help 
for a session.  We promise at least one Refstack member dedicated to your 
needs;-)

There will be group dinners for those interested...

--Rocky
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Neutron] client noauth deprecation

[Kevin Benton]

The option to disable keystone authentication in the neutron client was
marked for deprecation in August as part of a Keystone support upgrade.[1]

What was the reason for this? As far as I can tell, Neutron works fine in
the 'noauth' mode and there isn't a lot of code that tightly couples
neutron to Keystone that I can think of.


1.
https://github.com/openstack/python-neutronclient/commit/2203b013fb66808ef280eff0285318ce21d9bc67#diff-ba2e4fad85e66d9aabb6193f222fcc4cR438

-- 
Kevin Benton
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova]nova not work with eventlet 0.16.0

[Eli Qiao]

在 2015年01月07日 04:56, victor stinner 写道:

Hi,


I set up nova environment with latest upstream code.
nova-compute can not boot up due to failed to load libvirt driver.
by further debugging. found that eventlet (0.16.0) remove util which is
referenced by libvirt driver.
after I downgrade to (0.15.2) it works.

Can you please try my following change?
https://review.openstack.org/#/c/145335/

It changes the libvirt driver to stop using the deprecated (and now removed) 
eventlet.util module.

Victor
thanks victor, you response so quick, appreciate, I will get some time 
to verify it

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



--
Thanks,
Eli (Li Yong) Qiao


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [nova][api]do we need to have a spec for all api related changes?

[Eli Qiao]

hi all:
I have a patch [1], just did slight changes on api, do I need to write a 
spec(kinds of wasting time to get approved)?
since api-microversion[2] is almost done, can we just feel free to add 
changes as micro-version api?

like bump version , write down changes in rest_api_version_history.rst

[1] https://review.openstack.org/#/c/144914/
[2] 
https://review.openstack.org/#/q/status:merged+project:openstack/nova+branch:master+topic:bp/api-microversions,n,z 



--
Thanks,
Eli (Li Yong) Qiao

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Cross Project][Log][Profiler] Specs are in review and need constructive feedback soonest

[Rochelle Grober]

The Cross Project team meeting discussed the following specs today:



> * Discuss openstack-spec: log guidelines [1]

> * Discuss openstack-spec: OSProfiler [2]

> * Open discussion & announcements

>

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

> [2] https://review.openstack.org/#/c/134839/

For [1], the log guidelines spec is likely to reach approval for merge by the 
next meeting on 1/13.  The spec has not been discussed on any mailing list for 
a while, so might be flying a bit under the radar.  This log guidelines spec is 
high level and states a number of best practices for developers when writing 
the logging chunks of their project code.  It also codifies the set of log 
levels: Error; Warning; Info; etc. and removes the AUDIT level.

Operators and others who hold an interest in this:  *PLEASE REVIEW [1] AND 
COMMENT ON THE REVIEW BY 1/13*  Lack of comments, as always, implies approval.  
If there is only light discussion of the spec, it will be approved.  If there 
is lively discussion, the discussion will move towards consensus before final 
approval.

The spec will then be used to expand the code review checklist so that its 
contents are enforced.

For [2], the OSProfiler spec is not as far along, but if you as an Ops (or 
interested developer) sees an issue or has a suggestion for improvement, you 
should also comment on this review.  The profiler already has code in use and 
is considered useful by a number of developers and some DevOps, which is why 
this spec and its review is being highlighted for this audience.

Ops, if you've never commented on a review before, don't let that hurdle stop 
you.  Check  out this page:  
http://docs.openstack.org/infra/manual/developers.html#code-review

It tells you how to post a review.  It doesn't tell you that you need get an 
account on Launchpad.net, but that info is here:
http://docs.openstack.org/infra/manual/developers.html#account-setup . I'm not 
sure if you have to be a member of OpenStack for commenting, but I'm sure folks 
will chime in if you do;-)

If working through these docs is hard for you, go out to IRC and folks will 
help get you started so you *can* comment on the reviews.

Also, if there is a section of the spec that you feel needs broader attention, 
start a discussion of it on the mailing list.  Please reference the review and 
the part of the spec you want to discuss, but put it out there on the mailing 
list so the issues/suggestions you have get addressed.

--Rocky


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [api] [sdk] Proposal to achieve consistency in client side sorting

[Rochelle Grober]

Steven,

This sounds like a perfect place for a cross project spec.  It wouldn't have to 
be a big one, but all the projects would have a chance to review and the TC 
would oversee to ensure it gets proper review.

TCms, am I on point here?

--Rocky


From: Jay S. Bryant [mailto:jsbry...@electronicjungle.net]
Sent: Tuesday, January 06, 2015 10:41 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [api] [sdk] Proposal to achieve consistency in 
client side sorting

Steven,

Thank you for continuing to pursue this.  Adding this functionality and having 
it consistent will be a good thing.

The plan for Cinder looks good to me and is consistent with Mike and Duncan's 
input.

I look forward to seeing patches for Cinder.

Jay
On 01/06/2015 10:03 AM, Steven Kaufer wrote:

This is a follow up thread to [1]

In order to have consistency across clients, I am proposing that the client 
side sorting has the following syntax: --sort [:]

Where the --sort parameter is comma-separated and is used to specify one or 
more sort keys and directions. The direction defaults to 'desc' for each sort 
key and the user can supply 'asc' to override.

For example:

  nova list --sort display_name
  nova list --sort display_name,vm_state
  nova list --sort display_name:asc,vm_state:asc

If approved, then the following changes are needed for glance and cinder (note 
that nova already uses this syntax):

  Cinder: Deprecate --sort_key and --sort_dir and add support for --sort
  Glance: Modify [2] to this new syntax

I have not verified how all other projects handle sorting, there may be other 
projects that would also need to be changed.

Thoughts?  Objections?

Also, if there is a more formal way to propose/review this standard please let 
me know.

[1] http://www.mail-archive.com/openstack-dev@lists.openstack.org/msg42854.html
[2] https://review.openstack.org/#/c/120777/

Thanks,
Steven Kaufer



___

OpenStack-dev mailing list

OpenStack-dev@lists.openstack.org

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Keystone] Etherpad for the Keystone midcycle meetup

[Steve Martinelli]

Howdy,

https://etherpad.openstack.org/p/kilo-keystone-midcycle is the etherpad
for the Keystone midcycle meetup. Similar to the Nova team, we should 
start
collecting topics to cover, and sort them by priority later once we've
collected a few.

Steve___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [api] [sdk] Proposal to achieve consistency in client side sorting

[Everett Toews]

On Jan 6, 2015, at 12:46 PM, Kevin L. Mitchell  
wrote:

> On Tue, 2015-01-06 at 12:19 -0600, Anne Gentle wrote:
>> I'm all for consistency. Sounds like a great case for the API Working
>> Group to document. You can propose a patch describing the way we want
>> sorting to work. 
>> 
>> 
>> See https://review.openstack.org/#/q/project:openstack/api-wg,n,z
> 
> I really think that the API WG should be responsible for the REST API
> only, TBH, and maybe for the Pythonic APIs.  Once we start talking about
> CLI options, I think that's outside the API WG's perview, and we
> probably should have that be up to CLI authors.  My thinking is that a
> REST API and a Python API are both used by developers, where we have one
> set of conventions; but when you start talking about CLI, you're really
> talking about UX, and the rules there can be vastly different.

Agreed. The scope [1] of the API WG is the HTTP (REST) API. 

We won’t be touching any language SDKs (one of which is referred to as Pythonic 
APIs above) or any CLIs.

Thanks,
Everett

[1] https://wiki.openstack.org/wiki/API_Working_Group#Scope
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [nova] unit test migration failure specific to MySQL/MariaDB - 'uuid': used in a foreign key constraint 'block_device_mapping_instance_uuid_fkey'

[Mike Bayer]

Hello -

Victor Sergeyev and I are both observing the following test failure which 
occurs with all the tests underneath 
nova.tests.unit.db.test_migrations.TestNovaMigrationsMySQL.This is against 
master with a brand new tox environment and everything at the default.

It does not seem to be occurring on gates that run these tests and 
interestingly the tests seem to complete very quickly (under seven seconds) on 
the gate as well; the failures here take between 50-100 seconds to occur, not 
fully deterministically, and only on the MySQL backend; the Postgresql and 
SQLite versions of these tests pass.  I’m running against MariaDB server 
10.0.14 with Python 2.7.8 on Fedora 21.   

Below is the test just for test_walk_versions, but the warnings (not 
necessarily the failures themselves) here also occur for test_migration_267 as 
well as test_innodb_tables.

I’m still looking into what the cause of this is, I’d imagine it’s something 
related to newer MySQL versions or perhaps MariaDB vs. MySQL, I’m just putting 
it up here in case someone already knows what this is or has some clue to save 
me some time figuring it out.  I apologize if I’m just doing something dumb, 
I’ve only recently begun to run Nova’s test suite in full against all backends, 
so I haven’t yet put intelligent thought into this nor have I tried to yet look 
at the migration in question causing the problem.  Will do that next.


[mbayer@thinkpad nova]$ tox -e py27 -- 
nova.tests.unit.db.test_migrations.TestNovaMigrationsMySQL.test_walk_versions
py27 develop-inst-noop: /home/mbayer/dev/openstack/nova
py27 runtests: PYTHONHASHSEED='0'
py27 runtests: commands[0] | find . -type f -name *.pyc -delete
py27 runtests: commands[1] | bash tools/pretty_tox.sh 
nova.tests.unit.db.test_migrations.TestNovaMigrationsMySQL.test_walk_versions
running testr
running=OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} \
OS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} \
OS_TEST_TIMEOUT=${OS_TEST_TIMEOUT:-160} \
${PYTHON:-python} -m subunit.run discover -t ./ ${OS_TEST_PATH:-./nova/tests} 
--list 
running=OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} \
OS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} \
OS_TEST_TIMEOUT=${OS_TEST_TIMEOUT:-160} \
${PYTHON:-python} -m subunit.run discover -t ./ ${OS_TEST_PATH:-./nova/tests}  
--load-list /tmp/tmpw7zqhE

2015-01-06 18:28:12.913 32435 WARNING oslo.db.sqlalchemy.session 
[req-5cc6731f-00ef-43df-8aec-4914a44d12c5 ] MySQL SQL mode is '', consider 
enabling TRADITIONAL or STRICT_ALL_TABLES
{0} 
nova.tests.unit.db.test_migrations.TestNovaMigrationsMySQL.test_walk_versions 
[51.553131s] ... FAILED

Captured traceback:
~~~
Traceback (most recent call last):
  File "nova/tests/unit/db/test_migrations.py", line 151, in 
test_walk_versions
self.walk_versions(self.snake_walk, self.downgrade)
  File 
"/home/mbayer/dev/openstack/nova/.tox/py27/lib/python2.7/site-packages/oslo/db/sqlalchemy/test_migrations.py",
 line 193, in walk_versions
self.migrate_up(version, with_data=True)
  File "nova/tests/unit/db/test_migrations.py", line 148, in migrate_up
super(NovaMigrationsCheckers, self).migrate_up(version, with_data)
  File 
"/home/mbayer/dev/openstack/nova/.tox/py27/lib/python2.7/site-packages/oslo/db/sqlalchemy/test_migrations.py",
 line 263, in migrate_up
self.REPOSITORY, version)
  File 
"/home/mbayer/dev/openstack/nova/.tox/py27/lib/python2.7/site-packages/migrate/versioning/api.py",
 line 186, in upgrade
return _migrate(url, repository, version, upgrade=True, err=err, **opts)
  File "", line 2, in _migrate
  File 
"/home/mbayer/dev/openstack/nova/.tox/py27/lib/python2.7/site-packages/migrate/versioning/util/__init__.py",
 line 160, in with_engine
return f(*a, **kw)
  File 
"/home/mbayer/dev/openstack/nova/.tox/py27/lib/python2.7/site-packages/migrate/versioning/api.py",
 line 366, in _migrate
schema.runchange(ver, change, changeset.step)
  File 
"/home/mbayer/dev/openstack/nova/.tox/py27/lib/python2.7/site-packages/migrate/versioning/schema.py",
 line 93, in runchange
change.run(self.engine, step)
  File 
"/home/mbayer/dev/openstack/nova/.tox/py27/lib/python2.7/site-packages/migrate/versioning/script/py.py",
 line 148, in run
script_func(engine)
  File 
"/home/mbayer/dev/openstack/nova/nova/db/sqlalchemy/migrate_repo/versions/267_instance_uuid_non_nullable.py",
 line 103, in upgrade
process_null_records(meta, scan=False)
  File 
"/home/mbayer/dev/openstack/nova/nova/db/sqlalchemy/migrate_repo/versions/267_instance_uuid_non_nullable.py",
 line 89, in process_null_records
table.columns.uuid.alter(nullable=False)
  File 
"/home/mbayer/dev/openstack/nova/.tox/py27/lib/python2.7/site-packages/migrate/changeset/schema.py",
 line 534, in alter
return alter_column(self, *p, **k)
  File 
"/home/mbayer/dev/openstack/nova/.tox/py27/lib/python2.7/site-packages/migrate/changeset/schema.py",
 

[openstack-dev] taskflow 0.6.1 released

[Joshua Harlow]

The Oslo team is pleased to announce the release of:

taskflow 0.6.1: Taskflow structured state management library.

For more details, please see the git log history below and:

http://launchpad.net/taskflow/+milestone/0.6.1

Please report issues through launchpad:

http://bugs.launchpad.net/taskflow/

Changes in taskflow 0.6.0..0.6.1
---

69449ae Remove need to inherit/adjust netutils split
b52db18 Allow specifying the engine 'executor' as a string
2ed1ad9 Disallowing starting the executor when worker running
50c5441 Use a single shared queue for an executors lifecycle
49ac8ec Avoid creating a temporary list(s) for tree type
05518ca Update statement around stopwatch thread safety
d498fdb Register with 'ANY' in the cloned process
fce7afb Remove less than useful action_engine __str__
f897008 Ensure manager started/shutdown/joined and reset
f862775 Return the same namedtuple that the future module returns
6cb9a0c Add a simplistic hello world example
e841b5a Get event/notification sending working correctly
a170f4b Move the engine scoping test to its engines test folder
2a8fde1 Get the basics of a process executor working
dbc890f Correctly trigger 'on_exit' of starting/initial state
2b959da Add an example which shows how to send events out from tasks

Diffstat (except docs and test files)
-

taskflow/engines/action_engine/engine.py   | 113 +-
taskflow/engines/action_engine/executor.py | 429 
-

taskflow/engines/worker_based/engine.py|  34 +-
taskflow/engines/worker_based/executor.py  |  18 +-
taskflow/examples/alphabet_soup.py | 101 +
taskflow/examples/hello_world.py   | 110 ++
taskflow/examples/wbe_event_sender.py  | 148 +++
taskflow/types/fsm.py  |   7 +-
taskflow/types/timing.py   |   5 +-
taskflow/types/tree.py |   9 +-
taskflow/utils/async_utils.py  |  33 +-
taskflow/utils/lock_utils.py   |   9 +-
taskflow/utils/misc.py |  24 +-
taskflow/utils/threading_utils.py  |   7 +
26 files changed, 1517 insertions(+), 479 deletions(-)

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Nova] Etherpad for the Nova midcycle meetup

[Michael Still]

Heya,

https://etherpad.openstack.org/p/kilo-nova-midcycle is the etherpad
for the Nova midcycle meetup. I'd like to start collecting topics we'd
like to cover, and we'll sort them by priority later once we've
collected a few.

Thanks,
Michael

-- 
Rackspace Australia

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova]nova not work with eventlet 0.16.0

[Thomas Goirand]

On 01/06/2015 09:56 PM, victor stinner wrote:
> Hi,
> 
>> I set up nova environment with latest upstream code.
>> nova-compute can not boot up due to failed to load libvirt driver.
>> by further debugging. found that eventlet (0.16.0) remove util which is
>> referenced by libvirt driver.
>> after I downgrade to (0.15.2) it works.
> 
> Can you please try my following change?
> https://review.openstack.org/#/c/145335/
> 
> It changes the libvirt driver to stop using the deprecated (and now removed) 
> eventlet.util module.
> 
> Victor

Victor,

Could you also backport this to Juno?

Cheers,

Thomas


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [oslo] Progress of the port to Python 3

[Thomas Goirand]

On 01/06/2015 05:51 PM, victor stinner wrote:
> Hi,
> 
> I'm still working on porting OpenStack to Python 3.
> I'm fixing Python 3 issues in eventlet and I'm trying
> to replace eventlet with trollius in OpenStack. Two
> different and complementary ways to port OpenStack to Python 3.

Hi Victor,

Will you also work on moving away from python-memcache (eg: memcached)
and using pymemcache instead? I believe I shouted enough about this
being a major issue for the support of Python 3, but nothing is
happening here.

> I fixed some eventlet issues related to Python 3 and
> monkey-patching. My changes are part of eventlet 0.16 which was
> released the 2014-12-30. I tried this version with Oslo Messaging:
> with another fix in eventlet (threading.Condition) and a change in
> the zmq driver, only 3 tests are now failing (which is a great
> success for me).

Super cool! :)

Cheers,

Thomas Goirand (zigo)


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][Spec freeze exception] Rootwrap daemon ode support

[Carl Baldwin]

Miguel,

Thanks again for taking this on.  I went looking for the rootwrap
daemon code today in gerrit and found it here [1].  I can allocate
some review cycles to help get this merged early in the cycle.  Please
keep us posted on your progress refreshing the code.

Carl

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

On Mon, Nov 10, 2014 at 2:05 AM, Miguel Angel Ajo Pelayo
 wrote:
> Thank you very much Armando,
>
> I updated the spec (which is missing the dev impact now) and I must rebase
> all the patches.  That may happen during tomorrow if I'm not missing
> anything.
>
> I will ping you back when it's ready.
>
> Sent from my Android phone using TouchDown (www.nitrodesk.com)
>
>
> -Original Message-
> From: Armando M. [arma...@gmail.com]
> Received: Saturday, 08 Nov 2014, 11:25
> To: OpenStack Development Mailing List (not for usage questions)
> [openstack-dev@lists.openstack.org]
> Subject: Re: [openstack-dev] [Neutron][Spec freeze exception] Rootwrap
> daemon ode support
>
>
> Hi Miguel,
>
> Thanks for picking this up. Pull me in and I'd be happy to help!
>
> Cheers,
> Armando
>
> On 7 November 2014 10:05, Miguel Ángel Ajo  wrote:
>>
>>
>> Hi Yorik,
>>
>>I was talking with Mark Mcclain a minute ago here at the summit about
>> this. And he told me that now at the start of the cycle looks like a good
>> moment to merge the spec & the root wrap daemon bits, so we have a lot of
>> headroom for testing during the next months.
>>
>>We need to upgrade the spec [1] to the new Kilo format.
>>
>>Do you have some time to do it?, I can allocate some time and do it
>> right away.
>>
>> [1] https://review.openstack.org/#/c/93889/
>> --
>> Miguel Ángel Ajo
>> Sent with Sparrow
>>
>> On Thursday, 24 de July de 2014 at 01:42, Miguel Angel Ajo Pelayo wrote:
>>
>> +1
>>
>> Sent from my Android phone using TouchDown (www.nitrodesk.com)
>>
>>
>> -Original Message-
>> From: Yuriy Taraday [yorik@gmail.com]
>> Received: Thursday, 24 Jul 2014, 0:42
>> To: OpenStack Development Mailing List [openstack-dev@lists.openstack.org]
>> Subject: [openstack-dev] [Neutron][Spec freeze exception] Rootwrap daemon
>> mode support
>>
>>
>> Hello.
>>
>> I'd like to propose making a spec freeze exception for
>> rootwrap-daemon-mode spec [1].
>>
>> Its goal is to save agents' execution time by using daemon mode for
>> rootwrap and thus avoiding python interpreter startup time as well as sudo
>> overhead for each call. Preliminary benchmark shows 10x+ speedup of the
>> rootwrap interaction itself.
>>
>> This spec have a number of supporters from Neutron team (Carl and Miguel
>> gave it their +2 and +1) and have all code waiting for review [2], [3], [4].
>> The only thing that has been blocking its progress is Mark's -2 left when
>> oslo.rootwrap spec hasn't been merged yet. Now that's not the case and code
>> in oslo.rootwrap is steadily getting approved [5].
>>
>> [1] https://review.openstack.org/93889
>> [2] https://review.openstack.org/82787
>> [3] https://review.openstack.org/84667
>> [4] https://review.openstack.org/107386
>> [5]
>> https://review.openstack.org/#/q/project:openstack/oslo.rootwrap+topic:bp/rootwrap-daemon-mode,n,z
>>
>> --
>>
>> Kind regards, Yuriy.
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Telco][NFV] Meeting Reminder - Wednesday January 7th @ 2200 UTC in #openstack-meeting

[Steve Gordon]

Hi all,

Just a reminder that the OpenStack Telco Working Group [1] will be meeting @ 
2200 UTC in #openstack-meeting on Wednesday January 7th. Draft agenda is 
available here:

https://etherpad.openstack.org/p/nfv-meeting-agenda

Please feel free to add items that you wish to discuss at the meeting.

Thanks,

Steve

[1] https://wiki.openstack.org/wiki/TelcoWorkingGroup

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova]nova not work with eventlet 0.16.0

[Dr. Jens Rosenboom]

Am 06/01/15 um 18:01 schrieb Daniel P. Berrange:

On Tue, Jan 06, 2015 at 05:36:38PM +0100, Ihar Hrachyshka wrote:

On 01/06/2015 05:33 PM, Daniel P. Berrange wrote:

On Tue, Jan 06, 2015 at 10:21:10AM -0600, Matt Riedemann wrote:

Odd...eventlet 0.16.0 was released on 12/30 and the eventlet.util import is
still in the libvirt host module, but this isn't blowing up in the Jenkins
runs, so what's different?  There isn't a version cap on eventlet in
global-requirements either.

When I pip install it in my dev env it still pulls in 0.15.2.

Likewise looking at a jenkins log from today it pulls in 0.15.2

   
http://logs.openstack.org/89/140089/3/check/gate-nova-python27/55b24ee/tox/py27-1.log

But the pypi page refers to 0.16.0

   https://pypi.python.org/pypi/eventlet/

?!?!?


Maybe some external dependency pulls in older version?


Ah, it seems my devpi/wheel caching setup was not seeing the new version.
When I forced a refresh in that, it pulled down 0.16.0 Wonder if the gate
has a similar cache refresh issue


As I noted in https://bugs.launchpad.net/nova/+bug/1407685/comments/3 
the pypi version of eventlet 0.16.0 does still include the old code, so 
you are only going to see this issue if you install eventlet from 
source. In particular most devstack issues will not see this issue until 
the pypi package is fixed.



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova]nova not work with eventlet 0.16.0

[victor stinner]

Hi,

> I set up nova environment with latest upstream code.
> nova-compute can not boot up due to failed to load libvirt driver.
> by further debugging. found that eventlet (0.16.0) remove util which is
> referenced by libvirt driver.
> after I downgrade to (0.15.2) it works.

Can you please try my following change?
https://review.openstack.org/#/c/145335/

It changes the libvirt driver to stop using the deprecated (and now removed) 
eventlet.util module.

Victor

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [stable] Proposal to add Flavio Percoco to stable-maint-core

[Morgan Fainberg]

+1

Flavio has always been a good gate keeper of stable across the board. 

Sent via mobile

> On Jan 6, 2015, at 11:32, Adam Gandelman  wrote:
> 
> Hiya-
> 
> Flavio has been actively involved in stable branch maintenance for as long as 
> I can remember, but it looks like his +2 abilities were removed after the 
> organizational changes made to the stable maintenance teams.  He has 
> expressed interest in continuing on with general stable maintenance and I 
> think his proven understanding of branch policies make him a valuable 
> contributor. I propose we add him to the stable-maint-core team.
> 
> Cheers,
> Adam
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Octavia] Questions about the Octavia project

[Phillip Toohill]

Ill answer inline what I can, others can chime in to clear up anything and
answer the rest. 

On 1/6/15 10:38 AM, "Andrew Hutchings"  wrote:

>Hi,
>
>I¹m looking into the Octavia project in relation to something my team are
>working on inside HP and I have a bunch of questions.  I realise it is
>early days for the project and some of these could be too low level at
>this time.
>
>Some of these questions come from the fact that I could not get the
>documentation to compile and the docs site for Octavia is down.  The
>v0.5-component-design.dot file crashes Graphviz 2.38 in every OS I tried
>and unfortunately all my dev machines have that version or 2.36 which is
>too low to render it correctly.  It also requires at least 5 extra
>dependencies (Sphinx modules) to build the docs but doesn¹t try to
>install them.
>
>I¹ll guess I¹ll start from the most obvious question:
>
>1. Octavia looks a lot like Libra but with integration into Neutron and
>Barbican (both were planned for Libra) as well as few other changes.  So
>the most obvious question is: why not just develop Libra for integration
>with Neutron?
There was many discussions with many contributors that included HP,
Rackspace, Bluebox A10 etc.. In regards to this decision. In the docs we
should have links to the reasonings behind some of these.
>
>Amphorae stuff:
>
>2. I see a lot of building blocks for the controller and Amphorae but not
>a lot about communication.  What protocol / method is to be used to
>communicate to the Amphorae instances?
In the docs/specs the communication protocols are defined.

>3. How are Amphorae instances to be spun up on-demand?  I see a reference
>to Heat but not sure if that is why it is there

The specs define how this is to happen

>4. There is mention of Docker in some of the deploy scripts.  Is this for
>multi-tenancy or just separation of the Amphorae processes?
>5. I take it Amphorae is designed to be single-AZ for now?
>
>Load Balancing:
>
>6. It seems like you are going to have SSL termination support and are
>going to use HAProxy, which means that you will have unencrypted data
>between the LB and web servers.  How do you plan to work around this
>problem?
Not sure what the 'problem' is, ultimately its up to the user, but a
private network can be configured between the LB and Web server
>
>Security:
>
>7. Someone in the specification there is talk of a 1 minute cache of
>security certificates.  How are you going to ensure that the cache will
>actually erase that cache after the 1 minute?  Also why cache them at
>all?  It seems to me to be a potential security risk
>
>API:
>
>8. More a comment than a question.  There is talk of using Pecan+WSME.
>Libra had a 5K patch on top of WSME just to make it behave correctly with
>Pecan and correct JSON specifications in certain situations, judging by
>the planned API you will also hit those same situations.  I admit I¹ve
>not looked at WSME for a year and there was an effort to strip it out of
>Libra completely at one point.  So that one is mainly my 2c :)
>
>Many thanks for your time.
>
>Kind Regards
>--
>Andrew Hutchings - LinuxJedi - http://www.linuxjedi.co.uk/
>
>


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] update existing plugin and add new ones

[Christopher Aedo]

Ah, bad paste, sorry.

All the details around developing and certifying a plug-in can be found here:
http://docs.mirantis.com/openstack/fuel/fuel-6.0/plugin-dev.html

-Christopher

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] update existing plugin and add new ones

[Christopher Aedo]

On Tue, Jan 6, 2015 at 7:00 AM,   wrote:
> Actually there is two different fuel plugins git repositories. One in
> stackforge and the other in mirantis:
>
> https://github.com/stackforge/fuel-plugins
Stackforge plug-ins - used for plug-ins developed by Fuel Core team.

> https://github.com/Mirantis/fuel-plugins
Mirantis plug-ins - used for plug-ins developed by Partner
Integrations and MOS teams.

> it is a little bit confusing. Why needing two different repositories?

Samuel, I agree, it is confusing.  From what I see the repo on
stackforge is the one that matters from the perspective of someone
building a new plugin.  For those just looking to download and use a
plug-in, the directory of certified and non-certified plug-ins for
Fuel will live here:
https://software.mirantis.com/download-mirantis-openstack-fuel-plug-ins/

All the details around developing and certifying a plug-in can be found here:
https://software.mirantis.com/download-mirantis-openstack-fuel-plug-ins/
Feedback on improving the docs is greatly appreciated!

> How are going to be manage version? There is a stable/6.0 branch from
> stackforge repo but not mirantis one
Since plugins are developed and built outside Fuel, the plugins have
their own versions (see metadata.yaml file).

I expect we will make things a little clearer in the weeks to come,
but please share your feedback and thoughts on how to make this work
better.  Thanks!

-Christopher

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [stable] Proposal to add Flavio Percoco to stable-maint-core

[Adam Gandelman]

Hiya-

Flavio has been actively involved in stable branch maintenance for as long
as I can remember, but it looks like his +2 abilities were removed after
the organizational changes made to the stable maintenance teams.  He has
expressed interest in continuing on with general stable maintenance and I
think his proven understanding of branch policies make him a valuable
contributor. I propose we add him to the stable-maint-core team.

Cheers,
Adam
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Keystone] LDAP Assignment Backend Use Survey

[Morgan Fainberg]

The Keystone team is evaluating the support of the LDAP Assignment backend 
within OpenStack and how it is used in deployments. The assignment backend 
covers “Projects/Tenants”, “Roles/Grants”, and in the case of SQL “Domains”.

There is a concern that the assignment backend implemented against LDAP is 
falling further and further behind the SQL implementation. To get a good read 
on the deployments and how the LDAP assignment backend is being used, the 
Keystone development team would appreciate feedback from the community.  Please 
fill out the following form and let us know if you are using LDAP Assignment, 
what it provides you that the SQL assignment backend is not providing, and the 
release of OpenStack (specifically Keystone) you are using.

http://goo.gl/forms/xz6xJQOQf5 

This poll is only meant to get information on the use of the LDAP Assignment 
backend which only contains Projects/Tenants and Roles/Grants.

Cheers,
Morgan Fainberg

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [api] [sdk] Proposal to achieve consistency in client side sorting

[Kevin L. Mitchell]

On Tue, 2015-01-06 at 12:19 -0600, Anne Gentle wrote:
> I'm all for consistency. Sounds like a great case for the API Working
> Group to document. You can propose a patch describing the way we want
> sorting to work. 
> 
> 
> See https://review.openstack.org/#/q/project:openstack/api-wg,n,z

I really think that the API WG should be responsible for the REST API
only, TBH, and maybe for the Pythonic APIs.  Once we start talking about
CLI options, I think that's outside the API WG's perview, and we
probably should have that be up to CLI authors.  My thinking is that a
REST API and a Python API are both used by developers, where we have one
set of conventions; but when you start talking about CLI, you're really
talking about UX, and the rules there can be vastly different.

Now, my personal preference on the CLI side is that "--sort key[:dir]"
is the way to go, but I helped hash that out in the novaclient
implementation as a reviewer.  I also had suggestions about how it
should be transmitted in the REST API, but that had already been settled
at the blueprint phase; that may be something the API WG will want to
take up and review and provide guidance on now, though…
-- 
Kevin L. Mitchell 
Rackspace


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [api] [sdk] Proposal to achieve consistency in client side sorting

[Jay S. Bryant]

Steven,

Thank you for continuing to pursue this.  Adding this functionality and 
having it consistent will be a good thing.


The plan for Cinder looks good to me and is consistent with Mike and 
Duncan's input.


I look forward to seeing patches for Cinder.

Jay

On 01/06/2015 10:03 AM, Steven Kaufer wrote:


This is a follow up thread to [1]

In order to have consistency across clients, I am proposing that the 
client side sorting has the following syntax: --sort [:]


Where the --sort parameter is comma-separated and is used to specify 
one or more sort keys and directions. The direction defaults to 'desc' 
for each sort key and the user can supply 'asc' to override.


For example:

  nova list --sort display_name
  nova list --sort display_name,vm_state
  nova list --sort display_name:asc,vm_state:asc

If approved, then the following changes are needed for glance and 
cinder (note that nova already uses this syntax):


  Cinder: Deprecate --sort_key and --sort_dir and add support for --sort
  Glance: Modify [2] to this new syntax

I have not verified how all other projects handle sorting, there may 
be other projects that would also need to be changed.


Thoughts?  Objections?

Also, if there is a more formal way to propose/review this standard 
please let me know.


[1] 
http://www.mail-archive.com/openstack-dev@lists.openstack.org/msg42854.html

[2] https://review.openstack.org/#/c/120777/

Thanks,
Steven Kaufer


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova][all] nova not work with eventlet 0.16.0

[Sylvain Bauza]

Le 06/01/2015 19:25, Sylvain Bauza a écrit :

Maybe we should ask for cap eventlet to 0.15.2 in global-requirements ?




My bad, there is already a change https://review.openstack.org/#/c/145023/

-S


Adding the [all] tag as I think it's cross-project.

-Sylvain


Le 06/01/2015 18:01, Daniel P. Berrange a écrit :

On Tue, Jan 06, 2015 at 05:36:38PM +0100, Ihar Hrachyshka wrote:

On 01/06/2015 05:33 PM, Daniel P. Berrange wrote:

On Tue, Jan 06, 2015 at 10:21:10AM -0600, Matt Riedemann wrote:
Odd...eventlet 0.16.0 was released on 12/30 and the eventlet.util 
import is
still in the libvirt host module, but this isn't blowing up in the 
Jenkins

runs, so what's different?  There isn't a version cap on eventlet in
global-requirements either.

When I pip install it in my dev env it still pulls in 0.15.2.

Likewise looking at a jenkins log from today it pulls in 0.15.2

http://logs.openstack.org/89/140089/3/check/gate-nova-python27/55b24ee/tox/py27-1.log

But the pypi page refers to 0.16.0

   https://pypi.python.org/pypi/eventlet/

?!?!?


Maybe some external dependency pulls in older version?
Ah, it seems my devpi/wheel caching setup was not seeing the new 
version.
When I forced a refresh in that, it pulled down 0.16.0 Wonder if the 
gate

has a similar cache refresh issue

Regards,
Daniel



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova][all] nova not work with eventlet 0.16.0

[Sylvain Bauza]

Maybe we should ask for cap eventlet to 0.15.2 in global-requirements ?

Adding the [all] tag as I think it's cross-project.

-Sylvain


Le 06/01/2015 18:01, Daniel P. Berrange a écrit :

On Tue, Jan 06, 2015 at 05:36:38PM +0100, Ihar Hrachyshka wrote:

On 01/06/2015 05:33 PM, Daniel P. Berrange wrote:

On Tue, Jan 06, 2015 at 10:21:10AM -0600, Matt Riedemann wrote:

Odd...eventlet 0.16.0 was released on 12/30 and the eventlet.util import is
still in the libvirt host module, but this isn't blowing up in the Jenkins
runs, so what's different?  There isn't a version cap on eventlet in
global-requirements either.

When I pip install it in my dev env it still pulls in 0.15.2.

Likewise looking at a jenkins log from today it pulls in 0.15.2

   
http://logs.openstack.org/89/140089/3/check/gate-nova-python27/55b24ee/tox/py27-1.log

But the pypi page refers to 0.16.0

   https://pypi.python.org/pypi/eventlet/

?!?!?


Maybe some external dependency pulls in older version?

Ah, it seems my devpi/wheel caching setup was not seeing the new version.
When I forced a refresh in that, it pulled down 0.16.0 Wonder if the gate
has a similar cache refresh issue

Regards,
Daniel



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Glance] IRC logging

[Christopher Aedo]

On Tue, Jan 6, 2015 at 2:49 AM, Flavio Percoco  wrote:
> Fully agree... I don't see how enable logging should be a limitation
> for freedom of thought. We've used it in Zaqar since day 0 and it's
> bee of great help for all of us.
>
> The logging does not remove the need of meetings where decisions and
> more relevant/important topics are discussed.

Wanted to second this as well.  I'm strongly in favor of logging -
looking through backlogs of chats on other channels has been very
helpful to me in the past, and it sure to help others in the future.
I don't think there is danger of anyone pointing to a logged IRC
conversation in this context as some statement of record.

-Christopher

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [api] [sdk] Proposal to achieve consistency in client side sorting

[Anne Gentle]

On Tue, Jan 6, 2015 at 10:03 AM, Steven Kaufer  wrote:

> This is a follow up thread to [1]
>
> In order to have consistency across clients, I am proposing that the
> client side sorting has the following syntax: --sort [:]
>
> Where the --sort parameter is comma-separated and is used to specify one
> or more sort keys and directions. The direction defaults to 'desc' for each
> sort key and the user can supply 'asc' to override.
>
> For example:
>
>   nova list --sort display_name
>   nova list --sort display_name,vm_state
>   nova list --sort display_name:asc,vm_state:asc
>
> If approved, then the following changes are needed for glance and cinder
> (note that nova already uses this syntax):
>
>   Cinder: Deprecate --sort_key and --sort_dir and add support for --sort
>   Glance: Modify [2] to this new syntax
>
> I have not verified how all other projects handle sorting, there may be
> other projects that would also need to be changed.
>
> Thoughts?  Objections?
>
> Also, if there is a more formal way to propose/review this standard please
> let me know.
>
I'm all for consistency. Sounds like a great case for the API Working Group
to document. You can propose a patch describing the way we want sorting to
work.

See https://review.openstack.org/#/q/project:openstack/api-wg,n,z

Anne


>
>
> [1]
> http://www.mail-archive.com/openstack-dev@lists.openstack.org/msg42854.html
> [2] https://review.openstack.org/#/c/120777/
>
> Thanks,
> Steven Kaufer
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Lin Hua Cheng]

Radomir,

The current version of Angular were using in Horizon still does not have
cookie and mock packages:
https://github.com/stackforge/xstatic-angular/tree/1.2.1.1/xstatic/pkg/angular/data

We still need to do it the long way:
1. Update the Angular version in global-requirements
2. Wait till it gets merge and propagate to horizon requirements
3. Remove references loading of mock and cookie packages in horizon and
horizon requirement
4. Remove mock and cookie from global-requirements.

-Lin

On Tue, Jan 6, 2015 at 1:00 AM, Radomir Dopieralski 
wrote:

> On 06/01/15 01:39, Tripp, Travis S wrote:
> > What Radomir proposes looks like it would greatly ease the process I am
> still going through to get the latest angular available to Horizon for
> current development.  At the time of writing this, I’m still trying to get
> the updated library through.  I hit a rather difficult workflow:
> >
> >
> >   1.  Packaged the latest into Xstatic-Angular-1.3.7
> >   2.  Submitted patch which deprecated the separate older
> xstatic-angular-cookies and xstatic-angular-mock packages
> >   3.  Reviewed and approved (after correcting an initial mis-repackaging)
> >   4.  Radomir released to Pypi
> >
> > This was pretty easy and not too hard. Not too much to complain about.
> >
> > However, now, to get Horizon to use it, I have to get that into global
> requirements.  Since I’m deprecating old packages I got stuck in a sort of
> ugly dependency path.  I couldn’t remove the cookies and mock libraries
> from the global requirements patch that added the new 1.3.7 package because
> of horizon still referencing the deprecated packages.  And, when I did it
> anyway, the integration tests failed due to horizon being dependent on
> something not in global requirements.  So, now, as far as I can tell we
> have to jump through the following hoops:
> >
> >
> >   1.  Global requirements patch to add angular 1.3.7
> >  *   Verify check / recheck fun
> >  *   Reviewed and approved
> >  *   Gate check / recheck fun
> >   2.  Horizon patch to update to angular 1.3.7 and remove deprecated
> mock and cookies packages
> >  *   Verify check / recheck fun
> >  *   Reviewed and approved
> >  *   Gate check / recheck fun
> >   3.  Global requirements patch to remove deprecated mock and cookies
> >  *   Verify check / recheck fun
> >  *   Reviewed and approved
> >  *   Gate check / recheck fun
> >
> > Don’t get me wrong, I really do think the gate is brilliant and am all
> for a review / approval process, but this does seem excessive for a UI
> library that should only be used by Horizon. Is there some other reason
> that this should have to go through global requirements?
>
> You can do it much easier, since the current version of Angular already
> packages what is in the deprecated modules. So just:
>
> 1. Patch Horizon to remove the xstatic dependencies to the mock and
> cookies packages.
> 2. Patch global-requirements to remove them, and add newer Angular.
> 3. Patch Horizon to use the newer Angular.
>
> --
> Radomir Dopieralski
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [oslo] Progress of the port to Python 3

[Jordan Pittier]

Hi Victor.

Thanks for your effort. Did you read the ML thread "[nova]nova not work
with eventlet 0.16.0" ? It looks "important".

Jordan

On Tue, Jan 6, 2015 at 5:51 PM, victor stinner 
wrote:

> Hi,
>
> I'm still working on porting OpenStack to Python 3. I'm fixing Python 3
> issues in eventlet and I'm trying to replace eventlet with trollius in
> OpenStack. Two different and complementary ways to port OpenStack to Python
> 3.
>
>
> I fixed some eventlet issues related to Python 3 and monkey-patching. My
> changes are part of eventlet 0.16 which was released the 2014-12-30. I
> tried this version with Oslo Messaging: with another fix in eventlet
> (threading.Condition) and a change in the zmq driver, only 3 tests are now
> failing (which is a great success for me).
>
> See my Oslo Messaging change for more information:
> https://review.openstack.org/#/c/145241/
>
> It looks like eventlet 0.16 works much better with Python 3 and
> monkey-patching. You should try it on your own project! Tell me if you need
> help to fix issues.
>
> --
>
> About asyncio, I renamed my "aiogreen" project to "aioeventlet" (to make
> it more explicit that it is specific to eventlet). With the release 0.4,
> the API is now considered as stable.
> http://aioeventlet.readthedocs.org/
>
> Mehdi Abaakouk voted +2 on my Oslo Messaging patches to support trollius
> coroutines using aioeventlet project, but it looks that he's alone to
> review Oslo Messaging patches :-/ Anyway to approve my changes?
>
> * Add an optional executor callback to dispatcher
>   https://review.openstack.org/136652
> * Add a new aioeventlet executor
>   https://review.openstack.org/136653
>
> By the way, my review to add aioeventlet dependency also waits for a
> review:
>
> * Add aioeventlet dependency
>   https://review.openstack.org/138750
>
> Victor Stinner
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] pip 6.0.6 breaking py2* jobs - bug 1407736

[Matt Riedemann]

On 1/6/2015 7:27 AM, Ihar Hrachyshka wrote:


On 01/06/2015 03:09 AM, Matt Riedemann wrote:



On 1/5/2015 2:16 PM, Doug Hellmann wrote:


On Jan 5, 2015, at 12:22 PM, Doug Hellmann 
wrote:



On Jan 5, 2015, at 12:00 PM, Matt Riedemann
 wrote:


There is a deprecation warning in pip 6.0.6 which is making the
py26 (on stable branches) and py27 jobs hit subunit log sizes of
over 50 MB which makes the job fail.

A logstash query shows this started happening around 1/3 which is
when pip 6.0.6 was released. In Nova alone there are nearly 18
million hits of the deprecation warning.

Should we temporarily block so that pip < 6.0.6?

https://bugs.launchpad.net/nova/+bug/1407736


I think this is actually a change in pkg_resources (in the
setuptools dist) [1], being triggered by stevedore using
require=False to avoid checking dependencies when plugins are loaded.

Doug

[1]
https://bitbucket.org/pypa/setuptools/commits/b1c7a311fb8e167d026126f557f849450b859502



After some discussion with Jason Coombs and dstufft, a version of
setuptools with a split API to replace the deprecated option was
released. I have a patch up to teach stevedore about the new methods[1].

Doug

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






--

Thanks,

Matt Riedemann


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



The stevedore patch was merged. Do we need a release of stevedore and
a global-requirements update to then get the deprecation warnings
fixed in nova (on master and stable/juno)?



I guess so. Also, Icehouse is affected too. I've checked Nova
requirements.txt for Icehouse, and we don't cap steverore version, so a
new release will be automatically propagated to all new jobs.

/Ihar

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



I've closed the nova bug as a duplicate of the stevedore bug since the 
latest release of stevedore fixed the problem for my nova change on 
stable/juno, thanks Doug!


--

Thanks,

Matt Riedemann


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova]nova not work with eventlet 0.16.0

[Daniel P. Berrange]

On Tue, Jan 06, 2015 at 05:36:38PM +0100, Ihar Hrachyshka wrote:
> On 01/06/2015 05:33 PM, Daniel P. Berrange wrote:
> >On Tue, Jan 06, 2015 at 10:21:10AM -0600, Matt Riedemann wrote:
> >>Odd...eventlet 0.16.0 was released on 12/30 and the eventlet.util import is
> >>still in the libvirt host module, but this isn't blowing up in the Jenkins
> >>runs, so what's different?  There isn't a version cap on eventlet in
> >>global-requirements either.
> >When I pip install it in my dev env it still pulls in 0.15.2.
> >
> >Likewise looking at a jenkins log from today it pulls in 0.15.2
> >
> >   
> > http://logs.openstack.org/89/140089/3/check/gate-nova-python27/55b24ee/tox/py27-1.log
> >
> >But the pypi page refers to 0.16.0
> >
> >   https://pypi.python.org/pypi/eventlet/
> >
> >?!?!?
> >
> Maybe some external dependency pulls in older version?

Ah, it seems my devpi/wheel caching setup was not seeing the new version.
When I forced a refresh in that, it pulled down 0.16.0 Wonder if the gate
has a similar cache refresh issue

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

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [oslo] Progress of the port to Python 3

[victor stinner]

Hi,

I'm still working on porting OpenStack to Python 3. I'm fixing Python 3 issues 
in eventlet and I'm trying to replace eventlet with trollius in OpenStack. Two 
different and complementary ways to port OpenStack to Python 3.


I fixed some eventlet issues related to Python 3 and monkey-patching. My 
changes are part of eventlet 0.16 which was released the 2014-12-30. I tried 
this version with Oslo Messaging: with another fix in eventlet 
(threading.Condition) and a change in the zmq driver, only 3 tests are now 
failing (which is a great success for me).

See my Oslo Messaging change for more information:
https://review.openstack.org/#/c/145241/

It looks like eventlet 0.16 works much better with Python 3 and 
monkey-patching. You should try it on your own project! Tell me if you need 
help to fix issues.

--

About asyncio, I renamed my "aiogreen" project to "aioeventlet" (to make it 
more explicit that it is specific to eventlet). With the release 0.4, the API 
is now considered as stable.
http://aioeventlet.readthedocs.org/

Mehdi Abaakouk voted +2 on my Oslo Messaging patches to support trollius 
coroutines using aioeventlet project, but it looks that he's alone to review 
Oslo Messaging patches :-/ Anyway to approve my changes?

* Add an optional executor callback to dispatcher
  https://review.openstack.org/136652
* Add a new aioeventlet executor
  https://review.openstack.org/136653

By the way, my review to add aioeventlet dependency also waits for a review:

* Add aioeventlet dependency
  https://review.openstack.org/138750

Victor Stinner

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Octavia] Questions about the Octavia project

[Andrew Hutchings]

Hi,

I’m looking into the Octavia project in relation to something my team are 
working on inside HP and I have a bunch of questions.  I realise it is early 
days for the project and some of these could be too low level at this time.

Some of these questions come from the fact that I could not get the 
documentation to compile and the docs site for Octavia is down.  The 
v0.5-component-design.dot file crashes Graphviz 2.38 in every OS I tried and 
unfortunately all my dev machines have that version or 2.36 which is too low to 
render it correctly.  It also requires at least 5 extra dependencies (Sphinx 
modules) to build the docs but doesn’t try to install them.

I’ll guess I’ll start from the most obvious question:

1. Octavia looks a lot like Libra but with integration into Neutron and 
Barbican (both were planned for Libra) as well as few other changes.  So the 
most obvious question is: why not just develop Libra for integration with 
Neutron?

Amphorae stuff:

2. I see a lot of building blocks for the controller and Amphorae but not a lot 
about communication.  What protocol / method is to be used to communicate to 
the Amphorae instances?
3. How are Amphorae instances to be spun up on-demand?  I see a reference to 
Heat but not sure if that is why it is there
4. There is mention of Docker in some of the deploy scripts.  Is this for 
multi-tenancy or just separation of the Amphorae processes?
5. I take it Amphorae is designed to be single-AZ for now?

Load Balancing:

6. It seems like you are going to have SSL termination support and are going to 
use HAProxy, which means that you will have unencrypted data between the LB and 
web servers.  How do you plan to work around this problem?

Security:

7. Someone in the specification there is talk of a 1 minute cache of security 
certificates.  How are you going to ensure that the cache will actually erase 
that cache after the 1 minute?  Also why cache them at all?  It seems to me to 
be a potential security risk

API:

8. More a comment than a question.  There is talk of using Pecan+WSME.  Libra 
had a 5K patch on top of WSME just to make it behave correctly with Pecan and 
correct JSON specifications in certain situations, judging by the planned API 
you will also hit those same situations.  I admit I’ve not looked at WSME for a 
year and there was an effort to strip it out of Libra completely at one point.  
So that one is mainly my 2c :)

Many thanks for your time.

Kind Regards
--
Andrew Hutchings - LinuxJedi - http://www.linuxjedi.co.uk/





signature.asc
Description: Message signed with OpenPGP using GPGMail
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova]nova not work with eventlet 0.16.0

[Ihar Hrachyshka]

On 01/06/2015 05:33 PM, Daniel P. Berrange wrote:

On Tue, Jan 06, 2015 at 10:21:10AM -0600, Matt Riedemann wrote:

Odd...eventlet 0.16.0 was released on 12/30 and the eventlet.util import is
still in the libvirt host module, but this isn't blowing up in the Jenkins
runs, so what's different?  There isn't a version cap on eventlet in
global-requirements either.

When I pip install it in my dev env it still pulls in 0.15.2.

Likewise looking at a jenkins log from today it pulls in 0.15.2

   
http://logs.openstack.org/89/140089/3/check/gate-nova-python27/55b24ee/tox/py27-1.log

But the pypi page refers to 0.16.0

   https://pypi.python.org/pypi/eventlet/

?!?!?

Regards,
Daniel


Maybe some external dependency pulls in older version?

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova]nova not work with eventlet 0.16.0

[Daniel P. Berrange]

On Tue, Jan 06, 2015 at 10:21:10AM -0600, Matt Riedemann wrote:
> Odd...eventlet 0.16.0 was released on 12/30 and the eventlet.util import is
> still in the libvirt host module, but this isn't blowing up in the Jenkins
> runs, so what's different?  There isn't a version cap on eventlet in
> global-requirements either.

When I pip install it in my dev env it still pulls in 0.15.2.

Likewise looking at a jenkins log from today it pulls in 0.15.2

  
http://logs.openstack.org/89/140089/3/check/gate-nova-python27/55b24ee/tox/py27-1.log

But the pypi page refers to 0.16.0

  https://pypi.python.org/pypi/eventlet/

?!?!?

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

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] local and gate pep8 check comparsion

[Matt Riedemann]

On 1/6/2015 10:21 AM, Chen CH Ji wrote:

I got following error in patch
https://review.openstack.org/#/c/137009/ from Jenkins

_2015-01-06 12:24:20.445_

 |
./nova/compute/manager.py:5325:13: N331  Use LOG.warning due to
compatibility with py3
_2015-01-06 12:24:20.445_

 |
./nova/compute/manager.py:5726:13: N331  Use LOG.warning due to
compatibility with py3
_2015-01-06 12:24:20.916_

 |
ERROR: InvocationError:
'/home/jenkins/workspace/gate-nova-pep8/.tox/pep8/bin/flake8'

but I didn't get it either by ./run_test.sh -8 or tox -e pep8 in my
local test env, I am pretty sure I have the latest nova code so I think
I should get same result ?

Thanks a lot

Best Regards!

Kevin (Chen) Ji 纪 晨

Engineer, zVM Development, CSTL
Notes: Chen CH Ji/China/IBM@IBMCN   Internet: jiche...@cn.ibm.com
Phone: +86-10-82454158
Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian
District, Beijing 100193, PRC


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



Stale venv?  Try "tox -r -e pep8".

--

Thanks,

Matt Riedemann


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Telco] [NFV] Service function chaining

[Yuriy.Babenko]

Hi all, 

as discussed per last IRC meeting we prepared first thoughts on the 
requirements on Service Function Chaining (SFC) and relevant use-case. 

We have an etherpad for initial draft ideas. Later on we should move it to 
wiki. 

All comments are very welcome. 

https://etherpad.openstack.org/p/kKIqu2ipN6

Best, 
Yuriy 
Deutsche Telekom 

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova]nova not work with eventlet 0.16.0

[Matt Riedemann]

On 1/6/2015 6:33 AM, Jay Pipes wrote:

Thanks Eli, please do file a bug on Launchpad with your information below.

Best,
-jay

On 01/06/2015 04:18 AM, Eli Qiao wrote:

hi all ,
I set up nova environment with latest upstream code.
nova-compute can not boot up due to failed to load libvirt driver.
by further debugging. found that eventlet (0.16.0) remove util which is
referenced by libvirt driver.
after I downgrade to (0.15.2) it works.

*0.15.2*

In [3]: print eventlet.__version__
0.15.2

In [5]: import eventlet.util

In [6]:

-

*0.16.0**
*

In [1]: import eventlet.util
---

ImportError   Traceback (most recent call
last)
 in ()
> 1 import eventlet.util

ImportError: No module named util

In [3]: import eventlet

In [4]: print eventlet.__version__
0.16.0

In [5]:




In [1]: import nova.virt.libvirt.LibvirtDriver
---

ImportError   Traceback (most recent call
last)
 in ()
> 1 import nova.virt.libvirt.LibvirtDriver

/opt/stack/nova/nova/virt/libvirt/__init__.py in ()
  13 #under the License.
  14
---> 15 from nova.virt.libvirt import driver
  16
  17 LibvirtDriver = driver.LibvirtDriver

/opt/stack/nova/nova/virt/libvirt/driver.py in ()
  96 from nova.virt.libvirt import dmcrypt
  97 from nova.virt.libvirt import firewall as libvirt_firewall
---> 98 from nova.virt.libvirt import host
  99 from nova.virt.libvirt import imagebackend
 100 from nova.virt.libvirt import imagecache

/opt/stack/nova/nova/virt/libvirt/host.py in ()
  37 from eventlet import patcher
  38 from eventlet import tpool
---> 39 from eventlet import util as eventlet_util
  40
  41 from nova import exception

ImportError: cannot import name util

In [2]: import eventlet

In [3]: from eventlet import util
---

ImportError   Traceback (most recent call
last)
 in ()
> 1 from eventlet import util

ImportError: cannot import name util

In [4]:

--
Thanks,
Eli (Li Yong) Qiao



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



Odd...eventlet 0.16.0 was released on 12/30 and the eventlet.util import 
is still in the libvirt host module, but this isn't blowing up in the 
Jenkins runs, so what's different?  There isn't a version cap on 
eventlet in global-requirements either.


--

Thanks,

Matt Riedemann


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [nova] local and gate pep8 check comparsion

[Chen CH Ji]

I got following error in patch https://review.openstack.org/#/c/137009/
from Jenkins

2015-01-06 12:24:20.445 | ./nova/compute/manager.py:5325:13: N331  Use
LOG.warning due to compatibility with py3
2015-01-06 12:24:20.445 | ./nova/compute/manager.py:5726:13: N331  Use
LOG.warning due to compatibility with py3
2015-01-06 12:24:20.916 | ERROR: InvocationError:
'/home/jenkins/workspace/gate-nova-pep8/.tox/pep8/bin/flake8'

but I didn't get it either by ./run_test.sh -8 or tox -e pep8 in my local
test env, I am pretty sure I have the latest nova code so I think I should
get same result ?

Thanks a lot

Best Regards!

Kevin (Chen) Ji 纪 晨

Engineer, zVM Development, CSTL
Notes: Chen CH Ji/China/IBM@IBMCN   Internet: jiche...@cn.ibm.com
Phone: +86-10-82454158
Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District,
Beijing 100193, PRC___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] oslo.i18n 1.2.0 release

[Doug Hellmann]

This release is causing problems with some of Heat’s WSGI code that accesses 
private classes in oslo.i18n. We’re working on a fix: 
https://review.openstack.org/#/c/145257


> On Jan 6, 2015, at 10:15 AM, Doug Hellmann  wrote:
> 
> The Oslo team is pleased to announce the release of
> oslo.i18n 1.2.0: oslo.i18n library
> 
> The primary reason for this release is to move the code
> out of the oslo namespace package as part of
> https://blueprints.launchpad.net/oslo-incubator/+spec/drop-namespace-packages
> 
> For more details, please see the git log history below and
> http://launchpad.net/oslo.i18n/+milestone/1.2.0
> 
> Please report issues through launchpad:
> http://bugs.launchpad.net/oslo.i18n
> 
> 
> 
> Changes in openstack/oslo.i18n  1.1.0..1.2.0
> 
> 582c718 Correct the translation domain for loading messages
> ba05e9a Move out of the oslo namespace package
> c86629e Workflow documentation is now in infra-manual
> 53635ea Force code sample to be treated as python
> 
>  diffstat (except docs and test files):
> 
> CONTRIBUTING.rst|   7 +-
> oslo/i18n/__init__.py   |  23 +-
> oslo/i18n/_factory.py   | 110 --
> oslo/i18n/_gettextutils.py  |  90 -
> oslo/i18n/_i18n.py  |  25 --
> oslo/i18n/_lazy.py  |  38 --
> oslo/i18n/_locale.py|  25 --
> oslo/i18n/_message.py   | 167 -
> oslo/i18n/_translate.py |  73 
> oslo/i18n/fixture.py|  54 +--
> oslo/i18n/log.py|  86 +
> oslo_i18n/__init__.py   |  16 +
> oslo_i18n/_factory.py   | 110 ++
> oslo_i18n/_gettextutils.py  |  90 +
> oslo_i18n/_i18n.py  |  25 ++
> oslo_i18n/_lazy.py  |  38 ++
> oslo_i18n/_locale.py|  25 ++
> oslo_i18n/_message.py   | 167 +
> oslo_i18n/_translate.py |  73 
> oslo_i18n/fixture.py|  65 
> oslo_i18n/log.py|  97 ++
> setup.cfg   |   2 +-
> tests/fakes.py  |  59 
> tests/test_factory.py   |  91 -
> tests/test_fixture.py   |   2 +-
> tests/test_gettextutils.py  | 128 ---
> tests/test_handler.py   |   4 +-
> tests/test_lazy.py  |  40 ---
> tests/test_locale_dir_variable.py   |  32 --
> tests/test_logging.py   |  42 ---
> tests/test_message.py   | 518 
> tests/test_public_api.py|   2 +-
> tests/test_translate.py |  44 ---
> tests/test_warning.py   |  61 
> tests/utils.py  |  42 ---
> tox.ini |   2 +-
> 52 files changed, 2004 insertions(+), 1699 deletions(-)
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Tripp, Travis S]

Thanks, Radomir.

I originally started a patch on Horizon and was going to do that, but was
guided to update global requirements first.

I¹ll go ahead and redo that patch on Horizon.

-Travis

On 1/6/15, 2:00 AM, "Radomir Dopieralski"  wrote:

>On 06/01/15 01:39, Tripp, Travis S wrote:
>> What Radomir proposes looks like it would greatly ease the process I am
>>still going through to get the latest angular available to Horizon for
>>current development.  At the time of writing this, I¹m still trying to
>>get the updated library through.  I hit a rather difficult workflow:
>> 
>> 
>>   1.  Packaged the latest into Xstatic-Angular-1.3.7
>>   2.  Submitted patch which deprecated the separate older
>>xstatic-angular-cookies and xstatic-angular-mock packages
>>   3.  Reviewed and approved (after correcting an initial
>>mis-repackaging)
>>   4.  Radomir released to Pypi
>> 
>> This was pretty easy and not too hard. Not too much to complain about.
>> 
>> However, now, to get Horizon to use it, I have to get that into global
>>requirements.  Since I¹m deprecating old packages I got stuck in a sort
>>of ugly dependency path.  I couldn¹t remove the cookies and mock
>>libraries from the global requirements patch that added the new 1.3.7
>>package because of horizon still referencing the deprecated packages.
>>And, when I did it anyway, the integration tests failed due to horizon
>>being dependent on something not in global requirements.  So, now, as
>>far as I can tell we have to jump through the following hoops:
>> 
>> 
>>   1.  Global requirements patch to add angular 1.3.7
>>  *   Verify check / recheck fun
>>  *   Reviewed and approved
>>  *   Gate check / recheck fun
>>   2.  Horizon patch to update to angular 1.3.7 and remove deprecated
>>mock and cookies packages
>>  *   Verify check / recheck fun
>>  *   Reviewed and approved
>>  *   Gate check / recheck fun
>>   3.  Global requirements patch to remove deprecated mock and cookies
>>  *   Verify check / recheck fun
>>  *   Reviewed and approved
>>  *   Gate check / recheck fun
>> 
>> Don¹t get me wrong, I really do think the gate is brilliant and am all
>>for a review / approval process, but this does seem excessive for a UI
>>library that should only be used by Horizon. Is there some other reason
>>that this should have to go through global requirements?
>
>You can do it much easier, since the current version of Angular already
>packages what is in the deprecated modules. So just:
>
>1. Patch Horizon to remove the xstatic dependencies to the mock and
>cookies packages.
>2. Patch global-requirements to remove them, and add newer Angular.
>3. Patch Horizon to use the newer Angular.
>
>-- 
>Radomir Dopieralski
>
>___
>OpenStack-dev mailing list
>OpenStack-dev@lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][L3] Stop agent scheduling without stopping sevices

[Carl Baldwin]

Itsuro,

It would be desirable to be able to be hide an agent from scheduling
but no one has stepped up to make this happen.  Come to think of it,
I'm not sure that a bug or blueprint has been filed yet to address it
though it is something that I've wanted for a little while now.

Carl

On Mon, Jan 5, 2015 at 4:13 PM, Itsuro ODA  wrote:
> Neutron experts,
>
> I want to stop scheduling to a specific {dhcp|l3}_agent without
> stopping router/dhcp services on it.
> I expected setting admin_state_up of the agent to False is met
> this demand. But this operation stops all services on the agent
> in actuality. (Is this behavior intended ? It seems there is no
> document for agent API.)
>
> I think admin_state_up of agents should affect only scheduling.
> If it is accepted I will submit a bug report and make a fix.
>
> Or should I propose a blueprint for adding function to stop
> agent's scheduling without stopping services on it ?
>
> I'd like to hear neutron experts' suggestions.
>
> Thanks.
> Itsuro Oda
> --
> Itsuro ODA 
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [api] [sdk] Proposal to achieve consistency in client side sorting

[Steven Kaufer]

This is a follow up thread to [1]

In order to have consistency across clients, I am proposing that the client
side sorting has the following syntax: --sort [:]

Where the --sort parameter is comma-separated and is used to specify one or
more sort keys and directions. The direction defaults to 'desc' for each
sort key and the user can supply 'asc' to override.

For example:

  nova list --sort display_name
  nova list --sort display_name,vm_state
  nova list --sort display_name:asc,vm_state:asc

If approved, then the following changes are needed for glance and cinder
(note that nova already uses this syntax):

  Cinder: Deprecate --sort_key and --sort_dir and add support for --sort
  Glance: Modify [2] to this new syntax

I have not verified how all other projects handle sorting, there may be
other projects that would also need to be changed.

Thoughts?  Objections?

Also, if there is a more formal way to propose/review this standard please
let me know.

[1]
http://www.mail-archive.com/openstack-dev@lists.openstack.org/msg42854.html
[2] https://review.openstack.org/#/c/120777/

Thanks,
Steven Kaufer___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [kolla][tripleo] Announcing Kolla Milestone #2

[Steven Dake]

I'm pleased to announce the release of Kolla Milestone #2 available for 
immediate download from

https://github.com/stackforge/kolla/archive/version-m2.tar.gz.

Kolla is an effort to bring container deployment of OpenStack to TripleO.

This milestone brings several new features:

 * Integrated Neutron container

 * Integrated Ceilometer container

 * Integrated Horizon container

 * Integrated Zaqar container

 * Integrated Mongodb container


As can be seen from our list of updates, most of the work has been 
focused on updating the services we support to more fully deploy 
OpenStack.  Our huge feature this release is Neutron, which we would 
love people to test and use.


Instructions for running Kolla can be found with the software release in 
addition to our previous milestone #1 release at:

http://lists.openstack.org/pipermail/openstack-dev/2014-October/048970.html

Our milestone #3 and beyond will likely focus around tighter integration 
with TripleO.  For more details see:

https://review.openstack.org/#/c/144199/
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Openstack] [Devstack][Neutron]Neutron with External DHCP server

[John Belamaric]

We have a spec for implementing a DHCP relay agent [1], which would enable 
this.  We have implemented this, but it's not upstream (yet!). You would have 
to download our adapter [2] and dissect it to get the code from there, which 
may be pretty painful, because the package includes lots of changes related to 
our integration rather than just the relay.

The adapter uses ISC dhcrelay, but we had to patch it to add the link selection 
option. That code is also included with the adapter package, along with a build 
script for it.

[1] https://blueprints.launchpad.net/neutron/+spec/dhcp-relay
[2] https://www.infoblox.com/products/private-hybrid-cloud/openstack-adapter

From: Erhan Ekici mailto:erhan.ek...@gmail.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Tuesday, January 6, 2015 at 9:00 AM
To: foss geek mailto:thefossg...@gmail.com>>
Cc: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>, 
openstack mailto:openst...@lists.openstack.org>>
Subject: Re: [openstack-dev] [Openstack] [Devstack][Neutron]Neutron with 
External DHCP server

Hi,

As far as I know, there is a spec and feature for external dhcp server 
configuration but just for ironic project (bare metal installation).
Btw, I have not tested it yet.

http://specs.openstack.org/openstack/ironic-specs/specs/juno/support-external-dhcp.html

Erhan,





On Tue, Jan 6, 2015 at 1:04 PM, foss geek 
mailto:thefossg...@gmail.com>> wrote:
Dear All,

Is it possible to configure neutron to take VM ip from external DHCP server?

I am having All In One openstack env deployed using devstack icehouse. I am 
looking for an option to integrate it with external DHCP server.

--
Thanks & Regards
E-Mail: thefossg...@gmail.com
IRC: neophy
Blog : http://lmohanphy.livejournal.com/


___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : 
openst...@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Cross-Project meeting, Tue January 6th, 21:00 UTC

[Sean Dague]

On 01/06/2015 06:14 AM, Thierry Carrez wrote:
> Dear PTLs, cross-project liaisons and anyone else interested,
> 
> We'll have a cross-project meeting today at 21:00 UTC, with the
> following agenda:
> 
> * State of nova-network to neutron migration
> * Discuss openstack-spec: log guidelines [1]
> * Discuss openstack-spec: OSProfiler [2]
> * Open discussion & announcements
> 
> [1] https://review.openstack.org/#/c/132552/
> [2] https://review.openstack.org/#/c/134839/

I took another spin on [1] this morning attempting to clear up the
confusing parts and dumping the security section for now (as it was kind
of a mismatch in structure for this document).

Hopefully it's good enough to go at this point.

-Sean

> 
> See you there !
> 
> For more details on this meeting, please see:
> https://wiki.openstack.org/wiki/Meetings/CrossProjectMeeting
> 


-- 
Sean Dague
http://dague.net

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] oslo.i18n 1.2.0 release

[Doug Hellmann]

The Oslo team is pleased to announce the release of
oslo.i18n 1.2.0: oslo.i18n library

The primary reason for this release is to move the code
out of the oslo namespace package as part of
https://blueprints.launchpad.net/oslo-incubator/+spec/drop-namespace-packages

For more details, please see the git log history below and
 http://launchpad.net/oslo.i18n/+milestone/1.2.0

Please report issues through launchpad:
 http://bugs.launchpad.net/oslo.i18n



Changes in openstack/oslo.i18n  1.1.0..1.2.0

582c718 Correct the translation domain for loading messages
ba05e9a Move out of the oslo namespace package
c86629e Workflow documentation is now in infra-manual
53635ea Force code sample to be treated as python

  diffstat (except docs and test files):

 CONTRIBUTING.rst|   7 +-
 oslo/i18n/__init__.py   |  23 +-
 oslo/i18n/_factory.py   | 110 --
 oslo/i18n/_gettextutils.py  |  90 -
 oslo/i18n/_i18n.py  |  25 --
 oslo/i18n/_lazy.py  |  38 --
 oslo/i18n/_locale.py|  25 --
 oslo/i18n/_message.py   | 167 -
 oslo/i18n/_translate.py |  73 
 oslo/i18n/fixture.py|  54 +--
 oslo/i18n/log.py|  86 +
 oslo_i18n/__init__.py   |  16 +
 oslo_i18n/_factory.py   | 110 ++
 oslo_i18n/_gettextutils.py  |  90 +
 oslo_i18n/_i18n.py  |  25 ++
 oslo_i18n/_lazy.py  |  38 ++
 oslo_i18n/_locale.py|  25 ++
 oslo_i18n/_message.py   | 167 +
 oslo_i18n/_translate.py |  73 
 oslo_i18n/fixture.py|  65 
 oslo_i18n/log.py|  97 ++
 setup.cfg   |   2 +-
 tests/fakes.py  |  59 
 tests/test_factory.py   |  91 -
 tests/test_fixture.py   |   2 +-
 tests/test_gettextutils.py  | 128 ---
 tests/test_handler.py   |   4 +-
 tests/test_lazy.py  |  40 ---
 tests/test_locale_dir_variable.py   |  32 --
 tests/test_logging.py   |  42 ---
 tests/test_message.py   | 518 
 tests/test_public_api.py|   2 +-
 tests/test_translate.py |  44 ---
 tests/test_warning.py   |  61 
 tests/utils.py  |  42 ---
 tox.ini |   2 +-
 52 files changed, 2004 insertions(+), 1699 deletions(-)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Ironic] mid-cycle details

[Thierry Carrez]

Devananda van der Veen wrote:
> Dates: Feb 3 - 5 (Tue - Thu) with a half day for those sticking around
> on Friday, Feb 6th.
> 
> Location:
>   Hewlett Packard Centre de Compétences
>   5 Avenue Raymond Chanas
>   38320 Eybens
>   Grenoble, France

Could you please reference it on:
https://wiki.openstack.org/wiki/Sprints

Thanks!

-- 
Thierry Carrez (ttx)

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Fuel] update existing plugin and add new ones

[samuel.bartel]

Hello,

Actually there is two different fuel plugins git repositories. One in 
stackforge and the other in mirantis:
https://github.com/stackforge/fuel-plugins
https://github.com/Mirantis/fuel-plugins

it is a little bit confusing. Why needing two different repositories?

which one should be used in order to:
-add new plugin
-update/correct exisiting one (for example adding 7-mode and e-series support 
to cinder netapp plugin according to  
https://bugs.launchpad.net/fuel/+bug/1405186)
How are going to be manage version? There is a stable/6.0 branch from 
stackforge repo but not mirantis one

Regards,

Samuel Bartel
Orange




_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] stevedore 1.2.0 released

[Doug Hellmann]

The Oslo team is pleased to announce the release of
stevedore 1.2.0: Manage dynamic plugins for Python applications

This release includes an update to eliminate excessive deprecation
warnings generated by pkg_resources when plugins are loaded.

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

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



Changes in openstack/stevedore  1.1.0..1.2.0

37c94cd Use pkg_resources resolve() and require() instead of load()
9324bf0 Fix the README.rst file format for pypi
6027ff6 Workflow documentation is now in infra-manual
bbafbe9 Implement a __contains__ override for extension manager
f33adbe Update link to docs in README
a322d61 Bring doc build up to standard

  diffstat (except docs and test files):

 CONTRIBUTING.rst  |   2 +-
 README.rst|  12 +-
 setup.cfg |   4 +-
 stevedore/extension.py|  14 +-
 test-requirements.txt |   1 +
 54 files changed, 1792 insertions(+), 1734 deletions(-)

  Requirements updates:

 diff --git a/test-requirements.txt b/test-requirements.txt
 index 7f1e798..6075428 100644
 --- a/test-requirements.txt
 +++ b/test-requirements.txt
 @@ -11,0 +12 @@ oslotest>=1.2.0  # Apache-2.0
 +oslosphinx>=2.2.0  # Apache-2.0

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [stable] Stable check of openstack/keystone failed

[Dolph Mathews]

Both of these build failures should be fixed by:

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

(Thanks, Alan!)

On Tue, Jan 6, 2015 at 12:28 AM, A mailing list for the OpenStack Stable
Branch test reports.  wrote:

> Build failed.
>
> - periodic-keystone-docs-icehouse
> http://logs.openstack.org/periodic-stableperiodic-keystone-docs-icehouse/ac7970c/
> : FAILURE in 27s
> - periodic-keystone-python26-icehouse
> http://logs.openstack.org/periodic-stableperiodic-keystone-python26-icehouse/6f7ec11/
> : SUCCESS in 23m 03s
> - periodic-keystone-python27-icehouse
> http://logs.openstack.org/periodic-stableperiodic-keystone-python27-icehouse/527351e/
> : FAILURE in 41s
> - periodic-keystone-docs-juno
> http://logs.openstack.org/periodic-stableperiodic-keystone-docs-juno/6d4d68b/
> : SUCCESS in 5m 59s
> - periodic-keystone-python26-juno
> http://logs.openstack.org/periodic-stableperiodic-keystone-python26-juno/7517d87/
> : SUCCESS in 8m 24s
> - periodic-keystone-python27-juno
> http://logs.openstack.org/periodic-stableperiodic-keystone-python27-juno/727a389/
> : SUCCESS in 9m 40s
>
> ___
> Openstack-stable-maint mailing list
> openstack-stable-ma...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-stable-maint
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Openstack] [Devstack][Neutron]Neutron with External DHCP server

[Erhan Ekici]

Hi,

As far as I know, there is a spec and feature for external dhcp server
configuration but *just for ironic project* (bare metal installation).
Btw, I have not tested it yet.

http://specs.openstack.org/openstack/ironic-specs/specs/juno/support-external-dhcp.html

Erhan,





On Tue, Jan 6, 2015 at 1:04 PM, foss geek  wrote:

> Dear All,
>
> Is it possible to configure neutron to take VM ip from external DHCP
> server?
>
> I am having All In One openstack env deployed using devstack icehouse. I
> am looking for an option to integrate it with external DHCP server.
>
> --
> Thanks & Regards
> E-Mail: thefossg...@gmail.com
> IRC: neophy
> Blog : http://lmohanphy.livejournal.com/
>
>
> ___
> Mailing list:
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to : openst...@lists.openstack.org
> Unsubscribe :
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Devstack][Neutron]Neutron with External DHCP server

[Ihar Hrachyshka]

On 01/06/2015 12:04 PM, foss geek wrote:

Dear All,

Is it possible to configure neutron to take VM ip from external DHCP 
server?


I am having All In One openstack env deployed using devstack icehouse. 
I am looking for an option to integrate it with external DHCP server.


At the moment, there is no way to achieve this, though the option was 
discussed as part of Pluggable IPAM effort that was approved for Kilo: 
http://git.openstack.org/cgit/openstack/neutron-specs/tree/specs/kilo/neutron-ipam.rst


Quoting the spec: "Out-of-Scope Items [...] Pluggable DHCP would require 
a separate effort,

or must be addressed within the individual drivers."

/Ihar

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [cinder] [nova] [glance] Consistency in client side sorting

[Duncan Thomas]

I've got no strong preferences on which we go for, but agree they should be
consistent. The internal python library options should also be consistent.

On 5 January 2015 at 20:52, Mike Perez  wrote:

> On 09:13 Mon 05 Jan , Steven Kaufer wrote:
> > Giving that each of these 3 clients will be supporting client-side
> sorting
> > in kilo, it seems that we should get this implemented in a consistent
> > manner.  It seems that the 2 options are either:
> >
> >   --sort-key key1 --sort-dir desc --sort-key key2 --sort-dir asc
> >   --sort key1:asc,key2:desc
> >
> > Personally, I favor option 2 but IMO it is more important that these are
> > made consistent.
>
> I like option 2 better.
>
> --
> Mike Perez
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Duncan Thomas
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [heat][oslo] heat unit tests mocking private parts of oslo.messaging

[Jay Pipes]

On 01/05/2015 06:03 PM, Doug Hellmann wrote:

As part of updating oslo.messaging to move it out of the oslo
namespace package I ran into some issues with heat. While debugging,
I tried running the heat unit tests using the modified version of
oslo.messaging and ran into test failures because the tests are
mocking private parts of the library that are moving to have new
names.


It's just never polite to mock someone's private parts.

Best,
-jay

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] pip 6.0.6 breaking py2* jobs - bug 1407736

[Ihar Hrachyshka]

On 01/06/2015 03:09 AM, Matt Riedemann wrote:



On 1/5/2015 2:16 PM, Doug Hellmann wrote:


On Jan 5, 2015, at 12:22 PM, Doug Hellmann  
wrote:




On Jan 5, 2015, at 12:00 PM, Matt Riedemann 
 wrote:


There is a deprecation warning in pip 6.0.6 which is making the 
py26 (on stable branches) and py27 jobs hit subunit log sizes of 
over 50 MB which makes the job fail.


A logstash query shows this started happening around 1/3 which is 
when pip 6.0.6 was released. In Nova alone there are nearly 18 
million hits of the deprecation warning.


Should we temporarily block so that pip < 6.0.6?

https://bugs.launchpad.net/nova/+bug/1407736


I think this is actually a change in pkg_resources (in the 
setuptools dist) [1], being triggered by stevedore using 
require=False to avoid checking dependencies when plugins are loaded.


Doug

[1] 
https://bitbucket.org/pypa/setuptools/commits/b1c7a311fb8e167d026126f557f849450b859502


After some discussion with Jason Coombs and dstufft, a version of 
setuptools with a split API to replace the deprecated option was 
released. I have a patch up to teach stevedore about the new methods[1].


Doug

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






--

Thanks,

Matt Riedemann


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



The stevedore patch was merged. Do we need a release of stevedore and 
a global-requirements update to then get the deprecation warnings 
fixed in nova (on master and stable/juno)?




I guess so. Also, Icehouse is affected too. I've checked Nova 
requirements.txt for Icehouse, and we don't cap steverore version, so a 
new release will be automatically propagated to all new jobs.


/Ihar

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] Questions on pep8 F811 hacking check for microversion

[Sean Dague]

On 01/06/2015 06:25 AM, Chen CH Ji wrote:
> Based on nova-specs api-microversions.rst
> we support following function definition format, but it violate the
> hacking rule pep8 F811 because duplicate function definition
> we should use #noqa for them , but considering microversion may live for
> long time ,
> keep adding #noqa may be a little bit ugly, can anyone suggest a good
> solution for it ? thanks
> 
>>   @api_version(min_version='2.1')
>>   def _version_specific_func(self, req, arg1):
>>  pass
>>
>>   @api_version(min_version='2.5')
>>   def _version_specific_func(self, req, arg1):
>>  pass

Can you show the patch in question? (this is the only one I see -
https://review.openstack.org/#/c/144995/3/nova/api/openstack/compute/plugins/v3/hosts.py,cm)


We knew this was going to be an evolution. I think it was only ever
envisioned that @api_version would be used at the top level dispatch,
not 5 levels of private methods deep. The patch above does something
extremely unexpected, and not what I wanted to see out of this for sure.

-Sean

-- 
Sean Dague
http://dague.net

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Support for Amazon VPC APIs in OpenStack

[Jay Pipes]

On 01/06/2015 12:44 AM, Saju M wrote:

Hi,

I seen a blueprint which implement Amazon VPC APIs and Status is Abandoned
https://review.openstack.org/#/c/40071/

Have any plans to get it done in Kilo release ?
How can I change the Abandoned status ?.
Have any dependencies ?

Please let me know, So I can rebase it.


Hi Saju,

We'd need to see a nova-specs submission for this work, first. You could 
take much of the content from 
https://wiki.openstack.org/wiki/Blueprint-aws-vpc-support for the 
content of the nova-spec submission, though you will want to change 
references to "Quantum" to "Neutron" :)


The nova-specs submission is covered here:

https://wiki.openstack.org/wiki/Blueprints#Nova

Note that due to it being late in the cycle, it will be unlikely to get 
a newly-submitted spec approved, but that does not mean you cannot work 
on code that implements the spec.


Best,
-jay

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] Questions on pep8 F811 hacking check for microversion

[Alex Xu]

2015-01-06 20:31 GMT+08:00 Jay Pipes :

> On 01/06/2015 06:25 AM, Chen CH Ji wrote:
>
>> Based on nova-specs api-microversions.rst
>> we support following function definition format, but it violate the
>> hacking rule pep8 F811 because duplicate function definition
>> we should use #noqa for them , but considering microversion may live for
>> long time ,
>> keep adding #noqa may be a little bit ugly, can anyone suggest a good
>> solution for it ? thanks
>>
>>  >   @api_version(min_version='2.1')
>>  >   def _version_specific_func(self, req, arg1):
>>  >  pass
>>  >
>>  >   @api_version(min_version='2.5')
>>  >   def _version_specific_func(self, req, arg1):
>>  >  pass
>>
>
> Hey Kevin,
>
> This was actually one of my reservations about the proposed
> microversioning implementation -- i.e. having functions that are named
> exactly the same, only decorated with the microversioning notation. It
> kinda reminds me of the hell of debugging C++ code that uses STL: how does
> one easily know which method one is in when inside a debugger?
>
> That said, the only other technique we could try to use would be to not
> use a decorator and instead have a top-level dispatch function that would
> inspect the API microversion (only when the API version makes a difference
> to the output or input of that function) and then dispatch the call to a
> helper method that had the version in its name.
>
> So, for instance, let's say you are calling the controller's GET
> /$tenant/os-hosts method, which happens to get routed to the
> nova.api.openstack.compute.contrib.hosts.HostController.index() method.
> If you wanted to modify the result of that method and the API microversion
> is at 2.5, you might do something like:
>
>  def index(self, req):
>  req_api_ver = utils.get_max_requested_api_version(req)
>  if req_api_ver == (2, 5):
>  return self.index_2_5(req)
>  return self.index_2_1(req)
>
>  def index_2_5(self, req):
>  results = self.index_2_1(req)
>  # Replaces 'host' with 'host_name'
>  for result in results:
>  result['host_name'] = result['host']
>  del result['host']
>  return results
>
>  def index_2_1(self, req):
>  # Would be a rename of the existing index() method on
>  # the controller
>
> Another option would be to use something like JSON-patch to determine the
> difference between two output schemas and automatically translate one to
> another... but that would be a huge effort.
>

Just JSON-patch only can resolve multiple-version of request/response, we
need handle semantic change also.

But I still think we need something like JSON-patch, it can avoid add new
method only for small request/response changing, like this patch
https://review.openstack.org/#/c/144995/3

I have propose before, we can try mapping the request/response into nova
object by json-schema automatically, the nova object will handle the
change. When the request/response changed, nothing will change in REST API
code. I wrote the POC before
https://github.com/soulxu/nova-v3-api-doc/commits/micro_ver_with_obj_auto_mapping
This is more easy to maintenance than JSON-patch(thinking about the case of
3.3 patch based on 3.2 patch based on 3.1 patch.)


> That's the only other way I can think of besides disabling F811, which I
> really would not recommend, since it's a valuable safeguard against
> duplicate function names (especially duplicated test methods).
>
> Best,
> -jay
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [FUEL] Zabbix in HA mode

[Jay Pipes]

On 01/05/2015 04:05 PM, Andrew Woodward wrote:

  Secondly running monitoring on the cluster may
also result in the monitoring going offline if the cluster does, from
my own experience, not being able to see your monitoring is nearly
worse than having everything down and leads to lost precious moments
of downtime SLA.


Yep, this is exactly my experience as well. Excellent point.

-jay

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] Questions on pep8 F811 hacking check for microversion

[Daniel P. Berrange]

On Tue, Jan 06, 2015 at 07:31:19AM -0500, Jay Pipes wrote:
> On 01/06/2015 06:25 AM, Chen CH Ji wrote:
> >Based on nova-specs api-microversions.rst
> >we support following function definition format, but it violate the
> >hacking rule pep8 F811 because duplicate function definition
> >we should use #noqa for them , but considering microversion may live for
> >long time ,
> >keep adding #noqa may be a little bit ugly, can anyone suggest a good
> >solution for it ? thanks
> >
> > >   @api_version(min_version='2.1')
> > >   def _version_specific_func(self, req, arg1):
> > >  pass
> > >
> > >   @api_version(min_version='2.5')
> > >   def _version_specific_func(self, req, arg1):
> > >  pass
> 
> Hey Kevin,
> 
> This was actually one of my reservations about the proposed microversioning
> implementation -- i.e. having functions that are named exactly the same,
> only decorated with the microversioning notation. It kinda reminds me of the
> hell of debugging C++ code that uses STL: how does one easily know which
> method one is in when inside a debugger?
> 
> That said, the only other technique we could try to use would be to not use
> a decorator and instead have a top-level dispatch function that would
> inspect the API microversion (only when the API version makes a difference
> to the output or input of that function) and then dispatch the call to a
> helper method that had the version in its name.
> 
> So, for instance, let's say you are calling the controller's GET
> /$tenant/os-hosts method, which happens to get routed to the
> nova.api.openstack.compute.contrib.hosts.HostController.index() method. If
> you wanted to modify the result of that method and the API microversion is
> at 2.5, you might do something like:
> 
>  def index(self, req):
>  req_api_ver = utils.get_max_requested_api_version(req)
>  if req_api_ver == (2, 5):
>  return self.index_2_5(req)
>  return self.index_2_1(req)
> 
>  def index_2_5(self, req):
>  results = self.index_2_1(req)
>  # Replaces 'host' with 'host_name'
>  for result in results:
>  result['host_name'] = result['host']
>  del result['host']
>  return results
> 
>  def index_2_1(self, req):
>  # Would be a rename of the existing index() method on
>  # the controller

Yes, I'd much prefer to see us use version numbers in the method names
like this and not have identically named methods. With some cleverness
we could perhaps avoid the need for the repetative 'index' impl and just
auto-detect the versioned method names when needed.

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

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova]nova not work with eventlet 0.16.0

[Jay Pipes]

Thanks Eli, please do file a bug on Launchpad with your information below.

Best,
-jay

On 01/06/2015 04:18 AM, Eli Qiao wrote:

hi all ,
I set up nova environment with latest upstream code.
nova-compute can not boot up due to failed to load libvirt driver.
by further debugging. found that eventlet (0.16.0) remove util which is
referenced by libvirt driver.
after I downgrade to (0.15.2) it works.

*0.15.2*

In [3]: print eventlet.__version__
0.15.2

In [5]: import eventlet.util

In [6]:

-
*0.16.0**
*

In [1]: import eventlet.util
---
ImportError   Traceback (most recent call last)
 in ()
> 1 import eventlet.util

ImportError: No module named util

In [3]: import eventlet

In [4]: print eventlet.__version__
0.16.0

In [5]:




In [1]: import nova.virt.libvirt.LibvirtDriver
---
ImportError   Traceback (most recent call last)
 in ()
> 1 import nova.virt.libvirt.LibvirtDriver

/opt/stack/nova/nova/virt/libvirt/__init__.py in ()
  13 #under the License.
  14
---> 15 from nova.virt.libvirt import driver
  16
  17 LibvirtDriver = driver.LibvirtDriver

/opt/stack/nova/nova/virt/libvirt/driver.py in ()
  96 from nova.virt.libvirt import dmcrypt
  97 from nova.virt.libvirt import firewall as libvirt_firewall
---> 98 from nova.virt.libvirt import host
  99 from nova.virt.libvirt import imagebackend
 100 from nova.virt.libvirt import imagecache

/opt/stack/nova/nova/virt/libvirt/host.py in ()
  37 from eventlet import patcher
  38 from eventlet import tpool
---> 39 from eventlet import util as eventlet_util
  40
  41 from nova import exception

ImportError: cannot import name util

In [2]: import eventlet

In [3]: from eventlet import util
---
ImportError   Traceback (most recent call last)
 in ()
> 1 from eventlet import util

ImportError: cannot import name util

In [4]:

--
Thanks,
Eli (Li Yong) Qiao



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Problem installing devstack

[Rajdeep Dua]

Thanks for the responses RECLONE=yes worked for me.

On Tue, Jan 6, 2015 at 11:14 AM, Dr. Jens Rosenboom 
wrote:

> Am 06/01/15 um 04:40 schrieb Rajdeep Dua:
>
>  Getting this error while running stack.sh in devstack
>>
>> Could not find a version that satisfies the requirement
>> SQLAlchemy<=0.8.99,<=0.9.99,>=0.8.4,>=0.9.7 (from
>> keystone==2014.2.dev114)
>> (from versions: 0.4.2p3, 0.4.7p1, 0.5.4p1, 0.5.4p2, 0.1.0, 0.1.1, 0.1.2,
>> 0.1.3, 0.1.4, 0.1.5, 0.1.6, 0.1.7, 0.2.0, 0.2.1, 0.2.2, 0.2.3, 0.2.4,
>> 0.2.5, 0.2.6, 0.2.7, 0.2.8, 0.3.0, 0.3.1, 0.3.2, 0.3.3, 0.3.4, 0.3.5,
>> 0.3.6, 0.3.7, 0.3.8, 0.3.9, 0.3.10, 0.3.11, 0.4.0b1, 0.4.0b2, 0.4.0b3,
>> 0.4.0b4, 0.4.0b5, 0.4.0b6, 0.4.0, 0.4.1, 0.4.2a0, 0.4.2b0, 0.4.2, 0.4.3,
>> 0.4.4, 0.4.5, 0.4.6, 0.4.7, 0.4.8, 0.5.0b1, 0.5.0b2, 0.5.0b3, 0.5.0rc1,
>> 0.5.0rc2, 0.5.0rc3, 0.5.0rc4, 0.5.0, 0.5.1, 0.5.2, 0.5.3, 0.5.4, 0.5.5,
>> 0.5.6, 0.5.7, 0.5.8, 0.6b1, 0.6b2, 0.6b3, 0.6.0, 0.6.1, 0.6.2, 0.6.3,
>> 0.6.4, 0.6.5, 0.6.6, 0.6.7, 0.6.8, 0.6.9, 0.7.0, 0.7.1, 0.7.2, 0.7.3,
>> 0.7.4, 0.7.5, 0.7.6, 0.7.7, 0.7.8, 0.7.9, 0.7.10, 0.8.0b2, 0.8.0, 0.8.1,
>> 0.8.2, 0.8.3, 0.8.4, 0.8.5, 0.8.6, 0.8.7, 0.9.0, 0.9.1, 0.9.2, 0.9.3,
>> 0.9.4, 0.9.5, 0.9.6, 0.9.7, 0.9.8)
>>No distributions matching the version for
>> SQLAlchemy<=0.8.99,<=0.9.99,>=0.8.4,>=0.9.7 (from
>> keystone==2014.2.dev114)
>>
>> I saw a couple of bugs filed and patches going in.
>>
>> Please clarify if this is fixed and how to get the latest changes in.
>>
>
> I would assume that you are trying to reuse an older devstack
> installation, as this bug should have been fixed a couple of weeks ago.
>
> However, running stack.sh by default does not update the source repos once
> they exist, so you can either add "RECLONE=yes" to your config or go
> manually through the repos in /opt/stack and update them.
>
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] Questions on pep8 F811 hacking check for microversion

[Jay Pipes]

On 01/06/2015 06:25 AM, Chen CH Ji wrote:

Based on nova-specs api-microversions.rst
we support following function definition format, but it violate the
hacking rule pep8 F811 because duplicate function definition
we should use #noqa for them , but considering microversion may live for
long time ,
keep adding #noqa may be a little bit ugly, can anyone suggest a good
solution for it ? thanks

 >   @api_version(min_version='2.1')
 >   def _version_specific_func(self, req, arg1):
 >  pass
 >
 >   @api_version(min_version='2.5')
 >   def _version_specific_func(self, req, arg1):
 >  pass


Hey Kevin,

This was actually one of my reservations about the proposed 
microversioning implementation -- i.e. having functions that are named 
exactly the same, only decorated with the microversioning notation. It 
kinda reminds me of the hell of debugging C++ code that uses STL: how 
does one easily know which method one is in when inside a debugger?


That said, the only other technique we could try to use would be to not 
use a decorator and instead have a top-level dispatch function that 
would inspect the API microversion (only when the API version makes a 
difference to the output or input of that function) and then dispatch 
the call to a helper method that had the version in its name.


So, for instance, let's say you are calling the controller's GET 
/$tenant/os-hosts method, which happens to get routed to the 
nova.api.openstack.compute.contrib.hosts.HostController.index() method. 
If you wanted to modify the result of that method and the API 
microversion is at 2.5, you might do something like:


 def index(self, req):
 req_api_ver = utils.get_max_requested_api_version(req)
 if req_api_ver == (2, 5):
 return self.index_2_5(req)
 return self.index_2_1(req)

 def index_2_5(self, req):
 results = self.index_2_1(req)
 # Replaces 'host' with 'host_name'
 for result in results:
 result['host_name'] = result['host']
 del result['host']
 return results

 def index_2_1(self, req):
 # Would be a rename of the existing index() method on
 # the controller

Another option would be to use something like JSON-patch to determine 
the difference between two output schemas and automatically translate 
one to another... but that would be a huge effort.


That's the only other way I can think of besides disabling F811, which I 
really would not recommend, since it's a valuable safeguard against 
duplicate function names (especially duplicated test methods).


Best,
-jay

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [nova] Questions on pep8 F811 hacking check for microversion

[Chen CH Ji]

Based on nova-specs api-microversions.rst
we support following function definition format, but it violate the hacking
rule pep8 F811 because duplicate function definition
we should use #noqa for them , but considering microversion may live for
long time ,
keep adding #noqa may be a little bit ugly, can anyone suggest a good
solution for it ? thanks

>   @api_version(min_version='2.1')
>   def _version_specific_func(self, req, arg1):
>  pass
>
>   @api_version(min_version='2.5')
>   def _version_specific_func(self, req, arg1):
>  pass



Best Regards!

Kevin (Chen) Ji 纪 晨

Engineer, zVM Development, CSTL
Notes: Chen CH Ji/China/IBM@IBMCN   Internet: jiche...@cn.ibm.com
Phone: +86-10-82454158
Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District,
Beijing 100193, PRC___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [nova] microversion and backward incompatible changes on v2.1

[Chen CH Ji]

Hi
https://review.openstack.org/#/c/144995/ introduced a
backward incompatible change with mirco version support
and I think it's the microversion's purpose to enable v2.1
(v3) API to make those changes

The question is whether we should make bp for each change
for the API change? should we make a simple bp or go through the nova-spec
process? Thanks a lot

Best Regards!

Kevin (Chen) Ji 纪 晨

Engineer, zVM Development, CSTL
Notes: Chen CH Ji/China/IBM@IBMCN   Internet: jiche...@cn.ibm.com
Phone: +86-10-82454158
Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District,
Beijing 100193, PRC___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] Cross-Project meeting, Tue January 6th, 21:00 UTC

[Thierry Carrez]

Dear PTLs, cross-project liaisons and anyone else interested,

We'll have a cross-project meeting today at 21:00 UTC, with the
following agenda:

* State of nova-network to neutron migration
* Discuss openstack-spec: log guidelines [1]
* Discuss openstack-spec: OSProfiler [2]
* Open discussion & announcements

[1] https://review.openstack.org/#/c/132552/
[2] https://review.openstack.org/#/c/134839/

See you there !

For more details on this meeting, please see:
https://wiki.openstack.org/wiki/Meetings/CrossProjectMeeting

-- 
Thierry Carrez (ttx)

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Devstack][Neutron]Neutron with External DHCP server

[foss geek]

Dear All,

Is it possible to configure neutron to take VM ip from external DHCP server?

I am having All In One openstack env deployed using devstack icehouse. I am
looking for an option to integrate it with external DHCP server.

-- 
Thanks & Regards
E-Mail: thefossg...@gmail.com
IRC: neophy
Blog : http://lmohanphy.livejournal.com/
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Glance] IRC logging

[Flavio Percoco]

On 05/01/15 08:57 -0800, Morgan Fainberg wrote:




On Jan 5, 2015, at 08:07, Nikhil Komawar  wrote:

Based on the feedback received, we would like to avoid logging on the project 
channel. My take from the discussion was that it gives many a folks a feeling 
of informal platform to express their ideas freely in contrast to the meeting 
channels.

However, at the same time I would like to point out that using foul language in the open 
freenode channels is a bad practice. There are no admins monitoring our project channels 
however, those channels that are monitored have people kicked out on misbehavior.  The 
point being, "no logging" means freedom of thought for only the creative 
purposes; please do not take me any other way.

Thanks,
-Nikhil



I just want to point out that keystone has logging enabled for our channel and 
I do not see it as a hamper to creative discussion / open discussion. The 
logging is definitely of value. Also a lot of people will locally log a given 
irc channel, which largely nets the same result.

It is still not an official meeting, and we have heated debates at times, the 
logging let's us check back on things discussed outside of the official 
meetings. I do admit it is used less frequently than the meeting logs.


Fully agree... I don't see how enable logging should be a limitation
for freedom of thought. We've used it in Zaqar since day 0 and it's
bee of great help for all of us.

The logging does not remove the need of meetings where decisions and
more relevant/important topics are discussed.



From: Anita Kuno [ante...@anteaya.info]
Sent: Monday, January 05, 2015 10:42 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Glance] IRC logging


On 01/05/2015 06:42 AM, Cindy Pallares wrote:
Hi all,

I would like to re-open the discussion on IRC logging for the glance
channel. It was discussed on a meeting back in November[1], but it
didn't seem to have a lot of input from the community and it was not
discussed in the mailing list. A lot of information is exchanged through
the channel and it isn't accessible for people who occasionally come
into our channel from other projects, new contributors, and people who
don't want to be reached off-hours or don't have bouncers. Logging our
channel would  increase our community's transparency and make our
development discussions publicly accessible to contributors in all
time-zones and from other projects. It is very useful to look back on
the logs for previous discussions or as well as to refer people to
discussions or questions previously answered.


+2

Thanks for bringing this up :)

Flavio

--
@flaper87
Flavio Percoco


pgpq0Ec4GfNbo.pgp
Description: PGP signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [stable-maint] acceptable changes for stable/icehouse

[Thierry Carrez]

John Griffith wrote:
> On Mon, Jan 5, 2015 at 4:39 PM, Jay S. Bryant
>  wrote:
>> All,
>>
>> We have been getting a number of non-security patches proposed to
>> stable/icehouse for Cinder.  The cores were discussing what was ok to put
>> into icehouse at this point in time and couldn't agree as to whether we were
>> at the point of only accepting security changes.
>>
>> Appreciate advice on this topic.
>>
> 
> Hey Jay,
> 
> Thanks for raising this, my understanding was that we were in fact
> security only mode now for Icehouse.  That being said I completely
> forgot that it's been that long already and I let some reviews slip
> myself just today in fact.  Thanks for pointing it out.

Icehouse is now 9-month old, so it is in phase II support ("only
critical bugfixes and security patches are acceptable").

Reference: https://wiki.openstack.org/wiki/StableBranch#Support_phases

In case of doubt, you can ask stable-maint-core people for advice:
https://review.openstack.org/#/admin/groups/530,members

-- 
Thierry Carrez (ttx)

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [nova]nova not work with eventlet 0.16.0

[Eli Qiao]

hi all ,
I set up nova environment with latest upstream code.
nova-compute can not boot up due to failed to load libvirt driver.
by further debugging. found that eventlet (0.16.0) remove util which is 
referenced by libvirt driver.

after I downgrade to (0.15.2) it works.

*0.15.2*

In [3]: print eventlet.__version__
0.15.2

In [5]: import eventlet.util

In [6]:

-
*0.16.0**
*

In [1]: import eventlet.util
---
ImportError   Traceback (most recent call last)
 in ()
> 1 import eventlet.util

ImportError: No module named util

In [3]: import eventlet

In [4]: print eventlet.__version__
0.16.0

In [5]:




In [1]: import nova.virt.libvirt.LibvirtDriver
---
ImportError   Traceback (most recent call last)
 in ()
> 1 import nova.virt.libvirt.LibvirtDriver

/opt/stack/nova/nova/virt/libvirt/__init__.py in ()
 13 #under the License.
 14
---> 15 from nova.virt.libvirt import driver
 16
 17 LibvirtDriver = driver.LibvirtDriver

/opt/stack/nova/nova/virt/libvirt/driver.py in ()
 96 from nova.virt.libvirt import dmcrypt
 97 from nova.virt.libvirt import firewall as libvirt_firewall
---> 98 from nova.virt.libvirt import host
 99 from nova.virt.libvirt import imagebackend
100 from nova.virt.libvirt import imagecache

/opt/stack/nova/nova/virt/libvirt/host.py in ()
 37 from eventlet import patcher
 38 from eventlet import tpool
---> 39 from eventlet import util as eventlet_util
 40
 41 from nova import exception

ImportError: cannot import name util

In [2]: import eventlet

In [3]: from eventlet import util
---
ImportError   Traceback (most recent call last)
 in ()
> 1 from eventlet import util

ImportError: cannot import name util

In [4]:

--
Thanks,
Eli (Li Yong) Qiao

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Radomir Dopieralski]

On 06/01/15 01:39, Tripp, Travis S wrote:
> What Radomir proposes looks like it would greatly ease the process I am still 
> going through to get the latest angular available to Horizon for current 
> development.  At the time of writing this, I’m still trying to get the 
> updated library through.  I hit a rather difficult workflow:
> 
> 
>   1.  Packaged the latest into Xstatic-Angular-1.3.7
>   2.  Submitted patch which deprecated the separate older 
> xstatic-angular-cookies and xstatic-angular-mock packages
>   3.  Reviewed and approved (after correcting an initial mis-repackaging)
>   4.  Radomir released to Pypi
> 
> This was pretty easy and not too hard. Not too much to complain about.
> 
> However, now, to get Horizon to use it, I have to get that into global 
> requirements.  Since I’m deprecating old packages I got stuck in a sort of 
> ugly dependency path.  I couldn’t remove the cookies and mock libraries from 
> the global requirements patch that added the new 1.3.7 package because of 
> horizon still referencing the deprecated packages.  And, when I did it 
> anyway, the integration tests failed due to horizon being dependent on 
> something not in global requirements.  So, now, as far as I can tell we have 
> to jump through the following hoops:
> 
> 
>   1.  Global requirements patch to add angular 1.3.7
>  *   Verify check / recheck fun
>  *   Reviewed and approved
>  *   Gate check / recheck fun
>   2.  Horizon patch to update to angular 1.3.7 and remove deprecated mock and 
> cookies packages
>  *   Verify check / recheck fun
>  *   Reviewed and approved
>  *   Gate check / recheck fun
>   3.  Global requirements patch to remove deprecated mock and cookies
>  *   Verify check / recheck fun
>  *   Reviewed and approved
>  *   Gate check / recheck fun
> 
> Don’t get me wrong, I really do think the gate is brilliant and am all for a 
> review / approval process, but this does seem excessive for a UI library that 
> should only be used by Horizon. Is there some other reason that this should 
> have to go through global requirements?

You can do it much easier, since the current version of Angular already
packages what is in the deprecated modules. So just:

1. Patch Horizon to remove the xstatic dependencies to the mock and
cookies packages.
2. Patch global-requirements to remove them, and add newer Angular.
3. Patch Horizon to use the newer Angular.

-- 
Radomir Dopieralski

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Horizon switching to the normal .ini format

[Matthias Runge]

On 05/01/15 19:27, Matthew Farina wrote:
> Switching to an ini format would likely be painful to impossible.
> 
> Horizon is built on django which is where the settings.py format comes
> from. It's part of a django app.
> 
> For more info see the django docs. The settings information is at
> https://docs.djangoproject.com/en/1.6/topics/settings/
> 

Sorry, I fail to see, how this should be impossible, esp. if you look at
the linked patch; the rest of the stack uses such an .ini format, too.


Matthias
> On Thu, Dec 25, 2014 at 1:25 PM, Timur Sufiev  > wrote:
> 
> Thomas,
> 
> I could only point you to the Radomir's
> patch https://review.openstack.org/#/c/100521/
> 
> It's still a work in progress, so you may ask him for more details.
> 


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][vpnaas] VPNaaS Subteam meeting Tuesday 1500 UTC meeting-4

[Mathieu Rohon]

Thanks Paul,

I'll be there!

Mathieu

On Mon, Jan 5, 2015 at 8:43 PM, Paul Michali (pcm)  wrote:
> Since we took a break for two weeks and the meeting channel has changed, I
> figured I send a reminder.
>
> Please update the page for any agenda items you may have,
>
> Regards,
>
>
> PCM (Paul Michali)
>
> MAIL …..…. p...@cisco.com
> IRC ……..… pc_m (irc.freenode.com)
> TW ………... @pmichali
> GPG Key … 4525ECC253E31A83
> Fingerprint .. 307A 96BB 1A4C D2C7 931D 8D2D 4525 ECC2 53E3 1A83
>
>
>
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev