date:20161013

On 10/13/2016 7:47 PM, Emilien Macchi wrote:

Greetings OpenStack,

== Background

Since the beginning of OpenStack (or almost), devstack has been used
as a common tool to deploy OpenStack in CI environment. Most of
OpenStack projects (if not all) that are written in Python use it to
deploy the different components.
While devstack became popular and the reference in term of deployment
tool for continuous integration, devstack doesn't deploy OpenStack in
production (versus some tools like Kolla, Fuel, TripleO, Juju, etc).
It means things might (and did) break when deploying OpenStack outside
devstack, for different reasons. Some examples:

* until recently, SSL was not tested, and I believe some projects
still don't test with SSL enabled.
* IPv6 is not tested everywhere.
* Production scenarios, with HA (HAproxy or/and Pacemaker) are not tested.

My point here, is that devstack has been doing very good job for its
simplicity (written in bash) and its large adoption by projects to
make CI, though we might consider adding more coverage to make sure it
works outside devstack.
As an example, Puppet OpenStack modules CI is using a devstack-like
job (with 3 scenarios), called puppet-openstack-integration [1] but we
also run TripleO and Fuel CI jobs, to increase coverage and give a
better feedback on testing.

== Proposal

This is not about removing devstack! The idea is to add more coverage
in an iterative way, with some other tools.
We started some months ago by running TripleO CI jobs in Ironic and
Heat gates (experimental pipeline) because TripleO is high consumer of
Ironic and Heat.
Also, we recently added our TripleO multinode job in Nova experimental
pipeline (doc here [2]).
Now, we are moving forward with python-openstackclient and osc-lib.

I started to draft a document about how we could increase coverage in
different projects:
https://docs.google.com/spreadsheets/d/1bLg-uEGrQXyRZ-FuR6pf1WT4XN0-6MrlfqEShI7xMxg/edit#gid=0

(feel free to add your project and give your opinion directly in the
spreadsheet).

The intention here is to discuss with teams interested by such CI
coverage. We don't want to slow down or break your gate (example with
TripleO, our jobs are non-voting outside TripleO and take ~45 min);
but reduce the feedback loop between developers and deployment tools
used in production.
We don't expect developers to investigate why new CI jobs would fail
(ex: a Nova developer to look at TripleO CI job), it would be unfair.
Just some horizontal communication would be enough, IRC or email, to
inform that a patch might break a CI job outside devstack.
I also want to mention that the proposal is not only about TripleO. I
used this tool in my examples because I'm working on it but obviously
this proposal should be open to Big Tent projects that also deploy
OpenStack.

Please give any feedback, and let's make OpenStack testing stronger!
Thanks for reading so far,

[1] https://github.com/openstack/puppet-openstack-integration
[2] https://review.openstack.org/#/c/381838/

I don't really have a problem with wanting to run non-devstack
deployment tool jobs against project changes on-demand (experimental
queue job). That's why I approved the change to add that TripleO job to
nova's experimental queue.

The experimental queue is only on-demand though, so reviewers have to be
conscious of running it and even then people don't think to check the
results, or a failure might not be obvious as to what caused it (my
patch, or is this job always broken and is thus in the experimental
queue, like the nova-lxc job?).

For better or worse devstack is at least universally used and it's THE
default thing we point newcomers to when getting started if they want to
quickly and easily get a development environment with a running
openstack on a single-node up and running to kick the tires. I can't say
the same for the plethora of other deployment projects out there like
kolla, ansible, salt, puppet, chef, tripleo/packstack/rdo, fuel, etc,
etc. I think that's what's really caused the lack of universal adoption
of anything besides devstack in our CI environment. And love it or hate
it, I think anyone that's been around for awhile and tries to debug gate
failures is at least used to hacking on devstack and knows how it works
to a certain extent.

Anyway, as I said, I've got no problem with getting some additional
optional non-voting coverage in other projects besides devstack to at
least try and prevent breaking changes. I worry about trying to move
various deployment jobs into the check queue for multiple projects
though, as I think that would put a pretty serious strain on resources
for non-voting jobs, which we'd like to avoid I think.

My two cents.

Thanks,

Matt Riedemann

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

[openstack-dev] 答复: Re: [vitrage][aodh] about aodh notifier to create a event alarm

2016-10-13 Thread dong . wenjuan

Hi Ifat，

Got it. Thanks for your reponse.
Is there any record about the discussion between Aodh and Vitrage?

BR,
dwj







"Afek, Ifat (Nokia - IL)"  
2016-10-13 17:31
请答复 给
"OpenStack Development Mailing List \(not for usage questions\)" 



收件人
"OpenStack Development Mailing List (not for usage questions)" 

抄送

主题
Re: [openstack-dev] [vitrage][aodh] about aodh notifier to create a event 
alarm






Hi dwj,

Thanks for bringing this up.

Aodh notifier plugin inside Vitrage is defined as a POC, and is disabled 
by default. We are aware that this integration is not working well, and 
its purpose was to demonstrate how it could work and start a discussion 
about other possible implementations. I know that in Austin there were 
discussions between Aodh and Vitrage teams, and a general agreement that 
Vitrage would suggest a design for Aodh custom alarm. Such an alarm could 
then be used by Vitrage instead of the event-alarm in a more natural way. 

Unfortunately, due to time limitations, we did not get to write the custom 
alarm blueprint in Aodh. It is still defined as a high priority in Vitrage 
roadmap, and I hope it will happen in Ocata. If you have some free time 
you are more than welcome to give a hand :-)

Best Regards,
Ifat.


From: "dong.wenj...@zte.com.cn"
Date: Thursday, 13 October 2016 at 04:20

Hi vitrages, 

In aodh notifier plugin, we receive a ACTIVATE_DEDUCED_ALARM_EVENT and 
then create a aodh event alarm.
The event alarm with a `event_rule`, it should be include `event_type` and 
`query` which Aodh used to evaluator
a alarm when it receives a specify event to filter with the query to fire 
a alarm. see [1]

But we create a event alarm only with `query` in `event_rule`.
The deduced alarm create with the `alarm` state so Aodh will skip to 
evaluator the fired alarm.
The `event_rule` seems no necessary in the request body, am I right?
Let me know if i miss something. :)

[1]
https://github.com/openstack/aodh/blob/master/doc/source/event-alarm.rst


BR, 
dwj 

董文娟   Wenjuan Dong 
控制器四部 / 无线产品   Controller Dept Ⅳ. / Wireless Product Operation
  


上海市浦东新区碧波路889号中兴通讯D3
D3, ZTE, No. 889, Bibo Rd.
T: +86 021 85922M: +86 13661996389
E: dong.wenj...@zte.com.cn
www.ztedevice.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

[附件 "ATT1.gif" 被 董文娟00101742/user/zte_ltd 删除][附件 
"ATT2.gif" 被 董文娟00101742/user/zte_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] [tripleo] TripleO RC3

2016-10-13 Thread Emilien Macchi

Team,

We'll propose TripleO Newton RC3 on Friday 11am (eastern time).

List of actions:
- Keep reviewing https://review.openstack.org/#/q/topic:tripleo/rc3+status:open
- Keep backporting bugfixes into stable/newton if required.
- Use ocata-1 milestone for new bugs, with newton-backport-potential
tag if backport is relevant.

After the release, I'll move RC3 bugs to Ocata-1 with the
newton-backport-potential tag.
We still have 5 days until the hard freeze, so still able to push for
a new tag next week, that would be our final Newton release.

I also would like to thank everyone, we did an outstanding job over
the last weeks to respect this schedule. Big kudos to the team here
:-)

On Fri, Oct 7, 2016 at 3:45 PM, Emilien Macchi  wrote:
> Please read Doug's email:
> http://lists.openstack.org/pipermail/openstack-dev/2016-October/105266.html
>
> I think it makes sense for us to relax a bit on the RC3 and continue
> to work on blockers we wanted fixed in stable/newton.
> We already did amazing work to solve most of them, my hope is that we
> can release during the next 2 weeks.
>
> AFIK people are still testing upgrades from Mitaka, I"m pretty sure
> we'll have more patches to backport.
>
> Actions needed:
> - Keep RC3 bugs in https://launchpad.net/tripleo/+milestone/newton-rc3
> - they remain our current highest priority to finish.
> - Bugs moved from Newton to Ocata-1 stay at this milestone bug can
> have newton-backport-potential launchpad tag.
> - New bugs are ocata-1 and can have newton-backport-potential if
> critical bugfix or upgrade thing.
> - Once the bug merged in master, please submit the backport into 
> stable/newton.
>
> People can still continue to use:
> https://review.openstack.org/#/q/topic:tripleo/rc3+status:open
> To make reviews easier.
>
> Let me know if any question or feedback,
>
> Thanks and happy week-end!
>
> On Thu, Oct 6, 2016 at 9:08 AM, Emilien Macchi  wrote:
>> Last reminder before RC3 release that will be proposed on Friday
>> morning (eastern time):
>>
>> - use tripleo/rc3 Gerrit topic
>> - please backport rc3 bugfixes merged in master into stable/newton
>> - please let me know any blocker
>>
>> Thanks,
>>
>> On Fri, Sep 30, 2016 at 10:47 AM, Emilien Macchi  wrote:
>>> We have been granted to release a last release candidate (RC3) by next
>>> Friday (October 7th).
>>>
>>> Please use this milestone for the bugs targeted for Newton.
>>> https://launchpad.net/tripleo/+milestone/newton-rc3
>>>
>>> Some reminders:
>>> - assign the bug if you're working on it.
>>> - update it when you can, we need to know bug status before final RC.
>>> - use tripleo/rc3 Gerrit topic to help in reviews:
>>> https://review.openstack.org/#/q/topic:tripleo/rc3+status:open
>>> - don't forget to backport patches from master to stable/newton branch
>>> otherwise they'll not be part of the release.
>>>
>>> By next Friday, we'll proceed to final RC, any question or feedback is
>>> welcome, please let me or shardy know any critical blockers we might
>>> have missed.
>>>
>>> Thanks,
>>> --
>>> Emilien Macchi
>>
>>
>>
>> --
>> Emilien Macchi
>
>
>
> --
> Emilien Macchi



-- 
Emilien Macchi

__
OpenStack Development Mailing 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] [openstack-ansible][release] OpenStack-Ansible Newton RC3 available

2016-10-13 Thread Davanum Srinivas

Hello everyone,

A new release candidate for OpenStack Ansible for the end of the
Newton cycle is available!

You can find the source code tarballs at:
https://releases.openstack.org/newton/index.html#newton-openstack-ansible

Alternatively, you can directly test the stable/newton release branch at:
http://git.openstack.org/cgit/openstack/openstack-ansible/log/?h=stable/newton

(Note: there are many repositories named openstack/openstack-ansible*)

If you find an issue that could be considered release-critical, please
file it at:
https://bugs.launchpad.net/openstack-ansible/+filebug

and tag it *newton-rc-potential* to bring it to the OpenStackAnsible
release crew's attention.

Thanks,
Dims (On behalf of the Release team)


-- 
Davanum Srinivas :: https://twitter.com/dims

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

Re: [openstack-dev] [QA] The end-user test suite for OpenStack clusters

2016-10-13 Thread Ghanshyam Mann

I like os-faults library which can provide the abstraction over different 
destructive actions like reboot/poweroff node etc.

But not much clear about Stepler that what all tests it will contain. Tempest 
do have scenario tests which can hit the production env with significant way of 
testing scenario.
It can cover the end user scenario also which involves the interaction of 
public OpenStack APIs and always in enhancement state by adding more and more 
scenario tests.

Few query over Stepler as separate project:

1.   Is Stepler will cover only tests which hits the node level 
action(reboot, HA etc)?

2.   This should not mix the scenario tests which are in Tempest scope 
because that can make confusion for developers (where to add scenario tests) as 
well as for tester(from where to run what scenario tests).

3.   How we make sure those tests run fine or at least run while adding.

a.   I think devstack enhancement for multi-node etc can do this as 
mentioned by you also.

b.  If so then why not adding those tests in Tempest only using os-faults 
lib ?

Overall I feel os-faults  as lib is really nice idea but tests scope can go in 
Tempest under HW_scenario  (or something else) till it does not break basic 
principle of Tempest.

Thanks
gmann

From: Timur Nurlygayanov [mailto:tnurlygaya...@mirantis.com]
Sent: 06 October 2016 20:09
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [QA] The end-user test suite for OpenStack clusters

Ken, it is a good idea!

The plan is to develop os-faults as a library which will be able
to manage cluster nodes and OpenStack services on these nodes.
It is a good idea to add some Tempest tests which will use
os-faults library as well for some API tests.

The Stepler framework [1] will use os-faults to perform all destructive
actions in the clouds (the reboot of nodes, restart of OpenStack services,
enable/disable network interfaces or some firewall rules and etc).

We need to get +1 from you in [1] to create the repository with
advanced end-user scenario tests.

Thank you!

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

On Tue, Oct 4, 2016 at 8:53 PM, Yaroslav Lobankov 
> wrote:
Hi Ken,

OS-Faults doesn't have any scenarios in the tree yet (the project is two months 
old), but you can find some examples of the use in the os-faults/examples 
directory.

Regards,
Yaroslav Lobankov.

On Tue, Oct 4, 2016 at 8:02 PM, Ken'ichi Ohmichi 
> wrote:
Hi Timur,

Thanks for your explanation.

