Re: [openstack-dev] [Neutron] - DVR L3 data plane performance results and scenarios

[Gal Sagie]

Hi Swami,

Any luck on this? we plan to share our results soon and want to see we
cover all cases
and tests results are good

On Fri, Feb 19, 2016 at 7:49 PM, Vasudevan, Swaminathan (PNB Roseville) <
swaminathan.vasude...@hpe.com> wrote:

> Hi Gal Sagie,
>
> Let me try to pull in the data and will provide you the information.
>
> Thanks
>
> Swami
>
>
>
> *From:* Gal Sagie [mailto:gal.sa...@gmail.com]
> *Sent:* Thursday, February 18, 2016 9:36 PM
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Cc:* Yuli Stremovsky; Shlomo Narkolayev; Eran Gampel
> *Subject:* Re: [openstack-dev] [Neutron] - DVR L3 data plane performance
> results and scenarios
>
>
>
> Hi Swami,
>
>
>
> Thanks for the reply, is there any detailed links that describe this that
> we can look at?
>
>
>
> (Of course that having results without the full setup (hardware/ NIC, CPU
> and threads for OVS and so on..) details
>
> and without the full scenario details is a bit hard, regardless however i
> hope it will give us at least
>
> an estimation where we are at)
>
>
>
> Thanks
>
> Gal.
>
>
>
> On Thu, Feb 18, 2016 at 9:34 PM, Vasudevan, Swaminathan (PNB Roseville) <
> swaminathan.vasude...@hpe.com> wrote:
>
> Hi Gal Sagie,
>
> Yes there was some performance results on DVR that we shared with the
> community during the Liberty summit in Vancouver.
>
>
>
> Also I think there was a performance analysis that was done by Oleg
> Bondarev on DVR during the Paris summit.
>
>
>
> We have done lot more changes to the control plane to improve the scale
> and performance in DVR during the Mitaka cycle and will be sharing some
> performance results in the upcoming summit.
>
>
>
> Definitely we can align on our approach and have all those results
> captured in the upstream for the reference.
>
>
>
> Please let me know if you need any other information.
>
>
>
> Thanks
>
> Swami
>
>
>
> *From:* Gal Sagie [mailto:gal.sa...@gmail.com]
> *Sent:* Thursday, February 18, 2016 6:06 AM
> *To:* OpenStack Development Mailing List (not for usage questions); Eran
> Gampel; Shlomo Narkolayev; Yuli Stremovsky
> *Subject:* [openstack-dev] [Neutron] - DVR L3 data plane performance
> results and scenarios
>
>
>
> Hello All,
>
>
>
> We have started to test Dragonflow [1] data plane L3 performance and was
> wondering
>
> if there is any results and scenarios published for the current Neutron DVR
>
> that we can compare and learn the scenarios to test.
>
>
>
> We mostly want to validate and understand if our results are accurate and
> also join the
>
> community in defining base standards and scenarios to test any solution
> out there.
>
>
>
> For that we also plan to join and contribute to openstack-performance [2]
> efforts which to me
>
> are really important.
>
>
>
> Would love any results/information you can share, also interested in
> control plane
>
> testing and API stress tests (either using Rally or not)
>
>
>
> Thanks
>
> Gal.
>
>
>
> [1]
> http://docs.openstack.org/developer/dragonflow/distributed_dragonflow.html
>
> [2] https://github.com/openstack/performance-docs
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
>
> --
>
> Best Regards ,
>
> The G.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Best Regards ,

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

Re: [openstack-dev] [horizon][i18n] Any Horizon plugins ready for translation in Mitaka?

[Akihiro Motoki]

Daisy,

I can followup trove- and sahara- dashboard.
I don't think I can track the status of all of others. This is the
reason I used 'seem' in the past emails.
I suggest to check a release model which each project adopts at
http://governance.openstack.org/reference/projects/index.html.