2016-09-29 6:22 GMT-07:00 Timur Nurlygayanov 
>:
>
>> I am guessing the above "restart nodes" is for verifying each
>> OpenStack service restarts successfully, right?
>
> Yes, this is right. And we also will check that HA logic for these
> services works correctly (for example, rescheduling of L3 Neutron
> agents for networks).
>
>> But these service scripts are provided by distributors, and Devstack
>> itself doesn't contain service scripts IIUC.
>> So I'd like to know how to verify it on Devstack clouds.
>
> Yes, DevStack doesn't support many scenarios which are actual
> and should be supported on the production clouds.
> It will be not possible to run all advanced test scenarios for DevStack
> clouds,
> just because DevStack can't deploy OpenStack cloud with 3 controllers
> now (so, probably it will be possible in the future).
>
> Of course, some advanced scenarios will support DevStack clouds,
> for example, some test scenarios which are based on customer-found
> issues from the real production clouds, like upload of the large images
> (100+ Gb)
> to Glance with Swift backend. Such cases are important for verification of
> pre-production environments, but not very important for CI gate jobs.
>
> It is also important to note that in these advanced cases we are targeting
> to check not only the logic of Python code, but also the correct
> configuration
> of all OpenStack components on some pre-production OpenStack clusters.
I guessed some part of os-faults can be moved to Tempest if os-faults
contains API tests for enabling/disabling OpenStack services.
Then, os-faults would be able to concentrate on more destructive tests
like rebooting physical nodes, etc.
However, I could not find any actual scenarios on current os-faults
(https://github.com/openstack/os-faults).
That seems to just contain some abstraction layers and unit tests. Can
we see actual test scenarios of os-faults ?
Maybe I missed something.

Thanks
Ken Ohmichi

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

[openstack-dev] [all] running non-devstack jobs in Python projects aka "it works outside devstack"

2016-10-13 Thread Emilien Macchi

Greetings OpenStack,

== Background

== Proposal

I started to draft a document about how we could increase coverage in
different projects:
https://docs.google.com/spreadsheets/d/1bLg-uEGrQXyRZ-FuR6pf1WT4XN0-6MrlfqEShI7xMxg/edit#gid=0

(feel free to add your project and give your opinion directly in the
spreadsheet).

Please give any feedback, and let's make OpenStack testing stronger!
Thanks for reading so far,

[1] https://github.com/openstack/puppet-openstack-integration
[2] https://review.openstack.org/#/c/381838/
--
Emilien Macchi

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

[openstack-dev] [new][keystone] keystoneauth1 2.14.0 release (ocata)

We are gleeful to announce the release of:

keystoneauth1 2.14.0: Authentication Library for OpenStack Identity

This release is part of the ocata release series.

The source is available from:

http://git.openstack.org/cgit/openstack/keystoneauth

Download the package from:

https://pypi.python.org/pypi/keystoneauth1

Please report issues through launchpad:

http://bugs.launchpad.net/keystoneauth

For more details, please see below.

2.14.0
^^

Allow adding client and application name and version to the session
and adapter that will generate a userful user agent string.


New Features


* You can specify a "app_name" and "app_version" when creating a
  session. This information will be encoded into the user agent.

* You can specify a "client_name" and "client_version" when creating
  an adapter. This will be handled by client libraries and incluced
  into the user agent.

* Libraries like shade that modify the way requests are made can add
  themselves to additional_user_agent and have their version reflected
  in the user agent string.


Deprecation Notes
*

* We suggest you fill the name and version for the application and
  client instead of specifying a custom "user_agent". This will then
  generate a standard user agent string.

Changes in keystoneauth1 2.13.0..2.14.0
---

7d26de1 be more explicit about connection errors
729e4cd Fix a typo in opts.py
e1bf1f0 Fix a typo in base.py
eb5571a Allow specifying client and service info to user_agent
6c93b0b Enable release notes translation
01b7c87 Implement caching for the generic plugins.


Diffstat (except docs and test files)
-

keystoneauth1/adapter.py   |  14 ++-
keystoneauth1/identity/base.py |   2 +-
keystoneauth1/identity/generic/base.py |  40 +++-
keystoneauth1/identity/generic/password.py |  26 +
keystoneauth1/identity/generic/token.py|   5 +
keystoneauth1/loading/opts.py  |   2 +-
keystoneauth1/session.py   |  77 +++
.../user-agent-generation-b069100508c06177.yaml|  17 
releasenotes/source/conf.py|   3 +
12 files changed, 330 insertions(+), 25 deletions(-)




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

[openstack-dev] [new][keystone] keystoneauth1 2.12.2 release (newton)

We are eager to announce the release of:

keystoneauth1 2.12.2: Authentication Library for OpenStack Identity

This release is part of the newton stable release series.

The source is available from:

http://git.openstack.org/cgit/openstack/keystoneauth

Download the package from:

https://pypi.python.org/pypi/keystoneauth1

Please report issues through launchpad:

http://bugs.launchpad.net/keystoneauth

For more details, please see below.

Changes in keystoneauth1 2.12.1..2.12.2
---

10ba290 be more explicit about connection errors
bb8f9de Update .gitreview for stable/newton


Diffstat (except docs and test files)
-

.gitreview   |  1 +
keystoneauth1/session.py | 10 --
2 files changed, 9 insertions(+), 2 deletions(-)




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

Re: [openstack-dev] [keystone] keystoneclient.client.v3.Client: extract identity endpoint

2016-10-13 Thread Jamie Lennox

On 13 October 2016 at 23:19, Johannes Grassler  wrote:

> Hello,
>
> I've got an existing keystoneclient.client.v3.Client object with an
> authenticated session. Now I'd like to get the identity URL this
> object uses for requesting things from Keystone. I want to use that
> URL in a trust's endpoint list in order to allow the user the client
> is authenticated as to talk to Keystone on the trustor's behalf.
>
> The client is authenticated as a service user and issues a GET to
>
>GET http://192.168.123.20/identity_admin/v3/OS-TRUST/trusts
>
> when the following code snippet is executed:
>
>   client.trusts.list()
>
> (`client` is my keystoneclient.client.v3.Client instance).
>
> Initially I thought I could use the auth_url from the client's
> session object, i.e.
>
>   client.session.auth.auth_url
>
> but that turned out to be a dead end because it's the internal
> endpoint:
>
>   http://192.168.123.20/identity/v3
>
> This will be useless for a trust's endpoint URL list if the
> trustee (my service user) ends up using
>
>   http://192.168.123.20/identity_admin/v3
>
> to talk to Keystone. I could look up the admin URL from the catalog
> like this...
>
>   keystone_service=client.services.list(type='identity')[0]
>   client.endpoints.list(service=keystone_service,
> interface='admin',
> region=client.region_name)
>
> ...but that feels rather dirty since it independently looks up the
> admin endpoint rather than plucking the identity endpoint from the
> keystone client instance. Is there a cleaner way to get that
> information directly from the keystoneclient.client.v3.Client
> instance?
>
> Cheers,
>
> Johannes
>

So this is one of those times where keystoneclient is really jno different
from the other clients and is just using the session you gave it to do the
right thing.

>From the session you can do:

session.get_endpoint(service_type='identity', interface='admin',
region='region')

to get the URL from the catalog.



> --
> Johannes Grassler, Cloud Developer
> SUSE Linux GmbH, HRB 21284 (AG Nürnberg)
> GF: Felix Imendörffer, Jane Smithard, Graham Norton
> Maxfeldstr. 5, 90409 Nürnberg, Germany
>
> __
> OpenStack Development Mailing 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] Propose to add FusionCompute driver to Nova


On 10/13/2016 3:02 AM, Zhenyu Zheng wrote:

Hi All,

We would like to propose FusionCompute driver to become an official Nova
driver.

FusionCompute is an computing virtualization software developed by
Huawei, which can provide tuned high-performance and high reliabilities
in VM instance provisioning, clustered resource pool management, and
intelligent HA/FT scheduling.

The concepts and technical details for FusionCompute could be found in:
https://wiki.openstack.org/wiki/FusionCompute

Huawei has been working on integrating FusionCompute and OpenStack since
Folsom release using Nova-FusionCompute driver. FusionCompute has been
successfully deployed as the hypervisor within Huawei's FusionShpere
Openstack Cloud Operation System solution in large number of commercial
private and public clouds running stable for several years, including:

 *Deutsche Telekom - Open Telekom Cloud*:
 http://www.cebit.de/en/news/open-telekom-cloud-is-live.xhtml
 https://www.telekom.com/media/company/291108
 http://www.huawei.com/en/news/2016/3/dian-xin-yun
 https://cloud.telekom.de/en/cloud-infrastructure/open-telekom-cloud/

 *Telefonica LatAm Public Cloud*:
 
https://www.business-solutions.telefonica.com/es/information-centre/news/telefonica-and-huawei-reach-a-global-agreement-to-promote-enterprise-migration-to-the-cloud/
 
http://www.lightreading.com/services/cloud-services/telefonica-and-huawei-debut-latam-public-cloud/d/d-id/726571
 
https://www.huawei.com/th-TH/news/2016/9/Telefonica-Brazil-Mexico-Chile-Cloud-Serve
 https://www.cloud.telefonica.com/en/

 *Huawei Enterprise Cloud:*
 http://www.hwclouds.com/en-us/

 *China Telecom Public Cloud:*
 http://www.ctyun.cn/
 http://www.ctyun.cn/product/oos_e

 *Other cases can be found in*:
 http://e.huawei.com/en/case-studies?product=Cloud%20Computing

As mentioned above, FusionCompute has been proved to be with high
reliability and large user base, thus we would like to propose
FusionCompute driver to Nova as an official Nova driver.

We have tried to propose this back in 2014, blueprint and discussions
can be found in:
https://blueprints.launchpad.net/nova/+spec/driver-for-huawei-fusioncompute
http://lists.openstack.org/pipermail/openstack-dev/2014-February/026075.html

We have set up the ThirdPartyCI:
https://wiki.openstack.org/wiki/ThirdPartySystems/Huawei_FusionCompute_CI
and adjusting it to Nova, it will be online very soon.

Thanks

Kevin Zheng


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



As mentioned elsewhere in this thread, I think at a minimum we're 
looking for:


1. Available source code in GitHub. I'd recommend going the route of the 
PowerVM driver in git.openstack.org and get it into the openstack 
namespace and start doing your development in the open.


2. Third party CI. You could/should be running this on your driver 
changes in #1 above.


This basically sounds like a cluster driver like vCenter and PowerVC 
which poses scheduling and resource tracking issues which we've 
regretted from an architectural standpoint, so adding another driver 
that relies on this model is not attractive.


Are you also going to be proposing a Cinder storage driver and/or a 
Neutron ML2 plugin?


--

Thanks,

Matt Riedemann


__
OpenStack Development Mailing 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] Propose to add FusionCompute driver to Nova


On 10/13/2016 4:36 PM, Jay Pipes wrote:


What benefit besides marketing does Huawei get from "integrating"
FusionCompute with OpenStack? From looking at the wiki page above,
FusionCompute's product line essentially duplicates a half-dozen or more
OpenStack services, including Nova's scheduler, Nova's compute workers,
Nova's administrative APIs, Neutron, Cinder, Designate, Octavia,
Barbican, and Heat in a monolithic single cloud management application.

What technical benefit do you see from writing a Nova virt driver that
calls the Huawei Compute Management Agent, which then calls the Huawei
Virtual Resource Manager clustered resource management system?

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



That's basically describing the PowerVC driver that is in what used to 
be called stackforge:


http://git.openstack.org/cgit/openstack/powervc-driver/tree/nova-powervc/

It's a virt driver that talks to PowerVC's API, which is basically like 
a vCenter for Power systems. I think the point was you could have a 
vanilla openstack distribution and drop this driver in to talk to your 
PowerVC deployment, but why you'd do that rather than just use PowerVC 
directly I'm not sure, except maybe a 'hybrid' virt driver environment 
where you have some KVM, some vCenter, some HyperV and some PowerVC. I'm 
guessing the same argument could be made for the Huawei driver, and we'd 
likely reject it for the same reasons - it's really a cluster driver 
that talks to a virt manager and we really don't want any more cluster 
drivers in tree, especially single-vendor ones to proprietary backends.


--

Thanks,

Matt Riedemann


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

Re: [openstack-dev] [QA] Request for design session ideas of Barcelona Summit

2016-10-13 Thread Ken'ichi Ohmichi

Hi QA team,

Thanks for providing ideas for Barcelona summit.
I am trying to fit ideas for each design slots, please see the
following etherpad.

  https://etherpad.openstack.org/p/ocata-qa-summit-topics

Current content is just a prototype and not concrete yet.
I am happy if you give feedback to us on the etherpad or this mail thread :)

Thanks
Ken Ohmichi.

2016-09-27 12:40 GMT-07:00 Ken'ichi Ohmichi :
> Hi,
>
> We have a Design Summit next month, and now we are trying to get ideas
> for QA sessions.
> There is an etherpad for ideas and it is good if writing your ideas on that:
>
> https://etherpad.openstack.org/p/ocata-qa-summit-topics
>
> After getting ideas, we will arrange them into available slots for QA 
> sessions.
> Thanks in advance and see you in Barcelona :-)
>
> Thanks
> Ken Ohmichi

__
OpenStack Development Mailing 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] [telemetry] Telemetry presence at PTG in February

2016-10-13 Thread gordon chung

On 10/10/16 08:47 AM, Julien Danjou wrote:
> Hi team,
>
> I'd like to know if members and supporters of the Telemetry team would
> like to request a space in February 2017 during the next PTG¹ in
> Atlanta.
>
> It may be hard to schedule enough in advance, but if you got a feeling
> whether you'll be there and want to discuss some things, it's time to
> say so.
>
> ¹  http://www.openstack.org/ptg
>

to be honest, i probably could be there but it's very much dependent on 
what the topics are. i imagine considering the vast majority of our 
contributors are not from North America, this will be a very empty room.

if North America wants to step up, that'd be cool. that or if we have 
cross-project topics.

if it's just to go hang out and pat each other on the back well that 
will be a hard sell, with or without budget.

cheers,

-- 
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] [nova] Propose to add FusionCompute driver to Nova

2016-10-13 Thread Jay Pipes


On 10/13/2016 04:02 AM, Zhenyu Zheng wrote:

Hi All,

We would like to propose FusionCompute driver to become an official Nova
driver.

FusionCompute is an computing virtualization software developed by
Huawei, which can provide tuned high-performance and high reliabilities
in VM instance provisioning, clustered resource pool management, and
intelligent HA/FT scheduling.