2016-02-26 9:52 GMT+09:00 Ying Chun Guo :
> Thank you, Akihiro.
>
> Can you help me to understand these plugin projects are release together
> with Horizon or they have their own release schedule ?
> I mean, do they meet soft freeze/hard freeze/RC1 cutting at the same time
> for Horizon project ?
>
> Best regards
> Ying Chun Guo (Daisy)
>
>
> Akihiro Motoki  wrote on 2016/02/26 01:00:15:
>
>> From: Akihiro Motoki 
>> To: "OpenStack Development Mailing List (not for usage questions)"
>> 
>> Date: 2016/02/26 01:04
>
>
>> Subject: Re: [openstack-dev] [horizon][i18n] Any Horizon plugins
>> ready for translation in Mitaka?
>>
>> 2016-02-25 19:47 GMT+09:00 Andreas Jaeger :
>> > On 2016-02-25 11:40, Ying Chun Guo wrote:
>> >> Thank you, Akihiro.
>> >> The projects listed below are all in translation website except
>> >> desginate-dasbhard.
>> >
>> > Typo, it' designate, see
>> > https://translate.openstack.org/project/view/designate-dashboard
>>
>> Thanks for the follow-up.
>> Yeah. I typed designate-dashboard and made a mistake :-(
>>
>> >
>> >> Whether these projects can get translated in Mitaka depends.
>> >> Let's discuss with team.
>> >
>> > Andreas
>> >
>> >> Best regards
>> >> Ying Chun Guo (Daisy)
>> >>
>> >>
>> >> Akihiro Motoki  wrote on 2016/02/23 15:56:39:
>> >>
>> >>> From: Akihiro Motoki 
>> >>> To: "OpenStack Development Mailing List (not for usage questions)"
>> >>> 
>> >>> Date: 2016/02/23 16:00
>> >>> Subject: Re: [openstack-dev] [horizon][i18n] Any Horizon plugins
>> >>> ready for translation in Mitaka?
>> >>>
>> >>> Hi Daisy,
>> >>>
>> >>> AFAIK the following horizon plugins are ready for translation.
>> >>> I tested and confirmed translations of these two work well with
>> >>> Japanese.
>> >>> A minor improvement on devstack or other stuff are in progress but it
>> >>> does not affect translation.
>> >>>
>> >>> * trove-dashboard
>> >>> * sahara-dashboard
>> >>>
>> >>> The following horizon plugins SEEM to support translations.
>> >>> I have never tried them.
>> >>>
>> >>> * desginate-dasbhard
>> >>> * magnum-ui
>> >>> * monasca-ui
>> >>> * murano-dashboard
>> >>> * senlin-dashboard
>> >>>
>> >>> Thanks,
>> >>> Akihiro
>> >>>
>> >>> 2016-02-23 15:52 GMT+09:00 Ying Chun Guo :
>> >>> > Hi,
>> >>> >
>> >>> > Mitaka translation will be started from March 4 and ended in the
>> >>> > week of
>> >>> > March 28.
>> >>> > I'd like to know which Horizon plugins[1] are ready for translation
>> >>> > in
>> >>> > Mitaka release.
>> >>> > If there are, I'm happy to include them in the Mitaka translation
>> >>> > plan.
>> >>> >
>> >>> > Thank you.
>> >>> >
>> >>> > Best regards
>> >>> > Ying Chun Guo (Daisy)
>> >>> >
>> >>> > [1] http://docs.openstack.org/developer/horizon/plugin_registry.html
>> >>> >
>> >>> >
>> >>> >
>> >>
>> >> __
>> >>> > OpenStack Development Mailing List (not for usage questions)
>> >>> > Unsubscribe:
>> >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> >>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >>> >
>> >>>
>> >>>
>> >>> __
>> >>> OpenStack Development Mailing List (not for usage questions)
>> >>> Unsubscribe:
>> >>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >>>
>> >>
>> >>
>> >>
>> >>
>> >> __
>> >> OpenStack Development Mailing List (not for usage questions)
>> >> Unsubscribe:
>> >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >>
>> >
>> >
>> > --
>> >  Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
>> >   SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
>> >GF: Felix Imendörffer, Jane Smithard, Graham Norton,
>> >HRB 21284 (AG Nürnberg)
>> > GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
>> >
>> >
>> >
>> > __
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe:
>> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>> __
>> OpenStack 

[openstack-dev] [release][oslo] oslo.messaging 4.5.0 release (mitaka)

[no-reply]

We are content to announce the release of:

oslo.messaging 4.5.0: Oslo Messaging API

This release is part of the mitaka release series.

With source available at:

http://git.openstack.org/cgit/openstack/oslo.messaging

With package available at:

https://pypi.python.org/pypi/oslo.messaging

Please report issues through launchpad:

http://bugs.launchpad.net/oslo.messaging

For more details, please see below.

Changes in oslo.messaging 4.4.0..4.5.0
--

12e2780 amqp: log time elapsed between receiving a message and replying
02135bc [zmq] Matchmaker redis set instead of list
2d53db6 Allow Notifier to have multiple topics
f868936 Fix a minor syntax error in a log statement
1911828 Use PortOpt on kafka_default_port
d70dfc2 Added duration to notify server/client
f93e162 Improves logging
3288c4d Use more efficient mask_dict_password to mask password
4e1b813 Improves poller's stop logic
5fd3b15 Typos of 'recieve' instead of 'receive'
fda27b0 [zmq] Support transport URL
b97950e Get kafka notifications to work with kafka-python 0.9.5
1482687 Move server's logic from executors
11f78de Avoid hardcoding the notification topic and specify driver
8600f08 [zmq] Fix cinder create volume hangs
1561fbb Py3: Replace filter()/map() if a list is needed
f97ee52 Py3: Switch json to oslo_serialization
2f7b583 Updated from global requirements
46ec05b Option rpc_response_timeout should not be used in zmq driver
ccae7df Remove duplicate requirements
7347e14 Reduce number of rabbitmq consumer tag used
2eb4831 Documents the mirror queue policy of RabbitMQ 3.0

Diffstat (except docs and test files)
-

oslo_messaging/_cmd/zmq_broker.py  |   4 +-
oslo_messaging/_drivers/amqpdriver.py  |   9 +-
oslo_messaging/_drivers/impl_kafka.py  |  14 +-
oslo_messaging/_drivers/impl_pika.py   |   9 +-
oslo_messaging/_drivers/impl_rabbit.py |  54 +--
oslo_messaging/_drivers/impl_zmq.py|  34 -
oslo_messaging/_drivers/pika_driver/pika_engine.py |   4 +-
.../_drivers/pika_driver/pika_message.py   |  25 ++--
oslo_messaging/_drivers/pika_driver/pika_poller.py | 162 +
.../_drivers/protocols/amqp/controller.py  |   2 +-
oslo_messaging/_drivers/protocols/amqp/driver.py   |  44 +-
.../_drivers/zmq_driver/client/zmq_client_base.py  |   8 +-
.../_drivers/zmq_driver/client/zmq_request.py  |  27 ++--
.../_drivers/zmq_driver/matchmaker/base.py |   3 +-
.../zmq_driver/matchmaker/matchmaker_redis.py  |  55 ---
oslo_messaging/_drivers/zmq_driver/zmq_address.py  |   2 -
oslo_messaging/_executors/__init__.py  |   0
oslo_messaging/_executors/base.py  |  44 --
oslo_messaging/_executors/impl_blocking.py | 102 -
oslo_messaging/_executors/impl_eventlet.py |  43 --
oslo_messaging/_executors/impl_pooledexecutor.py   | 155 
oslo_messaging/_executors/impl_thread.py   |  30 
oslo_messaging/notify/_impl_log.py |   2 +-
oslo_messaging/notify/notifier.py  |  18 ++-
oslo_messaging/opts.py |  12 +-
oslo_messaging/server.py   |  92 +---
requirements.txt   |   2 +-
setup.cfg  |   6 +-
test-requirements.txt  |   1 -
tools/simulator.py |  98 +++--
42 files changed, 653 insertions(+), 841 deletions(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index 86e177f..662a699 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -11 +11 @@ oslo.log>=1.14.0 # Apache-2.0
-oslo.utils>=3.4.0 # Apache-2.0
+oslo.utils>=3.5.0 # Apache-2.0
diff --git a/test-requirements.txt b/test-requirements.txt
index 2d4dd83..7f22248 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -20 +19,0 @@ redis>=2.10.0 # MIT
-retrying!=1.3.0,>=1.2.3 # Apache-2.0



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

[openstack-dev] What's Up, Doc? 26 Feb 2016

[Lana Brindley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi everyone,

This week I've been working on code reviews and closing some of our oldest bugs 
from the bug queue. I've also updated the docs-specs core team list to reflect 
some recent changes to the Speciality Team leads, and doing some general prep 
work for the Mitaka release.  We are now well and truly ready to start testing 
the Install Guide. If you need help getting started, please contact Matt 
Kassawara, or any of your friendly core team members :)

== Progress towards Mitaka ==

40 days to go!

445 bugs closed so far for this release. There is a global bug smash event 
coming up March 7-9 to try and hit as many Mitaka bugs as possible. You can 
join an in-person group near you, or participate remotely. There are still 
plenty of docs bugs that can be attended to. Details here: 
https://etherpad.openstack.org/p/OpenStack-Bug-Smash-Mitaka

Docs Testing
* Volunteers required!
* https://wiki.openstack.org/wiki/Documentation/MitakaDocTesting

RST Conversions
* All planned RST conversions are now complete! 

Reorganisations
* Arch Guide: really needs a last minute push to get this complete before 
Mitaka. If you can help out, it would be greatly appreciated!
** 
https://blueprints.launchpad.net/openstack-manuals/+spec/archguide-mitaka-reorg
** Contact the Ops Guide Speciality team: 
https://wiki.openstack.org/wiki/Documentation/OpsGuide
* User Guides
** 
https://blueprints.launchpad.net/openstack-manuals/+spec/user-guides-reorganised
** Contact the User Guide Speciality team: 
https://wiki.openstack.org/wiki/User_Guides

DocImpact
* Is now complete

== The Road to Austin ==

* The final round of ATC passes should be going out shortly.
* I have now requested workrooms and fishbowls for the Austin Design Summit. 
I'll let you know when we get our allocation.
* There is a plan to separate the Design Summit from the main conference after 
Barcelona. I strongly suggest you read the thread on the dev mailing list, if 
you haven't done so already: 
http://lists.openstack.org/pipermail/openstack-dev/2016-February/087161.html
* You should be starting to think about booking travel and accommodation soon! 
If you need a visa to travel to the United States, there's more info here: 
https://www.openstack.org/summit/austin-2016/austin-and-travel/#visa

== Speciality Teams ==

'''HA Guide - Bogdan Dobrelya'''
No update this week.

'''Installation Guide - Matt Kassawara'''
Continue updating the guide for Mitaka using primarily RDO milestone 3 
packages. Review patch that adds manila to the guide. Review patch that adds 
magnum to the guide.

'''Networking Guide - Edgar Magana'''
No update this week.

'''Security Guide - Nathaniel Dillon'''
No update this week.

'''User Guides - Joseph Robinson'''
Team successfully moved across dashboard content from the Admin User Guide to 
the Cloud Admin guide.  Team is preparing to move the command line content, and 
then continue to edit the Cloud Admin guide over the next week.

'''Ops and Arch Guides - Shilla Saebi'''
The work items for the Architecture Design Guide have been converted to bugs: 
https://bugs.launchpad.net/openstack-manuals/+bugs?field.tag=arch-guide We need 
people to confirm the bugs, so we can start working on them. Call for 
volunteers email went out to the ops and docs ML from Devon Boatwright. We are 
still looking for help, not getting many responses. Architecture guide 
reorganization is underway. We have a drafts repo in openstack-manuals, feel 
free to ping Shilla or Darren Chan if you are interested in helping out. 
Considering doing a swarm or work session at the summit in Austin for the Arch 
guide

'''API Docs - Anne Gentle'''
Check for API migration bugs: 
https://bugs.launchpad.net/openstack-api-site/+bugs?field.tag=migration There 
are five bugs remaining. Look at the infra spec if you're interested in how 
we'll build docs with Swagger files. https://review.openstack.org/#/c/276484/ 
I'm investigating using this tool so that we replace flat HTML files built from 
WADL with flat HTML files built from Swagger. 
https://github.com/nknapp/bootprint-openapi

'''Config Ref - Gauvain Pocentek'''
No update this week.

'''Training labs - Pranav Salunke, Roger Luethi'''
Continued fixes to KVM backend and the library functions. Working on creating a 
webpage for training-labs. https://review.openstack.org/#/c/281713/ 
https://review.openstack.org/#/c/281721/ 
https://review.openstack.org/#/c/281367/ Hosting an additional meeting to get 
our new member on-board and some general discussion.

'''Training Guides - Matjaz Pancur'''
No update this week.

'''Hypervisor Tuning Guide - Joe Topjian'''
No update this week.

'''UX/UI Docs Guidelines - Linette Williams'''
Reviews continue for proposed panels in Invision. Enhancement in UI content 
guidelines complete for text and icon formatting recommendations 
(http://docs.openstack.org/contributor-guide/ui-text-guidelines.html).

== Doc team meeting ==

Next 

Re: [openstack-dev] [devstack] stack.sh keeps failing with RTNETLINK answers: Network is unreachable

[Matt Kassawara]

Seems like a config error. What's in local.conf?

On Thu, Feb 25, 2016 at 1:11 PM, Sean M. Collins  wrote:

> Can you provide the output of
>
> "ip route show"
>
> Was this after a unstack.sh that failed?
>
> It could be https://bugs.launchpad.net/devstack/+bug/1423020 popping up
> again
> --
> Sean M. Collins
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] - DVR L3 data plane performance results and scenarios

[Wuhongning]

I've not done any test on AWS yet.

But it seems that a simple optimization could be introduced for huge 
improvement: add a config item to let l3 agent remove all arp entry rpc, and 
reuse arp response by l2pop (if the admin choose to enable it)


From: Jay Pipes [jaypi...@gmail.com]
Sent: Tuesday, February 23, 2016 10:51 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Neutron] - DVR L3 data plane performance results 
and scenarios

On 02/22/2016 10:25 PM, Wuhongning wrote:
> Hi all,
>
> There is also a control plane performance issue when we try to catch on
> the spec of typical AWS limit (200 subnets per router). When a router
> with 200 subnets is scheduled on a new host, a 30s delay is watched when
> all data plane setup is finished.

How quickly does AWS do the same setup?

Best,
-jay

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

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

Re: [openstack-dev] [magnum] Failed to create trustee %(username) in domain $(domain_id)

[Eli Qiao]

hi, I am not sure Magnum need to introduce reno, which will help 
user/developer to understand what new feature magnum has recently.
I see HouMing Wang already registered a blueprint to add reno(I just 
registered a new one, after that I found it's registered already, great)


I think it's good to have this. Any though

[1]https://blueprints.launchpad.net/magnum/+spec/add-reno-for-release-management



On 2016年02月26日 09:42, Kai Qiang Wu wrote:

Thanks Hongbin for your info.

I really think it is not good way for new feature introduced.
As new feature introduced often break old work. it more often better 
with add-in feature is plus, old work still funciton.


Or at least, the error should say "swarm bay now requires trust to 
work, please use trust related access information before deploy a new 
swarm bay"


--
Best Regards, Eli(Li Yong)Qiao
Intel OTC China

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

Re: [openstack-dev] [os-brick][nova][cinder] os-brick/privsep change is done and awaiting your review

[Sean McGinnis]

On Thu, Feb 25, 2016 at 02:26:49PM +, John Garbutt wrote:
> 
> My understanding of what came out of the midcycle was:
> * current rootwrap system horribly breaks upgrade
> * adopting privsep in this "sudo" like form fixes upgrade
> * this approach is much lower risk than a full conversion at this
> point in the release
> * security wise its terrible, but then the current rules don't buy us
> much anyhow
> * makes it easier to slowly transition to better privsep integration
> * all seems better than reverting os-brick integration to fix upgrade issues
> 
> Now at this point, we are way closer to release, but I want to check
> we are making the correct tradeoff here.
> 
> Maybe the upgrade problem is not too bad this release, as the hard bit
> was done with the last upgrade? Or is that total nonsense?

We did have a couple cores watching this this cycle. Walt Boring has
been heavily involved working on this, and I've been waiting to see the
progress.

I think what it ultimately came down to is that it took longer than
expected, and it wasn't until after we cut the "final" os-brick Mitaka
release that some of the blocking issues were worked out with using
privsep.

Given that it has taken this long to get things working, along with how
close we are to M-3, I'm very hesitant to allow this through with very
little runtime.

We really are in a much better position this time around in that there
hasn't been anything added to the rootwrap filters that requires
matching changes in Cinder and Nova. So we should be able to use a mix
of Liberty and Mitaka services without fear of incompatibility.

I do want to see the patches to add the privsep wrapper to rootwrap go
in to Cinder and Nova, even though the official Mitaka os-brick won't be
using it. That should allow us to upgrade os-brick after release without
needing a backported change to the services to allow it.

Sean (smcginnis)

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

Re: [openstack-dev] [magnum] Failed to create trustee %(username) in domain $(domain_id)

[Kai Qiang Wu]

Thanks Hongbin for your info.

I really think it is not good way for new feature introduced.
As new feature introduced often break old work. it more often better with
add-in feature is plus, old work still funciton.

Or at least, the error should say "swarm bay now requires trust to work,
please use trust related access information before deploy a new swarm bay"



Thanks


Kai Qiang Wu (吴开强  Kennan）
IBM China System and Technology Lab, Beijing

E-mail: wk...@cn.ibm.com
Tel: 86-10-82451647
Address: Building 28(Ring Building), ZhongGuanCun Software Park,
 No.8 Dong Bei Wang West Road, Haidian District Beijing P.R.China
100193

Follow your heart. You are miracle!



From:   Hongbin Lu 
To: "OpenStack Development Mailing List (not for usage questions)"

Date:   26/02/2016 08:02 am
Subject:[openstack-dev] [magnum] Failed to create trustee %(username)
in  domain $(domain_id)



Hi team,

FYI, you might encounter the following error if you pull from master
recently:

magnum bay-create --name swarmbay --baymodel swarmbaymodel --node-count 1
Create for bay swarmbay failed: Failed to create trustee %(username) in
domain $(domain_id) (HTTP 500)"

This is due to a recent commit that added support for trust. In case you
don’t know, this error can be resolved by running the following steps:

# 1. create the necessary domain and user:
export OS_TOKEN=password
export OS_URL=http://127.0.0.1:5000/v3
export OS_IDENTITY_API_VERSION=3
openstack domain create magnum
openstack user create trustee_domain_admin --password=secret
--domain=magnum
openstack role add --user=trustee_domain_admin --domain=magnum admin

# 2. populate configs
source /opt/stack/devstack/functions
export MAGNUM_CONF=/etc/magnum/magnum.conf
iniset $MAGNUM_CONF trust trustee_domain_id $(openstack domain show magnum
| awk '/ id /{print $4}')
iniset $MAGNUM_CONF trust trustee_domain_admin_id $(openstack user show
trustee_domain_admin | awk '/ id /{print $4}')
iniset $MAGNUM_CONF trust trustee_domain_admin_password secret

# 3. screen -r stack, and restart m-api and m-cond
 __
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

Re: [openstack-dev] [all] A proposal to separate the design summit

[Sean McGinnis]

On Thu, Feb 25, 2016 at 04:13:56PM +0800, Qiming Teng wrote:
> Hi, All,
> 
> After reading through all the +1's and -1's, we realized how difficult
> it is to come up with a proposal that makes everyone happy. When we are
> discussing this proposal with some other contributors, we came up with a
> proposal which is a little bit different. This idea could be very
> impractical, very naive, given that we don't know much about the huge
> efforts behind the scheduling, planning, coordination ... etc etc. So,
> please treat this as a random thought.
> 
> Maybe we can still have the Summit and the Design Summit colocated, but
> we can avoid the overlap that has been the source of many troubles. The
> idea is to have both events scheduled by the end of a release cycle. For
> example:
> 
> Week 1:
>   Wednesday-Friday: 3 days Summit.
> * Primarily an event for marketing, sales, CTOs, architects,
>   operators, journalists, ...
> * Contributors can decide whether they want to attend this.
>   Saturday-Sunday:
> * Social activities: contributors meet-up, hang outs ...
> 
> Week 2:
>   Monday-Wednesday: 3 days Design Summit
> * Primarily an event for developers.
> * Operators can hold meetups during these days, or join project
>   design summits.
> 
> If you need to attend both events, you don't need two trips. Scheduling
> both events by the end of a release cycle can help gather more
> meaningful feedbacks, experiences or lessons from previous releases and
> ensure a better plan for the coming release.
> 
> If you want to attend just the main Summit or only the Design Summit,
> you can plan your trip accordingly.
> 
> Thoughts?
> 
>  - Qiming
> 

This would eliminate the need for a second flight, and it would
net be total less time away than attending two separate events. I could
see this working.

Sean

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

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

Re: [openstack-dev] [horizon][i18n] Any Horizon plugins ready for translation in Mitaka?

[Ying Chun Guo]

Thank you, Akihiro.

Can you help me to understand these plugin projects are release together
with Horizon or they have their own release schedule ?
I mean, do they meet soft freeze/hard freeze/RC1 cutting at the same time
for Horizon project ?

Best regards
Ying Chun Guo (Daisy)


Akihiro Motoki  wrote on 2016/02/26 01:00:15:

> From: Akihiro Motoki 
> To: "OpenStack Development Mailing List (not for usage questions)"
> 
> Date: 2016/02/26 01:04
> Subject: Re: [openstack-dev] [horizon][i18n] Any Horizon plugins
> ready for translation in Mitaka?
>
> 2016-02-25 19:47 GMT+09:00 Andreas Jaeger :
> > On 2016-02-25 11:40, Ying Chun Guo wrote:
> >> Thank you, Akihiro.
> >> The projects listed below are all in translation website except
> >> desginate-dasbhard.
> >
> > Typo, it' designate, see
> > https://translate.openstack.org/project/view/designate-dashboard
>
> Thanks for the follow-up.
> Yeah. I typed designate-dashboard and made a mistake :-(
>
> >
> >> Whether these projects can get translated in Mitaka depends.
> >> Let's discuss with team.
> >
> > Andreas
> >
> >> Best regards
> >> Ying Chun Guo (Daisy)
> >>
> >>
> >> Akihiro Motoki  wrote on 2016/02/23 15:56:39:
> >>
> >>> From: Akihiro Motoki 
> >>> To: "OpenStack Development Mailing List (not for usage questions)"
> >>> 
> >>> Date: 2016/02/23 16:00
> >>> Subject: Re: [openstack-dev] [horizon][i18n] Any Horizon plugins
> >>> ready for translation in Mitaka?
> >>>
> >>> Hi Daisy,
> >>>
> >>> AFAIK the following horizon plugins are ready for translation.
> >>> I tested and confirmed translations of these two work well with
Japanese.
> >>> A minor improvement on devstack or other stuff are in progress but it
> >>> does not affect translation.
> >>>
> >>> * trove-dashboard
> >>> * sahara-dashboard
> >>>
> >>> The following horizon plugins SEEM to support translations.
> >>> I have never tried them.
> >>>
> >>> * desginate-dasbhard
> >>> * magnum-ui
> >>> * monasca-ui
> >>> * murano-dashboard
> >>> * senlin-dashboard
> >>>
> >>> Thanks,
> >>> Akihiro
> >>>
> >>> 2016-02-23 15:52 GMT+09:00 Ying Chun Guo :
> >>> > Hi,
> >>> >
> >>> > Mitaka translation will be started from March 4 and ended in the
week of
> >>> > March 28.
> >>> > I'd like to know which Horizon plugins[1] are ready for translation
in
> >>> > Mitaka release.
> >>> > If there are, I'm happy to include them in the Mitaka translation
plan.
> >>> >
> >>> > Thank you.
> >>> >
> >>> > Best regards
> >>> > Ying Chun Guo (Daisy)
> >>> >
> >>> > [1]
http://docs.openstack.org/developer/horizon/plugin_registry.html
> >>> >
> >>> >
> >>> >
> >>
__
> >>> > OpenStack Development Mailing List (not for usage questions)
> >>> > Unsubscribe:
> >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>> >
> >>>
> >>>
__
> >>> OpenStack Development Mailing List (not for usage questions)
> >>> Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>>
> >>
> >>
> >>
> >>
__
> >> OpenStack Development Mailing List (not for usage questions)
> >> Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>
> >
> >
> > --
> >  Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
> >   SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
> >GF: Felix Imendörffer, Jane Smithard, Graham Norton,
> >HRB 21284 (AG Nürnberg)
> > GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
> >
> >
> >
__
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [i18n][stackalytics] Translations metrics

[Shuu Mutou]

Hi Ilya, 

Thank you for uploading patch to add my profile.
I confirmed it. I'm looking forward to be adopted into "Stackalytics".

Best regards, 
Shu Muto
NEC Solution Innovators, Ltd.

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

[openstack-dev] [magnum] Failed to create trustee %(username) in domain $(domain_id)

[Hongbin Lu]

Hi team,

FYI, you might encounter the following error if you pull from master recently:

magnum bay-create --name swarmbay --baymodel swarmbaymodel --node-count 1
Create for bay swarmbay failed: Failed to create trustee %(username) in domain 
$(domain_id) (HTTP 500)"

This is due to a recent commit that added support for trust. In case you don't 
know, this error can be resolved by running the following steps:

# 1. create the necessary domain and user:
export OS_TOKEN=password
export OS_URL=http://127.0.0.1:5000/v3
export OS_IDENTITY_API_VERSION=3
openstack domain create magnum
openstack user create trustee_domain_admin --password=secret --domain=magnum
openstack role add --user=trustee_domain_admin --domain=magnum admin

# 2. populate configs
source /opt/stack/devstack/functions
export MAGNUM_CONF=/etc/magnum/magnum.conf
iniset $MAGNUM_CONF trust trustee_domain_id $(openstack domain show magnum | 
awk '/ id /{print $4}')
iniset $MAGNUM_CONF trust trustee_domain_admin_id $(openstack user show 
trustee_domain_admin | awk '/ id /{print $4}')
iniset $MAGNUM_CONF trust trustee_domain_admin_password secret

# 3. screen -r stack, and restart m-api and m-cond

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

Re: [openstack-dev] [os-brick][nova][cinder] os-brick/privsep change is done and awaiting your review

[Angus Lees]

On Fri, 26 Feb 2016 at 01:28 John Garbutt  wrote:

> Agreed with the concerns here, but I thought these are the same we
> raised at the midcycle.
>

Yes, afaik everything is exactly as we discussed and following the
direction we agreed at Nova+CInder mid-cycles.

In hindsight, we probably should also have nominated 2x cores from each of
cinder/nova who were willing to be aware of the situation and review the
resulting change - before actually embarking on the work.  As it is, the
clock is striking noon and the street suddenly contains nothing but
tumbleweeds :-P

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

[openstack-dev] [Horizon][Searchlight] Plans for Horizon cross-region view

[Brad Pokorny]

The last info I've found on the ML about a cross-region view in Horizon is [1], 
which mentions making asynchronous calls to the APIs. Has anyone done further 
work on such a view?

If not, I think it would make sense to only show the view if Searchlight is 
enabled. One of the Searchlight use cases is cross-region searching, and only 
using the searchlight APIs would cut down on the slowness of going directly to 
the service APIs for what would potentially be a lot of records. Thoughts?

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

Re: [openstack-dev] [Fuel][Fuel-Library] Nominating Matthew Mosesohn for Fuel Library Core

[Sergey Vasilenko]

+1


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

Re: [openstack-dev] sqlalchemy-utils fails devstack install

[Tony Breeds]

On Thu, Feb 25, 2016 at 08:24:32AM -0500, Sean Dague wrote:

> The failure only exists if you are installing from tar.gz and not from
> wheels. For performance reasons the upstream gate builds a wheel mirror
> and installs from that.
>
> Those wheels were built on old setuptools, work on any version. There is
> a setuptools bug registered for this, which should hopefully be fixed today.

Thanks Sean.

Yours Tony.


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

Re: [openstack-dev] sqlalchemy-utils fails devstack install

[Tony Breeds]

On Thu, Feb 25, 2016 at 06:27:30AM -0500, Sean Dague wrote:

> Most of that is non-voting. It's not impacting kolla. This only exposes
> on Red Hat platforms, and only is actually downvoting ansible and
> oslo.messaging.

Okay my bad.  I ran out of time to do a deeper analysis :(

Yours Tony.


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

[openstack-dev] [Neutron] Gate failure

[Armando M.]

Folks,

The API job recent breakage prevents us from merging code. Please refrain
from pushing patches to the merge queue until [1] completes going through
the pipeline.

A.

[1] https://review.openstack.org/#/c/284911/
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [devstack] stack.sh keeps failing with RTNETLINK answers: Network is unreachable

[Sean M. Collins]

Can you provide the output of 

"ip route show"

Was this after a unstack.sh that failed?

It could be https://bugs.launchpad.net/devstack/+bug/1423020 popping up
again
-- 
Sean M. Collins

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

Re: [openstack-dev] [all] A proposal to separate the design summit

[Doug Hellmann]

Excerpts from Jan Klare's message of 2016-02-25 17:43:19 +0100:
> 
> > On 25 Feb 2016, at 15:54, Doug Hellmann  wrote:
> > 
> > Excerpts from Jan Klare's message of 2016-02-25 15:29:08 +0100:
> >> 
> >>> On 25 Feb 2016, at 13:39, Daniel P. Berrange  wrote:
> >>> 
> >>> On Thu, Feb 25, 2016 at 12:40:27PM +0100, Thierry Carrez wrote:
>  Qiming Teng wrote:
> > [...]
> > Week 1:
> > Wednesday-Friday: 3 days Summit.
> >   * Primarily an event for marketing, sales, CTOs, architects,
> > operators, journalists, ...
> >   * Contributors can decide whether they want to attend this.
> > Saturday-Sunday:
> >   * Social activities: contributors meet-up, hang outs ...
> > 
> > Week 2:
> > Monday-Wednesday: 3 days Design Summit
> >   * Primarily an event for developers.
> >   * Operators can hold meetups during these days, or join project
> > design summits.
> > 
> > If you need to attend both events, you don't need two trips. Scheduling
> > both events by the end of a release cycle can help gather more
> > meaningful feedbacks, experiences or lessons from previous releases and
> > ensure a better plan for the coming release.
> > 
> > If you want to attend just the main Summit or only the Design Summit,
> > you can plan your trip accordingly.
>  
>  This was an option we considered. The main objection was that we are 
>  pretty
>  burnt out and ready to go home when comes Friday on a single-week event, 
>  so
>  the prospect of doing two consecutive weeks looked a bit like madness
>  (especially considering ancillary events like upstream training, the 
>  board
>  meeting etc. which tend to happen on the weekend before summit already). 
>  It
>  felt like a good way to reduce our productivity and not make the most of 
>  the
>  limited common time together. Furthermore it doesn't solve the issue of
>  suboptimal timing as described in my original email.
> >> 
> >> I do not think that the other suggestion of two different events solves 
> >> the issues, but instead moves it to another suboptimal timing issue.
> >>> 
> >>> I'd wager a sizeable number of contributors would outright refuse to 
> >>> attend
> >>> an event for 2 weeks. 6-7 days away from family is already a long time. As
> >>> such, I would certainly never do any event which spanned 2 weeks, even if
> >>> both weeks were relevant to my work.
> >> 
> >> I don’t think that the suggestion here was to create an event spanning two 
> >> full weeks. As far as i understand it, the OpenStack summit itself would 
> >> span nearly the exact same time as before and maybe even less if you 
> >> decide that you do not want to attend the main summit (or only a part of 
> >> it), but just the design one (or only a part of it). In addition to that, 
> >> i think the suggestion of 3 days in the first week and 3 days in the 
> >> following one is just something we can start a discussion about. I think 
> >> it would be enough to just have a 2 day main event (maybe Monday and 
> >> Tuesday) and schedule the design summit with 2 or 3 days directly after 
> >> that (Wednesday to Thursday or Friday).
> > 
> > For most folks the summit now is a work week + 2 days for travel
> > on either side of it, or at least 7 days (some of us travel further
> > than others). Spreading it across 7 full days like this would mean
> 
> I do not understand the 7 days you mention here, since i suggested an event 
> starting Monday and ending Friday, which would mean a total of 5 days. Adding 
> the travel time of two days, means we end up with a total of 7 days, which is 
> exactly the work week you mentioned.

The original proposal started on a Wednesday and ended on a Wednesday,
and I should have been more clear that I was responding to that.

Your proposal of 2 days followed by 3 is what we did before the
contributor portion of the summit needed to grow to allow for more
projects. I think 3 days won't be enough time to be effective.

> 
> > at least 9 days for anyone who needs to be present for the entire
> > event. Given that many technical folks do also need to be present
> > for the conference portion of the event to meet with customers, I
> > think there would likely be quite a few folks for whom this would
> > turn into a very long, tiring, trip where productivity would drop off
> > steeply near the middle.
> > 
> > As Thierry pointed out, it's a bit questionable whether there's
> > actually much savings for participants with the extended event.
> > Anyone attending only one half will still need to fly to and stay
> > in the more expensive venues we're using now, so they save nothing.
> > Anyone attending both halves may save the cost of one airline ticket,
> > unless they're going to mid-cycles which we wouldn't be able to
> > eliminate. In which case extending the event *increases* their costs

[openstack-dev] [release] mitaka release countdown for R-5, Feb 29 - Mar 4

[Doug Hellmann]

Focus
-

R-5 (Feb 29 - Mar 4 ) is the Mitaka-3 milestone and overall feature,
requirements, and string freezes. Feature work already in progress
should continue.  Other features should be postponed to the next
release.

Project teams should start shifting focus from feature development
to hardening, bug fixes, and stability work.

General Notes
-

Non-client libraries are under a release freeze, except for critical
bug fixes.

Features in projects using the cycle-with-milestone release model
that are not completed this week will need a "feature freeze
exception" (FFE). PTLs can manage feature freeze exceptions directly,
but should be very cautious with them and not grant exceptions for
work where they are not 100% sure it will be finished given an extra
week. Every additional FFE delays the release candidates, which in
turn reduces the end release quality. Be careful about granting
more than a couple of exceptions.

Release Actions
---

We will be more strictly enforcing the library release freeze this
cycle. Please review client libraries managed by your team and
ensure that recent changes have been released and the global
requirements and constraints lists are up to date with accurate
minimum versions and exclusions. This week is the final opportunity
to release client libraries.

Projects using the cycle-with-intermediary release model need to
produce intermediate releases, if you are going to have one this
cycle. See Thierry's email for details [1].

Projects using cycle-with-milestone release model should prepare
the release requests for 0b3 tags for all projects this week. Refer
to the final release process, documented in Thierry's email [1].

Review your stable/liberty branches for necessary releases and
submit patches to openstack/releases if you want them.

[1] http://lists.openstack.org/pipermail/openstack-dev/2016-February/086152.html

Important Dates
---

Mitaka 3 milestone: Feb 29 - Mar 4
Final release for client libraries: Mar 2
RC Target Week: R-3, Mar 14-18

Mitaka release schedule: http://releases.openstack.org/mitaka/schedule.html

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

[openstack-dev] [app-catalog] App Catalog IRC meeting minutes - 2/25/2016

[Christopher Aedo]

Today we had a good meeting which included updates on the great work
markvan is doing to add integration tests to app-catalog-ui as well as
an update on the GLARE implementation kzaitsev has been heading up.
We also agreed that for Austin, we've got enough to do to need two
work sessions in addition to the fishbowl session.

Next week we're planning to talk in more detail about the transition
to using glare for our backend, and hash out the steps we'll be taking
in the near term.


=
#openstack-meeting-3: app-catalog
=
Meeting started by docaedo at 17:00:34 UTC.  The full logs are available
at
http://eavesdrop.openstack.org/meetings/app_catalog/2016/app_catalog.2016-02-25-17.00.log.html
.

Meeting summary
---
* Status updates  (docaedo, 17:02:19)
  * ACTION: add "glare transition review" to next weeks agenda
(docaedo, 17:10:34)
  * ACTION: docaedo to create "add tests" blueprint for markvan's many
work items  (docaedo, 17:19:44)
* Space considerations for Austin summit (docaedo)  (docaedo, 17:22:12)
  * ACTION: docaedo to remember to get some generic icon for assets that
don't include their own  (docaedo, 17:25:28)
* Open discussion  (docaedo, 17:35:25)

Meeting ended at 17:40:46 UTC.

Action items, by person
---
* docaedo
  * docaedo to create "add tests" blueprint for markvan's many work
items
  * docaedo to remember to get some generic icon for assets that don't
include their own
* markvan
  * docaedo to create "add tests" blueprint for markvan's many work
items

People present (lines said)
---
* docaedo (57)
* kfox (19)
* kzaitsev_mb (17)
* markvan (15)
* openstack (3)

Generated by `MeetBot`_ 0.1.4

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

Re: [openstack-dev] sqlalchemy-utils fails devstack install

[Angela Smith]

Sorry, I meant setuptools.

-Original Message-
From: Angela Smith [mailto:aal...@brocade.com] 
Sent: Thursday, February 25, 2016 11:21 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] sqlalchemy-utils fails devstack install

This bug was opened and the solution presented seems to be accurate:
https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.launchpad.net_devstack_-2Bbug_1548592=CwICAg=IL_XqQWOjubgfqINi2jTzg=Ai1MvyPlSw0GLEkv2TxEQpGqXLcFW8njDXhHMBos4Xc=vmbGnExBcDYh5VUlAwMyZOYtWE6xu-WUCH6_xGE0L_k=P4olklj94frFuJOh3sM4P9u2rYfiAw-ussz0xihw1Rc=
 

We had the same issue on our CI and deleting setuputils and reinstalling worked 
for us.

-Original Message-
From: Beliveau, Ludovic [mailto:ludovic.beliv...@windriver.com]
Sent: Thursday, February 25, 2016 7:18 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] sqlalchemy-utils fails devstack install

A bug has been raised against SQLAlchemy-Utils and a fixed has been proposed 
(but not yet merged):
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_kvesteri_sqlalchemy-2Dutils_pull_193=CwICAg=IL_XqQWOjubgfqINi2jTzg=Ai1MvyPlSw0GLEkv2TxEQpGqXLcFW8njDXhHMBos4Xc=ZPoJUKotO6G2_-zWu_uS-YpGG78LX8oSKkcPN3Wq7jI=kuIoTmjzDeBqjHGE_tKrKQyj5Ei5CsXOp5Tt1OHJb5U=
 

Workaround for running devstack:

- Download SQLAlchemy-Utils source code (see 
https://urldefense.proofpoint.com/v2/url?u=https-3A__sqlalchemy-2Dutils.readthedocs.org_en_latest_installation.html=CwICAg=IL_XqQWOjubgfqINi2jTzg=Ai1MvyPlSw0GLEkv2TxEQpGqXLcFW8njDXhHMBos4Xc=ZPoJUKotO6G2_-zWu_uS-YpGG78LX8oSKkcPN3Wq7jI=mJ8E6bsn0XM-nKHAqgJeEi3tNaQ3gTKwsB6UNjeT3p4=
 )
- Patch source code locally based on the proposed fix
- Install the package

Regards,
/ludovic

On 02/25/2016 08:27 AM, Sean Dague wrote:
> On 02/24/2016 11:45 PM, Watanabe, Isao wrote:
>> Hello team
>>
>> Does anyone know about why sqlalchemy-utils fails devstack install since 
>> about 3:00 UTC, Feb 25th?
>>
>> Our CI start to fail and in log it says:
>>
>> 2016-02-25 03:34:22.515 | Collecting SQLAlchemy-Utils===0.31.6 (from -c 
>> /opt/stack/new/requirements/upper-constraints.txt (line 24))
>> 2016-02-25 03:34:22.602 |   Downloading SQLAlchemy-Utils-0.31.6.tar.gz 
>> (112kB)
>> 2016-02-25 03:34:23.031 | Complete output from command python setup.py 
>> egg_info:
>> 2016-02-25 03:34:23.031 | error in SQLAlchemy-Utils setup command: 
>> 'extras_require' must be a dictionary whose values are strings or lists of 
>> strings containing valid project/version requirement specifiers.
>> 2016-02-25 03:34:23.031 | 
>> 2016-02-25 03:34:23.031 | 
>> 2016-02-25 03:34:23.062 | Command "python setup.py egg_info" failed 
>> with error code 1 in /tmp/pip-build-eRYND2/SQLAlchemy-Utils
>>
>> However, in mirror[1] which we are using, the package is just there, which 
>> confused me.
>> [1]
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__mirror.dfw.rax.op
>> enstack.org_pypi_simple_sqlalchemy-2Dutils_=CwICAg=IL_XqQWOjubgfq
>> INi2jTzg=Ai1MvyPlSw0GLEkv2TxEQpGqXLcFW8njDXhHMBos4Xc=ZPoJUKotO6G2
>> _-zWu_uS-YpGG78LX8oSKkcPN3Wq7jI=nPN16YBhP8L87MWHLOY9HhlCwA3__riE_6W
>> r5yqqaes=
>>
>> Thanks for any help.
>>
>> Best regards,
>> Watanabe.isao
> The failure only exists if you are installing from tar.gz and not from 
> wheels. For performance reasons the upstream gate builds a wheel 
> mirror and installs from that.
>
> Those wheels were built on old setuptools, work on any version. There 
> is a setuptools bug registered for this, which should hopefully be fixed 
> today.
>
>   -Sean
>


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openstack.org_cgi-2Dbin_mailman_listinfo_openstack-2Ddev=CwICAg=IL_XqQWOjubgfqINi2jTzg=Ai1MvyPlSw0GLEkv2TxEQpGqXLcFW8njDXhHMBos4Xc=ZPoJUKotO6G2_-zWu_uS-YpGG78LX8oSKkcPN3Wq7jI=e33iauUfMsY9Ous9cmzAXW9Qtzn0YRI75meDooNLRao=
 

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openstack.org_cgi-2Dbin_mailman_listinfo_openstack-2Ddev=CwICAg=IL_XqQWOjubgfqINi2jTzg=Ai1MvyPlSw0GLEkv2TxEQpGqXLcFW8njDXhHMBos4Xc=vmbGnExBcDYh5VUlAwMyZOYtWE6xu-WUCH6_xGE0L_k=AUnBfBYtDRZeDPPBJL3a23YR9U_tSlUltcEtM6NxEx4=
 

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

Re: [openstack-dev] sqlalchemy-utils fails devstack install

[Angela Smith]

This bug was opened and the solution presented seems to be accurate:
https://bugs.launchpad.net/devstack/+bug/1548592

We had the same issue on our CI and deleting setuputils and reinstalling worked 
for us.

-Original Message-
From: Beliveau, Ludovic [mailto:ludovic.beliv...@windriver.com] 
Sent: Thursday, February 25, 2016 7:18 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] sqlalchemy-utils fails devstack install

A bug has been raised against SQLAlchemy-Utils and a fixed has been proposed 
(but not yet merged):
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_kvesteri_sqlalchemy-2Dutils_pull_193=CwICAg=IL_XqQWOjubgfqINi2jTzg=Ai1MvyPlSw0GLEkv2TxEQpGqXLcFW8njDXhHMBos4Xc=ZPoJUKotO6G2_-zWu_uS-YpGG78LX8oSKkcPN3Wq7jI=kuIoTmjzDeBqjHGE_tKrKQyj5Ei5CsXOp5Tt1OHJb5U=
 

Workaround for running devstack:

- Download SQLAlchemy-Utils source code (see 
https://urldefense.proofpoint.com/v2/url?u=https-3A__sqlalchemy-2Dutils.readthedocs.org_en_latest_installation.html=CwICAg=IL_XqQWOjubgfqINi2jTzg=Ai1MvyPlSw0GLEkv2TxEQpGqXLcFW8njDXhHMBos4Xc=ZPoJUKotO6G2_-zWu_uS-YpGG78LX8oSKkcPN3Wq7jI=mJ8E6bsn0XM-nKHAqgJeEi3tNaQ3gTKwsB6UNjeT3p4=
 )
- Patch source code locally based on the proposed fix
- Install the package

Regards,
/ludovic

On 02/25/2016 08:27 AM, Sean Dague wrote:
> On 02/24/2016 11:45 PM, Watanabe, Isao wrote:
>> Hello team
>>
>> Does anyone know about why sqlalchemy-utils fails devstack install since 
>> about 3:00 UTC, Feb 25th?
>>
>> Our CI start to fail and in log it says:
>>
>> 2016-02-25 03:34:22.515 | Collecting SQLAlchemy-Utils===0.31.6 (from -c 
>> /opt/stack/new/requirements/upper-constraints.txt (line 24))
>> 2016-02-25 03:34:22.602 |   Downloading SQLAlchemy-Utils-0.31.6.tar.gz 
>> (112kB)
>> 2016-02-25 03:34:23.031 | Complete output from command python setup.py 
>> egg_info:
>> 2016-02-25 03:34:23.031 | error in SQLAlchemy-Utils setup command: 
>> 'extras_require' must be a dictionary whose values are strings or lists of 
>> strings containing valid project/version requirement specifiers.
>> 2016-02-25 03:34:23.031 | 
>> 2016-02-25 03:34:23.031 | 
>> 2016-02-25 03:34:23.062 | Command "python setup.py egg_info" failed 
>> with error code 1 in /tmp/pip-build-eRYND2/SQLAlchemy-Utils
>>
>> However, in mirror[1] which we are using, the package is just there, which 
>> confused me.
>> [1] 
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__mirror.dfw.rax.op
>> enstack.org_pypi_simple_sqlalchemy-2Dutils_=CwICAg=IL_XqQWOjubgfq
>> INi2jTzg=Ai1MvyPlSw0GLEkv2TxEQpGqXLcFW8njDXhHMBos4Xc=ZPoJUKotO6G2
>> _-zWu_uS-YpGG78LX8oSKkcPN3Wq7jI=nPN16YBhP8L87MWHLOY9HhlCwA3__riE_6W
>> r5yqqaes=
>>
>> Thanks for any help.
>>
>> Best regards,
>> Watanabe.isao
> The failure only exists if you are installing from tar.gz and not from 
> wheels. For performance reasons the upstream gate builds a wheel 
> mirror and installs from that.
>
> Those wheels were built on old setuptools, work on any version. There 
> is a setuptools bug registered for this, which should hopefully be fixed 
> today.
>
>   -Sean
>


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openstack.org_cgi-2Dbin_mailman_listinfo_openstack-2Ddev=CwICAg=IL_XqQWOjubgfqINi2jTzg=Ai1MvyPlSw0GLEkv2TxEQpGqXLcFW8njDXhHMBos4Xc=ZPoJUKotO6G2_-zWu_uS-YpGG78LX8oSKkcPN3Wq7jI=e33iauUfMsY9Ous9cmzAXW9Qtzn0YRI75meDooNLRao=
 

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

Re: [openstack-dev] [gate] ansible release breaks devstack-gate

[Monty Taylor]

On 02/25/2016 05:49 AM, Sean Dague wrote:

It looks like a new ansible release overnight breaks devstack-gate
(something we assumed was a success, empty subnode commands, is now a
failure when going from 2.0.0.2 to 2.0.1.0), which is why there is a
massive failure across the board.

The code to install ansible exists before things like global
requirements. I've proposed a fix with explicit versioning here -
https://review.openstack.org/#/c/284652/

Assuming tests patch I'll fast approve this through to get people up and
running. Most of infra is at the meetup and not around to review patches.


This has been reported to upstream ansible, reproduced, and a patch has 
been produced that fixes the issue.


The patch will be included in 2.0.2 when it is released.


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

[openstack-dev] [TripleO] Show TripleO: A terminal dashboard

[Dougal Matthews]

Hi all,

Over the past couple of weeks in my spare time I put together a basic
Python urwid dashboard for TripleO. You can see the usage and some
screenshots here:

http://python-tripleodash.readthedocs.org

The project is in very early stages (read as: very limited and buggy), but
I've found it useful already. At the moment it is read only but there is no
reason that needs to be the case going forward.

Ultimately I think it could become both a dashboard and a handy getting
started wizard.Good q It does this to a small extent now by listing the
commands needed to register nodes if none are found.

I wanted to share this for now and see if it interested anyone else.

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

Re: [openstack-dev] [glance][nova] images v1-v2 property name asymmetry

[Flavio Percoco]

On Thu, Feb 25, 2016 at 2:53 AM, Brian Rosmaita <
brian.rosma...@rackspace.com> wrote:

> Here's the situation:
>
> image property set:
> - Images v1 API: all image property names are converted to lowercase
> before they're stored
> - Compute v2 API: all image property names are converted to lowercase
> before they're stored
> - Images v2 API: image properties are stored in the case specified when
> they were created
>
> image property get:
> - Images v2 API: all image property names are returned in lowercase only
>

NIT: I think you meant v1 here


> - Compute v2 API: all image property names are returned in lowercase only
> - Images v2 API: image property names are returned as originally set
>
> Note: this applies only to property NAMES.  In all 3 APIs, values are
> returned in the same case pattern in which they were created.  Details of
> the above are avaliable on an etherpad [2].
>
> Here is why this matters.
> (1)  Current Glance behavior is that property names are treated as if they
> were un-cased.  In other words, if you create a property
> 'CamelCasedPropertyName' on image 1234, you cannot create another property
> named 'camelCasedPropertyName' on image 1234.  Adding "duplicate"
> properties in v2 is currently blocked more by a fortuitous bug than by
> design.  If this is the behavior we want (and I think it is), then we need
> to make the duplication detection more robust.
>
> (2)  The current patch for the CIM metadata definitions [0] is defining
> property names in all lowercase, for example,
> 'instructionsetextensionname' instead of 'InstructionSetExtensionName' as
> on an earlier patch.  In addition to being more readable, the CamelCased
> names are what's actually used in the CIM schema.  Lin's reason for the
> change is that if image consumers looking for image metadata are using the
> Images v1 or the Compute API, they won't find CamelCased property names
> among the image properties.  By keeping everything lowercase, we eliminate
> the problem of a developer forgetting to normalize image property names
> before testing for their existence.
>
> (3)  This issue impacts the work underway to convert Nova to consuming the
> Images v2 API.
>
> We need to formalize the intended behavior.  Here's a proposal:
> (a) If you use the Images v1 API or the Compute API to *set* an image
> property name, you get lowercase only.
> (b) If you use the Images v1 API or the Compute API to *get* an image
> proeprty name, you get lowercase only.
> (c) The behavior of the Compute API with respect to image property names
> should not change when Nova starts using the Images v2 API.
> (d) If you use the Images v2 API to *set* image property names, they are
> stored as cased in the request.
> (e) For the purposes of preventing duplicate image property names on a
> single image, property names are *case insensitive*.
> (f) If you use the Images v2 API to *get* image property names, you will
> receive them as they were stored, but you should treat them as case
> insensitive.
>
> This proposal is basically what we've got now, plus the recommendation
> that image property names be treated as case insensitive when using the
> Images v2 API.
>
> We need to get consensus on this quickly so that the implementation of the
> CIM Namespace Metadata spec [1] can be completed.  The hold up at the
> moment is whether the property names should be CamelCased or simply
> lowercased.  My opinion is that if everyone's going to make all property
> names lowercase just to be safe, then we ought to go ahead and enforce
> this in the Images API, that is, make the Images v2 API act just like the
> Images v1 API in this regard.
>

I think I'd let the image API enforce this, as you've suggested.

We could even keep the API as is and just make case-insensitve queries to
avoid duplicates. Do we care about the original case at all?

Flavio

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

Re: [openstack-dev] [Fuel] Question about Feature Freeze Exceptions for non-invasive features

[Dmitry Borodaenko]

If the spec is not going to require code changes in 9.0/Mitaka, why not
simply target it for 10.0/Newton?

On Thu, Feb 25, 2016 at 05:21:55PM +0300, Evgeniy L wrote:
> Hi,
> 
> We have a spec where we are trying to do research and describe how we are
> going to test extensions [0], we will not be able to land it before feature
> freeze, so should we get feature freeze exception for it? Or it will not be
> a problem to merge it even after FF?
> 
> The spec itself is more about the process which we are going to follow
> during extensions development, so there should be no changes for current
> projects.
> 
> Thanks,
> 
> [0] https://review.openstack.org/#/c/281749/

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


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

Re: [openstack-dev] [Neutron] Intra-column wrapping in python-neutronclient

[Carl Baldwin]

On Wed, Feb 24, 2016 at 2:58 PM, Steve Baker  wrote:
> My intention was that it be a usability improvement rather than merely an
> aesthetic one. Yes, it is unfortunate that it affects this specific copy
> paste scenario but there are others where it is improved. I've often been in
> the situation where I don't know which uuid to copy because of the amount of
> overlap of unrelated columns.

So, this helps you figure out which which uuid to copy but how do you
copy it when you've found it?  Do you do more than one copy/paste for
each?

>> How can I turned this off now?  Also, can I request that this new
>> "feature" be disabled by default?
>>
> Table resizing only occurs when a tty is present. This means that any
> existing script which parses table output will not be affected. It also
> means that you can disable it by piping your command to cat.

I'd be okay encouraging scripts to use the more script-friendly output
formats as mentioned by Akihiro.  But, I'm not talking about scripts
here.  I'm talking about human interaction.  Copy/paste is a human
interaction.  In my opinion, this change has not improved the
situation.

> If you're unwilling to adapt, or specify formatting options, or pipe to cat,
> then I would recommend that you submit a change to cliff to read a user set
> environment variable to switch off table resizing.

If I am unwilling to adapt, how would that help me?  It requires
adaptation, right?  ;)  In all seriousness, this thread is not about
anyone's willingness to adapt.  It is about whether this is the right
thing to do.  If it is then I'm happy to adapt.  But, I continue to
argue that it isn't the right thing to do.

Carl

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

Re: [openstack-dev] [Neutron] Intra-column wrapping in python-neutronclient

[Brian Haley]

On 2/24/16 3:58 PM, Steve Baker wrote:

On 25/02/16 06:23, Carl Baldwin wrote:

Hi,

I've noticed a new behavior from the python-neutronclient which
disturbs me.  For me, this just started happening with my latest build
of devstack which I built yesterday.  It didn't happen with another
recent but little bit older devstack.

The issue is that the client is now wrapping content within columns.
For example:


+-+-+--+

   | id  | name| subnets
   |

+-+-+--+

   | eb850219-6a42-42ed-ac6a-| public  |
099745e5-4925-4572-a88f- |
   | 927b03a0dc77| | a5376206c892
172.24.4.0/24   |
   | | | 5b6dfb0d-c97e-48ae-
   |
   | | | 98c9-7fe3e1e8e88b
2001:db8::/64  |
   | ec73110f-   | private | 4073b9e7-a58e-4d6e-
   |
   | 86ad-4292-9547-7c2789a7023b | | a2e4-7a45ae899671
10.0.0.0/24|
   | | |
f12aee80-fc13-4adf-a0eb- |
   | | | 706af4319094
fd9d:e27:3eab::/64  |

+-+-+--+


Notice how the ids in the first column are wrapped within the column.
I personally don't see this as an aesthetic improvement.  It destroys
by ability to cut and paste the data within this column.  When I
stretch my console out to fix it, I have to rerun the command with the
new window width to fix it.  I used to be able to stretch my console
horizontally and the wrapped would automatically go away.

My intention was that it be a usability improvement rather than merely
an aesthetic one. Yes, it is unfortunate that it affects this specific
copy paste scenario but there are others where it is improved. I've
often been in the situation where I don't know which uuid to copy
because of the amount of overlap of unrelated columns.


But even in your case, if the uuid of interest was wrapped it wouldn't 
be a candidate for cut/paste, so it's just as broken.



How can I turned this off now?  Also, can I request that this new
"feature" be disabled by default?


Table resizing only occurs when a tty is present. This means that any
existing script which parses table output will not be affected. It also
means that you can disable it by piping your command to cat.

If you're unwilling to adapt, or specify formatting options, or pipe to
cat, then I would recommend that you submit a change to cliff to read a
user set environment variable to switch off table resizing.


I don't think it's OK to change the formatting, then introduce a change 
to get the original behavior back, the change should be considered a 
bug.  If we want a different behavior then *that* should be controlled 
through some new option.


I filed https://bugs.launchpad.net/python-cliff/+bug/1549906

-Brian

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

Re: [openstack-dev] [ceilometer] Unable to get IPMI meter readings

[gordon chung]

at quick glance, it seems like data is being generated[1]. if you check 
your queues (rabbitmqctl list_queues for rabbit), do you see any items 
sitting on notification.sample queue or metering.sample queue? do you 
receive other meters fine? maybe you can query db directly to verify 
it's not a permission issue.

[1] see: 2016-02-25 13:36:58.909 21226 DEBUG ceilometer.pipeline [-] 
Pipeline meter_sink: Transform sample  from 0 transformer _publish_samples 
/usr/lib/python2.7/dist-packages/ceilometer/pipeline.py:296

On 25/02/2016 8:43 AM, Kapil wrote:
> Below is the output of ceilometer-agent-ipmi in debug mode
>
> http://paste.openstack.org/show/488180/
> ᐧ
>
> Regards,
> Kapil Agarwal
>
> On Wed, Feb 24, 2016 at 8:18 PM, Lu, Lianhao  > wrote:
>
> On Feb 25, 2016 06:18, Kapil wrote:
>  > Hi
>  >
>  >
>  > I discussed this problem with gordc on the telemetry IRC channel
> but I
>  > am still facing issues.
>  >
>  > I am running the ceilometer-agent-ipmi on the compute nodes, I
> changed
>  > pipeline.yaml of the compute node to include the ipmi meters and
>  > resource as "ipmi://localhost".
>  >
>  > - name: meter_ipmi
>  >   interval: 60
>  >   resources:
>  >   - ipmi://localhost meters: - "hardware.ipmi.node*" -
>  >   "hardware.ipmi*" - "hardware.degree*" sinks: - meter_sink I
>  > have ipmitool installed on the compute nodes and restarted the
>  > ceilometer services on compute and controller nodes. Yet, I am not
>  > receiving any ipmi meters when I run "ceilometer meter-list". I also
>  > tried passing the hypervisor IP address and the ipmi address I get
>  > when I run "ipmitool lan print" to resources but to no avail.
>  >
>  >
>  > Please help in this regard.
>  >
>  >
>  > Thanks
>  > Kapil Agarwal
>
> Hi Kapil,
>
> Would you please turn on debug/verbose configurations and paste the
> log of ceilometer-agent-ipmi on http://paste.openstack.org ?
>
> -Lianhao Lu
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

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

Re: [openstack-dev] [oslo] upgrade implications of lots of content in paste.ini

[Michael Krotscheck]

On Thu, Feb 18, 2016 at 10:18 AM Morgan Fainberg 
wrote:

>
> I am against "option 1". This could be a case where we classify it as a
> release blocking bug for Mitaka final (is that reasonable to have m3 with
> the current scenario and final to be fixed?), which opens the timeline a
> bit rather than hard against feature-freeze.
>

This sounds like a really good way to get us more time, so I'm in favor of
this. However, even with the additional time I will not be able to land all
these patches on my own.

Who is willing to help?

Michael

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

Re: [openstack-dev] [horizon][i18n] Any Horizon plugins ready for translation in Mitaka?

[Akihiro Motoki]

2016-02-25 19:47 GMT+09:00 Andreas Jaeger :
> On 2016-02-25 11:40, Ying Chun Guo wrote:
>> Thank you, Akihiro.
>> The projects listed below are all in translation website except
>> desginate-dasbhard.
>
> Typo, it' designate, see
> https://translate.openstack.org/project/view/designate-dashboard

Thanks for the follow-up.
Yeah. I typed designate-dashboard and made a mistake :-(

>
>> Whether these projects can get translated in Mitaka depends.
>> Let's discuss with team.
>
> Andreas
>
>> Best regards
>> Ying Chun Guo (Daisy)
>>
>>
>> Akihiro Motoki  wrote on 2016/02/23 15:56:39:
>>
>>> From: Akihiro Motoki 
>>> To: "OpenStack Development Mailing List (not for usage questions)"
>>> 
>>> Date: 2016/02/23 16:00
>>> Subject: Re: [openstack-dev] [horizon][i18n] Any Horizon plugins
>>> ready for translation in Mitaka?
>>>
>>> Hi Daisy,
>>>
>>> AFAIK the following horizon plugins are ready for translation.
>>> I tested and confirmed translations of these two work well with Japanese.
>>> A minor improvement on devstack or other stuff are in progress but it
>>> does not affect translation.
>>>
>>> * trove-dashboard
>>> * sahara-dashboard
>>>
>>> The following horizon plugins SEEM to support translations.
>>> I have never tried them.
>>>
>>> * desginate-dasbhard
>>> * magnum-ui
>>> * monasca-ui
>>> * murano-dashboard
>>> * senlin-dashboard
>>>
>>> Thanks,
>>> Akihiro
>>>
>>> 2016-02-23 15:52 GMT+09:00 Ying Chun Guo :
>>> > Hi,
>>> >
>>> > Mitaka translation will be started from March 4 and ended in the week of
>>> > March 28.
>>> > I'd like to know which Horizon plugins[1] are ready for translation in
>>> > Mitaka release.
>>> > If there are, I'm happy to include them in the Mitaka translation plan.
>>> >
>>> > Thank you.
>>> >
>>> > Best regards
>>> > Ying Chun Guo (Daisy)
>>> >
>>> > [1] http://docs.openstack.org/developer/horizon/plugin_registry.html
>>> >
>>> >
>>> >
>> __
>>> > OpenStack Development Mailing List (not for usage questions)
>>> > Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>> >
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> --
>  Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
>   SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
>GF: Felix Imendörffer, Jane Smithard, Graham Norton,
>HRB 21284 (AG Nürnberg)
> GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [oslo] upgrade implications of lots of content in paste.ini

[Michael Krotscheck]

On Thu, Feb 18, 2016 at 9:58 AM Sean Dague  wrote:

> Here is the future we're going to have.
>

The future is only going to happen if help materializes. So far, we still
need updated patches on all 22 projects, and these will need to land in
time for the mitaka release. I can commit to doing about 5 of them given my
other obligations, and I need help for the rest.

Who is willing to help?

Right now, it appears that the default in the middleware is do nothing.
> That means CORS won't be in a functional state on services by default.
> However, I thought the point of the effort was that all the APIs in the
> wild would be CORS enabled.
>

This is by design, and is specifically called out in the cross-project
specification, adopted on June 9th.

http://specs.openstack.org/openstack/openstack-specs/specs/cors-support.html

I'm not hugely sympathetic to defaulting to not having the Keystone
> headers specified in the non keystone case. I get there are non keystone
> cases, but keystone is defcore. Making the keystone case worse for the
> non keystone case seems like fundamentally the wrong tradeoff.
>

The non-keystone use cases is also mentioned in the spec.

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

Re: [openstack-dev] [all] A proposal to separate the design summit

[Jan Klare]

> On 25 Feb 2016, at 15:54, Doug Hellmann  wrote:
> 
> Excerpts from Jan Klare's message of 2016-02-25 15:29:08 +0100:
>> 
>>> On 25 Feb 2016, at 13:39, Daniel P. Berrange  wrote:
>>> 
>>> On Thu, Feb 25, 2016 at 12:40:27PM +0100, Thierry Carrez wrote:
 Qiming Teng wrote:
> [...]
> Week 1:
> Wednesday-Friday: 3 days Summit.
>   * Primarily an event for marketing, sales, CTOs, architects,
> operators, journalists, ...
>   * Contributors can decide whether they want to attend this.
> Saturday-Sunday:
>   * Social activities: contributors meet-up, hang outs ...
> 
> Week 2:
> Monday-Wednesday: 3 days Design Summit
>   * Primarily an event for developers.
>   * Operators can hold meetups during these days, or join project
> design summits.
> 
> If you need to attend both events, you don't need two trips. Scheduling
> both events by the end of a release cycle can help gather more
> meaningful feedbacks, experiences or lessons from previous releases and
> ensure a better plan for the coming release.
> 
> If you want to attend just the main Summit or only the Design Summit,
> you can plan your trip accordingly.
 
 This was an option we considered. The main objection was that we are pretty
 burnt out and ready to go home when comes Friday on a single-week event, so
 the prospect of doing two consecutive weeks looked a bit like madness
 (especially considering ancillary events like upstream training, the board
 meeting etc. which tend to happen on the weekend before summit already). It
 felt like a good way to reduce our productivity and not make the most of 
 the
 limited common time together. Furthermore it doesn't solve the issue of
 suboptimal timing as described in my original email.
>> 
>> I do not think that the other suggestion of two different events solves the 
>> issues, but instead moves it to another suboptimal timing issue.
>>> 
>>> I'd wager a sizeable number of contributors would outright refuse to attend
>>> an event for 2 weeks. 6-7 days away from family is already a long time. As
>>> such, I would certainly never do any event which spanned 2 weeks, even if
>>> both weeks were relevant to my work.
>> 
>> I don’t think that the suggestion here was to create an event spanning two 
>> full weeks. As far as i understand it, the OpenStack summit itself would 
>> span nearly the exact same time as before and maybe even less if you decide 
>> that you do not want to attend the main summit (or only a part of it), but 
>> just the design one (or only a part of it). In addition to that, i think the 
>> suggestion of 3 days in the first week and 3 days in the following one is 
>> just something we can start a discussion about. I think it would be enough 
>> to just have a 2 day main event (maybe Monday and Tuesday) and schedule the 
>> design summit with 2 or 3 days directly after that (Wednesday to Thursday or 
>> Friday).
> 
> For most folks the summit now is a work week + 2 days for travel
> on either side of it, or at least 7 days (some of us travel further
> than others). Spreading it across 7 full days like this would mean

I do not understand the 7 days you mention here, since i suggested an event 
starting Monday and ending Friday, which would mean a total of 5 days. Adding 
the travel time of two days, means we end up with a total of 7 days, which is 
exactly the work week you mentioned.

> at least 9 days for anyone who needs to be present for the entire
> event. Given that many technical folks do also need to be present
> for the conference portion of the event to meet with customers, I
> think there would likely be quite a few folks for whom this would
> turn into a very long, tiring, trip where productivity would drop off
> steeply near the middle.
> 
> As Thierry pointed out, it's a bit questionable whether there's
> actually much savings for participants with the extended event.
> Anyone attending only one half will still need to fly to and stay
> in the more expensive venues we're using now, so they save nothing.
> Anyone attending both halves may save the cost of one airline ticket,
> unless they're going to mid-cycles which we wouldn't be able to
> eliminate. In which case extending the event *increases* their costs
> because they end up staying in the more expensive hotel for more
> nights.

The difference in nights in comparison to the current summit of 4 days + 2 days 
travel would be just one night and i do not think than one night in a hotel is 
more expensive than the expenses for a completely separate event.

> 
> We also have to consider the extra difficulty and expense of trying
> to book a venue for such an extended time (considering set up and
> tear down time we need it for longer than we'll be actively using
> it, even if not by a lot).
> 
> Doug
> 
>> 
>> Cheers,
>> Jan
>> 
>>> 
>>> 
>>> 

Re: [openstack-dev] [nova] solving API case sensitivity issues

[Michał Dulko]

On 02/24/2016 01:48 PM, Sean Dague wrote:
> We have a specific bug around aggregrate metadata setting in Nova which
> exposes a larger issue with our mysql schema.
> https://bugs.launchpad.net/nova/+bug/1538011
>
> On mysql the following will explode with a 500:
>
>> nova aggregate-create agg1
>> nova aggregate-set-metadata agg1 abc=1
>> nova aggregate-set-metadata agg1 ABC=2
> mysql (by default) treats abc == ABC. However the python code does not.
>
> We have a couple of options:
>
> 1) make the API explicitly case fold
>
> 2) update the mysql DB to use latin_bin collation for these columns
>
> 3) make this a 400 error because duplicates were found
>
>
> Options 1 & 2 make all OpenStack environments consistent regardless of
> backend.
>
> Option 2 is potentially expensive TABLE alter.
>
> Option 3 gets rid of the 500 error, however at the risk that the
> behavior for this API is different depending on DB backend. Which is
> less than ideal.
>
>
> My preference is slightly towards #1. It's taken a long time for someone
> to report this issue, so I think it's an edge case, and people weren't
> think about this being case sensitive. It has the risk of impacting
> someone on an odd db platform that has been using that feature.
>
> There are going to be a few other APIs to clean up in a similar way. I
> don't think this comes in under a microversion because of how deep in
> the db api layer this is, and it's just not viable to keep both paths.
>
>   -Sean

We've faced similar issues in Cinder and as solution we've moved
filtering to Python code. Like in for example [1] or [2]. But no, we
haven't had UNIQUE constraint on the DB column in these cases, only on IDs.

[1] https://review.openstack.org/225024
[2] https://review.openstack.org/#/c/274589/12/cinder/db/sqlalchemy/api.py

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

Re: [openstack-dev] Fwd: [Juno] LBaaS v1.0 mystery device_id

[Brandon Logan]

I do believe it is just an arbitrary uuid.  I don't know the decision
behind doing it this way, but I'm sure there were reasons.  Or maybe
not :)

https://github.com/openstack/neutron-lbaas/blob/stable/kilo/neutron_lbaas/services/loadbalancer/drivers/common/agent_driver_base.py#L195


On Wed, 2016-02-24 at 16:43 -0800, surekha saharan wrote:
> Hello All,
> 
> 
> I can't find the "device_id" anywhere the port in vip returns.
> 
> Below is the details of a vip, note the port_id
> "03a12958-656f-492b-8114-65d037ad6743"
> 
> neutron lb-vip-show b2b11f89-48fc-4fd4-99f9-6f26977f353a
> 
> +-+--+
> 
> | Field| Value |
> 
> +-+--+
> 
> | address  | 30.0.0.138|
> 
> | admin_state_up   | True  |
> 
> | connection_limit | -1|
> 
> | description  |   |
> 
> | id   | b2b11f89-48fc-4fd4-99f9-6f26977f353a |
> 
> | name | vip2  |
> 
> | pool_id  | 4e0a1909-08f9-4124-94c0-ef0650b36512 |
> 
> | port_id  | 03a12958-656f-492b-8114-65d037ad6743 |
> 
> | protocol | HTTP  |
> 
> | protocol_port| 80|
> 
> | session_persistence |   |
> 
> | status   | ACTIVE|
> 
> | status_description  |   |
> 
> | subnet_id| 61ed9305-7b15-484a-b843-cb759aebc163 |
> 
> | tenant_id| 3418d53683654d37b47caa1b66b72a21 |
> 
> +-+--+
> 
> 
> 
> 
> 
> Now, if I get the details of the above port, I get the device_id "
> 724fc160-2b2e-597e-b9ed-7f65313cd73f". 
> The id of the vip is part of name attribute
> "vip-b2b11f89-48fc-4fd4-99f9-6f26977f353a "
> 
> 
> 
> 
> neutron port-show 03a12958-656f-492b-8114-65d037ad6743
> 
> +---+---+
> 
> | Field  | Value
> |
> 
> +---+---+
> 
> | admin_state_up | True
> |
> 
> | allowed_address_pairs |
> |
> 
> | binding:host_id| ubuntu
> |
> 
> | binding:profile| {}
> |
> 
> | binding:vif_details   | {"port_filter": true, "ovs_hybrid_plug":
> true} |
> 
> | binding:vif_type   | ovs
> |
> 
> | binding:vnic_type | normal
> |
> 
> | device_id  | 724fc160-2b2e-597e-b9ed-7f65313cd73f
> |
> 
> | device_owner   | neutron:LOADBALANCER
> |
> 
> | extra_dhcp_opts|
> |
> 
> | fixed_ips  | {"subnet_id":
> "61ed9305-7b15-484a-b843-cb759aebc163", "ip_address": "30.0.0.138"} |
> 
> | id | 03a12958-656f-492b-8114-65d037ad6743
> |
> 
> | mac_address| fa:16:3e:ec:2e:3b
> |
> 
> | name   | vip-b2b11f89-48fc-4fd4-99f9-6f26977f353a
> |
> 
> | network_id | ef132b57-edc1-4d64-9591-38b80f73e23f
> |
> 
> | security_groups| 3365e9e0-4038-4800-b6b3-364b34e177d1
> |
> 
> | status | ACTIVE
> |
> 
> | tenant_id  | 3418d53683654d37b47caa1b66b72a21
> |
> 
> +---+---+
> 
> 
> 
> I cannot find the device_id anywhere as part of "nova list" or any
> other neutron command, what is this device_id referring to.
> 
> 
> Appreciate any response on this.
> 
> 
> Regards,
> 
> Surekha
> 
> 
> 
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [gate] ansible release breaks devstack-gate