The concepts and technical details for FusionCompute could be found in:
https://wiki.openstack.org/wiki/FusionCompute


What benefit besides marketing does Huawei get from "integrating" 
FusionCompute with OpenStack? From looking at the wiki page above, 
FusionCompute's product line essentially duplicates a half-dozen or more 
OpenStack services, including Nova's scheduler, Nova's compute workers, 
Nova's administrative APIs, Neutron, Cinder, Designate, Octavia, 
Barbican, and Heat in a monolithic single cloud management application.


What technical benefit do you see from writing a Nova virt driver that 
calls the Huawei Compute Management Agent, which then calls the Huawei 
Virtual Resource Manager clustered resource management system?


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

Re: [openstack-dev] PTG from the Ops Perspective - a few short notes

2016-10-13 Thread Erin Disney

Hey everyone- wanted to introduce myself and answer a couple questions from 
this thread. I’m Erin, part of the Foundation’s Marketing/Events team, and I 
have been helping organize the inaugural PTG.
 
Here is what I can tell you from a logistics perspective: 
The first PTG will be held February 20-24, 2017 in Atlanta, GA at the downtown 
Sheraton Hotel 
Our group rate for rooms is $185 a night (which includes a breakfast buffet)
Registration will go live in the next couple of weeks and tickets will be $100, 
which will help cover lunch/coffee every day and help us ensure attendance for 
those that register 
Horizontal/cross project teams will meet Monday and Tuesday, Vertical project 
team meetings will be held Wednesday, Thursday and Friday 

For anyone going to the Summit in Barcelona later this month, Thierry and I 
will be hosting an informational presentation on the PTG 

 and then answering questions in the Foundation Lounge (located near the main 
entrance of the Convention Center near Registration) on Wednesday 10/26 during 
lunch from 1:05-1:35pm. Feel free to stop by to learn more or ask us questions, 
and stay tuned for more information in the coming weeks. 

Erin Disney
OpenStack Marketing
e...@openstack.org 

> 
> 
> -- Forwarded message -
> From: Clint Byrum >
> Date: Thu, Oct 13, 2016 at 8:42 AM
> Subject: Re: [openstack-dev] PTG from the Ops Perspective - a few short notes
> To: openstack-dev  >
> 
> 
> Excerpts from Dmitry Tantsur's message of 2016-10-13 10:30:44 +0200:
> > On 10/12/2016 08:47 PM, Clint Byrum wrote:
> > > Excerpts from Jaesuk Ahn's message of 2016-10-12 15:08:24 +:
> > >> It can be cheap if you are in the US. However, for Asia folks, it is not
> > >> that cheap considering it is all overseas travel. In addition, all-in-one
> > >> event like the current summit makes us much easier to get the travel fund
> > >> from the company, since the company only need to send everyone (tech, 
> > >> ops,
> > >> business, strategy) to one event. Even as an ops or developers, doing
> > >> presentation or a meeting with one or two important company can be very
> > >> good excuse to get the travel money.
> > >>
> > >
> > > This is definitely on the list of concerns I heard while the split was
> > > being discussed.
> > >
> > > I think the concern is valid, and we'll have to see how it affects
> > > attendance at PTG's and summits.
> > >
> > > However, I am not so sure the overseas cost is being accurately
> > > characterized. Of course, the complications are higher with immigration
> > > details, but ultimately hotels around international hub airports are
> > > extremely cheap, and flights tend to be quite a bit less expensive and
> > > more numerous to these locations. You'll find flights from Narita to
> > > LAX for < $500 where as you'd be hard pressed to find Narita to Boston
> > > for under $600, and they'll be less convenient, possibly requiring more
> > > hotel days.
> >
> > The bit about hotels contradicts my whole experience. I've never seen 
> > hotels in
> > big busy hubs cheaper than in less popular and crowded cities. Following 
> > your
> > logic, hotels e.g. in Paris should be cheaper than ones in e.g. Prague, 
> > which I
> > promise you is far from being the case :)
> >
> 
> Sorry I communicated that horribly.
> 
> The hotels next to LAX, which are _ugly_ and _disgusting_ but perfectly
> suitable for a PTG, are much cheaper than say, the ones in DT LA near the
> convention center, or in Hollywood, or near Disneyland.
> 
> A better comparison than LAX might be Atlanta or Minneapolis, which
> are cities that aren't such common end-destinations, but have tons of
> flights in and out and generally affordable accommodations.
> 
> > >
> > > Also worth considering is how cheap the space is for the PTG
> > > vs. Summit. Without need for large expo halls, keynote speakers,
> > > catered lunch and cocktail hours, we can rent a smaller, less impressive
> > > space. That should mean either a cheaper ticket price (if there is one
> > > at all) or more sponsored travel to the PTG. Either one of those should
> > > help alleviate the concerns about travel budget.
> >
> > For upstream developers ticker price was 0. Now it will be > 0, so for 
> > companies
> > who send mostly developers, this is a clear budget increase.
> >
> 
> The nominal price of the PTG is expected to be something like $25 or
> $50. This isn't to cover all the costs, but to ensure that people don't
> just sign up "just in case I'm in the area" or anything like that.
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:

Re: [openstack-dev] [gnocchi] host field information flapping for instance resource-type

2016-10-13 Thread gordon chung

you might want to try editing 
https://github.com/openstack/ceilometer/blob/master/etc/ceilometer/gnocchi_resources.yaml#L62

-  host: resource_metadata.host
+  host: resource_metadata.(instance_host|host)

that might work? if it does, feel free to push it back to community.

On 13/10/16 04:53 PM, gordon chung wrote:
> it actually might be related to this previous fix:
> https://github.com/openstack/ceilometer/commit/de5ff7303d6f278ef37149297bbb7d2e77f45a0d

-- 
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] [nova] Propose to add FusionCompute driver to Nova

2016-10-13 Thread Michael Still

So, its good that you're working on third party CI, but I see that as a
blocker before we can start this conversation -- we need to have a solid
history there before we can do much. You also don't mention (that I can
find) where the code to the driver is. Can I have a pointer to that please?

Michael

On Thu, Oct 13, 2016 at 7:02 PM, Zhenyu Zheng 
wrote:

> Hi All,
>
> We would like to propose FusionCompute driver to become an official Nova
> driver.
>
> FusionCompute is an computing virtualization software developed by Huawei,
> which can provide tuned high-performance and high reliabilities in VM
> instance provisioning, clustered resource pool management, and intelligent
> HA/FT scheduling.
>
> The concepts and technical details for FusionCompute could be found in:
> https://wiki.openstack.org/wiki/FusionCompute
>
> Huawei has been working on integrating FusionCompute and OpenStack since
> Folsom release using Nova-FusionCompute driver. FusionCompute has been
> successfully deployed as the hypervisor within Huawei's FusionShpere
> Openstack Cloud Operation System solution in large number of commercial
> private and public clouds running stable for several years, including:
>
>  *Deutsche Telekom - Open Telekom Cloud*:
>  http://www.cebit.de/en/news/open-telekom-cloud-is-live.xhtml
>  https://www.telekom.com/media/company/291108
>  http://www.huawei.com/en/news/2016/3/dian-xin-yun
>  https://cloud.telekom.de/en/cloud-infrastructure/open-telekom-cloud/
>
>  *Telefonica LatAm Public Cloud*:
>  https://www.business-solutions.telefonica.com/es/information-centre/news/
> telefonica-and-huawei-reach-a-global-agreement-to-promote-
> enterprise-migration-to-the-cloud/
>  http://www.lightreading.com/services/cloud-services/
> telefonica-and-huawei-debut-latam-public-cloud/d/d-id/726571
>  https://www.huawei.com/th-TH/news/2016/9/Telefonica-Brazil-
> Mexico-Chile-Cloud-Serve
>  https://www.cloud.telefonica.com/en/
>
>  *Huawei Enterprise Cloud:*
>  http://www.hwclouds.com/en-us/
>
>  *China Telecom Public Cloud:*
>  http://www.ctyun.cn/
>  http://www.ctyun.cn/product/oos_e
>
>  *Other cases can be found in*:
>  http://e.huawei.com/en/case-studies?product=Cloud%20Computing
>
> As mentioned above, FusionCompute has been proved to be with high
> reliability and large user base, thus we would like to propose
> FusionCompute driver to Nova as an official Nova driver.
>
> We have tried to propose this back in 2014, blueprint and discussions can
> be found in:
> https://blueprints.launchpad.net/nova/+spec/driver-for-
> huawei-fusioncompute
> http://lists.openstack.org/pipermail/openstack-dev/2014-
> February/026075.html
>
> We have set up the ThirdPartyCI:
> https://wiki.openstack.org/wiki/ThirdPartySystems/Huawei_FusionCompute_CI
> and adjusting it to Nova, it will be online very soon.
>
> Thanks
>
> Kevin Zheng
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Rackspace Australia
__
OpenStack Development Mailing 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] [gnocchi] host field information flapping for instance resource-type

2016-10-13 Thread gordon chung

i won't lie, i don't remember opening that bug.lol

it actually might be related to this previous fix: 
https://github.com/openstack/ceilometer/commit/de5ff7303d6f278ef37149297bbb7d2e77f45a0d

On 12/10/16 08:49 PM, Jake Yip wrote:
> Hi all!
>
> We've been trying to get gnocchi working us, and have been hitting some
> performance bottlenecks. It seems that the 'host' field for the instance
> resource-type flaps between host id and host names. This makes the
> gnocchi dispatcher calls an update per resource which is a HTTP PATCH
> call. The large amount of HTTP calls causes gnocchi to be unable to keep
> up with ceilometer, essentially making it unworkable for us in production.
>
> I've tried removing this update code and can get ~5x the performance. So
> I guess the questions are,
>
> 1) why is the host information flapping? Are there difference services
> generating this data?
>
> 2) If gnocchi data can be viewable by the user, should we only have host
> id in the resource? (similar to what nova shows to user)
>
> 3) Anyone running gnocchi in prod, can you let us know how is it going?
>
> Any pointers to track down this issue will be appreciated! There is a
> bug[1] open for this issue but I hope this email can reach more people.
>
> FYI, we are running Mitaka ceilometer and gnocchi, but we have patched
> ceilometer to use the Newton gnocchi dispatcher to help with performance.
>
> [1] https://bugs.launchpad.net/ceilometer/+bug/1569037
>
> Jake Yip,
> DevOps Engineer,
> Core Services, NeCTAR Research Cloud,
> The University of Melbourne
>
>
> __
> OpenStack Development Mailing 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] [rpm-packaging][chef][puppet][salt][openstack-ansible][HA][tripleo][kolla][fuel] Schema proposal for config file handling for services

2016-10-13 Thread Alex Schultz

On Thu, Oct 13, 2016 at 3:27 AM, Thomas Bechtold  wrote:
> On Tue, Oct 11, 2016 at 12:32:40PM -0600, Alex Schultz wrote:
>> On Tue, Oct 11, 2016 at 1:39 AM, Thomas Bechtold  wrote:
>> > Hi,
>> >
>> > On Mon, Oct 10, 2016 at 10:07:05AM -0600, Alex Schultz wrote:
>> >> On Mon, Oct 10, 2016 at 5:03 AM, Thomas Bechtold  
>> >> wrote:
>> >> > Hi,
>> >> >
>> >> > in the rpm-packaging project we started to package the services and are
>> >> > currently discussing a possible schema for configuration files and
>> >> > snippets used by the systemd .service files (but this would also affect
>> >> > OCF resource agents).
>> >> > This affects packagers, endusers and config management systems (Chef,
>> >> > Puppet, Ansible, Salt, ...) so I want to discuss the proposal here on
>> >> > the list.
>> >>
>> >> This also affects deployment tools so you may want to include tripleo,
>> >> kolla, fuel as they are downstream consumers and may have their own
>> >> assumptions about how services are launched.
>> >
>> > Done.
>> >
>> >> > Most services (at least for SUSE and RDO) are using a single config
>> >> > (e.g. /etc/nova/nova.conf) when starting the service. Some services
>> >> > (e.g. neutron services like neutron-l3-agent) use multiple config files.
>> >> >
>> >> > There are multiple problems with that approach:
>> >> > - when using a config-mgmt-system, users may want to override a config
>> >> > option (for a feature that is not yet supported) but the
>> >> > config-mgmt-system will override the config later again.
>> >>
>> >> Just to chime in here from a puppet standpoint, this is not a problem
>> >> because we provide a way for a user to add any extra options they wish
>> >> using the provider so it always ends up in the correct configuration
>> >> file.
>> >
>> > Does that also work if you need extra configuration files for 3rd party
>> > plugins (e.g. neutron plugins) ? I guess you could just copy the 3rd
>> > party config file content to the needed neutron config but that's ugly imo.
>> >
>>
>> Plugins also have their own .ini files and are handled differently.
>> They get weird but we put the service configs in
>> /etc/neutron/neutron.conf and agent configs get put in .ini files.
>
> So you put the config sections from the plugins into the neutron conf
> and mix things, right?

Specifically for neutron, yes the service configs for plugins get put
in neutron.conf but I believe they are in their own section.  It seems
not to have an issue with this.


>
>> >> > - when users adjust /etc/$service/$service.conf and a release update is
>> >> > done (e.g. mitaka->newton) /etc/$service/$service.conf wil not be
>> >> > overridden. That's good because the user changed something but otoh the
>> >> > file (with all it's config options and comments) is no longer correct.
>> >>
>> >> Depending on the configuration management tool, the 'default' options
>> >> and comments may not even be there so I'm not sure this is actually
>> >> that much of a concern.  Also when you upgrade there is usually some
>> >> sort of upgrade process that has to go along with your configuration
>> >> management tool which should take care of this for you. So i'm not
>> >> sure this needs to be a packaging concern.
>> >>
>> >> > - when config-mgmt-systems use templates for the $service.conf file,
>> >> > updating theses templates is a lot of work.
>> >>
>> >> Yes which is why tools that don't use templates in the configuration
>> >> management tool makes this a non-issue.  I'm not sure this needs to be
>> >> a concern of packagers as it's an issue with the configuration
>> >> management tool of choice and many of these tools have switched away
>> >> from templates or are currently handling this.  If the configuration
>> >> management tool doesn't support this or is suffering from this, simply
>> >> adding conf.d support might help but then you also run into issues
>> >> about ensuring things are removed and cleaned up.
>> >
>> > There *are* config-mgmt-tools still using templates. And having the
>> > possibility to add config snippets simplifies the process here without
>> > any downside for available solutions. Just don't use it if you don't
>> > need it.
>> >
>>
>> Yes there are but that's not a packaging concern other than providing
>> a simple way to not have to deal with constantly managing
>> $service.conf.  I'm ok with a conf.d folder, but I guess that's more
>> of a question for folks who have to manage those templates today as to
>> what their prefered method is. Speaking from experience with a tool
>> that we try not to use templates, my preference is still to have
>> $service.conf but don't have it replaced on package update.
>
> Having $service.conf which is not replaced on package update is what is
> proposed in this proposal (and is what distros already do).
> And speaking as a Crowbar contributor (which uses templates in some
> places), the conf.d/ directory would help a lot.

[openstack-dev] [nova][barbican][security] Ocata design summit session change

I've changed the nova design summit session on docs needed for newton to 
now be a session to cover the various security-related specs up for review:


https://www.openstack.org/summit/barcelona-2016/summit-schedule/events/16977/nova-security-specs-and-testing

And to also talk about getting a CI job going which will test some of 
these features, like with barbican as the key manager and using signed 
images.


I've tagged this session with 'barbican' although I see that the 
barbican team is having another session at the same time. There was one 
other slot that I could have moved for nova but barbican had a conflict 
then too, so I've just left this where it is and if anyone from barbican 
can show up all the better, but I don't think it's necessarily a 
requirement.


--

Thanks,

Matt Riedemann


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

Re: [openstack-dev] [QA] The end-user test suite for OpenStack clusters

2016-10-13 Thread Ken'ichi Ohmichi

Hi Timur,

I discussed this on irc, and it seems hard to get feedback from many
people because now the scope and implementation of this os-faults are
separated into multiple pieces(like multiple mails, github code,
gerrit etc).
So how about proposing this as qa-spec?
If doing that, We can discuss this on clear document and it is clear
to get a consensus about adding this.

Thanks
Ken Ohmichi

---

.

2016-10-07 12:43 GMT-07:00 Ken'ichi Ohmichi :
> Hi Timur,
>
> 2016-10-06 4:08 GMT-07:00 Timur Nurlygayanov :
>> Ken, it is a good idea!
>>
>> The plan is to develop os-faults as a library which will be able
>> to manage cluster nodes and OpenStack services on these nodes.
>> It is a good idea to add some Tempest tests which will use
>> os-faults library as well for some API tests.
>
> Sorry for my misleading, that is not I wanted to say.
> I am thinking Tempest doesn't use os-faults as library.
> I just wanted to say some destructive tests which will use REST APIs
> can be implemented in Tempest instead of os-faults.
>
> For example, the compute service client contains disable_service which
> disables nova service but Tempest doesn't contain the corresponding
> test cases because Tempest tests need to run in parallel.
> https://github.com/openstack/tempest/blob/master/tempest/lib/services/compute/services_client.py#L54
>
> If some tests use this method, the other tests which run in parallel
> can be failed as unexpected on the gate.
> Such tests also are destructive and I am hoping these tests also will
> be able to run the gate by finding better way.
>
>> The Stepler framework [1] will use os-faults to perform all destructive
>> actions in the clouds (the reboot of nodes, restart of OpenStack services,
>> enable/disable network interfaces or some firewall rules and etc).
>>
>> We need to get +1 from you in [1] to create the repository with
>> advanced end-user scenario tests.
>
> OK, I'd like to summarize my thinking here for adding os-faults under
> QA project:
>
> Under QA project, the first target of most programs(tempest, devstack,
> etc) is for the gate testing.
> Of course, some of them are available on production clouds also as the
> design, but the first is for the gate.
> That means devstack clouds as the first target/purpose.
> At this time, this os-faults doesn't seem the gate as the first
> purpose based on current implementation.
> So I feel os-faults seems different from the existing programs.
>
> os-faults is very young and we will be able to extend it for devstack
> clouds also later, I hope.
> In addition, I heard this kind of tests(destructive, HA, etc) are
> requested from the other users.
> So this os-faults seems very valuable for users.
>
> Just in my opinion, I am find to add this os-faults under QA project.
> But before that, I'd like to get opinions from the other people of QA team.
>
> Thanks
> Ken Ohmichi
>
>
>
>
>
>
>
>
>
>
>
>
>> On Tue, Oct 4, 2016 at 8:53 PM, Yaroslav Lobankov 
>> wrote:
>>>
>>> Hi Ken,
>>>
>>> OS-Faults doesn't have any scenarios in the tree yet (the project is two
>>> months old), but you can find some examples of the use in the
>>> os-faults/examples directory.
>>>
>>> Regards,
>>> Yaroslav Lobankov.
>>>
>>> On Tue, Oct 4, 2016 at 8:02 PM, Ken'ichi Ohmichi 
>>> wrote:

 Hi Timur,

 Thanks for your explanation.

 2016-09-29 6:22 GMT-07:00 Timur Nurlygayanov
 :
 >
 >> I am guessing the above "restart nodes" is for verifying each
 >> OpenStack service restarts successfully, right?
 >
 > Yes, this is right. And we also will check that HA logic for these
 > services works correctly (for example, rescheduling of L3 Neutron
 > agents for networks).
 >
 >> But these service scripts are provided by distributors, and Devstack
 >> itself doesn't contain service scripts IIUC.
 >> So I'd like to know how to verify it on Devstack clouds.
 >
 > Yes, DevStack doesn't support many scenarios which are actual
 > and should be supported on the production clouds.
 > It will be not possible to run all advanced test scenarios for DevStack
 > clouds,
 > just because DevStack can't deploy OpenStack cloud with 3 controllers
 > now (so, probably it will be possible in the future).
 >
 > Of course, some advanced scenarios will support DevStack clouds,
 > for example, some test scenarios which are based on customer-found
 > issues from the real production clouds, like upload of the large images
 > (100+ Gb)
 > to Glance with Swift backend. Such cases are important for verification
 > of
 > pre-production environments, but not very important for CI gate jobs.
 >
 > It is also important to note that in these advanced cases we are
 > targeting
 > to check not only the logic of Python code, but also the correct
 >

Re: [openstack-dev] [nova] How to handle hw_pointer_model image meta?


On 10/13/2016 12:30 PM, Matt Riedemann wrote:

In Newton we replaced the CONF.libvirt.use_usb_tablet option with
CONF.pointer_model, both default to creating a usb tablet input device
for HVM guests in the libvirt driver.

To straddle backward compatibility with use_usb_tablet=False, we added
None and ps2mouse as options for the pointer_model config option, which
basically mean if you specify those you get whatever default input
device there is (ps2mouse for libvirt x86).

The hw_pointer_model image metadata takes precedence over the config
option in nova.

I noticed today that the hw_pointer_model ImageMeta object property is
using a field with a single enum, 'usbtablet'. So while the config
option lets you set None/ps2mouse/usbtablet, the image meta value can
only be usbtablet if it's set.

This is important because we don't have hw_pointer_model defined in the
glance libvirt image metadefs:

https://github.com/openstack/glance/blob/13.0.0/etc/metadefs/compute-libvirt-image.json


I'd like to add it but the only value you can have for it is 'usbtablet'
right now. Having a single enum value seems kind of weird, but maybe
that's fine. I only found 3 other image metadefs in glance that had
'None' as possible enum values.

So would we define 'ps2mouse' as a hw_pointer_model option in nova or
just add hw_pointer_model to glance and it has a single enum value for
setting it, which is usbtablet? If you don't want usbtablet then you
don't add hw_pointer_model to your image - HOWEVER - given we default
CONF.pointer_model='usbtablet' we're still going to try and set it when
creating the guest, which may or may not fail depending on your other
config for that compute host (e.g. any non-kvm/qemu virt_type will fail).

Alternatively we could change the default value of CONF.pointer_model to
be None and then it's purely an opt-in behavior, but it would be a
change in default behavior for guests on kvm/qemu hosts.



FWIW this is what the proposed metadef change looks like:

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

--

Thanks,

Matt Riedemann


__
OpenStack Development Mailing 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] [ovs-discuss] [ovn][neutron] networking-ovn 1.0.0 release (newton) -- port-security

2016-10-13 Thread Murali R

>> Please clarify if port security is required to be enabled with newton
release when installing OVN
>
> You can disable it.  There's no problem with that.  It will just disable
related features: L2 and L3 port security and security groups.
>
> --
> Russell Bryant
-
--

>> newton release when installing OVN. The install.rst says it must be.
>
> Disabling port security should work with networking-ovn. This can be
> done via the extension or at a port or network level. OVN acls shouldn't
? be created for port with port security disabled.

> - Richard

--

Thanks Russell & Richard for the clarifications.
__
OpenStack Development Mailing 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] To PTG or not to be that is the question!

2016-10-13 Thread Doug Hellmann

Excerpts from Joshua Harlow's message of 2016-10-13 09:02:06 -0700:
> Hi oslo folks,
> 
> It appears we also need to discuss and decide on whether oslo and its 
> associated folks want to try to go to the PTG (project team gathering) 
> or do folks in oslo not feel such a thing would be needed?
> 
> I personally could see either way being useful, but in person 
> discussions do seem nice though I'm also fine with async ones over IRC to...
> 
> Thoughts from other oslo folks?
> 
> https://www.openstack.org/ptg/ (to be or not to be),
> 
> -Josh
> 

We should try to reserve some space, even if we don't need a whole week
(or even a whole day). Given that a lot of folks on the team contribute
part time, initiatives can stall out a bit if they're not given the
bootstrapping that in-person meetings can produce.

Doug

__
OpenStack Development Mailing 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] How to handle hw_pointer_model image meta?

In Newton we replaced the CONF.libvirt.use_usb_tablet option with 
CONF.pointer_model, both default to creating a usb tablet input device 
for HVM guests in the libvirt driver.


To straddle backward compatibility with use_usb_tablet=False, we added 
None and ps2mouse as options for the pointer_model config option, which 
basically mean if you specify those you get whatever default input 
device there is (ps2mouse for libvirt x86).


The hw_pointer_model image metadata takes precedence over the config 
option in nova.


I noticed today that the hw_pointer_model ImageMeta object property is 
using a field with a single enum, 'usbtablet'. So while the config 
option lets you set None/ps2mouse/usbtablet, the image meta value can 
only be usbtablet if it's set.


This is important because we don't have hw_pointer_model defined in the 
glance libvirt image metadefs:


https://github.com/openstack/glance/blob/13.0.0/etc/metadefs/compute-libvirt-image.json

I'd like to add it but the only value you can have for it is 'usbtablet' 
right now. Having a single enum value seems kind of weird, but maybe 
that's fine. I only found 3 other image metadefs in glance that had 
'None' as possible enum values.


So would we define 'ps2mouse' as a hw_pointer_model option in nova or 
just add hw_pointer_model to glance and it has a single enum value for 
setting it, which is usbtablet? If you don't want usbtablet then you 
don't add hw_pointer_model to your image - HOWEVER - given we default 
CONF.pointer_model='usbtablet' we're still going to try and set it when 
creating the guest, which may or may not fail depending on your other 
config for that compute host (e.g. any non-kvm/qemu virt_type will fail).


Alternatively we could change the default value of CONF.pointer_model to 
be None and then it's purely an opt-in behavior, but it would be a 
change in default behavior for guests on kvm/qemu hosts.


--

Thanks,

Matt Riedemann


__
OpenStack Development Mailing 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] [all][api] POST /api-wg/news

2016-10-13 Thread michael mccune


Greetings OpenStack community,

Today's meeting began with a quick review of the API usability tests 
that are being conducted at the Barcelona Summit[7]. We also had two 
lively discussions which took up most of the meeting: one about 
collecting and improving error messages across OpenStack, and the other 
about request semantics with regards to GET and body processing. All 
interested parties can find the logs in the usual place [5] for the full 
details.


In the first conversation, Eddie Ramirez shared some work that he and 
his team have been creating to help improve how we consume errors in 
OpenStack. So far, they have done work collecting errors from a few of 
the most common projects and have incorporated this effort into an error 
knowledge base website[8]. There is some great work here, and we look 
forward to this process advancing with help from the greater OpenStack 
community, here is an etherpad where some ideas have been collected[9].


The other conversation was brought by Ed Leafe and concerns how GET 
requests can be filtered by using either request URL parameters or by 
adding a body to the request. This topic is in relation to a spec[10] 
currently winding its way through the Nova project, and the sincere 
desire of that team to create an API guideline to help define their process.


All in all, a great meeting with good participation and several 
interesting topics.


# New guidelines

There are no new guidelines that have been merged this week, but we did 
accept a change to the landing page.


* add a warning about json expectations
  https://review.openstack.org/#/c/364460/

# API guidelines that have been recently merged

Nothing new in the recent past.

# API guidelines proposed for freeze

The following guidelines are available for broader review by interested 
parties. These will be merged in one week if there is no further feedback.


No new guidelines proposed for freeze this week

# Guidelines currently under review [6]

* Specify time intervals based filtering queries
https://review.openstack.org/#/c/383862/

# API Impact reviews currently open

Reviews marked as APIImpact [1] are meant to help inform the working 
group about changes which would benefit from wider inspection by group 
members and liaisons. While the working group will attempt to address 
these reviews whenever possible, it is highly recommended that 
interested parties attend the API WG meetings [2] to promote 
communication surrounding their reviews.


To learn more about the API WG mission and the work we do, see OpenStack 
API Working Group [3].


Thanks for reading and see you next week!

[1] 
https://review.openstack.org/#/q/status:open+AND+(message:ApiImpact+OR+message:APIImpact),n,z