[Thierry Carrez]

Sean Dague wrote:

On 02/25/2016 06:49 AM, Sean Dague wrote:

It looks like a new ansible release overnight breaks devstack-gate
(something we assumed was a success, empty subnode commands, is now a
failure when going from 2.0.0.2 to 2.0.1.0), which is why there is a
massive failure across the board.

The code to install ansible exists before things like global
requirements. I've proposed a fix with explicit versioning here -
https://review.openstack.org/#/c/284652/

Assuming tests patch I'll fast approve this through to get people up and
running. Most of infra is at the meetup and not around to review patches.


This patch is now merged, things should be good to go again.


Thanks Sean for unbreaking the world once again!

--
Thierry Carrez (ttx)

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

Re: [openstack-dev] [all] A proposal to separate the design summit

[James Bottomley]

On Thu, 2016-02-25 at 12:40 +0100, Thierry Carrez wrote:
> Qiming Teng wrote:
> > [...]
> > Week 1:
> >Wednesday-Friday: 3 days Summit.
> >  * Primarily an event for marketing, sales, CTOs, architects,
> >operators, journalists, ...
> >  * Contributors can decide whether they want to attend this.
> >Saturday-Sunday:
> >  * Social activities: contributors meet-up, hang outs ...
> > 
> > Week 2:
> >Monday-Wednesday: 3 days Design Summit
> >  * Primarily an event for developers.
> >  * Operators can hold meetups during these days, or join
> > project
> >design summits.
> > 
> > If you need to attend both events, you don't need two trips.
> > Scheduling
> > both events by the end of a release cycle can help gather more
> > meaningful feedbacks, experiences or lessons from previous releases
> > and
> > ensure a better plan for the coming release.
> > 
> > If you want to attend just the main Summit or only the Design
> > Summit,
> > you can plan your trip accordingly.
> 
> This was an option we considered. The main objection was that we are 
> pretty burnt out and ready to go home when comes Friday on a single
> -week event, so the prospect of doing two consecutive weeks looked a 
> bit like madness (especially considering ancillary events like 
> upstream training, the board meeting etc. which tend to happen on the 
> weekend before summit already). It felt like a good way to reduce our 
> productivity and not make the most of the limited common time 
> together. Furthermore it doesn't solve the issue of suboptimal timing 
> as described in my original email.
> 
> The benefit is that for people attending both events, you indeed save 
> on pure flight costs. But since you have to cover for conference 
> hotel rooms and food over the weekend and otherwise compensate 
> employees for being stuck there over the weekend, the gain is not 
> that significant...

We did actually try to do this for Kernel Summit, Plumbers and Linux
Con in 2012.  Once we tried to schedule it, we got a huge back reaction
from the sponsors, the attendees and the speakers mostly about having
to be away over the weekend.  Eventually we caved to pressure and
overlaid all three events in the same week, which lead to another set
of complaints ...

The lesson I took away from this is never schedule a set of events
longer than a week and I still have the scars to remind me.

James


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

[openstack-dev] [devstack] stack.sh keeps failing with RTNETLINK answers: Network is unreachable

[Paul Carlton]

Trying to setup devstack but stack.sh fails

2016-02-25 15:45:03.930 | + sudo ip route replace 10.1.0.0/20 via 
192.168.100.200

2016-02-25 15:45:03.939 | RTNETLINK answers: Network is unreachable

Tried master and stable/liberty without success

any idea how to debug this?

Thanks

--
Paul Carlton
Software Engineer
Cloud Services
Hewlett Packard
BUK03:T242
Longdown Avenue
Stoke Gifford
Bristol BS34 8QZ

Mobile:+44 (0)7768 994283
Email:mailto:paul.carlt...@hpe.com
Hewlett-Packard Limited registered Office: Cain Road, Bracknell, Berks RG12 1HN 
Registered No: 690597 England.
The contents of this message and any attachments to it are confidential and may be 
legally privileged. If you have received this message in error, you should delete it from 
your system immediately and advise the sender. To any recipient of this message within 
HP, unless otherwise stated you should consider this message and attachments as "HP 
CONFIDENTIAL".




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

Re: [openstack-dev] [oslo] upgrade implications of lots of content in paste.ini

[Michael Krotscheck]

On Thu, Feb 18, 2016 at 11:42 AM Adam Young  wrote:

> If the deployer does and all-in-one, and all services are on port 443,
> CORS is not an issue.
>

I feel that this is based on the assumption that a cloud will only ever
have one GUI, which I already know is not the case. From the survey I ran a
year ago, I can point at several instances where custom UI's were built to
handle different use cases. There were examples of Monitoring dashboards,
Custom admin panels, etc.

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

[openstack-dev] Introducing simple client creation in os-client-config

[Monty Taylor]

Hey all,

I just responded to a mailing list thread about a question related to 
constructing a nova Client object - and I realized I'd been remiss about 
sending out an announcement of a couple of little but helpful features 
we landed in os-client-config - namely, simple factory functions to 
create Client objects and mounted Session objects.


As with all os-client-config things, they are fully aware of the 
standard OS_ env vars, as well as clouds.yaml config files - and can 
also delegate to argparse processing.


I wrote a blog post with examples:

http://inaugust.com/posts/simple-openstack-clients.html

but I'll include examples here too:

* Client Library Client Objects *

# Make a nova client object that uses env vars for auth info:

nova = os_client_config.make_client('compute')

# Make a glance client object for the cloud named 'mtvexx' in my 
clouds.yaml file:


client = os_client_config.make_client('image', cloud='mtvxx')

# Make a neutron client by passing in all of the values directly

client = os_client_config.make_client(
'network',
auth_url='https://example.com', username='my-user',
password='awesome-password', project_name='my-project',
region_name='the-best-region')

# Make a barbican client from env vars and all the standard arguments
# passed on the comand line:

import argparse
client = os_client_config.make_client(
'key-manager', options=argparse.ArgumentParser())

# Swift has a Connection object, not a Client object, but that's fine
# We're an equal opportunity player
client = os_client_config.make_client('object-store')

I hope that covers most of the common end-user use cases with using
OpenStack Client Libraries. If you need more flexibility, you can always
create an os-client-config CloudConfig object and call
get_legacy_client, but I'm a big believer in one step instead of three
if you can get away with it:

config = os_client_config.OpenStackConfig()
cloud_config = config.get_one_cloud(cloud='vexxhost')
client = cloud_config.get_legacy_client('compute')

* Mounted Keystone Session *

What if what you want to do is make some direct REST calls to an 
OpenStack service, but you want to be able to do env vars or argparse or 
clouds.yaml files to configure your authentication? Well - you're in luck:


# Make a nova client object that uses env vars for auth info:

client = os_client_config.session_client('compute')

That will get you a keystoneauth Session object that has been "mounted" 
on the compute service. So you can do this:


response = session.get('/servers')
server_list = response.json()['servers']

session_client supports the exact same interface as make_client does, so 
all the above examples will work, but you'll get a ksa Session instead 
of a Client object.


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

Re: [openstack-dev] sqlalchemy-utils fails devstack install

[Beliveau, Ludovic]

A bug has been raised against SQLAlchemy-Utils and a fixed has been proposed 
(but not yet merged):
https://github.com/kvesteri/sqlalchemy-utils/pull/193

Workaround for running devstack:

- Download SQLAlchemy-Utils source code (see 
https://sqlalchemy-utils.readthedocs.org/en/latest/installation.html)
- Patch source code locally based on the proposed fix
- Install the package

Regards,
/ludovic

On 02/25/2016 08:27 AM, Sean Dague wrote:
> On 02/24/2016 11:45 PM, Watanabe, Isao wrote:
>> Hello team
>>
>> Does anyone know about why sqlalchemy-utils fails devstack install since 
>> about 3:00 UTC, Feb 25th?
>>
>> Our CI start to fail and in log it says:
>>
>> 2016-02-25 03:34:22.515 | Collecting SQLAlchemy-Utils===0.31.6 (from -c 
>> /opt/stack/new/requirements/upper-constraints.txt (line 24))
>> 2016-02-25 03:34:22.602 |   Downloading SQLAlchemy-Utils-0.31.6.tar.gz 
>> (112kB)
>> 2016-02-25 03:34:23.031 | Complete output from command python setup.py 
>> egg_info:
>> 2016-02-25 03:34:23.031 | error in SQLAlchemy-Utils setup command: 
>> 'extras_require' must be a dictionary whose values are strings or lists of 
>> strings containing valid project/version requirement specifiers.
>> 2016-02-25 03:34:23.031 | 
>> 2016-02-25 03:34:23.031 | 
>> 2016-02-25 03:34:23.062 | Command "python setup.py egg_info" failed with 
>> error code 1 in /tmp/pip-build-eRYND2/SQLAlchemy-Utils
>>
>> However, in mirror[1] which we are using, the package is just there, which 
>> confused me.
>> [1] http://mirror.dfw.rax.openstack.org/pypi/simple/sqlalchemy-utils/
>>
>> Thanks for any help.
>>
>> Best regards,
>> Watanabe.isao
> The failure only exists if you are installing from tar.gz and not from
> wheels. For performance reasons the upstream gate builds a wheel mirror
> and installs from that.
>
> Those wheels were built on old setuptools, work on any version. There is
> a setuptools bug registered for this, which should hopefully be fixed today.
>
>   -Sean
>


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

Re: [openstack-dev] [all] A proposal to separate the design summit

[Doug Hellmann]

Excerpts from Jan Klare's message of 2016-02-25 15:29:08 +0100:
> 
> > On 25 Feb 2016, at 13:39, Daniel P. Berrange  wrote:
> > 
> > On Thu, Feb 25, 2016 at 12:40:27PM +0100, Thierry Carrez wrote:
> >> Qiming Teng wrote:
> >>> [...]
> >>> Week 1:
> >>>  Wednesday-Friday: 3 days Summit.
> >>>* Primarily an event for marketing, sales, CTOs, architects,
> >>>  operators, journalists, ...
> >>>* Contributors can decide whether they want to attend this.
> >>>  Saturday-Sunday:
> >>>* Social activities: contributors meet-up, hang outs ...
> >>> 
> >>> Week 2:
> >>>  Monday-Wednesday: 3 days Design Summit
> >>>* Primarily an event for developers.
> >>>* Operators can hold meetups during these days, or join project
> >>>  design summits.
> >>> 
> >>> If you need to attend both events, you don't need two trips. Scheduling
> >>> both events by the end of a release cycle can help gather more
> >>> meaningful feedbacks, experiences or lessons from previous releases and
> >>> ensure a better plan for the coming release.
> >>> 
> >>> If you want to attend just the main Summit or only the Design Summit,
> >>> you can plan your trip accordingly.
> >> 
> >> This was an option we considered. The main objection was that we are pretty
> >> burnt out and ready to go home when comes Friday on a single-week event, so
> >> the prospect of doing two consecutive weeks looked a bit like madness
> >> (especially considering ancillary events like upstream training, the board
> >> meeting etc. which tend to happen on the weekend before summit already). It
> >> felt like a good way to reduce our productivity and not make the most of 
> >> the
> >> limited common time together. Furthermore it doesn't solve the issue of
> >> suboptimal timing as described in my original email.
> 
> I do not think that the other suggestion of two different events solves the 
> issues, but instead moves it to another suboptimal timing issue.
> > 
> > I'd wager a sizeable number of contributors would outright refuse to attend
> > an event for 2 weeks. 6-7 days away from family is already a long time. As
> > such, I would certainly never do any event which spanned 2 weeks, even if
> > both weeks were relevant to my work.
> 
> I don’t think that the suggestion here was to create an event spanning two 
> full weeks. As far as i understand it, the OpenStack summit itself would span 
> nearly the exact same time as before and maybe even less if you decide that 
> you do not want to attend the main summit (or only a part of it), but just 
> the design one (or only a part of it). In addition to that, i think the 
> suggestion of 3 days in the first week and 3 days in the following one is 
> just something we can start a discussion about. I think it would be enough to 
> just have a 2 day main event (maybe Monday and Tuesday) and schedule the 
> design summit with 2 or 3 days directly after that (Wednesday to Thursday or 
> Friday).

For most folks the summit now is a work week + 2 days for travel
on either side of it, or at least 7 days (some of us travel further
than others). Spreading it across 7 full days like this would mean
at least 9 days for anyone who needs to be present for the entire
event. Given that many technical folks do also need to be present
for the conference portion of the event to meet with customers, I
think there would likely be quite a few folks for whom this would
turn into a very long, tiring, trip where productivity would drop off
steeply near the middle.

As Thierry pointed out, it's a bit questionable whether there's
actually much savings for participants with the extended event.
Anyone attending only one half will still need to fly to and stay
in the more expensive venues we're using now, so they save nothing.
Anyone attending both halves may save the cost of one airline ticket,
unless they're going to mid-cycles which we wouldn't be able to
eliminate. In which case extending the event *increases* their costs
because they end up staying in the more expensive hotel for more
nights.

We also have to consider the extra difficulty and expense of trying
to book a venue for such an extended time (considering set up and
tear down time we need it for longer than we'll be actively using
it, even if not by a lot).

Doug

> 
> Cheers,
> Jan
> 
> > 
> > 
> > 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] [Security] IRC Meeting Agenda

[Clark, Robert Graham]

https://etherpad.openstack.org/p/security-20160225-agenda

Cheers
-Rob

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

Re: [openstack-dev] [all] A proposal to separate the design summit

[Jan Klare]

> On 25 Feb 2016, at 13:39, Daniel P. Berrange  wrote:
> 
> On Thu, Feb 25, 2016 at 12:40:27PM +0100, Thierry Carrez wrote:
>> Qiming Teng wrote:
>>> [...]
>>> Week 1:
>>>  Wednesday-Friday: 3 days Summit.
>>>* Primarily an event for marketing, sales, CTOs, architects,
>>>  operators, journalists, ...
>>>* Contributors can decide whether they want to attend this.
>>>  Saturday-Sunday:
>>>* Social activities: contributors meet-up, hang outs ...
>>> 
>>> Week 2:
>>>  Monday-Wednesday: 3 days Design Summit
>>>* Primarily an event for developers.
>>>* Operators can hold meetups during these days, or join project
>>>  design summits.
>>> 
>>> If you need to attend both events, you don't need two trips. Scheduling
>>> both events by the end of a release cycle can help gather more
>>> meaningful feedbacks, experiences or lessons from previous releases and
>>> ensure a better plan for the coming release.
>>> 
>>> If you want to attend just the main Summit or only the Design Summit,
>>> you can plan your trip accordingly.
>> 
>> This was an option we considered. The main objection was that we are pretty
>> burnt out and ready to go home when comes Friday on a single-week event, so
>> the prospect of doing two consecutive weeks looked a bit like madness
>> (especially considering ancillary events like upstream training, the board
>> meeting etc. which tend to happen on the weekend before summit already). It
>> felt like a good way to reduce our productivity and not make the most of the
>> limited common time together. Furthermore it doesn't solve the issue of
>> suboptimal timing as described in my original email.

I do not think that the other suggestion of two different events solves the 
issues, but instead moves it to another suboptimal timing issue.
> 
> I'd wager a sizeable number of contributors would outright refuse to attend
> an event for 2 weeks. 6-7 days away from family is already a long time. As
> such, I would certainly never do any event which spanned 2 weeks, even if
> both weeks were relevant to my work.

I don’t think that the suggestion here was to create an event spanning two full 
weeks. As far as i understand it, the OpenStack summit itself would span nearly 
the exact same time as before and maybe even less if you decide that you do not 
want to attend the main summit (or only a part of it), but just the design one 
(or only a part of it). In addition to that, i think the suggestion of 3 days 
in the first week and 3 days in the following one is just something we can 
start a discussion about. I think it would be enough to just have a 2 day main 
event (maybe Monday and Tuesday) and schedule the design summit with 2 or 3 
days directly after that (Wednesday to Thursday or Friday).

Cheers,
Jan

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

Re: [openstack-dev] [os-brick][nova][cinder] os-brick/privsep change is done and awaiting your review

[John Garbutt]

On 25 February 2016 at 05:32, Angus Lees  wrote:
> (Reposting my reply to your gerrit comment here as well - conversation will
> probably be easier here than in gerrit)
>
> On Thu, 25 Feb 2016 at 00:07 Duncan Thomas  wrote:
>>
>> My (negative) feedback is on the review - I'm really not sure that this
>> matches what I understood the vision of privsep to be at all.
>>
>> - If this is the vision / the new vision then I think it is majorly
>> flawed.
>>
>> - If it is skipping the vision in the name of expediency of
>> implementation, then I think it has gone too far in that direction and we've
>> better off holding off one more cycle and putting it in next cycle instead
>> with a touch more purity of vision.
>>
>> Apologies since you've clearly put work into it, and I should have
>> provided such feedback earlier.
>
>
> Yes, I agree with your concerns 100% and I'm actually quite glad that you
> also understand that this isn't a very satisfying use of privsep.
>
> Better uses of privsep would look more like
> https://review.openstack.org/#/c/258252/ - but they're slow to write since
> they typically involve quite a bit of refactoring of code in order to move
> the trust boundary to a useful point up the call stack.  For os-brick in
> particular, I found it quite difficult/risky performing such code refactors
> without an easy way to actually test the affected low-level device
> manipulation.
>
> At the nova mid-cycle (and again in the nova-cinder VC conversation you were
> part of), it was decided that the difficulties in merging the os-brick
> rootwrap filters into nova (and I presume cinder) were too urgent to wait
> for such a slow os-brick refactoring process.  The conclusion we reached was
> that we would do a quick+dirty rootwrap drop-in replacement that effectively
> just ran commands as root for Mitaka, and then we would come back and
> refactor various codepaths away from that mechanism over time.  This is that
> first quick+dirty change.
> I tried to capture that in the commit description, but evidently did a poor
> job - if the above makes it any clearer to you, I'd welcome any suggested
> rewording for the commit description.
>
> TL;DR: what this buys us is the ability to use new/different command lines
> in os-brick without having to go through a rootwrap filters merge in
> downstream projects (and it is also that first baby step towards a
> technology that will allow something better in the future).

Agreed with the concerns here, but I thought these are the same we
raised at the midcycle.

My understanding of what came out of the midcycle was:
* current rootwrap system horribly breaks upgrade
* adopting privsep in this "sudo" like form fixes upgrade
* this approach is much lower risk than a full conversion at this
point in the release
* security wise its terrible, but then the current rules don't buy us
much anyhow
* makes it easier to slowly transition to better privsep integration
* all seems better than reverting os-brick integration to fix upgrade issues

Now at this point, we are way closer to release, but I want to check
we are making the correct tradeoff here.

Maybe the upgrade problem is not too bad this release, as the hard bit
was done with the last upgrade? Or is that total nonsense?

Thanks,
johnthetubaguy

>> On 24 February 2016 at 14:59, Michał Dulko  wrote:
>>>
>>> On 02/24/2016 04:51 AM, Angus Lees wrote:
>>> > Re: https://review.openstack.org/#/c/277224
>>> >
>>> > Most of the various required changes have flushed out by now, and this
>>> > change now passes the dsvm-full integration tests(*).
>>> >
>>> > (*) well, the experimental job anyway.  It still relies on a
>>> > merged-but-not-yet-released change in oslo.privsep so gate + 3rd party
>>> > won't pass until that happens.
>>> >
>>> > What?
>>> > This change replaces os-brick's use of rootwrap with a quick+dirty
>>> > privsep-based drop-in replacement.  Privsep doesn't actually provide
>>> > much security isolation when used in this way, but it *does* now run
>>> > commands with CAP_SYS_ADMIN (still uid=0/gid=0) rather than full root
>>> > superpowers.  The big win from a practical point of view is that it
>>> > also means os-brick's rootwrap filters file is essentially deleted and
>>> > no longer has to be manually merged with downstream projects.
>>> >
>>> > Code changes required in nova/cinder:
>>> > There is one change each to nova+cinder to add the relevant
>>> > privsep-helper command to rootwrap filters, and a devstack change to
>>> > add a nova.conf/cinder.conf setting.  That's it - this is otherwise a
>>> > backwards/forwards compatible change for nova+cinder.
>>> >
>>> > Deployment changes required in nova/cinder:
>>> > A new "privsep_rootwrap.helper_command" needs to be defined in
>>> > nova/cinder.conf (default is something sensible using sudo), and
>>> > rootwrap filters or sudoers updated depending on the exact command
>>> > chosen.  Be aware 

[openstack-dev] [Fuel] Question about Feature Freeze Exceptions for non-invasive features

[Evgeniy L]

Hi,

We have a spec where we are trying to do research and describe how we are
going to test extensions [0], we will not be able to land it before feature
freeze, so should we get feature freeze exception for it? Or it will not be
a problem to merge it even after FF?

The spec itself is more about the process which we are going to follow
during extensions development, so there should be no changes for current
projects.

Thanks,

[0] https://review.openstack.org/#/c/281749/
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [freezer] 1st recorded session for code walkthrough

[Ramirez Garcia, Guillermo]

Hello All, the recorded session of our first code walkthrough is available at: 
https://www.youtube.com/watch?v=G8nG5l8u5Yg in this session we cover the 
freezer-agent which is the responsible to do the backup and restore of our data.

Any input is appreciated.

Thanks a lot

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

Re: [openstack-dev] [all] A proposal to separate the design summit

[Clark, Robert Graham]

+1 For security too, this exactly mirrors our experience.

From: Duncan Thomas [mailto:duncan.tho...@gmail.com]
Sent: 24 February 2016 12:55
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [all] A proposal to separate the design summit



On 22 February 2016 at 23:11, Devananda van der Veen 
> wrote:
On 02/22/2016 09:45 AM, Thierry Carrez wrote:

The split should ideally reduce the needs to organize separate in-person 
mid-cycle events. If some are still needed, the main conference venue and time 
could easily be used to provide space for such midcycle events (given that it 
would end up happening in the middle of the cycle).

If this "extra midcycle" is sanctioned by the foundation, even if optional, I'm 
concerned that it would grow until developer attendance is expected again. That 
said, I can appreciate the need to keep the option open for now. Perhaps if the 
Conference organizers include a hack-space and allow developers to 
self-organize if present, it will avoid the draw that a formal midcycle has?

The cinder mid-cycle is, by far, out most productive part of the cycle, and 
this has been true for two cycles now. The midcycle is already much, much 
cheaper to attend than the foundation events, and I think the bulk of the 
productivity comes from the fact that all of the people are totally focused on 
one thing - there's no running out to do something else, little scheduling 
around other commitments (except remote attendees) and plenty of opportunity to 
circle back around to things. The massive progress we made at the Cinder 
midcycle only happened because we came back to it I think four times - the kind 
of thinking and communication needed often doesn't fit into slots and sessions, 
and really needs the bandwidth of face to face time.
I now think the cinder mid-cycle is more valuable for many devs, and much 
cheaper, than the foundation events. I don't see that this proposal will 
actually increase that value at all.

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

Re: [openstack-dev] [ceilometer] Unable to get IPMI meter readings

[Kapil]

Below is the output of ceilometer-agent-ipmi in debug mode

http://paste.openstack.org/show/488180/
ᐧ

Regards,
Kapil Agarwal

On Wed, Feb 24, 2016 at 8:18 PM, Lu, Lianhao  wrote:

> On Feb 25, 2016 06:18, Kapil wrote:
> > Hi
> >
> >
> > I discussed this problem with gordc on the telemetry IRC channel but I
> > am still facing issues.
> >
> > I am running the ceilometer-agent-ipmi on the compute nodes, I changed
> > pipeline.yaml of the compute node to include the ipmi meters and
> > resource as "ipmi://localhost".
> >
> > - name: meter_ipmi
> >   interval: 60
> >   resources:
> >   - ipmi://localhost meters: - "hardware.ipmi.node*" -
> >   "hardware.ipmi*" - "hardware.degree*" sinks: - meter_sink I
> > have ipmitool installed on the compute nodes and restarted the
> > ceilometer services on compute and controller nodes. Yet, I am not
> > receiving any ipmi meters when I run "ceilometer meter-list". I also
> > tried passing the hypervisor IP address and the ipmi address I get
> > when I run "ipmitool lan print" to resources but to no avail.
> >
> >
> > Please help in this regard.
> >
> >
> > Thanks
> > Kapil Agarwal
>
> Hi Kapil,
>
> Would you please turn on debug/verbose configurations and paste the log of
> ceilometer-agent-ipmi on http://paste.openstack.org ?
>
> -Lianhao Lu
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] sqlalchemy-utils fails devstack install

[Sean Dague]

On 02/24/2016 11:45 PM, Watanabe, Isao wrote:
> Hello team
> 
> Does anyone know about why sqlalchemy-utils fails devstack install since 
> about 3:00 UTC, Feb 25th?
> 
> Our CI start to fail and in log it says:
> 
> 2016-02-25 03:34:22.515 | Collecting SQLAlchemy-Utils===0.31.6 (from -c 
> /opt/stack/new/requirements/upper-constraints.txt (line 24))
> 2016-02-25 03:34:22.602 |   Downloading SQLAlchemy-Utils-0.31.6.tar.gz (112kB)
> 2016-02-25 03:34:23.031 | Complete output from command python setup.py 
> egg_info:
> 2016-02-25 03:34:23.031 | error in SQLAlchemy-Utils setup command: 
> 'extras_require' must be a dictionary whose values are strings or lists of 
> strings containing valid project/version requirement specifiers.
> 2016-02-25 03:34:23.031 | 
> 2016-02-25 03:34:23.031 | 
> 2016-02-25 03:34:23.062 | Command "python setup.py egg_info" failed with 
> error code 1 in /tmp/pip-build-eRYND2/SQLAlchemy-Utils
> 
> However, in mirror[1] which we are using, the package is just there, which 
> confused me.
> [1] http://mirror.dfw.rax.openstack.org/pypi/simple/sqlalchemy-utils/
> 
> Thanks for any help.
> 
> Best regards,
> Watanabe.isao

The failure only exists if you are installing from tar.gz and not from
wheels. For performance reasons the upstream gate builds a wheel mirror
and installs from that.

Those wheels were built on old setuptools, work on any version. There is
a setuptools bug registered for this, which should hopefully be fixed today.

-Sean

-- 
Sean Dague
http://dague.net

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

Re: [openstack-dev] [gate] ansible release breaks devstack-gate

[Sean Dague]

On 02/25/2016 06:49 AM, Sean Dague wrote:
> It looks like a new ansible release overnight breaks devstack-gate
> (something we assumed was a success, empty subnode commands, is now a
> failure when going from 2.0.0.2 to 2.0.1.0), which is why there is a
> massive failure across the board.
> 
> The code to install ansible exists before things like global
> requirements. I've proposed a fix with explicit versioning here -
> https://review.openstack.org/#/c/284652/
> 
> Assuming tests patch I'll fast approve this through to get people up and
> running. Most of infra is at the meetup and not around to review patches.