[2] https://wiki.openstack.org/wiki/Meetings/API-WG#Agenda
[3] http://specs.openstack.org/openstack/api-wg/
[4]: https://bugs.launchpad.net/openstack-api-wg
[5]: http://eavesdrop.openstack.org/meetings/api_wg/
[6]: 
https://review.openstack.org/#/q/status:open+project:openstack/api-wg,n,z
[7]: 
https://wiki.openstack.org/wiki/UX#Participate_in_a_usability_study_being_conducted_at_the_Barcelona_Summit.21

[8]: http://172.99.106.155/exceptions/
[9]: https://etherpad.openstack.org/p/api-error-messages
[10]: https://review.openstack.org/#/c/300178/



__
OpenStack Development Mailing 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] [openstack][nova] Port unbound from active VM

2016-10-13 Thread Ajay Kalambur (akalambu)

Any comments/input on this?
Ajay

From: Ajay Kalambur >
Date: Monday, October 10, 2016 at 6:31 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
>
Subject: [openstack][nova] Port unbound from active VM

Hi
There seems to be a corner case bug in nova code. Steps to reproduce it are

  1.  Create a neutron port
  2.  Create a VM and launch instance with this port
  3.  Shutdown nova compute and network agent on compute node
  4.  Unbind port from VM and delete the VM (offline delete)
  5.  Now create a VM with same port but on a different compute node
  6.  Bring up nova compute on old node

It basically runs the reap for deleted instances and cleanes up VM from 
libvirt. In the process it unbinds the pre-existing ports and ends up unbinding 
the port from an active VM on a different compute node
Reason nova simply sends a blind port-update with binding_host: “” even if that 
port is bound to a different instance

So following fix seemed to help any suggestions on a better fix

In nova/network/neutronv2/api.py. So basically when neutron sees no ports for 
this instance don’t attempt an unbind
In this case
data = neutron.list_ports(**search_opts)
Call in deallocate_for_instance returns empty ports

  # Reset device_id and device_owner for the ports that are skipped

if data.get('ports', []):

self._unbind_ports(context, ports_to_skip, neutron)

else:

LOG.debug("Neutron sees a different view of this port hence 
skipping unbind”)

Ajay

__
OpenStack Development Mailing 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] (action required) Summit schedule

2016-10-13 Thread Emilien Macchi

Team,

I just finished a first draft of TripleO schedule for Barcelona Summit:
https://www.openstack.org/summit/barcelona-2016/summit-schedule/global-search?t=TripleO%3A

Please review it and let me know ASAP your schedule constraints if you
have some.
If you're chair, I sent you a email in private to make sure your
session is well prepared: what problem we need to solve, what outcome
do we expect.
Please take some time to finish it as soon as you can before the
Summit: https://etherpad.openstack.org/p/ocata-tripleo

Any question or feedback is welcome,

Thanks,
-- 
Emilien Macchi

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

[openstack-dev] [oslo] To PTG or not to be that is the question!

2016-10-13 Thread Joshua Harlow


Hi oslo folks,

It appears we also need to discuss and decide on whether oslo and its 
associated folks want to try to go to the PTG (project team gathering) 
or do folks in oslo not feel such a thing would be needed?


I personally could see either way being useful, but in person 
discussions do seem nice though I'm also fine with async ones over IRC to...


Thoughts from other oslo folks?

https://www.openstack.org/ptg/ (to be or not to be),

-Josh

__
OpenStack Development Mailing 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] [tc] governance review dashboard

2016-10-13 Thread Doug Hellmann

Since we have some new members this term, I thought I would share
the TC review dashboard link I set up a while back in case others
find it useful. It organizes reviews based on formal-vote items and
whether or not you have responded to the current draft.

https://review.openstack.org/#/dashboard/?foreach=project%3Aopenstack%2Fgovernance+is%3Aopen=Technical+Committee+Inbox+items=owner%3Aself+Vote+Items+I+have+not+voted+in+yet=topic%3Aformal%2Dvote%0ANOT+label%3ACode%2DReview%3C%3D2%2Cself%0ANOT+label%3ARollcall%2Dvote%3C%3D2%2Cself%0ANOT+owner%3Aself+Vote+Items=topic%3Aformal%2Dvote+Haven%27t+Voted+on+this+Draft=NOT+label%3ACode%2DReview%3C%3D2%2Cself%0ANOT+label%3ARollcall%2Dvote%3C%3D2%2Cself%0ANOT+owner%3Aself+at+Least+One+Objection=NOT+label%3ACode%2DReview%3C%3D2%2Cself%0ANOT+owner%3Aself%0Alabel%3ACode%2DReview%3C%3D%2D1

The dashboard config file is part of the gerrit-dash-creator repo, in
case you're interested in suggesting enhancements.
http://git.openstack.org/cgit/openstack/gerrit-dash-creator/tree/dashboards/tc.dash

Doug

__
OpenStack Development Mailing 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] [lbaas] [octavia] Proposing Lubosz Kosnik (diltram) as Octavia Core

2016-10-13 Thread Kosnik, Lubosz

Thank you very much for believing that I can be valuable asset for Octavia.
I will work as hard as currently, or even harder because of responsibility, on 
making Octavia better from day to day.

Lubosz

> On Oct 12, 2016, at 3:48 PM, Michael Johnson  wrote:
> 
> That is quorum from the cores, welcome Lubosz!
> 
> Michael
> 
> 
> On Wed, Oct 12, 2016 at 1:26 PM, Doug Wiegley
>  wrote:
>> +1
>> 
>>> On Oct 10, 2016, at 3:40 PM, Brandon Logan  
>>> wrote:
>>> 
>>> +1
>>> 
>>> On Mon, 2016-10-10 at 13:06 -0700, Michael Johnson wrote:
 Greetings Octavia and developer mailing list folks,
 
 I propose that we add Lubosz Kosnik (diltram) as an OpenStack Octavia
 core reviewer.
 
 His contributions [1] are in line with other cores and he has been an
 active member of our community.  He regularly attends our weekly
 meetings, contributes good code, and provides solid reviews.
 
 Overall I think Lubosz would make a great addition to the core review
 team.
 
 Current Octavia cores, please respond with +1/-1.
 
 Michael
 
 [1] http://stackalytics.com/report/contribution/octavia/90
 
 _
 _
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubs
 cribe
 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


__
OpenStack Development Mailing 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] OpenStack Newton for Ubuntu 16.04 LTS and Ubuntu 16.10

2016-10-13 Thread Corey Bryant

Hi All,

The Ubuntu OpenStack team is pleased to announce the general availability
of OpenStack Newton, available in today’s release of Ubuntu 16.10 (Yakkety
Yak) [0] and also available for Ubuntu 16.04 LTS (Xenial Xerus) via the
Ubuntu Cloud Archive.

Ubuntu 16.04 LTS



You can enable the Ubuntu Cloud Archive pocket for OpenStack Newton on
Ubuntu 16.04 installations by running the following commands:

  sudo add-apt-repository cloud-archive:newton

  sudo apt update

The Ubuntu Cloud Archive for Newton includes updates for: Aodh, Barbican,
Ceilometer, Cinder, Congress, Designate, DPDK (16.07), Glance, Gnocchi,
Heat, Horizon, Ironic (6.2.1), Keystone, Magnum, Manila, Mistral, Murano,
Networking-L2GW, Networking-ODL, Networking-OVN, Networking-SFC, Neutron,
Neutron-Dynamic-Routing, Neutron-FWaaS, Neutron-LBaaS, Neutron-TaaS,
Neutron-VPNaaS, Nova, Nova-LXD, OpenvSwitch (2.6.0), Sahara, Senlin, Swift
(2.10.0), Trove, and Zaqar.

You can see the full list of packages and versions at [1].

Ubuntu 16.10

--

No extra steps required; just start installing OpenStack!

Branch Package Builds

---

If you want to try out the latest updates to stable branches, we are
delivering continuously integrated packages on each upstream commit in the
following PPA’s:

  sudo add-apt-repository ppa:openstack-ubuntu-testing/liberty

  sudo add-apt-repository ppa:openstack-ubuntu-testing/mitaka

  sudo add-apt-repository ppa:openstack-ubuntu-testing/newton

bear in mind these are built per-commitish (30 min checks for new commits
at the moment) so ymmv from time-to-time.

Reporting bugs



Any issues please report bugs using the 'ubuntu-bug' tool:

  sudo ubuntu-bug nova-conductor

this will ensure that bugs get logged in the right place in Launchpad.

Thank you to all who contributed to OpenStack Newton both upstream and in
Debian/Ubuntu packaging!

Regards,

Corey

(on behalf of the Ubuntu OpenStack team)

[0] https://wiki.ubuntu.com/YakketyYak/ReleaseNotes

[1]
http://reqorts.qa.ubuntu.com/reports/ubuntu-server/cloud-archive/newton_versions.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

Re: [openstack-dev] [mistral] Who's interested in attending PTG?

2016-10-13 Thread Ренат Ахмеров

Hi Dougal, thank you. That helps a lot.

Renat

> 13 окт. 2016 г., в 17:49, Dougal Matthews  написал(а):
> 
> 
> 
>> On 13 October 2016 at 10:29, Ренат Ахмеров  wrote:
>> Hi,
>> 
>> Can you please reply to this thread? It's very important for our further 
>> planning. We will get a space at PTG only if at least two companies need it. 
>> I recognize it may be too early to make this decision but at least some 
>> intentions expressed by you would already be enough. In other words, I am 
>> just asking to answer honestly.
> 
> We will most likely be sending a number of people, and among them there will 
> be a good percentage of TripleO developers. I would then expect that some of 
> them will be interested in Mistral since we use it now, and expect to use it 
> for more in Ocata. I don't know if I will be one of those people, I think 
> Ryan Brady is more likely.
> 
> So, yes, I think we have interest and intend to send people but can't confirm 
> anything 100% yet.
> 
> I hope that helps!
> 
> Dougal
> 
>  
>> 
>> Thanks
>> 
>> Renat
>> 
>> 
>>> От: Renat Akhmerov 
>>> Дата: 7 oct 2016 г., 13:09:01 GMT+7
>>> Кому: "OpenStack Development Mailing List (not for usage questions)" 
>>> 
>>> Тема: Ответ:⁨ [openstack-dev] [mistral] Who's interested in attending PTG?⁩
>>> 
>>> Yes, thanks for clarification Clint.
>>> 
>>> Renat Akhmerov
>>> @Nokia
>>> 
> On 6 Oct 2016, at 20:02, Clint Byrum  wrote:
> 
> Excerpts from Renat Akhmerov's message of 2016-10-06 19:21:40 +0700:
> Hi,
> 
> As you likely know, the summit format will change after Barcelona. There 
> will be two events now: PTG (Project Team Gathering) for design sessions 
> and OpenStack Summit which is more customer/promotion oriented . The 
> first will take place in Atlanta on Feb 20-24, 2017 and the second one in 
> May 2017 in Boston. More about that at [1]. Please read it.
 
 May 2017 is the OpenStack Conference, not a PTG. Teams are welcome to
 schedule a mid-cycle coinciding with this event to take advantage of
 contributors attending the conference, but it's not an "everyone together
 in one place" event.
 
 __
 OpenStack Development Mailing 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] [kolla] RC3 Objectives - OCT 18th DEADLINE

2016-10-13 Thread Steven Dake (stdake)

RC2 has been tagged.  The stable/newton branch has been created.  Master is 
open for business!  Core reviewers please remove any procedural -2’s you have 
placed on reviews.

In RC3 of Kolla, we are fixing only critical bugs.  All bugs in rc3 need to be 
backported to stable/newton in order to tag 3.0.0.

The deadline for RC3 is short – October 18th – only 5 days.

We really need to hammer down on these last bugs.   As you can see many are 
unassigned.  Please cores, help finish the job on Newton and focus on these 
last remaining critical issues.  Help welcome from broader community as well ☺

https://launchpad.net/kolla/+milestone/newton-rc3

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

Re: [openstack-dev] [ironic] [infra] RFC: consolidating and extending Ironic CI jobs

2016-10-13 Thread Jim Rollenhagen

>
> ++
>
> Thanks for bringing this up Dmitry! Might I suggest, if we don't already
> have it, that this would be a good time to track (in a spreadsheet-like
> form), the jobs with the tests covered by each job (or desired but not
> covered yet). I can never remember what we are testing vs not testing. (e.g.
> I thought we had adoption of a running instance.)

The test for adoption is still in review:
https://review.openstack.org/#/c/344975/

// jim

__
OpenStack Development Mailing 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] [ironic] [API] Evolving our REST API

2016-10-13 Thread Devananda van der Veen

Hi all,

We discussed a little at the last summit, and discussed further at the midcycle
[1], about how we might go about remedying some of the frustrations and missing
functionality in our API, and I volunteered to work on it during the Newton 
cycle.

As I looked at all of the feedback we collected and thought about these issues,
I became convinced we could make most, if not all, of the changes with small
steps. Together, they bring a lot of new functionality, but without a complete
API rewrite and the accompanying burden of carrying two versions of the API.

So I have finalized five proposals of substantial changes we can make, that
folks agreed were important to work on, and which I believe we can do within the
microversion framework starting immediately. Four of them will, I think, be
fairly straight forward. The fifth, adding a /tasks/ resource, has the most
challenges, and its own session planned.

I have posted the specs here:

https://review.openstack.org/#/q/status:open+project:openstack/ironic-specs+branch:master+topic:api-evolution

Please give them a read, and let's discuss them in Barcelona [2].

It would be great to have someone from the API working group also peruse these
proposals and validate the direction.

Cheers,
Devananda


[1] https://etherpad.openstack.org/p/ironic-newton-midcycle around L390
[2] https://etherpad.openstack.org/p/ironic-ocata-summit-api-evolution

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

[openstack-dev] [sahara] Meeting at Oct. 13 is cancelled

2016-10-13 Thread Vitaly Gridnev

Hello team,

Since there is no items to discuss during the meeting today, I think that
it is ok to cancel meeting today. See you next week to make a last sync
before the summit at the Barcelona.