This patch is now merged, things should be good to go again.

-Sean

-- 
Sean Dague
http://dague.net

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

Re: [openstack-dev] [puppet] What's up in our CI?

[Bogdan Dobrelya]

On 25.02.2016 03:28, Emilien Macchi wrote:
> 1/ CI failures
> For those who contributed to Puppet OpenStack modules over the last
> days, you might have noticed our CI was pretty unstable.
> 
> The main reason is that our 2 scenarios are overloaded by the number of
> services & tests, so they randomly timeout.

I'm just wondering if we should consider to switch to the "VM-like"
docker (v.1.10) centos/ubuntu based containers plus pipework [0] for
advanced networking? Yes, this'd be not a "docker way", but containers
provide less overhead to HW infra and are really lightweight comparing
to VMs!

Sorry, it that was an off-topic/irrelevant... But I have a simple PoC
example [1] that proves that it works more or less, at least for me,
well - it tests a rabbitmq cluster built on top of a pacemaker cluster
in docker containers at Travis CI. No nodepools, and only VM's involved
is the one that Travis spawns for a user's job.

[0] https://github.com/jpetazzo/pipework
[1]
https://github.com/bogdando/rabbitmq-cluster-ocf-vagrant/blob/master/.travis.yml_example

> 
> Here are some actions that should bring back our CI in a good shape:
> * Add scenario003 and move some services from 001/002 to 003
>   https://review.openstack.org/284388
> * Optimize Zuul layout to consume less resources in OpenStack Infra
>   https://review.openstack.org/284431
> * Continue to reduce to 2 the number of workers when possible
>   https://review.openstack.org/284289
> * Investigate why `gem install r10k` takes 12 minutes on Internap cloud
>   (instead of a few seconds on other clouds)
>   https://review.openstack.org/#/c/283696/
> 
> 
> 2/ scenario001 is the RBD scenario
> scenario001 is now deploying Glance, Nova, Cinder and Gnocchi with RBD
> backend (Ceph).
> We can call it a Compute + Telemetry + Ceph scenario.
> 
> 
> 3/ What's next
> Currently in the pipe:
> * running tempest with plugins
> * add Zaqar
> * add Neutron FWaaS, LBaaS
> * on scenario002: use Swift for Glance backand and Neutron ML2
> linuxbridge (instead of ML2 OVS).
> * more (please bring ideas & feedback)
> 
> Any questions / suggestions are welcome,
> 
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 


-- 
Best regards,
Bogdan Dobrelya,
Irc #bogdando

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

Re: [openstack-dev] [all] A proposal to separate the design summit

[Sean Dague]

On 02/25/2016 07:39 AM, Daniel P. Berrange wrote:
> On Thu, Feb 25, 2016 at 12:40:27PM +0100, Thierry Carrez wrote:
>> Qiming Teng wrote:
>>> [...]
>>> Week 1:
>>>   Wednesday-Friday: 3 days Summit.
>>> * Primarily an event for marketing, sales, CTOs, architects,
>>>   operators, journalists, ...
>>> * Contributors can decide whether they want to attend this.
>>>   Saturday-Sunday:
>>> * Social activities: contributors meet-up, hang outs ...
>>>
>>> Week 2:
>>>   Monday-Wednesday: 3 days Design Summit
>>> * Primarily an event for developers.
>>> * Operators can hold meetups during these days, or join project
>>>   design summits.
>>>
>>> If you need to attend both events, you don't need two trips. Scheduling
>>> both events by the end of a release cycle can help gather more
>>> meaningful feedbacks, experiences or lessons from previous releases and
>>> ensure a better plan for the coming release.
>>>
>>> If you want to attend just the main Summit or only the Design Summit,
>>> you can plan your trip accordingly.
>>
>> This was an option we considered. The main objection was that we are pretty
>> burnt out and ready to go home when comes Friday on a single-week event, so
>> the prospect of doing two consecutive weeks looked a bit like madness
>> (especially considering ancillary events like upstream training, the board
>> meeting etc. which tend to happen on the weekend before summit already). It
>> felt like a good way to reduce our productivity and not make the most of the
>> limited common time together. Furthermore it doesn't solve the issue of
>> suboptimal timing as described in my original email.
> 
> I'd wager a sizeable number of contributors would outright refuse to attend
> an event for 2 weeks. 6-7 days away from family is already a long time. As
> such, I would certainly never do any event which spanned 2 weeks, even if
> both weeks were relevant to my work.

Agreed. For folks that need to get in time for the board meeting, the
Summit is basically already an 8 day event (counting travel days). I
know I wouldn't do back to back weeks.

-Sean

-- 
Sean Dague
http://dague.net

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

Re: [openstack-dev] [all] A proposal to separate the design summit

[Daniel P. Berrange]

On Thu, Feb 25, 2016 at 12:40:27PM +0100, Thierry Carrez wrote:
> Qiming Teng wrote:
> >[...]
> >Week 1:
> >   Wednesday-Friday: 3 days Summit.
> > * Primarily an event for marketing, sales, CTOs, architects,
> >   operators, journalists, ...
> > * Contributors can decide whether they want to attend this.
> >   Saturday-Sunday:
> > * Social activities: contributors meet-up, hang outs ...
> >
> >Week 2:
> >   Monday-Wednesday: 3 days Design Summit
> > * Primarily an event for developers.
> > * Operators can hold meetups during these days, or join project
> >   design summits.
> >
> >If you need to attend both events, you don't need two trips. Scheduling
> >both events by the end of a release cycle can help gather more
> >meaningful feedbacks, experiences or lessons from previous releases and
> >ensure a better plan for the coming release.
> >
> >If you want to attend just the main Summit or only the Design Summit,
> >you can plan your trip accordingly.
> 
> This was an option we considered. The main objection was that we are pretty
> burnt out and ready to go home when comes Friday on a single-week event, so
> the prospect of doing two consecutive weeks looked a bit like madness
> (especially considering ancillary events like upstream training, the board
> meeting etc. which tend to happen on the weekend before summit already). It
> felt like a good way to reduce our productivity and not make the most of the
> limited common time together. Furthermore it doesn't solve the issue of
> suboptimal timing as described in my original email.

I'd wager a sizeable number of contributors would outright refuse to attend
an event for 2 weeks. 6-7 days away from family is already a long time. As
such, I would certainly never do any event which spanned 2 weeks, even if
both weeks were relevant to my work.


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

Re: [openstack-dev] [nova] nova-compute blocking main thread under heavy disk IO

[Sam Matzek]

For what it's worth Glance API also has to deal with file I/O blocking
all greenthreads and has CooperativeReaders/Writers that yield around
the file I/O to mitigate starvation.  A while ago I hit an issue with
5 concurrent VM snapshots starving Nova compute eventlets due to the
excessive file IO of reading the snapshot file to upload.  This could
be remedied by taking the cooperative reader from Glance API and using
it in glanceclient [1].  It's not perfect but something similar could
help out the glance image download issues without needing to tweak the
OS.

[1] https://bugs.launchpad.net/python-glanceclient/+bug/1327248

On Mon, Feb 22, 2016 at 1:13 PM, Chris Friesen
 wrote:
> On 02/22/2016 11:20 AM, Daniel P. Berrange wrote:
>>
>> On Mon, Feb 22, 2016 at 12:07:37PM -0500, Sean Dague wrote:
>>>
>>> On 02/22/2016 10:43 AM, Chris Friesen wrote:
>
>
 But the fact remains that nova-compute is doing disk I/O from the main
 thread, and if the guests push that disk hard enough then nova-compute
 is going to suffer.

 Given the above...would it make sense to use eventlet.tpool or similar
 to perform all disk access in a separate OS thread?  There'd likely be a
 bit of a performance hit, but at least it would isolate the main thread
 from IO blocking.
>>>
>>>
>>> Making nova-compute more robust is fine, though the reality is once you
>>> IO starve a system, a lot of stuff is going to fall over weird.
>>>
>>> So there has to be a tradeoff of the complexity of any new code vs. what
>>> it gains. I think individual patches should be evaluated as such, or a
>>> spec if this is going to get really invasive.
>>
>>
>> There are OS level mechanisms (eg cgroups blkio controller) for doing
>> I/O priorization that you could use to give Nova higher priority over
>> the VMs, to reduce (if not eliminate) the possibility that a busy VM
>> can inflict a denial of service on the mgmt layer.  Of course figuring
>> out how to use that mechanism correctly is not entirely trivial.
>
>
> The 50+ second delays were with CFQ as the disk scheduler.  (No cgroups
> though, just CFQ with equal priorities on nova-compute and the guests.)
> This was with a 3.10 kernel though, so maybe CFQ behaves better on newer
> kernels.
>
> If you put nova-compute at high priority then glance image downloads,
> qemu-img format conversions, and volume clearing will also run at the higher
> priority, potentially impacting running VMs.
>
> In an ideal world we'd have per-VM cgroups and all activity on behalf of a
> particular VM would be done in the context of that VM's cgroup.
>
> Chris
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[openstack-dev] [gate] ansible release breaks devstack-gate

[Sean Dague]

It looks like a new ansible release overnight breaks devstack-gate
(something we assumed was a success, empty subnode commands, is now a
failure when going from 2.0.0.2 to 2.0.1.0), which is why there is a
massive failure across the board.

The code to install ansible exists before things like global
requirements. I've proposed a fix with explicit versioning here -
https://review.openstack.org/#/c/284652/

Assuming tests patch I'll fast approve this through to get people up and
running. Most of infra is at the meetup and not around to review patches.

-Sean

-- 
Sean Dague
http://dague.net

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

Re: [openstack-dev] [all] A proposal to separate the design summit

[Thierry Carrez]

Qiming Teng wrote:

[...]
Week 1:
   Wednesday-Friday: 3 days Summit.
 * Primarily an event for marketing, sales, CTOs, architects,
   operators, journalists, ...
 * Contributors can decide whether they want to attend this.
   Saturday-Sunday:
 * Social activities: contributors meet-up, hang outs ...

Week 2:
   Monday-Wednesday: 3 days Design Summit
 * Primarily an event for developers.
 * Operators can hold meetups during these days, or join project
   design summits.

If you need to attend both events, you don't need two trips. Scheduling
both events by the end of a release cycle can help gather more
meaningful feedbacks, experiences or lessons from previous releases and
ensure a better plan for the coming release.

If you want to attend just the main Summit or only the Design Summit,
you can plan your trip accordingly.


This was an option we considered. The main objection was that we are 
pretty burnt out and ready to go home when comes Friday on a single-week 
event, so the prospect of doing two consecutive weeks looked a bit like 
madness (especially considering ancillary events like upstream training, 
the board meeting etc. which tend to happen on the weekend before summit 
already). It felt like a good way to reduce our productivity and not 
make the most of the limited common time together. Furthermore it 
doesn't solve the issue of suboptimal timing as described in my original 
email.


The benefit is that for people attending both events, you indeed save on 
pure flight costs. But since you have to cover for conference hotel 
rooms and food over the weekend and otherwise compensate employees for 
being stuck there over the weekend, the gain is not that significant...


--
Thierry Carrez (ttx)

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

Re: [openstack-dev] [Kuryr] Now part of OpenStack big-tent

[Fawad Khaliq]

On Wed, Feb 24, 2016 at 8:51 PM, Gal Sagie  wrote:

> Hello Everyone,
>
> Just wanted to update you that Kuryr [1] was officially accepted yesterday
> as a
> big tent project.
>

Great news and congrats everyone!


> We are currently facing some interesting challenges and times and if you
> are running containers in OpenStack in mixed environments you most
> certainly
> want to look and examine Kuryr.
>
> We are holding a weekly IRC meeting [2] which is alternating between time
> zones
> so you have no excuse :) everyone are welcome!
>

+1, and sometimes free virtual food (KFC) is also served ;-)


> We want to help and solve more challenges in the realm of containers
> networking
> deployments in OpenStack and if you are deploying this either in
> development or
> in production we would love to hear your experience and the problems you
> are facing
> and try to help you manage this better, feel free to share!
>

+1


> [1] https://wiki.openstack.org/wiki/Kuryr
> [2] https://wiki.openstack.org/wiki/Meetings/Kuryr
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel][Fuel-Library] Nominating Matthew Mosesohn for Fuel Library Core

[Bogdan Dobrelya]

I agree, although, with an additional thing to be addressed as a
mandatory action item. As that'd reduce an amount of the fuel-library
mainteners, which review patches before to invite core reviewers, we
shall suggest a new maintainer to replace Matthew as well.


On 25.02.2016 10:43, Vitaly Kramskikh wrote:
> +1
> 
> 2016-02-25 16:41 GMT+07:00 Sergey Kulanov  >:
> 
> +1
> 
> 2016-02-25 11:37 GMT+02:00 Alexander Kislitsky
> >:
> 
> +1
> 
> On Thu, Feb 25, 2016 at 12:32 PM, Bulat Gaifullin
> > wrote:
> 
> +1
> 
> Regards,
> Bulat Gaifullin
> Mirantis Inc.
> 
> 
> 
>> On 24 Feb 2016, at 16:02, Aleksandr Didenko
>> > wrote:
>>
>> +1
>>
>> On Wed, Feb 24, 2016 at 1:50 PM, Vladimir Kuklin
>> > wrote:
>>
>> Fellow Fuelers 
>>
>> I would like to kindly ask you to consider voting for
>> Matthew Mosesohn as a Fuel Library Core
>> reviewer.
>>
>> Matthew has been working with Fuel since its
>> inception, worked on countless amount of features,
>> such as :
>>
>> Master Node Upgrades and Backup
>> Improvements to Fuel Infra
>> Mitaka, Kilo and Juno Support
>> Detachable Services Plugins
>> RHOS Support in Fuel
>> UCA Support
>> Refactoring of Haproxy and Firewall pieces
>>
>> He has also been known as our Fuel Master node and
>> Docker guru and has been continuously working on
>> bugfixing where he scores as a bug squashing monster
>> with more than 150 bugfixes to all the parts of Fuel
>> Library (#1 throughout FL history).
>>
>> As you can see, there is not a piece of Fuel Library
>> that he has not yet gained experience with.
>>
>> And this can easily be fetched with simple statistics
>> of Matt's contribution. He is the topmost contributor
>> to all Fuel projects among all Fuel Library folks and
>> is the 3rd contributor of Fuel Library.
>> He also reviews a lot and has a fair amount of -1's
>> (he is not as cruel as me, though :-))
>>
>> Having that said, I would like to open the vote to
>> promote Matt to OpenStack Fuel Library core reviewers.
>>
>> -- 
>> Yours Faithfully,
>> Vladimir Kuklin,
>> Fuel Library Tech Lead,
>> Mirantis, Inc.
>> +7 (495) 640-49-04 
>> +7 (926) 702-39-68 
>> Skype kuklinvv
>> 35bk3, Vorontsovskaya Str.
>> Moscow, Russia,
>> www.mirantis.com 
>> www.mirantis.ru 
>> vkuk...@mirantis.com 
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage
>> questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> 
>> 
>> 
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org
>> 
>> ?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe 
> 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
>   

[openstack-dev] [nova][cinder] Fix nova swap volume (updating an attached volume) function

[Takashi Natsume]

Hi Nova and Cinder developers.

As I reported in a bug report [1], nova swap volume
(updating an attached volume) fuction does not work
in the case of non admin users by default. 
(Volumes are stuck.)

Before I was working for fixing another swap volume bug [2][3].
But Ryan fixed it on the Cinder side [4].
As a result, admin users can execute swap volume function,
but it was not fixed in the case of non admin users.
So I reported the bug report [1].

In the patch[5], I tried to change the default cinder's policy
to allow non admin users to execute migrate_volume_completion API.
But it was rejected by the cinder project ('-2' was voted).

In the patch[5], it was suggested to make the swap volume API admin only
on the Nova side.
But IMO, the swap volume function should be allowed to non admin users
because attaching a volume and detaching a volume can be performed
by non admin users.

If migrate_volume_completion is only allowed to admin users
by default on the Cinder side, attaching a new volume and
detaching an old volume should be performed on the Nova side
when swapping volumes.

If you have a good idea, please let me know it.

[1] Cinder volumes are stuck when non admin user executes nova swap volume API
https://bugs.launchpad.net/cinder/+bug/1522705

[2] Cinder volume stuck in swap_volume
https://bugs.launchpad.net/nova/+bug/1471098

[3] Fix cinder volume stuck in swap_volume
https://review.openstack.org/#/c/207385/

[4] Fix swap_volume for case without migration
https://review.openstack.org/#/c/247767/

[5] Enable volume owners to execute migrate_volume_completion
https://review.openstack.org/#/c/253363/

Regards,
Takashi Natsume
NTT Software Innovation Center
E-mail: natsume.taka...@lab.ntt.co.jp





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

Re: [openstack-dev] [glance] Austin Design Summit space needs

[Flavio Percoco]

On Wed, Feb 24, 2016 at 2:25 PM, Nikhil Komawar 
wrote:

> Here are a few ideas that I've in mind (more than 6 for now) for the
> workroom sessions (of course that can be prioritized):
>
> 1. Import refactor
> 2. Glare
> 3. Quotas
> 4. State of Image sharing, community images, Hierarchical Images etc.
> 5. glance_store improvements, general gate jobs discussions, releases
> discussions, logging, notification etc.
> 6. First hand & closed loop dedicated operator, superuser, general user,
> experience, etc. feedback
> 7. Feedback into the team from other projects, cross projects, general
> workflow, etc. changes
> 8. Priorities discussions
>

Thing is that most of what's going to be discussed is dictated by the
priorities themselves. We have a rough idea of what the priorities for
Newton are.

I think the list you provided is good but it still doesn't seem to require
an extra workroom for us (considering we have 3 fishbowl sessions too).

Flavio

>
> I think we can utilize the contributors meetup for some of them but all of
> them potentially involve folks who may not necessarily be first level
> contributors to Glance or at all (in case they want to attend other
> meetup). Also, asking for 8 (or more than 6) would be ill effect against
> being good openstack citizens.
>
>
> On 2/24/16 12:25 PM, Flavio Percoco wrote:
>
>
>
> On Wed, Feb 24, 2016 at 12:27 PM, Nikhil Komawar < 
> nik.koma...@gmail.com> wrote:
>
>> Can we make it ? :
>>
>> FB 3
>> W 6
>> C 2
>>
>>
>
> Could you elaborate on why you think we need 6 workroom sessions?
>
> Back in Tokyo, 5 seemed more than enough and there will be more projects
> to host in Austin.
>
> Cheers,
> Flavio
>
>
>>
>> On 2/24/16 10:42 AM, Flavio Percoco wrote:
>>
>> Hey Folks,
>>
>> It's that time of the year. We need to choose what our needs with regards
>> to slots and sessions are for the next summit.
>>
>> We can choose among 3 different types of sessions:
>>
>> * Fishbowl slots (Wed-Thu)
>> Our traditional largish rooms organized in fishbowl style, with
>> advertised session content on the summit schedule for increased external
>> participation. Ideal for when wider feedback is essential.
>>
>> * Workroom slots (Tue-Thu)
>> Smaller rooms organized in boardroom style, with topic buried in the
>> session description, in an effort to limit attendance and not overcrowd
>> the room. Ideal to get work done and prioritize work in small teams.
>>
>> * Contributors meetup (Fri)
>> Half-day session(s) on the Friday to get into the Newton action while
>> decisions and plans are still hot, or to finish discussions started
>> during the week, whatever works for you.
>>
>> Our usage in Tokyo was: 3, 5, 2
>>
>> I'd recommend we keep it that way. Thoughts?
>> Cheers,
>> Flavio
>>
>> --
>> @flaper87
>> Flavio Percoco
>>
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: 
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>> --
>>
>> Thanks,
>> Nikhil
>>
>>
>
>
> --
> @flaper87
> Flavio Percoco
>
>
> --
>
> Thanks,
> Nikhil
>
>


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

Re: [openstack-dev] sqlalchemy-utils fails devstack install

[Sean Dague]

On 02/25/2016 12:53 AM, Tony Breeds wrote:
> On Thu, Feb 25, 2016 at 04:45:48AM +, Watanabe, Isao wrote:
>> Hello team
>>
>> Does anyone know about why sqlalchemy-utils fails devstack install since
>> about 3:00 UTC, Feb 25th?
> 
> I don't have anything helpful to add really other than:
> 
> This bug https://bugs.launchpad.net/devstack/+bug/1548591 was opened 2 days 
> ago ; but
> http://logstash.openstack.org/#/dashboard/file/logstash.json?query=message:%5C%22error%20in%20SQLAlchemy-Utils%20setup%20command:%5C%22=864000s
> 
> Matches your timeline that it's started being an issue in the last 2 hours
> 
> Shows that's really hurting kolla, but openstack-ansible, devstack, neutron 
> and
> octavia are all affected.
> 
> Typically somethign like this will happen when a new release for $project 
> comes out but:
> SQLAlchemy-Utils-0.31.6.tar.gz : 2016-01-21T12:36:09
> 
> And I4ff173ed9559d3dfe38cde15dc0f9a9487b45528 merged it into u-c on Sun Jan 24
> 06:26:51 2016 +
> 
> Looksing at: 
> https://github.com/kvesteri/sqlalchemy-utils/blob/master/setup.py#L25-L58
> 
> I wonder if all the failures share a common python? perhaps 3.4?