-- 
Best Regards,
Vitaly Gridnev,
Project Technical Lead of OpenStack DataProcessing Program (Sahara)
__
OpenStack Development Mailing 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] [OSC] adding quota delete command to osc

2016-10-13 Thread Sergey Belous

Hello everyone.

Now I’m working on the patch to OSC that adds 'quota delete' command (former
neutron quota-delete, cinder quota-delete and nova quota-delete) [1]
In the past the python-*clients used this command for setting the quotas for
resources to default value.
So, some times ago we have a conversation in irc [2] about this "confused"
command and the main solution was (with which I agreed) resetting quotas via
'quota set' command with '--default' argument instead of 'quota delete'
But I tried to imagine how a new 'quota set' (with --default argument) command
will looks like and I’m not enjoying it.
At the first, in the current state the 'quota set' takes a project/class as a
mandatory argument. What will happen if we try to pass a class argument for
'quota set --default'? Actually, there is no classes support for quota delete.
Secondly, I like the idea to pass --compute or/and --volume or/and --network
for reseting the respective quotas, but I don't really understand how to
properly implement it for 'quota set --default'. It looks like we should split
'quota set' command with old 'quota set' behavior and with the new 'quota set
--default'. And I don’t know how it can be represented in the docs and in the
cli usage info.
All of this, I believe, will lead to the fact that the 'quota set' will be very
complicated for users, not obvious and sometimes unpredictable.
I propose to do not add '—default' to the 'quota set' command. I think that the
action that resets quotas to default values needs to be a separate command. But
'quota delete' also is not is not appropriate because delete is really meaning
'remove'.
I propose to call this command 'quota reset' instead of 'quota delete'.
Please tell me what do you think about it.

[1] https://review.openstack.org/#/c/376311/
[2]
http://eavesdrop.openstack.org/irclogs/%23openstack-sdks/%23openstack-sdks.2016-10-12.log.html#t2016-10-12T15:01:58

--
Best Regards,
Sergey Belous

[openstack-dev] [kolla][release] Kolla Newton RC2 available

2016-10-13 Thread Davanum Srinivas

Hello everyone,

A new release candidate for Kolla for the end of the Newton cycle
is available!  You can find the source code tarball at:

https://tarballs.openstack.org/kolla/kolla-3.0.0.0rc2.tar.gz

Alternatively, you can directly test the stable/newton release
branch at:

http://git.openstack.org/cgit/openstack/kolla/log/?h=stable/newton

If you find an issue that could be considered release-critical,
please file it at:

https://bugs.launchpad.net/kolla/+filebug

and tag it *newton-rc-potential* to bring it to the PROJECT release
crew's attention.

Thanks,
Dims (On behalf of the Release team)

-- 
Davanum Srinivas :: https://twitter.com/dims

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

Re: [openstack-dev] [ironic] [infra] RFC: consolidating and extending Ironic CI jobs

2016-10-13 Thread Ruby Loo

On Wed, Oct 12, 2016 at 2:13 PM, Devananda van der Veen <
devananda@gmail.com> wrote:

>
>
> On 10/12/2016 05:01 AM, Dmitry Tantsur wrote:
> > Hi folks!
> >
> > I'd like to propose a plan on how to simultaneously extend the coverage
> of our
> > jobs and reduce their number.
> >
> > Currently, we're running one instance per job. This was reasonable when
> the
> > coreos-based IPA image was the default, but now with tinyipa we can run
> up to 7
> > instances (and actually do it in the grenade job). I suggest we use 6
> fake bm
> > nodes to make a single CI job cover many scenarios.
> >
> > The jobs will be grouped based on driver (pxe_ipmitool and
> agent_ipmitool) to be
> > more in sync with how 3rd party CI does it. A special configuration
> option will
> > be used to enable multi-instance testing to avoid breaking 3rd party CI
> systems
> > that are not ready for it.
> >
> > To ensure coverage, we'll only leave a required number of nodes
> "available", and
> > deploy all instances in parallel.
> >
> > In the end, we'll have these jobs on ironic:
> > gate-tempest-ironic-pxe_ipmitool-tinyipa
> > gate-tempest-ironic-agent_ipmitool-tinyipa
> >
> > Each job will cover the following scenarious:
> > * partition images:
> > ** with local boot:
> > ** 1. msdos partition table and BIOS boot
> > ** 2. GPT partition table and BIOS boot
> > ** 3. GPT partition table and UEFI boot  <*>
> > ** with netboot:
> > ** 4. msdos partition table and BIOS boot <**>
> > * whole disk images:
> > * 5. with msdos partition table embedded and BIOS boot
> > * 6. with GPT partition table embedded and UEFI boot  <*>
> >
> >  <*> - in the future, when we figure our UEFI testing
> >  <**> - we're moving away from defaulting to netboot, hence only one
> scenario
> >
> > I suggest creating the jobs for Newton and Ocata, and starting with
> Xenial right
> > away.
> >
> > Any comments, ideas and suggestions are welcome.
>
> Huge +1 on this from me, as well.
>
> I am also in favor of some of the other suggestions on this thread, namely,
> moving API testing over to functional tests so that those can be run more
> quickly / with less resources / without affecting tempest scenario tests.
>
> I also think we should begin defining additional scenario tests to cover
> things
> we are not covering today  (eg, adopt a running instance), as Vasyl already
> pointed out. But I don't think that conflicts or prevents the changes
> you're
> suggesting, Dmitry.
>
> -Deva
>
>
++

Thanks for bringing this up Dmitry! Might I suggest, if we don't already
have it, that this would be a good time to track (in a spreadsheet-like
form), the jobs with the tests covered by each job (or desired but not
covered yet). I can never remember what we are testing vs not testing.
(e.g. I thought we had adoption of a running instance.)

--ruby
__
OpenStack Development Mailing 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] PTG from the Ops Perspective - a few short notes

2016-10-13 Thread Clint Byrum

Excerpts from Dmitry Tantsur's message of 2016-10-13 10:30:44 +0200:
> On 10/12/2016 08:47 PM, Clint Byrum wrote:
> > Excerpts from Jaesuk Ahn's message of 2016-10-12 15:08:24 +:
> >> It can be cheap if you are in the US. However, for Asia folks, it is not
> >> that cheap considering it is all overseas travel. In addition, all-in-one
> >> event like the current summit makes us much easier to get the travel fund
> >> from the company, since the company only need to send everyone (tech, ops,
> >> business, strategy) to one event. Even as an ops or developers, doing
> >> presentation or a meeting with one or two important company can be very
> >> good excuse to get the travel money.
> >>
> >
> > This is definitely on the list of concerns I heard while the split was
> > being discussed.
> >
> > I think the concern is valid, and we'll have to see how it affects
> > attendance at PTG's and summits.
> >
> > However, I am not so sure the overseas cost is being accurately
> > characterized. Of course, the complications are higher with immigration
> > details, but ultimately hotels around international hub airports are
> > extremely cheap, and flights tend to be quite a bit less expensive and
> > more numerous to these locations. You'll find flights from Narita to
> > LAX for < $500 where as you'd be hard pressed to find Narita to Boston
> > for under $600, and they'll be less convenient, possibly requiring more
> > hotel days.
> 
> The bit about hotels contradicts my whole experience. I've never seen hotels 
> in 
> big busy hubs cheaper than in less popular and crowded cities. Following your 
> logic, hotels e.g. in Paris should be cheaper than ones in e.g. Prague, which 
> I 
> promise you is far from being the case :)
> 

Sorry I communicated that horribly.

The hotels next to LAX, which are _ugly_ and _disgusting_ but perfectly
suitable for a PTG, are much cheaper than say, the ones in DT LA near the
convention center, or in Hollywood, or near Disneyland.

A better comparison than LAX might be Atlanta or Minneapolis, which
are cities that aren't such common end-destinations, but have tons of
flights in and out and generally affordable accommodations.

> >
> > Also worth considering is how cheap the space is for the PTG
> > vs. Summit. Without need for large expo halls, keynote speakers,
> > catered lunch and cocktail hours, we can rent a smaller, less impressive
> > space. That should mean either a cheaper ticket price (if there is one
> > at all) or more sponsored travel to the PTG. Either one of those should
> > help alleviate the concerns about travel budget.
> 
> For upstream developers ticker price was 0. Now it will be > 0, so for 
> companies 
> who send mostly developers, this is a clear budget increase.
> 

The nominal price of the PTG is expected to be something like $25 or
$50. This isn't to cover all the costs, but to ensure that people don't
just sign up "just in case I'm in the area" or anything like that.

__
OpenStack Development Mailing 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] [tripleo] Default the HA scenario to Ceph

2016-10-13 Thread Paul Dardeau

RGW does not use Swift. It’s an optional component of Ceph that can provide a 
Swift compliant API (and also S3). But it does not make use of openstack-swift. 
It’s a completely separate implementation written in c++ [1].

[1] https://github.com/ceph/ceph/blob/master/src/rgw/rgw_rest_swift.cc

> On Oct 13, 2016, at 5:36 AM, Shinobu Kinjo  wrote:
> 
> 
> 
> On Wed, Oct 12, 2016 at 9:59 PM, Giulio Fidente  > wrote:
> On 10/12/2016 02:29 PM, Thiago da Silva wrote:
> 
> 
> On 10/12/2016 07:10 AM, Giulio Fidente wrote:
> hi,
> 
> we introduced support for the deployment of Ceph in the liberty
> release so that it could optionally be used as backend for one or more
> of Cinder, Glance, Nova and more recently Gnocchi.
> 
> We used to deploy Ceph MONs on the controller nodes and Ceph OSDs on
> dedicated ceph-storage nodes so a deployment of OpenStack with Ceph
> would need at least 1 more additional node to host a Ceph OSD.
> 
> In our HA scenario the storage backends are configured as follows:
> 
> Glance -> Swift
> Nova (ephemeral) -> Local
> Cinder (persistent) -> LVM (on controllers)
> Gnocchi -> Swift
> 
> The downside of the above configuration is that Cinder volumes can not
> be replicated across the controller nodes and become unavailable if a
> controller fails, while production environments generally expect
> persistent storage to be highly available. Cinder volumes instead
> could even get lost completely in case of a permanent failure of a
> controller.
> 
> With the Newton release and the composable roles we can now deploy
> Ceph OSDs on the compute nodes, removing the requirement we had for an
> additional node to host a Ceph OSD.
> 
> I would like to ask for some feedback on the possibility of deploying
> Ceph by default in the HA scenario and use it as backend for Cinder.
> 
> Also using Swift as backend for Glance and Gnocchi is enough to cover
> the availability issue for the data, but it also means we're storing
> that data on the controller nodes which might or might not be wanted;
> I don't see a strong reason for defaulting them to Ceph, but it might
> make more sense when Ceph is available; feedback about this would be
> appreciated as well.
> I think it would be important to take into account the recently created
> guiding principles [0]:
> 
> "While the software that OpenStack produces has well defined and
> documented APIs, the primary output of OpenStack is software, not API
> definitions. We expect people who say they run “OpenStack” to run the
> software produced by and in the community, rather than alternative
> implementations of the API."
> 
> In the case of Cinder, I think the situation is a bit muddy as LVM is
> not openstack software, and my limited understanding is that LVM is used
> as a reference implementation, but in the case of Swift, I think RGW
> would be considered an 'alternative implementation of the API'.
> 
> Thiago
> 
> hi Thiago,
> 
> sorry if it wasn't clear in my original message but I did not suggest to 
> replace Swift with Ceph RGW.
> 
> Swift would continue to be deployed by default, not RGW.
> 
> RGW utilizes Swift. So Swift has to be there anyway -;
>  
> 
> The feedback I'm asking for is about storing (or not) the Cinder volumes in 
> Ceph for the HA scenario by default, and also store the Glance images and 
> Gnocchi metrics in Ceph or rather keep that data in Swift.
> -- 
> Giulio Fidente
> GPG KEY: 08D733BA
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe 
> 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
> 
> 
> 
> 
> -- 
> Email:
> shin...@linux.com 
> shin...@redhat.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-dev] [senlin] Proposed changes to senlin core team

2016-10-13 Thread Qiming Teng

As the project keeps growing and maturing, we are happily seeing more
eyes on it, more hands on it. Among the many contributors, the following
two are outstanding:

lvdongbing 
Involved in OpenStack for a few years now. His contribution is not
limited to senlin, but also other projects such as heat, nova, solum
etc. His experience and passion would be a great help to our team.

ref:
http://stackalytics.com/?module=senlin-group=commits_id=dbcocle=all

XueFeng Liu 
Both a user and a developer of senlin. His recent contribution has shown
that he has a good understanding of the project's mission and
implementation. His commits and reviews are all of good quality.

ref:
http://stackalytics.com/?module=senlin-group=commits=all_id=jonnary-liu

With this email, I'm formally inviting these two developers to join
senlin core team. Please cast your votes by replying this email, core
team. Thank you.

Regards,
  Qiming


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

Re: [openstack-dev] [gnocchi] host field information flapping for instance resource-type

2016-10-13 Thread Julien Danjou

On Thu, Oct 13 2016, Jake Yip wrote:

Hi Jake,

It's probably better to keep updating the bug, so I've added my comments
there too. :)

> 1) why is the host information flapping? Are there difference services
> generating this data?

Likely divergence between Nova notifications and Ceilometer polling
through Nova API I'd say. But I didn't check.

> 2) If gnocchi data can be viewable by the user, should we only have host id
> in the resource? (similar to what nova shows to user)

I'm not that familiar with Nova, but if compute host have ids that are
also stored as resource_id in Gnocchi, it's likely better to use them.

-- 
Julien Danjou
// Free Software hacker
// https://julien.danjou.info

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

[openstack-dev] [keystone] keystoneclient.client.v3.Client: extract identity endpoint

2016-10-13 Thread Johannes Grassler


Hello,

I've got an existing keystoneclient.client.v3.Client object with an
authenticated session. Now I'd like to get the identity URL this
object uses for requesting things from Keystone. I want to use that
URL in a trust's endpoint list in order to allow the user the client
is authenticated as to talk to Keystone on the trustor's behalf.