Most of that is non-voting. It's not impacting kolla. This only exposes
on Red Hat platforms, and only is actually downvoting ansible and
oslo.messaging.

-Sean

-- 
Sean Dague
http://dague.net

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

Re: [openstack-dev] sqlalchemy-utils fails devstack install

[Sean Dague]

On 02/25/2016 05:49 AM, Jesse Pretorius wrote:
> On 25 February 2016 at 06:43, Shinobu Kinjo  > wrote:
> 
> Sorry, I don't use master.
> But AFAICT there is no issue with stable/liberty.
> 
> 
> It would seem that this is affecting neutron, oslo.messaging, kolla,
> barbican, openstack-ansible, octavia and is affecting master and liberty
> branches.
> 
> http://logstash.openstack.org/#/dashboard/file/logstash.json?query=message:%5C%22error%20in%20SQLAlchemy-Utils%20setup%20command:%5C%22=864000s
>  

Add voting:1 to the query.

Very few of those are voting jobs. It's only affecting olso.messaging
and ansible.

-Sean

-- 
Sean Dague
http://dague.net

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

Re: [openstack-dev] [nova] solving API case sensitivity issues

[Sean Dague]

On 02/24/2016 06:56 PM, Chris Friesen wrote:
> On 02/24/2016 02:34 PM, Sean Dague wrote:
> 
>> There are no urls stored here. This is content coming through the body.
>> While I do appreciate many folks weighing in that haven't read the bug
>> yet, I would be even better if people did read the bug first.
>>
>> We have the ability to decide at the API level what the behavior is of
>> payloads in POST / GET. Given the majority of our users are on mysql,
>> they've never had access to case sensitive overlapping metadata on
>> aggregates before. Doing so seems odd and potentially confusing.
> 
> On the other hand, coming from a UNIX environment where case sensitivity
> is the default, it seems odd that we'd intentionally become
> case-insensitive.
> 
> For option 2 do we need to actually update the DB column description? 
> Or is there a way to alter the query to be case-insensitive without
> altering the column itself (using collate maybe)?

Collate is a change in the way the data is stored, it's a real alter.
The data structures look different if they are designed to be searched
with case folding or as binary.

-Sean

-- 
Sean Dague
http://dague.net

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

Re: [openstack-dev] [Fuel][murano][fuel-plugins] Move Murano to plugin from Fuel box

[Denis Egorenko]

Hey Igor,

We are planing to release Murano plugin with Fuel 9.0. So, after plugin
will be ready,
we just disable Murano built in installation. We don't expect to have any
conflicts, because
we will use overridden hiera data for plugin and all old serialized Murano
information will be
useless.


2016-02-25 13:38 GMT+03:00 Igor Kalnitsky :

> Hey Denis,
>
> I didn't read the spec yet, but want to raise one important question.
> AFAIU, you plan to release Murano plugin between Fuel 9.0 and Fuel 10,
> so the question is do you plan to support installation of Murano
> plugin on Fuel 9.0? If so, that might be a problem.
>
> Thanks,
> - Igor
>
> On Wed, Feb 24, 2016 at 6:30 PM, Denis Egorenko 
> wrote:
> > Hello folks,
> >
> > i would like to notify you, that we are going to remove Murano as built
> in
> > Fuel and move this functionality to fuel-plugin.
> >
> > Transition from Fuel built in to Fuel plugin deployment will follow next
> > way:
> >
> > * Murano deployment in Fuel 9.0 will be deprecated: we leave an ability
> to
> > deploy it,
> >   keeping puppet manifests for Murano in fuel-library, keeping UI
> settings
> >   untill plugin will be prepared and tested;
> >
> > * Once plugin is ready, Fuel 9.0 deployment from built in Murano will
> >   forbidden. All Murano codebase will be removed from Fuel in next
> release.
> >
> > Since Murano will be a plugin, it will have his own development cycle,
> > differ from Fuel releases.
> >
> > There is specification for this activity [1]. Any feedback is welcome.
> >
> > [1] https://review.openstack.org/275124
> >
> > --
> > Best Regards,
> > Egorenko Denis,
> > Senior Deployment Engineer
> > Mirantis
> >
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Best Regards,
Egorenko Denis,
Senior Deployment Engineer
Mirantis
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] sqlalchemy-utils fails devstack install

[Valeriy Ponomaryov]

There is more affected projects than mentioned "neutron, oslo.messaging,
kolla, barbican, openstack-ansible, octavia". Their logs just do not have
same error messages as you search for in logstash.

Manila project is broken too and it does not have such error message in
logs.

On Thu, Feb 25, 2016 at 12:49 PM, Jesse Pretorius  wrote:

> On 25 February 2016 at 06:43, Shinobu Kinjo  wrote:
>
>> Sorry, I don't use master.
>> But AFAICT there is no issue with stable/liberty.
>>
>
> It would seem that this is affecting neutron, oslo.messaging, kolla,
> barbican, openstack-ansible, octavia and is affecting master and liberty
> branches.
>
>
> http://logstash.openstack.org/#/dashboard/file/logstash.json?query=message:%5C%22error%20in%20SQLAlchemy-Utils%20setup%20command:%5C%22=864000s
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Kind Regards
Valeriy Ponomaryov
www.mirantis.com
vponomar...@mirantis.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] sqlalchemy-utils fails devstack install

[Jesse Pretorius]

On 25 February 2016 at 06:43, Shinobu Kinjo  wrote:

> Sorry, I don't use master.
> But AFAICT there is no issue with stable/liberty.
>

It would seem that this is affecting neutron, oslo.messaging, kolla,
barbican, openstack-ansible, octavia and is affecting master and liberty
branches.

http://logstash.openstack.org/#/dashboard/file/logstash.json?query=message:%5C%22error%20in%20SQLAlchemy-Utils%20setup%20command:%5C%22=864000s
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [i18n][stackalytics] Translations metrics

[Ying Chun Guo]

Hi, Ilya

Is it possible to link two IDs with email ?

Best regards
Ying Chun Guo (Daisy)


Ilya Shakhat  wrote on 2016/02/25 18:35:22:

> From: Ilya Shakhat 
> To: "OpenStack Development Mailing List (not for usage questions)"
> 
> Cc: Haruhiko Katou 
> Date: 2016/02/25 18:39
> Subject: Re: [openstack-dev] [i18n][stackalytics] Translations metrics
>
> Hi Shu,
>
> Thanks for bringing attention to this. The reason is that
> Stackalytics tries to match Zanata id with LP id, and expects both
> to be the same. But if they are different (or point to different
> people) then a static profile should help. I will add the one for you
soon.
>
> Best regards,
> Ilya Shakhat
>
> 2016-02-25 12:19 GMT+03:00 Akihiro Motoki :
> Hi Shu,
>
> I am confused with the sentence "My Zanata ID "shu" is used by "Seihu"
> in Launchpad".
> I think Zanata ID is linked with OpenStack Foundation profile
> and is not linked directly with launchpad ID.
> Could you clarify the situation?
>
>
>
> 2016-02-25 18:08 GMT+09:00 Shuu Mutou :
> > Hi,
> >
> > Stackalytics shows my translations as other ones.
> > Does the difference between Zanata ID and Launchpad ID cause the
problem?
> >
> > * My Zanata ID "shu" is used by "Seihu" in Launchpad.
> > * My Launchpad ID is "shu-mutou".
> >
> > If so, I hope that email address will be used for matching user.
> >
> > Shu Muto
> > NEC Solution Innovators, Ltd.
> >
> >
> >
__
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [horizon][i18n] Any Horizon plugins ready for translation in Mitaka?

[Andreas Jaeger]

On 2016-02-25 11:40, Ying Chun Guo wrote:
> Thank you, Akihiro.
> The projects listed below are all in translation website except
> desginate-dasbhard.

Typo, it' designate, see
https://translate.openstack.org/project/view/designate-dashboard

> Whether these projects can get translated in Mitaka depends.
> Let's discuss with team.

Andreas

> Best regards
> Ying Chun Guo (Daisy)
> 
> 
> Akihiro Motoki  wrote on 2016/02/23 15:56:39:
> 
>> From: Akihiro Motoki 
>> To: "OpenStack Development Mailing List (not for usage questions)"
>> 
>> Date: 2016/02/23 16:00
>> Subject: Re: [openstack-dev] [horizon][i18n] Any Horizon plugins
>> ready for translation in Mitaka?
>>
>> Hi Daisy,
>>
>> AFAIK the following horizon plugins are ready for translation.
>> I tested and confirmed translations of these two work well with Japanese.
>> A minor improvement on devstack or other stuff are in progress but it
>> does not affect translation.
>>
>> * trove-dashboard
>> * sahara-dashboard
>>
>> The following horizon plugins SEEM to support translations.
>> I have never tried them.
>>
>> * desginate-dasbhard
>> * magnum-ui
>> * monasca-ui
>> * murano-dashboard
>> * senlin-dashboard
>>
>> Thanks,
>> Akihiro
>>
>> 2016-02-23 15:52 GMT+09:00 Ying Chun Guo :
>> > Hi,
>> >
>> > Mitaka translation will be started from March 4 and ended in the week of
>> > March 28.
>> > I'd like to know which Horizon plugins[1] are ready for translation in
>> > Mitaka release.
>> > If there are, I'm happy to include them in the Mitaka translation plan.
>> >
>> > Thank you.
>> >
>> > Best regards
>> > Ying Chun Guo (Daisy)
>> >
>> > [1] http://docs.openstack.org/developer/horizon/plugin_registry.html
>> >
>> >
>> >
> __
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
> 
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 


-- 
 Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
  SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GF: Felix Imendörffer, Jane Smithard, Graham Norton,
   HRB 21284 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126


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

Re: [openstack-dev] [horizon][i18n] Any Horizon plugins ready for translation in Mitaka?

[Ying Chun Guo]

Thank you, Akihiro.
The projects listed below are all in translation website except
desginate-dasbhard.
Whether these projects can get translated in Mitaka depends.
Let's discuss with team.

Best regards
Ying Chun Guo (Daisy)


Akihiro Motoki  wrote on 2016/02/23 15:56:39:

> From: Akihiro Motoki 
> To: "OpenStack Development Mailing List (not for usage questions)"
> 
> Date: 2016/02/23 16:00
> Subject: Re: [openstack-dev] [horizon][i18n] Any Horizon plugins
> ready for translation in Mitaka?
>
> Hi Daisy,
>
> AFAIK the following horizon plugins are ready for translation.
> I tested and confirmed translations of these two work well with Japanese.
> A minor improvement on devstack or other stuff are in progress but it
> does not affect translation.
>
> * trove-dashboard
> * sahara-dashboard
>
> The following horizon plugins SEEM to support translations.
> I have never tried them.
>
> * desginate-dasbhard
> * magnum-ui
> * monasca-ui
> * murano-dashboard
> * senlin-dashboard
>
> Thanks,
> Akihiro
>
> 2016-02-23 15:52 GMT+09:00 Ying Chun Guo :
> > Hi,
> >
> > Mitaka translation will be started from March 4 and ended in the week
of
> > March 28.
> > I'd like to know which Horizon plugins[1] are ready for translation in
> > Mitaka release.
> > If there are, I'm happy to include them in the Mitaka translation plan.
> >
> > Thank you.
> >
> > Best regards
> > Ying Chun Guo (Daisy)
> >
> > [1] http://docs.openstack.org/developer/horizon/plugin_registry.html
> >
> >
> >
__
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
>
__
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel][murano][fuel-plugins] Move Murano to plugin from Fuel box

[Igor Kalnitsky]

Hey Denis,

I didn't read the spec yet, but want to raise one important question.
AFAIU, you plan to release Murano plugin between Fuel 9.0 and Fuel 10,
so the question is do you plan to support installation of Murano
plugin on Fuel 9.0? If so, that might be a problem.

Thanks,
- Igor

On Wed, Feb 24, 2016 at 6:30 PM, Denis Egorenko  wrote:
> Hello folks,
>
> i would like to notify you, that we are going to remove Murano as built in
> Fuel and move this functionality to fuel-plugin.
>
> Transition from Fuel built in to Fuel plugin deployment will follow next
> way:
>
> * Murano deployment in Fuel 9.0 will be deprecated: we leave an ability to
> deploy it,
>   keeping puppet manifests for Murano in fuel-library, keeping UI settings
>   untill plugin will be prepared and tested;
>
> * Once plugin is ready, Fuel 9.0 deployment from built in Murano will
>   forbidden. All Murano codebase will be removed from Fuel in next release.
>
> Since Murano will be a plugin, it will have his own development cycle,
> differ from Fuel releases.
>
> There is specification for this activity [1]. Any feedback is welcome.
>
> [1] https://review.openstack.org/275124
>
> --
> Best Regards,
> Egorenko Denis,
> Senior Deployment Engineer
> Mirantis
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

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

Re: [openstack-dev] [i18n][stackalytics] Translations metrics

[Ilya Shakhat]

Hi Shu,

Thanks for bringing attention to this. The reason is that Stackalytics
tries to match Zanata id with LP id, and expects both to be the same. But
if they are different (or point to different people) then a static profile
should help. I will add the one for you soon.

Best regards,
Ilya Shakhat

2016-02-25 12:19 GMT+03:00 Akihiro Motoki :

> Hi Shu,
>
> I am confused with the sentence "My Zanata ID "shu" is used by "Seihu"
> in Launchpad".
> I think Zanata ID is linked with OpenStack Foundation profile
> and is not linked directly with launchpad ID.
> Could you clarify the situation?
>
>
>
> 2016-02-25 18:08 GMT+09:00 Shuu Mutou :
> > Hi,
> >
> > Stackalytics shows my translations as other ones.
> > Does the difference between Zanata ID and Launchpad ID cause the problem?
> >
> > * My Zanata ID "shu" is used by "Seihu" in Launchpad.
> > * My Launchpad ID is "shu-mutou".
> >
> > If so, I hope that email address will be used for matching user.
> >
> > Shu Muto
> > NEC Solution Innovators, Ltd.
> >
> >
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [i18n][stackalytics] Translations metrics

[Ying Chun Guo]

Zanata ID is not linked directly with launchpad ID.
It will cause a contributor have two IDs in stacklaytics, not a unique ID.
An ID in Gerrit metrics and etc, and a second ID in translation metrics.

He want to have a unique ID in stacklaytics which can link to
all of his contributions.
I think this is what Shu is talking about.

Best regards
Ying Chun Guo (Daisy)


Akihiro Motoki  wrote on 2016/02/25 17:19:40:

> From: Akihiro Motoki 
> To: "OpenStack Development Mailing List (not for usage questions)"
> 
> Cc: Haruhiko Katou 
> Date: 2016/02/25 17:23
> Subject: Re: [openstack-dev] [i18n][stackalytics] Translations metrics
>
> Hi Shu,
>
> I am confused with the sentence "My Zanata ID "shu" is used by "Seihu"
> in Launchpad".
> I think Zanata ID is linked with OpenStack Foundation profile
> and is not linked directly with launchpad ID.
> Could you clarify the situation?
>
>
>
> 2016-02-25 18:08 GMT+09:00 Shuu Mutou :
> > Hi,
> >
> > Stackalytics shows my translations as other ones.
> > Does the difference between Zanata ID and Launchpad ID cause the
problem?
> >
> > * My Zanata ID "shu" is used by "Seihu" in Launchpad.
> > * My Launchpad ID is "shu-mutou".
> >
> > If so, I hope that email address will be used for matching user.
> >
> > Shu Muto
> > NEC Solution Innovators, Ltd.
> >
> >
> >
__
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] A proposal to separate the design summit

[Michał Dulko]

On 02/25/2016 09:13 AM, Qiming Teng wrote:
> Hi, All,
>
> After reading through all the +1's and -1's, we realized how difficult
> it is to come up with a proposal that makes everyone happy. When we are
> discussing this proposal with some other contributors, we came up with a
> proposal which is a little bit different. This idea could be very
> impractical, very naive, given that we don't know much about the huge
> efforts behind the scheduling, planning, coordination ... etc etc. So,
> please treat this as a random thought.
>
> Maybe we can still have the Summit and the Design Summit colocated, but
> we can avoid the overlap that has been the source of many troubles. The
> idea is to have both events scheduled by the end of a release cycle. For
> example:
>
> Week 1:
>   Wednesday-Friday: 3 days Summit.
> * Primarily an event for marketing, sales, CTOs, architects,
>   operators, journalists, ...
> * Contributors can decide whether they want to attend this.
>   Saturday-Sunday:
> * Social activities: contributors meet-up, hang outs ...
>
> Week 2:
>   Monday-Wednesday: 3 days Design Summit
> * Primarily an event for developers.
> * Operators can hold meetups during these days, or join project
>   design summits.
>
> If you need to attend both events, you don't need two trips. Scheduling
> both events by the end of a release cycle can help gather more
> meaningful feedbacks, experiences or lessons from previous releases and
> ensure a better plan for the coming release.
>
> If you want to attend just the main Summit or only the Design Summit,
> you can plan your trip accordingly.
>
> Thoughts?
>
>  - Qiming

>From my perspective this idea is more appealing. If someone doesn't want
to join main conference he don't need to and we avoid distractions
coming from both events intersecting.

What isn't solved here is placing developer conference in "cheaper"
cities, but I have a feeling that even if hotels cost less, it will be
harder to travel to less popular locations.

Another problem is the timing of the main conference, which in this
proposition won't happen in the middle of the cycle. I wonder however if
it really makes a difference here and if companies want to present
products based on latest release in 2.5 month timeline.

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

Re: [openstack-dev] [all] tenant vs. project

[Kairat Kushaev]

>
> os1:~> set | grep ^OS_
> OS_AUTH_URL=http://10.42.0.50:5000/v2.0
> OS_CACERT=
> OS_IDENTITY_API_VERSION=2.0
> OS_NO_CACHE=1
> OS_PASSWORD=pass
> OS_PROJECT_NAME=demo
> OS_REGION_NAME=RegionOne
> OS_USERNAME=demo
> OS_VOLUME_API_VERSION=2
>
> os1:~> cinder list
> ERROR: You must provide a tenant_name, tenant_id, project_id or
> project_name (with project_domain_name or project_domain_id) via
> --os-tenant-name (env[OS_TENANT_NAME]),  --os-tenant-id
> (env[OS_TENANT_ID]),  --os-project-id (env[OS_PROJECT_ID])
> --os-project-name (env[OS_PROJECT_NAME]),  --os-project-domain-id
> (env[OS_PROJECT_DOMAIN_ID])  --os-project-domain-name
> (env[OS_PROJECT_DOMAIN_NAME])
>
> os1:~> glance image-list
> You must provide a project_id or project_name (with project_domain_name
> or project_domain_id) via   --os-project-id (env[OS_PROJECT_ID])
> --os-project-name (env[OS_PROJECT_NAME]),  --os-project-domain-id
> (env[OS_PROJECT_DOMAIN_ID])  --os-project-domain-name
> (env[OS_PROJECT_DOMAIN_NAME])


It looks like project names are unique within domain.
So clients require project domain to be specified for v3.
Otherwise they raise an error.

Best regards,
Kairat Kushaev


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

Re: [openstack-dev] [Fuel][Fuel-Library] Nominating Matthew Mosesohn for Fuel Library Core

[Vitaly Kramskikh]

+1

2016-02-25 16:41 GMT+07:00 Sergey Kulanov :

> +1
>
> 2016-02-25 11:37 GMT+02:00 Alexander Kislitsky :
>
>> +1
>>
>> On Thu, Feb 25, 2016 at 12:32 PM, Bulat Gaifullin <
>> bgaiful...@mirantis.com> wrote:
>>
>>> +1
>>>
>>> Regards,
>>> Bulat Gaifullin
>>> Mirantis Inc.
>>>
>>>
>>>
>>> On 24 Feb 2016, at 16:02, Aleksandr Didenko 
>>> wrote:
>>>
>>> +1
>>>
>>> On Wed, Feb 24, 2016 at 1:50 PM, Vladimir Kuklin 
>>> wrote:
>>>
 Fellow Fuelers

 I would like to kindly ask you to consider voting for Matthew Mosesohn
 as a Fuel Library Core
 reviewer.

 Matthew has been working with Fuel since its inception, worked on
 countless amount of features, such as :

 Master Node Upgrades and Backup
 Improvements to Fuel Infra
 Mitaka, Kilo and Juno Support
 Detachable Services Plugins
 RHOS Support in Fuel
 UCA Support
 Refactoring of Haproxy and Firewall pieces

 He has also been known as our Fuel Master node and Docker guru and has
 been continuously working on bugfixing where he scores as a bug squashing
 monster with more than 150 bugfixes to all the parts of Fuel Library (#1
 throughout FL history).

 As you can see, there is not a piece of Fuel Library that he has not
 yet gained experience with.

 And this can easily be fetched with simple statistics of Matt's
 contribution. He is the topmost contributor to all Fuel projects among all
 Fuel Library folks and is the 3rd contributor of Fuel Library.
 He also reviews a lot and has a fair amount of -1's (he is not as cruel
 as me, though :-))

 Having that said, I would like to open the vote to promote Matt to
 OpenStack Fuel Library core reviewers.

 --
 Yours Faithfully,
 Vladimir Kuklin,
 Fuel Library Tech Lead,
 Mirantis, Inc.
 +7 (495) 640-49-04
 +7 (926) 702-39-68
 Skype kuklinvv
 35bk3, Vorontsovskaya Str.
 Moscow, Russia,
 www.mirantis.com 
 www.mirantis.ru
 vkuk...@mirantis.com


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


>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.openstack.org
>>> ?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> --
> Sergey
> DevOps Engineer
> IRC: SergK
> Skype: Sergey_kul
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Vitaly Kramskikh,
Fuel UI Tech Lead,
Mirantis, Inc.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel][Fuel-Library] Nominating Matthew Mosesohn for Fuel Library Core

[Sergey Kulanov]

+1

2016-02-25 11:37 GMT+02:00 Alexander Kislitsky :

> +1
>
> On Thu, Feb 25, 2016 at 12:32 PM, Bulat Gaifullin  > wrote:
>
>> +1
>>
>> Regards,
>> Bulat Gaifullin
>> Mirantis Inc.
>>
>>
>>
>> On 24 Feb 2016, at 16:02, Aleksandr Didenko 
>> wrote:
>>
>> +1
>>
>> On Wed, Feb 24, 2016 at 1:50 PM, Vladimir Kuklin 
>> wrote:
>>
>>> Fellow Fuelers
>>>
>>> I would like to kindly ask you to consider voting for Matthew Mosesohn
>>> as a Fuel Library Core
>>> reviewer.
>>>
>>> Matthew has been working with Fuel since its inception, worked on
>>> countless amount of features, such as :
>>>
>>> Master Node Upgrades and Backup
>>> Improvements to Fuel Infra
>>> Mitaka, Kilo and Juno Support
>>> Detachable Services Plugins
>>> RHOS Support in Fuel
>>> UCA Support
>>> Refactoring of Haproxy and Firewall pieces
>>>
>>> He has also been known as our Fuel Master node and Docker guru and has
>>> been continuously working on bugfixing where he scores as a bug squashing
>>> monster with more than 150 bugfixes to all the parts of Fuel Library (#1
>>> throughout FL history).
>>>
>>> As you can see, there is not a piece of Fuel Library that he has not yet
>>> gained experience with.
>>>
>>> And this can easily be fetched with simple statistics of Matt's
>>> contribution. He is the topmost contributor to all Fuel projects among all
>>> Fuel Library folks and is the 3rd contributor of Fuel Library.
>>> He also reviews a lot and has a fair amount of -1's (he is not as cruel
>>> as me, though :-))
>>>
>>> Having that said, I would like to open the vote to promote Matt to
>>> OpenStack Fuel Library core reviewers.
>>>
>>> --
>>> Yours Faithfully,
>>> Vladimir Kuklin,
>>> Fuel Library Tech Lead,
>>> Mirantis, Inc.
>>> +7 (495) 640-49-04
>>> +7 (926) 702-39-68
>>> Skype kuklinvv
>>> 35bk3, Vorontsovskaya Str.
>>> Moscow, Russia,
>>> www.mirantis.com 
>>> www.mirantis.ru
>>> vkuk...@mirantis.com
>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> 
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org
>> ?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


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

Re: [openstack-dev] [Fuel][Fuel-Library] Nominating Matthew Mosesohn for Fuel Library Core

[Alexander Kislitsky]

+1

On Thu, Feb 25, 2016 at 12:32 PM, Bulat Gaifullin 
wrote:

> +1
>
> Regards,
> Bulat Gaifullin
> Mirantis Inc.
>
>
>
> On 24 Feb 2016, at 16:02, Aleksandr Didenko  wrote:
>
> +1
>
> On Wed, Feb 24, 2016 at 1:50 PM, Vladimir Kuklin 
> wrote:
>
>> Fellow Fuelers
>>
>> I would like to kindly ask you to consider voting for Matthew Mosesohn as
>> a Fuel Library Core
>> reviewer.
>>
>> Matthew has been working with Fuel since its inception, worked on
>> countless amount of features, such as :
>>
>> Master Node Upgrades and Backup
>> Improvements to Fuel Infra
>> Mitaka, Kilo and Juno Support
>> Detachable Services Plugins
>> RHOS Support in Fuel
>> UCA Support
>> Refactoring of Haproxy and Firewall pieces
>>
>> He has also been known as our Fuel Master node and Docker guru and has
>> been continuously working on bugfixing where he scores as a bug squashing
>> monster with more than 150 bugfixes to all the parts of Fuel Library (#1
>> throughout FL history).
>>
>> As you can see, there is not a piece of Fuel Library that he has not yet
>> gained experience with.
>>
>> And this can easily be fetched with simple statistics of Matt's
>> contribution. He is the topmost contributor to all Fuel projects among all
>> Fuel Library folks and is the 3rd contributor of Fuel Library.
>> He also reviews a lot and has a fair amount of -1's (he is not as cruel
>> as me, though :-))
>>
>> Having that said, I would like to open the vote to promote Matt to
>> OpenStack Fuel Library core reviewers.
>>
>> --
>> Yours Faithfully,
>> Vladimir Kuklin,
>> Fuel Library Tech Lead,
>> Mirantis, Inc.
>> +7 (495) 640-49-04
>> +7 (926) 702-39-68
>> Skype kuklinvv
>> 35bk3, Vorontsovskaya Str.
>> Moscow, Russia,
>> www.mirantis.com 
>> www.mirantis.ru
>> vkuk...@mirantis.com
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> 
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel][Fuel-Library] Nominating Matthew Mosesohn for Fuel Library Core

[Bulat Gaifullin]

+1

Regards,
Bulat Gaifullin
Mirantis Inc.



> On 24 Feb 2016, at 16:02, Aleksandr Didenko  wrote:
> 
> +1
> 
> On Wed, Feb 24, 2016 at 1:50 PM, Vladimir Kuklin  > wrote:
> Fellow Fuelers 
> 
> I would like to kindly ask you to consider voting for Matthew Mosesohn as a 
> Fuel Library Core
> reviewer.
> 
> Matthew has been working with Fuel since its inception, worked on countless 
> amount of features, such as :
> 
> Master Node Upgrades and Backup
> Improvements to Fuel Infra
> Mitaka, Kilo and Juno Support
> Detachable Services Plugins
> RHOS Support in Fuel
> UCA Support
> Refactoring of Haproxy and Firewall pieces
> 
> He has also been known as our Fuel Master node and Docker guru and has been 
> continuously working on bugfixing where he scores as a bug squashing monster 
> with more than 150 bugfixes to all the parts of Fuel Library (#1 throughout 
> FL history).
> 
> As you can see, there is not a piece of Fuel Library that he has not yet 
> gained experience with.
> 
> And this can easily be fetched with simple statistics of Matt's contribution. 
> He is the topmost contributor to all Fuel projects among all Fuel Library 
> folks and is the 3rd contributor of Fuel Library.
> He also reviews a lot and has a fair amount of -1's (he is not as cruel as 
> me, though :-))
> 
> Having that said, I would like to open the vote to promote Matt to OpenStack 
> Fuel Library core reviewers.
> 
> -- 
> Yours Faithfully,
> Vladimir Kuklin,
> Fuel Library Tech Lead,
> Mirantis, Inc.
> +7 (495) 640-49-04 
> +7 (926) 702-39-68 
> Skype kuklinvv
> 35bk3, Vorontsovskaya Str.
> Moscow, Russia,
> www.mirantis.com 
> www.mirantis.ru 
> vkuk...@mirantis.com 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe 
> 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
> 
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [nova] python-novaclient region setting

[Xav Paice]

On 24 February 2016 at 22:18, Andrey Kurilin  wrote:

> Hi!
>
> >didn't work for me in this particular case because of a bug in novaclient
>
> Can you tell more about bug in novaclient or share a bug report?
>
>
Sure - https://bugs.launchpad.net/python-novaclient/+bug/1494116


> On Wed, Feb 24, 2016 at 8:42 AM, Xav Paice  wrote:
>
>> fwiw, the second part of Monty's message is in the docs, sans region - it
>> would be a fairly swift change to add that and I'll probably submit a
>> gerrit for it soon.
>>
>> Regards os_client_config,
>> http://docs.openstack.org/developer/os-client-config/ is great.
>> Unfortunately it didn't work for me in this particular case because of a
>> bug in novaclient, but that's beside the point - os_client_config is doing
>> exactly the right thing and I'm really happy with that approach in most
>> cases (and am changing some of our tooling to reflect that).
>>
>> On 24 February 2016 at 05:05, Matt Riedemann 
>> wrote:
>>
>>>
>>>
>>> On 2/22/2016 8:02 AM, Monty Taylor wrote:
>>>
 On 02/21/2016 11:40 PM, Andrey Kurilin wrote:

> Hi!
> `novaclient.client.Client` entry-point supports almost the same
> arguments as `novaclient.v2.client.Client`. The difference is only in
> api_version, so you can set up region via `novaclient.client.Client` in
> the same way as `novaclient.v2.client.Client`.
>

 The easiest way to get a properly constructed nova Client is with
 os-client-config:

 import os_client_config

 OS_PROJECT_NAME="d8af8a8f-a573-48e6-898a-af333b970a2d"
 OS_USERNAME="0b8c435b-cc4d-4e05-8a47-a2ada0539af1"
 OS_PASSWORD="REDACTED"
 OS_AUTH_URL="http://auth.vexxhost.net;
 OS_REGION_NAME="ca-ymq-1"

 client = os_client_config.make_client(
  'compute',
  auth_url=OS_AUTH_URL, username=OS_USERNAME,
  password=OS_PASSWORD, project_name=OS_PROJECT_NAME,
  region_name=OS_REGION_NAME)

 The upside is that the constructor interface is the same for all of the
 rest of the client libs too (just change the first argument) - and it
 will also read in OS_ env vars or named clouds from clouds.yaml if you
 have them set.

 (The 'simplest' way is to put your auth and region information into a
 clouds.yaml file like this:


 http://docs.openstack.org/developer/os-client-config/#site-specific-file-locations


 Such as:

 # ~/.config/openstack/clouds.yaml
 clouds:
vexxhost:
   profile: vexxhost
   auth:
 project_name: d8af8a8f-a573-48e6-898a-af333b970a2d
 username: 0b8c435b-cc4d-4e05-8a47-a2ada0539af1
 password: REDACTED
   region_name: ca-ymq-1


 And do:

 client = os_client_config.make_client('compute', cloud='vexxhost')


 If you don't want to do that for some reason but you'd like to construct
 a novaclient Client object by hand:


 from keystoneauth1 import loading
 from keystoneauth1 import session as ksa_session
 from novaclient import client as nova_client

 OS_PROJECT_NAME="d8af8a8f-a573-48e6-898a-af333b970a2d"
 OS_USERNAME="0b8c435b-cc4d-4e05-8a47-a2ada0539af1"
 OS_PASSWORD="REDACTED"
 OS_AUTH_URL="http://auth.vexxhost.net;
 OS_REGION_NAME="ca-ymq-1"

 # Get the auth loader for the password auth plugin
 loader = loading.get_plugin_loader('password')
 # Construct the auth plugin
 auth_plugin = loader.load_from_options(
  auth_url=OS_AUTH_URL, username=OS_USERNAME, password=OS_PASSWORD,
  project_name=OS_PROJECT_NAME)

 # Construct a keystone session
 # Other arguments that are potentially useful here are:
 #  verify - bool, whether or not to verify SSL connection validity
 #  cert - SSL cert information
 #  timout - time in seconds to use for connection level TCP timeouts
 session = ksa_session.Session(auth_plugin)

 # Now make the client
 # Other arguments you may be interested in:
 #  service_name - if you need to specify a service name for finding the
 # right service in the catalog
 #  service_type - if the cloud in question has given a different
 # service type (should be 'compute' for nova - but
 # novaclient sets it, so it's safe to omit in most cases
 #  endpoint_override - if you want to tell it to use a different URL
 #  than what the keystone catalog returns
 #  endpoint_type - if you need to specify admin or internal
 #  endpoints rather than the default 'public'
 #  Note that in glance and barbican, this key is called
 #  'interface'
 client = nova_client.Client(
  version='2.0', # or set the specific microversion you want
  

Re: [openstack-dev] [i18n][stackalytics] Translations metrics

[Akihiro Motoki]

Hi Shu,

I am confused with the sentence "My Zanata ID "shu" is used by "Seihu"
in Launchpad".
I think Zanata ID is linked with OpenStack Foundation profile
and is not linked directly with launchpad ID.
Could you clarify the situation?



2016-02-25 18:08 GMT+09:00 Shuu Mutou :
> Hi,
>
> Stackalytics shows my translations as other ones.
> Does the difference between Zanata ID and Launchpad ID cause the problem?
>
> * My Zanata ID "shu" is used by "Seihu" in Launchpad.
> * My Launchpad ID is "shu-mutou".
>
> If so, I hope that email address will be used for matching user.
>
> Shu Muto
> NEC Solution Innovators, Ltd.
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[openstack-dev] [i18n][stackalytics] Translations metrics

[Shuu Mutou]

Hi, 

Stackalytics shows my translations as other ones.
Does the difference between Zanata ID and Launchpad ID cause the problem?

* My Zanata ID "shu" is used by "Seihu" in Launchpad.
* My Launchpad ID is "shu-mutou".

If so, I hope that email address will be used for matching user.

Shu Muto
NEC Solution Innovators, Ltd.


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

Re: [openstack-dev] [all] A proposal to separate the design summit

[Jan Klare]

Hi Qiming,

this sounds like a much more pragmatic and practical idea to me and it think 
just splitting the events into two not parallel parts, but keeping them in the 
same “week” would also solve most of the problems mentioned in this thread, but 
allow people to attend both summits without travelling twice as you mentioned. 
The main issue with this idea might be, that this will not reduce the costs of 
the Desing summit, but in my opinion neither will the completely splittet 
solution. Thanks for this suggestion.

Cheers,
Jan

> On 25 Feb 2016, at 09:13, Qiming Teng  wrote:
> 
> Hi, All,
> 
> After reading through all the +1's and -1's, we realized how difficult
> it is to come up with a proposal that makes everyone happy. When we are
> discussing this proposal with some other contributors, we came up with a
> proposal which is a little bit different. This idea could be very
> impractical, very naive, given that we don't know much about the huge
> efforts behind the scheduling, planning, coordination ... etc etc. So,
> please treat this as a random thought.
> 
> Maybe we can still have the Summit and the Design Summit colocated, but
> we can avoid the overlap that has been the source of many troubles. The
> idea is to have both events scheduled by the end of a release cycle. For
> example:
> 
> Week 1:
>  Wednesday-Friday: 3 days Summit.
>* Primarily an event for marketing, sales, CTOs, architects,
>  operators, journalists, ...
>* Contributors can decide whether they want to attend this.
>  Saturday-Sunday:
>* Social activities: contributors meet-up, hang outs ...
> 
> Week 2:
>  Monday-Wednesday: 3 days Design Summit
>* Primarily an event for developers.
>* Operators can hold meetups during these days, or join project
>  design summits.
> 
> If you need to attend both events, you don't need two trips. Scheduling
> both events by the end of a release cycle can help gather more
> meaningful feedbacks, experiences or lessons from previous releases and
> ensure a better plan for the coming release.
> 
> If you want to attend just the main Summit or only the Design Summit,
> you can plan your trip accordingly.
> 
> Thoughts?
> 
> - Qiming
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

Re: [openstack-dev] [Horizon][Neutron][QoS]horizon angular network QoS panel

[Miguel Angel Ajo Pelayo]

Hi Masco!,

   Thanks a lot for working on this, I’m not following the [Horizon] tag and I 
missed
this. I’ve added the Neutron and QoS tags.

   I will give it a try as soon as I can. 

   Keep up the good work!,

Cheers,
Miguel Ángel.
> On 10 Feb 2016, at 13:04, masco  wrote:
> 
> 
> Hello All,
> 
> As most of you people knows the 'QoS' feature is added in neutron during 
> liberty release.
> It will be nice to have this feature in horizon, so I have added a 'network 
> qos' panel for the same in angularJS.
> It will be very helpful if you people reviewing this patches and helping to 
> land this feature in horizon.
> 
> gerrit links:
> 
> https://review.openstack.org/#/c/247997/ 
> 
> https://review.openstack.org/#/c/259022/11 
> 
> https://review.openstack.org/#/c/272928/4 
> 
> https://review.openstack.org/#/c/277743/3 
> 
> 
> 
> To set test env:
> here is some steps how to enable a QoS in neutron.
> If you want to test it will help you.
> 
> 
>   To enable the QoS in devstack please add below two
>   lines in the local.conf enable_plugin neutron
>   git://git.openstack.org/openstack/neutron
>   enable_service q-qos and rebuild your stack
>   (./stack.sh)
> 
> Thanks,
> Masco.
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[openstack-dev] [Nova][Migration][RFC]: What are in progress migration?

[少合冯]

There's one current nova code define it as follow:
https://github.com/openstack/nova/blob/master/nova/db/sqlalchemy/api.py#L4535-L4546

that means: beside [ 'accepted', 'confirmed', 'reverted', 'error', 'failed'
], other status are all in progress.
Note: here  finished is in progress.

John Garbutt has raised the same question in the code review.
https://review.openstack.org/#/c/258771/29/nova/db/sqlalchemy/api.py


There are two problems want to discuss.

1.  should "finished" be in progress?
from literal meaning, it should not.
So we should add it to  non-in-progress list.

And should not return the "finished" migration when users use
migration-index to fetch it.

But is this reasonable?
A user do a migration, he get nothing information about the  migrations by
migration-index after it is finished.


2. I wonder what's the difference among "done", "completed" and "finished" ?
I use  this command:
$ git grep "migration.*status"
I have gotten all migrations status beside non-in-progress as follow.
 done, post-migrating, preparing, queued, completed, accepted,  finished,
running.

The current migration.status define is not good for read so I file a bug. (
https://bugs.launchpad.net/nova/+bug/1549558)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] A proposal to separate the design summit

[Qiming Teng]

Hi, All,

After reading through all the +1's and -1's, we realized how difficult
it is to come up with a proposal that makes everyone happy. When we are
discussing this proposal with some other contributors, we came up with a
proposal which is a little bit different. This idea could be very
impractical, very naive, given that we don't know much about the huge
efforts behind the scheduling, planning, coordination ... etc etc. So,
please treat this as a random thought.

Maybe we can still have the Summit and the Design Summit colocated, but
we can avoid the overlap that has been the source of many troubles. The
idea is to have both events scheduled by the end of a release cycle. For
example:

Week 1:
  Wednesday-Friday: 3 days Summit.
* Primarily an event for marketing, sales, CTOs, architects,
  operators, journalists, ...
* Contributors can decide whether they want to attend this.
  Saturday-Sunday:
* Social activities: contributors meet-up, hang outs ...

Week 2:
  Monday-Wednesday: 3 days Design Summit
* Primarily an event for developers.
* Operators can hold meetups during these days, or join project
  design summits.

If you need to attend both events, you don't need two trips. Scheduling
both events by the end of a release cycle can help gather more
meaningful feedbacks, experiences or lessons from previous releases and
ensure a better plan for the coming release.

If you want to attend just the main Summit or only the Design Summit,
you can plan your trip accordingly.

Thoughts?

 - Qiming


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

[openstack-dev] [infra][neutron] Can ovs repository added to \$PROJECTS variable in the job definition ?

[Chen Li]

Hi guys,


For a devstack installation, if we set "RECLONE=True" in local.conf, all
code should be updated to the newest, right ?

Recently, when I run devstack with "ovs", I found that the "ovs" code will
not be re-cloned with "RECLONE=True".
So, I submitted a patch try to fix it:
https://review.openstack.org/#/c/282233/

As you can see in the comments, now we have a question:
Can we add ovs to \$PROJECTS variable in the job definition ?

If we can, how to do that ?
If we cannot, why not ?

Looking forward to your reply.

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