The client is authenticated as a service user and issues a GET to

   GET http://192.168.123.20/identity_admin/v3/OS-TRUST/trusts

when the following code snippet is executed:

  client.trusts.list()

(`client` is my keystoneclient.client.v3.Client instance).

Initially I thought I could use the auth_url from the client's
session object, i.e.

  client.session.auth.auth_url

but that turned out to be a dead end because it's the internal
endpoint:

  http://192.168.123.20/identity/v3

This will be useless for a trust's endpoint URL list if the
trustee (my service user) ends up using

  http://192.168.123.20/identity_admin/v3

to talk to Keystone. I could look up the admin URL from the catalog
like this...

  keystone_service=client.services.list(type='identity')[0]
  client.endpoints.list(service=keystone_service,
interface='admin',
region=client.region_name)

...but that feels rather dirty since it independently looks up the
admin endpoint rather than plucking the identity endpoint from the
keystone client instance. Is there a cleaner way to get that
information directly from the keystoneclient.client.v3.Client
instance?

Cheers,

Johannes

--
Johannes Grassler, Cloud Developer
SUSE Linux GmbH, HRB 21284 (AG Nürnberg)
GF: Felix Imendörffer, Jane Smithard, Graham Norton
Maxfeldstr. 5, 90409 Nürnberg, Germany

__
OpenStack Development Mailing 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] planning the PTG -- lessons from Swift's midcycles

2016-10-13 Thread Rob C

I agree with pretty much everything John's written, especially with regards
to what's required of a host (and accepting that things will have to be
different at the PTG).

For security, although we have a pre-event etherpad to propose topics
nothing is decided until the first day, where we will have an unconference,
vote on things we want to talk about and try to create a schedule that
doesn't clash. We have on a number of occasions conducted our mid-cycle
overlapping with Barbican, where we've been able to participate in each
other's projects, vote on topics, register interest etc. This
cross-polination has been very useful and works well in an unconference
setting.

-Rob

On Wed, Oct 12, 2016 at 6:30 PM, John Dickinson  wrote:

> The Swift team has been doing midcycles for a while now, and as the new
> PTG gets closer, I want to write down our experience with what has worked
> for us. I hope it is beneficial to other teams, too.
> Logistics of the event
>
>- 2 rooms is ideal, but can make due with one larger room
>- move tables and chairs
>- whiteboards/flip charts
>- projector/tv
>- host provides lunch and snacks
>- host provides one evening meal/event
>
> When someone offers to host a midcycle, this is what I ask them to
> provide. The PTG will be slightly different, but the general idea is the
> same. There's a few important things to note here. First, be flexible about
> who's talking about what and when people are working together. The point of
> getting together in person is to facilitate face-to-face communication, so
> be sure that the room logistics don't get in the way by forcing people into
> a certain configuration. Providing lunch and snacks allows the participants
> to not break any tech or social flow in the middle of the day. It keeps
> people together and helps facilitate communication. And the one evening
> event is super helpful to let people relax, have fun, and do something
> interesting away from a computer. In the past we've done everything from
> locked-room challenges and bowling to brewery tours and a boat ride under
> the Golden Gate bridge.
> Only agenda item is "set the agenda"
>
>- dotmocracy
>- too much to do for the people we have to work on it
>- what's the big stuff we need the right people to be together for?
>- schedule one big talk each am and pm
>
> When it comes to the actual flow of the limited time together, there are
> two important things to keep in mind. First, make sure there's time to
> cover all the topics that are of interest to the people in the room.
> Second, make sure the big important stuff gets discussed without requiring
> someone to be in two places at once.
>
> Unfortunately, these two goals are often in conflict. We've solved this in
> the past by starting the midcycle with one and only one agenda item: set
> the agenda. The most successful way we've done this is to ask the room to
> shout out topics to discuss. Every topic gets written down on a piece of
> paper or on a flipboard. When you've got all the topics written down, then
> give everyone a limited number of dot stickers and ask them to vote for
> what they want to talk about by placing one or more dots next to it. The
> trick is that there are more topics to talk about than people who are there
> and each person has less dots than the full schedule of time we have. So,
> for example, if there are 3 days together, that's a total of 6 morning and
> afternoon blocks of time. Give everyone 4 dots, and force them to
> prioritize. This also has the very real visual side effect of emphasizing
> that we are a team and not one person can be a part of everything going on.
> After everyone has put their dots on topics, sort the topics by number of
> dots. In our example, we've got 6 blocks of time, so choose the top six and
> schedule them. This ensures that the big stuff can get scheduled, the
> little stuff can fill in the gaps, and people can know when to be available
> for conversations that are important to them.
>
> Imagine than you've got a glass mason jar, and you need to fill it up with
> stuff. You've got big rocks, small rocks, sand, and water. If you fill it
> up with water first, the water will spill out when you add anything else.
> But if you add the big things first, then you can fit more in. The big
> rocks go first, then small rocks fill up the spaces, then sand fills up the
> cracks, then the water can seem in the tiny air gaps. It's the same way
> with prioritizing the in-person meetings. Schedule the big stuff, then fill
> in any gaps with the small stuff.
> Social dynamics during the week
>
>- you won't be able to participate in everything. that's ok
>- there will be several conversations going on at one time. be
>considerate and flexible
>- don't wait for someone to start a conversation. start it yourself.
>this is very important!
>
> There's a lot going on at in-person meetings. It's ok to not

Re: [openstack-dev] [all][tc] Exposing project team's metadata in README files

2016-10-13 Thread Qiming Teng

project-navigator? http://www.openstack.org/software/

It is often misinterpreted as: OpenStack has 6 core services which are
all mandatory (because they are *core* services) plus 13 optional
services that can be selectively installed.

I tried hard to find out how the lists are generated, but I failed.
There are at least the following projects which are neither *core* nor
*optional* services:

cloudkitty
dragonflow
freezer
karbor
kolla
kuryr
mistral
monasca
searchlight
senlin
solum
tacker
vitrage
watcher

Looks like this is something causing some confusions. Should/can we fix
that?

Regards,
  Qiming


On Wed, Oct 12, 2016 at 02:43:45PM -0700, Mike Perez wrote:
> On 14:50 Oct 12, Flavio Percoco wrote:
> > Greetings,
> > 
> > One of the common complains about the existing project organization in the 
> > big
> > tent is that it's difficult to wrap our heads around the many projects there
> > are, their current state (in/out the big tent), their tags, etc.
> > 
> > This information is available on the governance website[0]. Each official
> > project team has a page there containing the information related to the
> > deliverables managed by that team. Unfortunately, I don't think this page is
> > checked often enough and I believe it's not known by everyone.
> 
> Besides the governance site, there is also the project navigator [1] which is
> a more friendly landing page on projects and their tags. Although it does not
> today capture separate deliverables.
> 
> Assuming the README files aren't being manually updated, I don't have a 
> problem
> with this idea.
> 
> [1] - https://www.openstack.org/software/project-navigator/
> 
> -- 
> Mike Perez


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

Re: [openstack-dev] [tripleo] PTG space request

2016-10-13 Thread Thierry Carrez

Doug Hellmann wrote:
> Excerpts from Eoghan Glynn's message of 2016-10-13 05:45:59 -0400:
>>> ** The PTG week is split between horizontal team meetings
>>> (Monday/Tuesday) and vertical team meetings (Wednesday-Friday). As we
>>> have more vertical teams than horizontal teams (and the space is the
>>> same size), we /should/ have more flexibility to add horizontal stuff.
>>
>> This split in the PTG week raises an obvious question ...
>>
>> Do we expect the horizontal folks to skip town by mid-week, or to hang
>> around without a home-room in order to talk to the vertical folks who
>> put the "project" in "cross-project"?
>>
>> Conversely, do we expect the vertical teams to turn up on the Monday in
>> order to collaborate with the horizontal teams? (similarly without a
>> project room for the first 2 days?)
>>
> We expect the "horizontal folks" and "vertical teams" to be the same
> people, focusing on different things on different days of the week. We
> *hope* to enable more contributions to horizontal teams as a result.

Yes. We obviously can't force anyone to stay for the whole week when
their main focus is on a specific team. But at least the new format
makes it *possible* for people to get involved in an horizontal effort
(and for members of cross-project efforts to stay around to assist
specific teams).

-- 
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][tc] Exposing project team's metadata in README files


On 13/10/16 13:06 +0200, Flavio Percoco wrote:

On 12/10/16 11:01 -0400, Doug Hellmann wrote:

Excerpts from Flavio Percoco's message of 2016-10-12 14:50:03 +0200:

Greetings,

One of the common complains about the existing project organization in the big
tent is that it's difficult to wrap our heads around the many projects there
are, their current state (in/out the big tent), their tags, etc.

This information is available on the governance website[0]. Each official
project team has a page there containing the information related to the
deliverables managed by that team. Unfortunately, I don't think this page is
checked often enough and I believe it's not known by everyone.

In the hope that we can make this information clearer to people browsing the
many repos (most likely on github), I'd like to propose that we include the
information of each deliverable in the readme file. This information would be
rendered along with the rest of the readme (at least on Github, which might not
be our main repo but it's the place most humans go to to check our projects).

Rather than duplicating this information, I'd like to find a way to just
"include it" in the Readme file. As far as showing the "official" badge goes, I
believe it'd be quite simple. We can do it the same way CI tags are exposed when
using travis (just include an image). As for the rest of the tags, it might
require some extra hacking.

So, before I start digging more into this, I wanted to get other opinions/ideas
on this topic and how we can make this information more evident to the rest of
the community (and people not as familiar with our processes as some of us are).

Thanks in advance,
Flavio

[0] http://governance.openstack.org/reference/projects/index.html



Is your proposal that a tag like release:cycle-with-milestones would
result in a badge being added when the README.rst is rendered on
github.com? Would that work for git.openstack.org, too?


I don't think it'd work for git.openstack.org because it doesn't render the
README's[0] like github does. One thing I'd like to avoid is for this
information to result in new changes to the README file everytime the tags are
updated because I'd like for this information to not be duplicated and to make
it clear that this information is not meant to be updated manually.

Here's[1] an example of what it would look like (or kinda).

[0] http://git.openstack.org/cgit/openstack/glance/tree/README.rst
[1] https://github.com/celery/kombu/blob/master/README.rst


Just wanted to add one more thing. This badges can be generated automatically
and there's a small project that does this already[0][1]. We can host it or use
it. We do need, however, a small API that will generate the list of "badges".

[0] http://shields.io/
[1] https://img.shields.io/badge/release-cycle--with--milestones-blue.svg

Flavio




I agree that the governance site is not the best place to put the
info to make it discoverable. Do users look first at the source
repository, or at some other documentation?


The feedback* I've gotten is that users normally look at repos first and they go
from there to docs (which are normally linked in the README file).

* Neither based on a survey nor on any empirical research. This is based on
hallway talks.

Flavio

--
@flaper87
Flavio Percoco




--
@flaper87
Flavio Percoco


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] [new][winstackers] os-win 1.2.1 release (newton)

We are pleased to announce the release of:

os-win 1.2.1: Windows / Hyper-V library for OpenStack projects.

This release is part of the newton stable release series.

The source is available from:

http://git.openstack.org/cgit/openstack/os-win

Download the package from:

https://pypi.python.org/pypi/os-win

Please report issues through launchpad:

http://bugs.launchpad.net/os-win

For more details, please see below.

Changes in os-win 1.2.0..1.2.1
--

83aa222 Ensure GetLastError gets called in the right thread
67c9568 Retry on opening named pipe failures
d94247a Handle sporadic iSCSI initiator errors
031f349 Fix clustered VM migration status polling
1fd8eaf VM Importing/Exporting
8b0f51c Non-clustered VM live migration fix
a78531b Fix clustered vm live migration
5f2925b Add method for retrieving vm config root dir
e23bb91 vmutils: honor host argument
7c9bc96 Avoid using diskpart for disk rescans
5414e89 Ensure Win32 API calls do not block
fa431d4 Update .gitreview for stable/newton


Diffstat (except docs and test files)
-

.gitreview |   1 +
os_win/_utils.py   |  38 ++-
os_win/constants.py|  11 +
os_win/exceptions.py   |  15 ++
.../utils/storage/initiator/test_iscsi_utils.py| 128 ++
os_win/utils/compute/_clusapi_utils.py | 197 +++
os_win/utils/compute/clusterutils.py   |  97 +++-
os_win/utils/compute/livemigrationutils.py |  56 ++---
os_win/utils/compute/migrationutils.py |  80 ++
os_win/utils/compute/vmutils.py|  61 -
os_win/utils/io/ioutils.py |   7 +-
os_win/utils/pathutils.py  |   3 +
os_win/utils/storage/diskutils.py  |  14 +-
os_win/utils/storage/initiator/fc_utils.py |   2 +
os_win/utils/storage/initiator/iscsi_utils.py  |  78 +++---
.../utils/storage/initiator/iscsidsc_structures.py |   2 +
os_win/utils/win32utils.py |  15 +-
os_win/utilsfactory.py |  16 +-
29 files changed, 1494 insertions(+), 226 deletions(-)




__
OpenStack Development Mailing 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] [tripleo] PTG space request

2016-10-13 Thread Doug Hellmann

Excerpts from Eoghan Glynn's message of 2016-10-13 05:45:59 -0400:
> 
> > >>> I would like to request for some space dedicated to TripleO project
> > >>> for the first OpenStack PTG.
> > >>>
> > >>> https://www.openstack.org/ptg/
> > >>>
> > >>> The event will happen in February 2017 during the next PTG in Atlanta.
> > >>> Any feedback is welcome,
> > >>
> > >> Just a quick note: as you can imagine we have finite space at the event,
> > >> and the OpenStack Foundation wants to give priority to teams which have
> > >> a diverse affiliation (or which are not tagged "single-vendor").
> > >> Depending on which teams decide to take advantage of the event and which
> > >> don't, we may or may not be able to offer space to single-vendor
> > >> projects -- and TripleO is currently tagged single-vendor.
> > > 
> > > Thanks for the feedback Thierry, I can understand the need to somehow keep
> > > PTG space requirements bounded, but I would agree with Emilien and Eoghan
> > > that perhaps the single-vendor tag is too coarse a metric with which to
> > > judge all projects (it really doesn't capture cross-project collaboration
> > > at all IMO).
> > > 
> > > One of the main goals of TripleO is using OpenStack projects where
> > > possible, and as such we have a very broad range of cross project
> > > collaboration happening, and clearly the PTG is the ideal forum for such
> > > discussions.
> > 
> > Indeed, I totally agree.
> > 
> > While at this stage we can't *guarantee* space for TripleO, I really
> > hope that we'll be able to provide space. One interesting factor is that
> > there should be less tension for space in the "horizontal" part of the
> > week than in the "vertical" part of the week**. TripleO's cross-cutting
> > nature makes it a good fit for the "horizontal" segment, so I'm hopeful
> > we can make that work. We should know very soon, once we collect the
> > results of the PTL survey. Stay tuned!
> > 
> > ** The PTG week is split between horizontal team meetings
> > (Monday/Tuesday) and vertical team meetings (Wednesday-Friday). As we
> > have more vertical teams than horizontal teams (and the space is the
> > same size), we /should/ have more flexibility to add horizontal stuff.
> 
> This split in the PTG week raises an obvious question ...
> 
> Do we expect the horizontal folks to skip town by mid-week, or to hang
> around without a home-room in order to talk to the vertical folks who
> put the "project" in "cross-project"?
> 
> Conversely, do we expect the vertical teams to turn up on the Monday in
> order to collaborate with the horizontal teams? (similarly without a
> project room for the first 2 days?)
> 
> Cheers,
> Eoghan
> 

We expect the "horizontal folks" and "vertical teams" to be the same
people, focusing on different things on different days of the week. We
*hope* to enable more contributions to horizontal teams as a result.

Doug

__
OpenStack Development Mailing 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][tc] Exposing project team's metadata in README files


On 12/10/16 15:13 +, Hayes, Graham wrote:

On 12/10/2016 16:08, Doug Hellmann wrote:

Excerpts from Flavio Percoco's message of 2016-10-12 14:50:03 +0200:

Greetings,

One of the common complains about the existing project organization in the big
tent is that it's difficult to wrap our heads around the many projects there
are, their current state (in/out the big tent), their tags, etc.

This information is available on the governance website[0]. Each official
project team has a page there containing the information related to the
deliverables managed by that team. Unfortunately, I don't think this page is
checked often enough and I believe it's not known by everyone.

In the hope that we can make this information clearer to people browsing the
many repos (most likely on github), I'd like to propose that we include the
information of each deliverable in the readme file. This information would be
rendered along with the rest of the readme (at least on Github, which might not
be our main repo but it's the place most humans go to to check our projects).

Rather than duplicating this information, I'd like to find a way to just
"include it" in the Readme file. As far as showing the "official" badge goes, I
believe it'd be quite simple. We can do it the same way CI tags are exposed when
using travis (just include an image). As for the rest of the tags, it might
require some extra hacking.

So, before I start digging more into this, I wanted to get other opinions/ideas
on this topic and how we can make this information more evident to the rest of
the community (and people not as familiar with our processes as some of us are).

Thanks in advance,
Flavio

[0] http://governance.openstack.org/reference/projects/index.html



Is your proposal that a tag like release:cycle-with-milestones would
result in a badge being added when the README.rst is rendered on
github.com? Would that work for git.openstack.org, too?

I agree that the governance site is not the best place to put the
info to make it discoverable. Do users look first at the source
repository, or at some other documentation?

Doug


I like this idea.

I know when I am looking at software, I look at the source repo
initially.

We could do it in the readme, and maybe re-use it in the docs as well?


Yup! Re-using this in the docs is definitely part of the plan.


I would be willing to dig in and help if needed.


Might take your word on this :D

Flavio

--
@flaper87
Flavio Percoco


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

Re: [openstack-dev] [all][tc] Exposing project team's metadata in README files


On 12/10/16 14:43 -0700, Mike Perez wrote:

On 14:50 Oct 12, Flavio Percoco wrote:

Greetings,

One of the common complains about the existing project organization in the big
tent is that it's difficult to wrap our heads around the many projects there
are, their current state (in/out the big tent), their tags, etc.

This information is available on the governance website[0]. Each official
project team has a page there containing the information related to the
deliverables managed by that team. Unfortunately, I don't think this page is
checked often enough and I believe it's not known by everyone.


Besides the governance site, there is also the project navigator [1] which is
a more friendly landing page on projects and their tags. Although it does not
today capture separate deliverables.

Assuming the README files aren't being manually updated, I don't have a problem
with this idea.


Yeah, not manually updated and I'd go as far as saying that I'd prefer the info
to not be duplicated. That is, I'd prefer to not have a bot copying from the
governance repo to the project's README but rather have this info populated at
render time.

Flavio

--
@flaper87
Flavio Percoco


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

Re: [openstack-dev] [all][tc] Exposing project team's metadata in README files


On 12/10/16 11:01 -0400, Doug Hellmann wrote:

Excerpts from Flavio Percoco's message of 2016-10-12 14:50:03 +0200:

Greetings,

One of the common complains about the existing project organization in the big
tent is that it's difficult to wrap our heads around the many projects there
are, their current state (in/out the big tent), their tags, etc.

This information is available on the governance website[0]. Each official
project team has a page there containing the information related to the
deliverables managed by that team. Unfortunately, I don't think this page is
checked often enough and I believe it's not known by everyone.

In the hope that we can make this information clearer to people browsing the
many repos (most likely on github), I'd like to propose that we include the
information of each deliverable in the readme file. This information would be
rendered along with the rest of the readme (at least on Github, which might not
be our main repo but it's the place most humans go to to check our projects).

Rather than duplicating this information, I'd like to find a way to just
"include it" in the Readme file. As far as showing the "official" badge goes, I
believe it'd be quite simple. We can do it the same way CI tags are exposed when
using travis (just include an image). As for the rest of the tags, it might
require some extra hacking.

So, before I start digging more into this, I wanted to get other opinions/ideas
on this topic and how we can make this information more evident to the rest of
the community (and people not as familiar with our processes as some of us are).

Thanks in advance,
Flavio

[0] http://governance.openstack.org/reference/projects/index.html



Is your proposal that a tag like release:cycle-with-milestones would
result in a badge being added when the README.rst is rendered on
github.com? Would that work for git.openstack.org, too?


I don't think it'd work for git.openstack.org because it doesn't render the
README's[0] like github does. One thing I'd like to avoid is for this
information to result in new changes to the README file everytime the tags are
updated because I'd like for this information to not be duplicated and to make
it clear that this information is not meant to be updated manually.

Here's[1] an example of what it would look like (or kinda).

[0] http://git.openstack.org/cgit/openstack/glance/tree/README.rst
[1] https://github.com/celery/kombu/blob/master/README.rst



I agree that the governance site is not the best place to put the
info to make it discoverable. Do users look first at the source
repository, or at some other documentation?


The feedback* I've gotten is that users normally look at repos first and they go
from there to docs (which are normally linked in the README file).

* Neither based on a survey nor on any empirical research. This is based on
 hallway talks.

Flavio

--
@flaper87
Flavio Percoco


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] [tripleo] PTG space request

2016-10-13 Thread Hayes, Graham

On 12/10/2016 10:31, Thierry Carrez wrote:
> Emilien Macchi wrote:
>> I would like to request for some space dedicated to TripleO project
>> for the first OpenStack PTG.
>>
>> https://www.openstack.org/ptg/
>>
>> The event will happen in February 2017 during the next PTG in Atlanta.
>> Any feedback is welcome,
>
> Just a quick note: as you can imagine we have finite space at the event,
> and the OpenStack Foundation wants to give priority to teams which have
> a diverse affiliation (or which are not tagged "single-vendor").
> Depending on which teams decide to take advantage of the event and which
> don't, we may or may not be able to offer space to single-vendor
> projects -- and TripleO is currently tagged single-vendor.
>
> The rationale is, the more organizations are involved in a given project
> team, the more value there is to offer common meeting space to that team
> for them to sync on priorities and get stuff done. If more than 90% of
> contributions / reviews / core reviewers come from a single
> organization, there is less coordination needs and less value in having
> all those people from a single org to travel to a distant place to have
> a team meeting. And as far as recruitment of new team members go (to
> increase that diversity), the OpenStack Summit will be a better venue to
> do that.
>
> I hope we'll be able to accommodate you, though. And in all cases
> TripleO people are more than welcome to join the event to coordinate
> with other teams. It's just not 100% sure we'll be able to give you a
> dedicated room for multiple days. We should know better in a week or so,
> once we get a good idea of who plans to meet at the event and who doesn't.
>

For me, this is somewhat concerning. When the PTG was proposed, It was
suggested as a replacement for Mid Cycles, with a design summit at the
right point.

I thought it was a good idea, but I never thought that we would have a
situation where there was a possibility to turn away projects that:

a) Traditionally had mid cycles
b) Was an active user of design summit space.

What I am getting from this is a very real chance that some projects
will now have 3 things in a 6 month cycle they need to do.

PTG - to do cross project work (If I had to fly transatlantic for 2
days of cross project, with no room for my project after that, I would
not be happy)

Mid Cycle / Self Hosted design summit - as we do not have space anymore
at the traditional summit, or the PTG

Traditional Summit - close the loop with users / Ops / employer tasks.

If I proposed this I might get 2 of 3, and I know what I would be
dropping (hint - its the one with 24 hours of traveling for maybe 16
hours of face to face).

I foresee quite a lot of cross project disengagement from smaller teams
if this is how we are going to proceed.

We are also getting back to the old catch-22 issue we had in the
incubation / integration days - its harder to get diversity of
contributors up, if a project are not at the PTG, but the project
won't be guaranteed space, due to the lack of diversity.

__
OpenStack Development Mailing 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] [tripleo] Default the HA scenario to Ceph

2016-10-13 Thread Shinobu Kinjo

On Wed, Oct 12, 2016 at 9:59 PM, Giulio Fidente  wrote:

> On 10/12/2016 02:29 PM, Thiago da Silva wrote:
>
>>
>>
>> On 10/12/2016 07:10 AM, Giulio Fidente wrote:
>>
>>> hi,
>>>
>>> we introduced support for the deployment of Ceph in the liberty
>>> release so that it could optionally be used as backend for one or more
>>> of Cinder, Glance, Nova and more recently Gnocchi.
>>>
>>> We used to deploy Ceph MONs on the controller nodes and Ceph OSDs on
>>> dedicated ceph-storage nodes so a deployment of OpenStack with Ceph
>>> would need at least 1 more additional node to host a Ceph OSD.
>>>
>>> In our HA scenario the storage backends are configured as follows:
>>>
>>> Glance -> Swift
>>> Nova (ephemeral) -> Local
>>> Cinder (persistent) -> LVM (on controllers)
>>> Gnocchi -> Swift
>>>
>>> The downside of the above configuration is that Cinder volumes can not
>>> be replicated across the controller nodes and become unavailable if a
>>> controller fails, while production environments generally expect
>>> persistent storage to be highly available. Cinder volumes instead
>>> could even get lost completely in case of a permanent failure of a
>>> controller.
>>>
>>> With the Newton release and the composable roles we can now deploy
>>> Ceph OSDs on the compute nodes, removing the requirement we had for an
>>> additional node to host a Ceph OSD.
>>>
>>> I would like to ask for some feedback on the possibility of deploying
>>> Ceph by default in the HA scenario and use it as backend for Cinder.
>>>
>>> Also using Swift as backend for Glance and Gnocchi is enough to cover
>>> the availability issue for the data, but it also means we're storing
>>> that data on the controller nodes which might or might not be wanted;
>>> I don't see a strong reason for defaulting them to Ceph, but it might
>>> make more sense when Ceph is available; feedback about this would be
>>> appreciated as well.
>>>
>> I think it would be important to take into account the recently created
>> guiding principles [0]:
>>
>> "While the software that OpenStack produces has well defined and
>> documented APIs, the primary output of OpenStack is software, not API
>> definitions. We expect people who say they run “OpenStack” to run the
>> software produced by and in the community, rather than alternative
>> implementations of the API."
>>
>> In the case of Cinder, I think the situation is a bit muddy as LVM is
>> not openstack software, and my limited understanding is that LVM is used
>> as a reference implementation, but in the case of Swift, I think RGW
>> would be considered an 'alternative implementation of the API'.
>>
>> Thiago
>>
>
> hi Thiago,
>
> sorry if it wasn't clear in my original message but I did not suggest to
> replace Swift with Ceph RGW.
>
> Swift would continue to be deployed by default, not RGW.
>

RGW utilizes Swift. So Swift has to be there anyway -;


>
> The feedback I'm asking for is about storing (or not) the Cinder volumes
> in Ceph for the HA scenario by default, and also store the Glance images
> and Gnocchi metrics in Ceph or rather keep that data in Swift.
> --
> Giulio Fidente
> GPG KEY: 08D733BA
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Email:
shin...@linux.com
shin...@redhat.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] [mistral] Who's interested in attending PTG?

2016-10-13 Thread Deja, Dawid

On Thu, 2016-10-06 at 19:21 +0700, Renat Akhmerov wrote:
Hi,

As you likely know, the summit format will change after Barcelona. There will 
be two events now: PTG (Project Team Gathering) for design sessions and 
OpenStack Summit which is more customer/promotion oriented . The first will 
take place in Atlanta on Feb 20-24, 2017 and the second one in May 2017 in 
Boston. More about that at [1]. Please read it.


Hi,

I'd like to go to the PTG in Atlanta but I can't tell right now if I'll have 
budget approved for this event.

Thanks,
Dawid Deja

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

[openstack-dev] [new][openstackclient] os-client-config 1.22.0 release (ocata)