Re: [openstack-dev] [stable/ocata] [nova] [devstack multi-node] nova-conductor complaining about "No cell mapping found for cell0"

[Prashant Shetty]

Hi Matt,
I have addressed your comment on patch and uploaded new patch to master
branch.
Could you please check https://review.openstack.org/#/c/437381

Thanks,
Prashant

On Thu, Feb 23, 2017 at 2:34 PM, Prashant Shetty <
prashantshetty1...@gmail.com> wrote:

> Thanks Matt, I found out there was issue in my nova.conf on controller.
> [placement] section was missing on controller nova.conf.
> Looks like devstack ignores configuring nova.conf if n-cpu is not running.
>
> I have filed https://bugs.launchpad.net/devstack/+bug/1667219 and posted
> fix https://review.openstack.org/#/c/437274/.
> Let me know what you think.
>
> Thanks,
> Prashant
>
> On Wed, Feb 22, 2017 at 8:19 PM, Matt Riedemann 
> wrote:
>
>> On 2/22/2017 9:33 AM, Prashant Shetty wrote:
>>
>>> Thanks Matt.
>>>
>>> Here are the steps I have performed, I dont see any error related to
>>> cell0 now but n-cond still not able to detect computes after discover as
>>> well :(.
>>>
>>> Do we need any cell setting on nova-compute nodes as well?.
>>>
>>> vmware@cntr11:~/nsbu_cqe_openstack/devstack$ nova service-list
>>> ++--+---+--+
>>> -+---++-+
>>> | Id | Binary   | Host  | Zone | Status  | State |
>>> Updated_at | Disabled Reason |
>>> ++--+---+--+
>>> -+---++-+
>>> | 7  | nova-conductor   | cntr11| internal | enabled | up|
>>> 2017-02-22T14:23:34.00 | -   |
>>> | 9  | nova-scheduler   | cntr11| internal | enabled | up|
>>> 2017-02-22T14:23:28.00 | -   |
>>> | 10 | nova-consoleauth | cntr11| internal | enabled | up|
>>> 2017-02-22T14:23:33.00 | -   |
>>> | 11 | nova-compute | esx-ubuntu-02 | nova | enabled | up|
>>> 2017-02-22T14:23:35.00 | -   |
>>> | 12 | nova-compute | esx-ubuntu-03 | nova | enabled | up|
>>> 2017-02-22T14:23:35.00 | -   |
>>> | 13 | nova-compute | esx-ubuntu-01 | nova | enabled | up|
>>> 2017-02-22T14:23:28.00 | -   |
>>> | 14 | nova-compute | kvm-3 | nova | enabled | up|
>>> 2017-02-22T14:23:28.00 | -   |
>>> | 15 | nova-compute | kvm-1 | nova | enabled | up|
>>> 2017-02-22T14:23:32.00 | -   |
>>> | 16 | nova-compute | kvm-2 | nova | enabled | up|
>>> 2017-02-22T14:23:32.00 | -   |
>>> ++--+---+--+
>>> -+---++-+
>>> vmware@cntr11:~/nsbu_cqe_openstack/devstack$
>>> vmware@cntr11:~/nsbu_cqe_openstack/devstack$ nova-manage cell_v2
>>> map_cell0 --database_connection
>>> mysql+pymysql://root:vmware@127.0.0.1/nova?charset=utf8
>>> 
>>> vmware@cntr11:~/nsbu_cqe_openstack/devstack$ nova-manage cell_v2
>>> simple_cell_setup --transport-url
>>> rabbit://stackrabbit:vmware@60.0.24.49:5672/
>>> 
>>>
>>> Cell0 is already setup
>>> vmware@cntr11:~/nsbu_cqe_openstack/devstack$ nova-manage cell_v2
>>> list_cells
>>> +---+--+
>>> |  Name | UUID |
>>> +---+--+
>>> |  None | ea6bec24-058a-4ba2-8d21-57d34c01802c |
>>> | cell0 | ---- |
>>> +---+--+
>>> vmware@cntr11:~/nsbu_cqe_openstack/devstack$ nova-manage cell_v2
>>> discover_hosts --verbose
>>> Found 2 cell mappings.
>>> Skipping cell0 since it does not contain hosts.
>>> Getting compute nodes from cell: ea6bec24-058a-4ba2-8d21-57d34c01802c
>>> Found 6 computes in cell: ea6bec24-058a-4ba2-8d21-57d34c01802c
>>> Checking host mapping for compute host 'kvm-3':
>>> a4b175d6-f5cc-45a8-9cf2-45726293b5c5
>>> Checking host mapping for compute host 'esx-ubuntu-02':
>>> 70281329-590c-4cb7-8839-fd84160345b7
>>> Checking host mapping for compute host 'esx-ubuntu-03':
>>> 04ea75a2-789e-483e-8d0e-4b0f79e012dc
>>> Checking host mapping for compute host 'kvm-1':
>>> dfabae3c-4ea9-4e8f-a496-8880dd9e89d9
>>> Checking host mapping for compute host 'kvm-2':
>>> d1cb30f5-822c-4c18-81fb-921ca676b834
>>> Checking host mapping for compute host 'esx-ubuntu-01':
>>> d00f8f16-af6b-437d-8136-bc744eb2472f
>>> vmware@cntr11:~/nsbu_cqe_openstack/devstack$
>>>
>>> ​n-sch:
>>> 2017-02-22 14:26:51.467 INFO nova.scheduler.host_manager
>>> [req-56d1cefb-1dfb-481d-aaff-b7b6e05f83f0 None None] Successfully synced
>>> instances from host 'kvm-2'.
>>> 2017-02-22 14:26:51.608 INFO nova.scheduler.host_manager
>>> [req-690b1a18-a709-49b2-bfad-2a6a75a3bee2 None None] Successfully synced
>>> instances from host 'kvm-3'.
>>> 2017-02-22 14:27:23.366 INFO 

Re: [openstack-dev] [Neutron] Alternative approaches for L3 HA

[Adam Spiers]

Anil Venkata  wrote:
> On Thu, Feb 23, 2017 at 12:10 AM, Miguel Angel Ajo Pelayo 
>  wrote:
> > On Wed, Feb 22, 2017 at 11:28 AM, Adam Spiers  wrote:
> >> With help from others, I have started an analysis of some of the
> >> different approaches to L3 HA:
> >>
> >> https://ethercalc.openstack.org/Pike-Neutron-L3-HA
> >>
> >> (although I take responsibility for all mistakes ;-)
> 
> Did you test with this patch https://review.openstack.org/#/c/255237/  ? It
> was merged in newton cycle.
> With this patch, HA+L2pop doesn't depend on control plane during fail over,
> hence failover should be faster(same as without l2pop).

Thanks Anil!  I've updated the spreadsheet to take this into account.

> >> It would be great if someone from RH or RDO could provide information
> >> on how this RDO (and/or RH OSP?) solution based on Pacemaker +
> >> keepalived works - if so, I volunteer to:
> >>
> >>   - help populate column E of the above sheet so that we can
> >> understand if there are still remaining gaps in the solution, and
> >>
> >>   - document it (e.g. in the HA guide).  Even if this only ended up
> >> being considered as a shorter-term solution, I think it's still
> >> worth documenting so that it's another option available to
> >> everyone.
> >>
> >> Thanks!
> 
> > I have updated the spreadsheet.

Thanks a lot Miguel and everyone else who contributed to the
spreadsheet so far!

After a very productive meeting this morning at the PTG, I think it is
quite close to completion now, and I am already working with the docs
team on moving it into official documentation, either in the HA Guide
(which I am trying to help maintain) or the Networking Guide.  I don't
have strong opinions on where it should live - if anyone does then
please let us know now.

I also attempted to write up a mini-report summarising this morning's
meeting for future reference; it's (currently) at line 279 onwards of:

https://etherpad.openstack.org/p/neutron-ptg-pike-final

but I'll reproduce it here for convenience.

The conclusion, at least as I understand it, is as follows:

- The l3_ha solution is already working pretty well in many
  deployments, especially when coupled with a few extra benefits from
  Pacemaker (although
  https://bugs.launchpad.net/neutron/+bugs?field.tag=l3-ha might
  suggest otherwise ...)

- Some more refinements to this solution could be made to reduce the
  remaining corner cases where failures are not handled well.

- I (and hopefully others) will work towards documenting this solution
  in more detail.

- In the mean time, Ann Taraday and anyone else interested may
  continue out-of-tree experiments with different architectures such
  as tooz/etcd.  It is expected that these would be invasive changes,
  possibly taking at least 1-2 release cycles to stabilise, but they
  might still be worth it.

- If a PoC is submitted for review and looks promising, we can decide
  whether it makes sense to aim to replace the existing keepalived
  solution, or instead offer it as an alternative by introducing
  pluggable L3 drivers.  However, adding a driver abstraction layer
  would also be costly and expand the test matrix, at a time where
  developer resources are scarce. So there would need to be a
  compelling reason to do this.

I hope that's a reasonably accurate representation of the outcome from
this morning - obviously feel free to submit comments if I missed or
mistook anything.  Thanks for a great meeting!

__
OpenStack Development Mailing 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-docs] [docs] [arch-guide] Architecture Design Guide plan for Pike

[Darren Chan]

Hi everyone,

Just an update on the draft Architecture Design Guide.

For Ocata, we reorganized some migrated content from the current Arch 
Guide and Ops Guide, and updated the compute and networking sections in 
the Design chapter. It is currently published at 
http://docs.openstack.org/draft/arch-design-draft/.


As discussed at the PTG (1), our plan for Pike:

1. Writing the Design chapter is the highest priority.  The goal to
   complete the networking and storage sections first, then work on the
   remaining sections and chapters.
2. Create a bug report for each task, describing what information
   should be covered to complete the task.
3. Develop a use case template which will be applied to all
   architecture use cases in the guide.
4. Remove the architecture content from the Ops Guide since it has been
   migrated and integrated into the draft Arch Guide.
5. Remove the current Arch Guide and publish the draft Arch Guide to
   docs.openstack.org.

Our plans are also documented in the spec: 
https://review.openstack.org/#/c/436747/. I would really appreciate some 
reviews and comments.


Overhauling the guide has been ongoing for a few release cycles due to 
lack of contributors. We would like to make good progress for Pike, so 
if you are interested in getting involved, please reach out to me or Ben 
Silverman.


Thanks!

Darren

 (1) https://etherpad.openstack.org/p/docs-i18n-ptg-pike

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

[openstack-dev] [neutron] Ocata postmortem

[Armando M.]

Hi folks,

Now that Ocata is officially releases, I'd like to get a moment of your
time to double check our postmortem document [1], and provide as much
information as you can on the state of work assigned to you or work you
have been involved with during the Ocata timeframe.

Your old PTL and consumers/watchers of our project will be immensely
grateful.

Cheers,
Armando

[1] https://review.openstack.org/#/c/425990/
__
OpenStack Development Mailing 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][cinder] Schedule Instances according to Local disk based Volume?

[Zhenyu Zheng]

BTW, I think this can be done using new placement service, using the custom
resource provider? correct?

On Fri, Feb 24, 2017 at 10:18 AM, Zhenyu Zheng 
wrote:

> Matt,
>
> Thanks for the information, I will check that; But still I think the user
> demand here is to use local disk from
> compute node as block device, as the data can be remained if the old vm
> got deleted, and we can start a
> new one with the data and having the performance they wanted.
>
> Kevin Zheng
>
> On Fri, Feb 24, 2017 at 4:06 AM, Matt Riedemann <
> mrie...@linux.vnet.ibm.com> wrote:
>
>> On 9/26/2016 9:21 PM, Zhenyu Zheng wrote:
>>
>>> Hi,
>>>
>>> Thanks for the reply, actually approach one is not we are looking for,
>>> our demands is to attach the real physical volume from compute node to
>>> VMs,
>>> by this way we can achieve the performance we need for usecases such as
>>> big data, this can be done by cinder using BlockDeviceDriver, it is quite
>>> different from the approach one you mentioned. The only problem now is
>>> that we cannot practially ensure the compute resource located on the same
>>> host with the volume, as Matt mentioned above, currently we have to
>>> arrange 1:1 AZ in Cinder and Nova to do this and it is not practical in
>>> commercial
>>> deployments.
>>>
>>> Thanks.
>>>
>>>
>> Kevin,
>>
>> Is the issue because you can't use ephemeral local disks (it must be a
>> persistent boot from volume)?
>>
>> Have you looked at using the LVM image backend for local storage in Nova?
>> I thought cfriesen said once that windriver is doing high performance
>> config using local LVM in nova.
>>
>> --
>>
>> Thanks,
>>
>> Matt Riedemann
>>
>>
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> 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][cinder] Schedule Instances according to Local disk based Volume?

[Zhenyu Zheng]

Matt,

Thanks for the information, I will check that; But still I think the user
demand here is to use local disk from
compute node as block device, as the data can be remained if the old vm got
deleted, and we can start a
new one with the data and having the performance they wanted.

Kevin Zheng

On Fri, Feb 24, 2017 at 4:06 AM, Matt Riedemann 
wrote:

> On 9/26/2016 9:21 PM, Zhenyu Zheng wrote:
>
>> Hi,
>>
>> Thanks for the reply, actually approach one is not we are looking for,
>> our demands is to attach the real physical volume from compute node to
>> VMs,
>> by this way we can achieve the performance we need for usecases such as
>> big data, this can be done by cinder using BlockDeviceDriver, it is quite
>> different from the approach one you mentioned. The only problem now is
>> that we cannot practially ensure the compute resource located on the same
>> host with the volume, as Matt mentioned above, currently we have to
>> arrange 1:1 AZ in Cinder and Nova to do this and it is not practical in
>> commercial
>> deployments.
>>
>> Thanks.
>>
>>
> Kevin,
>
> Is the issue because you can't use ephemeral local disks (it must be a
> persistent boot from volume)?
>
> Have you looked at using the LVM image backend for local storage in Nova?
> I thought cfriesen said once that windriver is doing high performance
> config using local LVM in nova.
>
> --
>
> 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 Development Mailing 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] [congress][ptg] Friday aquarium trip

[Eric K]

For those interested, a few of us at the PTG are going to the Georgia Aquarium 
Friday (2/24) morning. All welcome!
Meet at Sheraton hotel lobby at 9:30AM.
Purchase your ticket in advance here for early bird pricing (valid for entering 
before 11am):  
https://estore.georgiaaquarium.org/webstore/shop/viewitems.aspx?cg=store=ebd
__
OpenStack Development Mailing 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]PKI token VS Fernet token

[joehuang]

Database async. replication across data centers should work considering that 
the data in KeyStone is not updated frequently. There is a little delay for the 
data replication, may lead to quite few requests rejection in a data center 
where the data has not arrived. But I think it's quite short and acceptable. 
For public cloud, I would like to know others thoughts on the security risk, is 
the security risk also acceptable.

Best Regards
Chaoyi Huang (joehuang)

From: 王玺源 [wangxiyuan1...@gmail.com]
Sent: 23 February 2017 21:39
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [keystone]PKI token VS Fernet token

Thanks for all your advices and opinions.

We'll try to solve the PKI issue and hope it can come back in the future.

About the fernet token, we'll test it with the new config options and show you 
the result later. Hope it performs well.

At last, we still have one question:
For public cloud, it is very common that multi regions are deployed. And the 
distance is usually very far between the regions. So the transport delay is 
really a problem. Fernet token requires the data must be the same. Because of 
the slow connection and high time delay, in our opinion, it is unrealistic that 
let the keystones from different regions to use the same keystone datacenter. 
Any idea about this problem? Thanks.



2017-02-21 8:58 GMT-05:00 Dolph Mathews 
>:
It appears that you don't have caching enabled, then. Without enabling caching, 
Fernet performance is well known to be terrible, which would explain your 
benchmark results. If you run a similar benchmark with caching, I'd be eager to 
see the new configuration and benchmark results.


On Fri, Feb 17, 2017 at 8:16 AM 王玺源 
> wrote:
Hi Dolph:

We made the keystone.conf same with the example.

[token]

provider = fernet



[fernet_tokens]   //all configuration is default

#

# From keystone

#



# Directory containing Fernet token keys. (string value)

#key_repository = /etc/keystone/fernet-keys/



# This controls how many keys are held in rotation by keystone-manage

# fernet_rotate before they are discarded. The default value of 3 means that

# keystone will maintain one staged key, one primary key, and one secondary

# key. Increasing this value means that additional secondary keys will be kept

# in the rotation. (integer value)

# max_active_keys = 3

Dolph Mathews 
>于2017年2月17日 周五上午7:22写道：
Thank you for the data and your test scripts! As Lance and Stanek already 
alluded, Fernet performance is very sensitive to keystone's configuration. Can 
your share your keystone.conf as well?

I'll also be in Atlanta and would love to talk Fernet performance, even if we 
don't have a formal time slot on the schedule.

On Wed, Feb 15, 2017 at 9:08 AM Lance Bragstad 
> wrote:
In addition to what David said, have you played around with caching in keystone 
[0]? After the initial implementation of fernet landed, we attempted to make it 
the default token provider. We ended up reverting the default back to uuid 
because we hit several issues. Around the Liberty and Mitaka timeframe, we 
reworked the caching implementation to fix those issues and improve overall 
performance of all token formats, especially fernet.

We have a few different performance perspectives available, too. Some were run 
nearly 2 years ago [1] and some are run today [2]. Since the Newton release, 
we've made drastic improvements to the overall structure of the token provider 
[3] [4] [5]. At the very least, it should make understanding keystone's 
approach to tokens easier. Maintaining out-of-tree token providers should also 
be easier since we cleaned up a lot of the interfaces that affect developers 
maintaining their own providers.

We can try and set something up at the PTG. We are getting pretty tight for 
time slots, but I'm sure we can find some time to work through the issues 
you're seeing (also, feel free to hop into #openstack-keystone on freenode if 
you want to visit prior to the PTG).


[0] 
https://docs.openstack.org/developer/keystone/configuration.html#caching-layer
[1] http://dolphm.com/benchmarking-openstack-keystone-token-formats/
[2] https://github.com/lbragstad/keystone-performance
[3] 
https://review.openstack.org/#/q/status:merged+project:openstack/keystone+branch:master+topic:make-fernet-default
[4] 
https://review.openstack.org/#/q/status:merged+project:openstack/keystone+branch:master+topic:cleanup-token-provider
[5] 
http://specs.openstack.org/openstack/keystone-specs/specs/keystone/ocata/token-provider-cleanup.html

On Wed, Feb 15, 2017 at 8:44 AM, David Stanek 
> wrote:
On 15-Feb 18:16, 王玺源 wrote:
> Hello everyone,
>   PKI/PKIZ 

Re: [openstack-dev] The end of OpenStack packages in Debian?

[Allison Randal]

On 02/21/2017 12:57 PM, Ritesh Raj Sarraf wrote:
> Hello Thomas,
> 
> Sad to see this. But with so much free loading trend, these are bound to 
> happen.
> 
> For the LIO-fb target in Debian, we've been depending on the rtslib-fb 
> package,
> which you've maintained so far. Should we pick it up under the 
> pkg-linux-target
> team ?

Hi Ritesh,

For the sake of consistency, it probably makes more sense to maintain
rtslib-fb within the Debian Python Modules Team. If you'd like to chat
in more detail about which Debian team is the best fit, we can narrow
this thread down to just the PKG OpenStack mailing list.

Thanks,
Allison



signature.asc
Description: OpenPGP digital 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] [heat][all]Heat evening event on Thrusday this week

[Rico Lin]

We're at second floor

2017年2月23日 下午2:37，"Rico Lin" 寫道：

.

2017-02-23 2:42 GMT+08:00 Rico Lin :

> Dear all
>
> We will have a PTG dinner and beer session on Thursday night 7:00
> Here is the place: http://www.maxlagersrestaurantatlanta.com/
> *location: 320 Peachtree St NE, Atlanta, GA*.
> All teams are welcome to join us.
>
>
> --
> May The Force of OpenStack Be With You,
>
> *Rico Lin*irc: ricolin
>
>


-- 
May The Force of OpenStack Be With You,

*Rico Lin*irc: ricolin
__
OpenStack Development Mailing 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

[Davanum Srinivas]

Sampath,

I am not sure if you will hear back from Timur soon as he may not be
working on this stuff anymore (in Mirantis). So i'd recommend picking
up the work if you don't hear from him soon.

Thanks,
Dims

On Thu, Feb 23, 2017 at 3:41 PM, Sam P  wrote:
> Hi Timur,
>
>  The current status of this work is,
> 1) The QA user story for destructive testing of OpenStack cloud [1] is merged 
> .
> 2) The spec for a new framework which will focus on HA/failover and
> destructive testing  [2] has no update since Nov 30 2016.
> 3) The commit for the new repository [3]  has abandoned due to no
> update after Nov 29 2016.
>
> Currently, I am working on 3rd party destructive/HA testing CI for
> Masakari[4] and very much interested in this work.
> I will keep working on [1] with PWG.
> Please let me know your plans for [2], and [3].
> If it is difficult for you to continue, I would love to continue your
> work on [2], and [3].
>
> [1] https://review.openstack.org/#/c/396142
> [2] https://review.openstack.org/#/c/399618
> [3] https://review.openstack.org/#/c/374667
> [4] https://wiki.openstack.org/wiki/Masakari
> --- Regards,
> Sampath
>
>
>
> On Mon, Nov 28, 2016 at 6:37 AM, Timur Nurlygayanov
>  wrote:
>> Hi team,
>>
>> here is a short update:
>>
>> 1) The QA user story for destructive testing of OpenStack cloud is on review
>> [1].
>> 2) The spec for a new framework which will focus on HA/failover and
>> destructive testing is no review [2].
>> 3) The commit for the new repository is on review [3] as well.
>>
>> [1] https://review.openstack.org/#/c/396142
>> [2] https://review.openstack.org/#/c/399618
>> [3] https://review.openstack.org/#/c/374667
>>
>>
>> On Fri, Oct 14, 2016 at 3:47 AM, Ghanshyam Mann
>>  wrote:
>>>
>>> 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 

Re: [openstack-dev] [release][ansible] release job failure for openstack-ansible docs

[Andy McCrae]

On 23 February 2017 at 16:54, Doug Hellmann  wrote:

> This looks like an issue with the node (filesystem corruption?) but just
> in case it's reproducible I'm forwarding the link to the logs.
>
> Doug
>
> --- Begin forwarded message from jenkins ---
> From: jenkins 
> To: release-job-failures 
> Date: Thu, 23 Feb 2017 20:25:06 +
> Subject: [Release-job-failures] Release of openstack/openstack-ansible
> failed
>
> Build failed.
>
> - openstack-ansible-docs-ubuntu-xenial http://logs.openstack.org/1b/
> 1bcce47f34bd4a49d5a87d8ef86c08caba0bac16/release/openstack-
> ansible-docs-ubuntu-xenial/3cf244d/ : FAILURE in 1m 03s
> - openstack-ansible-announce-release http://logs.openstack.org/1b/
> 1bcce47f34bd4a49d5a87d8ef86c08caba0bac16/release/openstack-
> ansible-announce-release/eb2d662/ : SUCCESS in 2m 01s
>
> --- End forwarded message ---
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>


Thanks for the heads-up.

We believe this should be ok now, a patch merged shortly after that with
the docs build succeeding, but there are a few in the queue that I'll keep
an eye on, to be sure.

Andy
__
OpenStack Development Mailing 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] [charms] 17.02 OpenStack Charms release

[James Page]

Hi All

I'm pleased to announce the 17.02 release of the OpenStack Charms.

In addition to 120 bug fixes across the charms and support for the Ocata
OpenStack release, there are new charms for Ceph FS and Manila and to
support integration of Keystone with LDAP/Active Directory leveraging
domain specific drivers with Keystone v3 domains.

For full details of the release, please refer to the release notes:

  https://docs.openstack.org/developer/charm-guide/1702.html

It's also worth noting that bug reporting has now been moved out of the
Juju Charms distribution on Launchpad into individual projects for each
charm under the OpenStack Charms project group:

  https://launchpad.net/openstack-charms

All existing bugs have been migrated to the new project locations.

Thanks go to the following contributors for this release:

  Seyeong Kim
  Mario Splivalo
  Ante Karamatić
  Shane Peters
  JuanJo Ciarlante
  Billy Olsen
  Paolo de Rosa
  Frode Nordahl
  Felipe Reyes
  David Ames
  Liam Young
  Edward Hope-Morley
  Chris MacNaughton
  Chris Holcombe
  Alex Kavanagh
  Brad Marshall
  Dmitrii Shcherbakov
  Ryan Beisner
  Viswesuwara Nathan
  Pascal Mazon
  Hua Zhang
  Chris Glass

Cheers

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

[openstack-dev] [release][ansible] release job failure for openstack-ansible docs

[Doug Hellmann]

This looks like an issue with the node (filesystem corruption?) but just
in case it's reproducible I'm forwarding the link to the logs.

Doug

--- Begin forwarded message from jenkins ---
From: jenkins 
To: release-job-failures 
Date: Thu, 23 Feb 2017 20:25:06 +
Subject: [Release-job-failures] Release of openstack/openstack-ansible failed

Build failed.

- openstack-ansible-docs-ubuntu-xenial 
http://logs.openstack.org/1b/1bcce47f34bd4a49d5a87d8ef86c08caba0bac16/release/openstack-ansible-docs-ubuntu-xenial/3cf244d/
 : FAILURE in 1m 03s
- openstack-ansible-announce-release 
http://logs.openstack.org/1b/1bcce47f34bd4a49d5a87d8ef86c08caba0bac16/release/openstack-ansible-announce-release/eb2d662/
 : SUCCESS in 2m 01s

--- End forwarded message ---

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

Re: [openstack-dev] [neutron] - Neutron team social in Atlanta on Thursday

[reedip banerjee]

+1 from Rajiv Kumar as well :)

On Fri, Feb 24, 2017 at 3:07 AM, Vasudevan, Swaminathan (PNB Roseville) <
swaminathan.vasude...@hpe.com> wrote:

> +1
>
>
>
> *From:* Kevin Benton [mailto:ke...@benton.pub]
> *Sent:* Thursday, February 23, 2017 4:09 PM
>
> *To:* OpenStack Development Mailing List (not for usage questions) <
> openstack-dev@lists.openstack.org>
> *Subject:* Re: [openstack-dev] [neutron] - Neutron team social in Atlanta
> on Thursday
>
>
>
> Hi everyone,
>
>
>
> We will meet tonight at Mellow Mushroom at 6PM. It's about a 10-15 minute
> walk from the venue.
>
>
>
> Here is the location:
>
>
>
> https://goo.gl/maps/FAnmVEVEUSE2
>
>
>
> On Feb 23, 2017 13:27, "Duarte Cardoso, Igor" <
> igor.duarte.card...@intel.com> wrote:
>
> +1
>
>
>
> Best regards,
>
> Igor.
>
>
>
> *From:* Vasudevan, Swaminathan (PNB Roseville) [mailto:
> swaminathan.vasude...@hpe.com]
> *Sent:* Friday, February 17, 2017 8:30 PM
> *To:* OpenStack Development Mailing List (not for usage questions) <
> openstack-dev@lists.openstack.org>
> *Subject:* Re: [openstack-dev] [neutron] - Neutron team social in Atlanta
> on Thursday
>
>
>
> Count me in.
>
>
>
> *From:* Kevin Benton [mailto:ke...@benton.pub ]
> *Sent:* Friday, February 17, 2017 11:19 AM
> *To:* openstack-dev@lists.openstack.org
> *Subject:* [openstack-dev] [neutron] - Neutron team social in Atlanta on
> Thursday
>
>
>
> Hi all,
>
>
>
> I'm organizing a Neutron social event for Thursday evening in Atlanta
> somewhere near the venue for dinner/drinks. If you're interested, please
> reply to this email with a "+1" so I can get a general count for a
> reservation.
>
>
>
> Cheers,
>
> Kevin Benton
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Thanks and Regards,
Reedip Banerjee
IRC: reedip
__
OpenStack Development Mailing 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] Call for upstream training liaison

[Kendall Nelson]

Thanks Jay!

   We really appreciate your interest! As we get closer to the event,
Ildiko and I will send more details. At this point the important
information is that it will take place before the Summit on Saturday and
Sunday.

Thanks Again,

Kendall Nelson (diablo_rojo)

On Thu, Feb 23, 2017 at 2:53 PM Jay Pipes  wrote:

> On 02/21/2017 02:45 PM, Matt Riedemann wrote:
> > If you haven't seen this yet [1] there is going to be an upstream
> > training meeting at the PTG on Wednesday 2/22 at 12ET to talk about
> > upstream training and what liaisons from each project can do to help.
> >
> > This email is a call for anyone that's working on Nova and is interested
> > in volunteering to be the team liaison for the upstream training which
> > happens the weekend before the Pike summit in Boston.
> >
> > At a high level, it's my understanding that this involves helping some
> > new contributors get comfortable with the various projects and to
> > associate a person with each project so when they show up in IRC they
> > know someone and can ask questions (similar to mentoring but I believe
> > less involved on an ongoing basis).
> >
> > So if you're going to be at the Boston summit and this is something
> > you're interested in, please either speak with me, Ildiko, or show up to
> > the meeting to find out more.
> >
> > [1]
> >
> http://lists.openstack.org/pipermail/openstack-dev/2017-February/112270.html
>
> I will be in Boston and would be happy to participate in the upstream
> training.
>
> Best,
> -jay
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] - Neutron team social in Atlanta on Thursday

[Vasudevan, Swaminathan (PNB Roseville)]

+1

From: Kevin Benton [mailto:ke...@benton.pub]
Sent: Thursday, February 23, 2017 4:09 PM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [neutron] - Neutron team social in Atlanta on 
Thursday

Hi everyone,

We will meet tonight at Mellow Mushroom at 6PM. It's about a 10-15 minute walk 
from the venue.

Here is the location:

https://goo.gl/maps/FAnmVEVEUSE2

On Feb 23, 2017 13:27, "Duarte Cardoso, Igor" 
> wrote:
+1

Best regards,
Igor.

From: Vasudevan, Swaminathan (PNB Roseville) 
[mailto:swaminathan.vasude...@hpe.com]
Sent: Friday, February 17, 2017 8:30 PM
To: OpenStack Development Mailing List (not for usage questions) 
>
Subject: Re: [openstack-dev] [neutron] - Neutron team social in Atlanta on 
Thursday

Count me in.

From: Kevin Benton [mailto:ke...@benton.pub]
Sent: Friday, February 17, 2017 11:19 AM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [neutron] - Neutron team social in Atlanta on Thursday

Hi all,

I'm organizing a Neutron social event for Thursday evening in Atlanta somewhere 
near the venue for dinner/drinks. If you're interested, please reply to this 
email with a "+1" so I can get a general count for a reservation.

Cheers,
Kevin Benton

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

Re: [openstack-dev] [all] parsing libraries

[Jay Pipes]

On 02/20/2017 09:48 PM, Eric K wrote:

Hi all,

In the congress project, we¹re looking to replace the antlr3-based parser
with a better maintained alternative. I see that pyparsing and Parsley are
used in some projects, could anyone share their experience with them and
potentially other parsing libraries?

The intended use is to parse input into abstract syntax trees according to
a grammar like this:
https://github.com/openstack/congress/blob/master/congress/datalog/Congress
.g

More specific questions:
- how would they do on a grammar that¹s slightly more complex than the
typical usage? e.g.,
https://github.com/openstack/congress/blob/master/congress/datalog/Congress
.g

- does anyone know if Parsley is well-maintained? Their repo seems to be
very quiet over the past 2 yrs
https://github.com/python-parsley/parsley/graphs/contributors?from=2015-02-
01=2017-02-20=c

- Any thoughts or comments on the other Other libraries I¹m considering?
(these are more geared toward larger grammars)
-- Grako https://pypi.python.org/pypi/grako/3.19.1

-- PLY https://pypi.python.org/pypi/ply/3.10


I've used PLY before and been quite happy with it. It's easy to use and 
for folks who understand EBNF grammars, is a natural fit.


Best,
-jay


-- I have ³soft-rejected² Antlr4 because the AST feature has been removed.
If I have to put in non-trivial work anyway (to create the AST), I figure
I might as well invest the work into moving to a pure Python framework.
But would love to hear more if someone thinks it¹s the way to go!

Thanks so much!

Eric



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



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

Re: [openstack-dev] [neutron] - Neutron team social in Atlanta on Thursday

[Kevin Benton]

Hi everyone,

We will meet tonight at Mellow Mushroom at 6PM. It's about a 10-15 minute
walk from the venue.

Here is the location:

https://goo.gl/maps/FAnmVEVEUSE2

On Feb 23, 2017 13:27, "Duarte Cardoso, Igor" 
wrote:

> +1
>
>
>
> Best regards,
>
> Igor.
>
>
>
> *From:* Vasudevan, Swaminathan (PNB Roseville) [mailto:
> swaminathan.vasude...@hpe.com]
> *Sent:* Friday, February 17, 2017 8:30 PM
> *To:* OpenStack Development Mailing List (not for usage questions) <
> openstack-dev@lists.openstack.org>
> *Subject:* Re: [openstack-dev] [neutron] - Neutron team social in Atlanta
> on Thursday
>
>
>
> Count me in.
>
>
>
> *From:* Kevin Benton [mailto:ke...@benton.pub ]
> *Sent:* Friday, February 17, 2017 11:19 AM
> *To:* openstack-dev@lists.openstack.org
> *Subject:* [openstack-dev] [neutron] - Neutron team social in Atlanta on
> Thursday
>
>
>
> Hi all,
>
>
>
> I'm organizing a Neutron social event for Thursday evening in Atlanta
> somewhere near the venue for dinner/drinks. If you're interested, please
> reply to this email with a "+1" so I can get a general count for a
> reservation.
>
>
>
> Cheers,
>
> Kevin Benton
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] neutron-classifier (CCF) at the PTG

[Duarte Cardoso, Igor]

Hi all,

I’ve added a photo of our whiteboard drafting today to the wiki: 
https://wiki.openstack.org/wiki/Neutron/CommonFlowClassifier#Atlanta_PTG_main_whiteboard_drafting
Best regards,
Igor.

From: Thomas Morin [mailto:thomas.mo...@orange.com]
Sent: Friday, February 17, 2017 2:51 PM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [neutron] neutron-classifier (CCF) at the PTG

Hi,

I have no opinion on where/when this should happen, but will be interested to 
participate.

-Thomas

Tue Feb 14 2017 15:39:22 GMT+0100 (CET), Duarte Cardoso, Igor:
Hi neutron,

Me and David would like to discuss the Common Classification Framework (CCF) 
(current approach based on openstack/neutron-classifier) at the PTG but we 
aren’t sure if the main session is the appropriate forum for that or if we 
should only have a meeting with the interested people and a few Neutron cores 
or PTL (to discuss if and how this work could be brought closer to Neutron 
itself).

I appreciate your feedback, thanks!

Best regards,
Igor.





__

OpenStack Development Mailing 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] Call for upstream training liaison

[Jay Pipes]

On 02/21/2017 02:45 PM, Matt Riedemann wrote:

If you haven't seen this yet [1] there is going to be an upstream
training meeting at the PTG on Wednesday 2/22 at 12ET to talk about
upstream training and what liaisons from each project can do to help.

This email is a call for anyone that's working on Nova and is interested
in volunteering to be the team liaison for the upstream training which
happens the weekend before the Pike summit in Boston.

At a high level, it's my understanding that this involves helping some
new contributors get comfortable with the various projects and to
associate a person with each project so when they show up in IRC they
know someone and can ask questions (similar to mentoring but I believe
less involved on an ongoing basis).

So if you're going to be at the Boston summit and this is something
you're interested in, please either speak with me, Ildiko, or show up to
the meeting to find out more.

[1]
http://lists.openstack.org/pipermail/openstack-dev/2017-February/112270.html


I will be in Boston and would be happy to participate in the upstream 
training.


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] [QA] The end-user test suite for OpenStack clusters

[Sam P]

Hi Timur,

 The current status of this work is,
1) The QA user story for destructive testing of OpenStack cloud [1] is merged .
2) The spec for a new framework which will focus on HA/failover and
destructive testing  [2] has no update since Nov 30 2016.
3) The commit for the new repository [3]  has abandoned due to no
update after Nov 29 2016.

Currently, I am working on 3rd party destructive/HA testing CI for
Masakari[4] and very much interested in this work.
I will keep working on [1] with PWG.
Please let me know your plans for [2], and [3].
If it is difficult for you to continue, I would love to continue your
work on [2], and [3].

[1] https://review.openstack.org/#/c/396142
[2] https://review.openstack.org/#/c/399618
[3] https://review.openstack.org/#/c/374667
[4] https://wiki.openstack.org/wiki/Masakari
--- Regards,
Sampath



On Mon, Nov 28, 2016 at 6:37 AM, Timur Nurlygayanov
 wrote:
> Hi team,
>
> here is a short update:
>
> 1) The QA user story for destructive testing of OpenStack cloud is on review
> [1].
> 2) The spec for a new framework which will focus on HA/failover and
> destructive testing is no review [2].
> 3) The commit for the new repository is on review [3] as well.
>
> [1] https://review.openstack.org/#/c/396142
> [2] https://review.openstack.org/#/c/399618
> [3] https://review.openstack.org/#/c/374667
>
>
> On Fri, Oct 14, 2016 at 3:47 AM, Ghanshyam Mann
>  wrote:
>>
>> 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 

Re: [openstack-dev] [nova][cinder] Schedule Instances according to Local disk based Volume?

[Matt Riedemann]

On 9/26/2016 9:21 PM, Zhenyu Zheng wrote:

Hi,

Thanks for the reply, actually approach one is not we are looking for,
our demands is to attach the real physical volume from compute node to VMs,
by this way we can achieve the performance we need for usecases such as
big data, this can be done by cinder using BlockDeviceDriver, it is quite
different from the approach one you mentioned. The only problem now is
that we cannot practially ensure the compute resource located on the same
host with the volume, as Matt mentioned above, currently we have to
arrange 1:1 AZ in Cinder and Nova to do this and it is not practical in
commercial
deployments.

Thanks.



Kevin,

Is the issue because you can't use ephemeral local disks (it must be a 
persistent boot from volume)?


Have you looked at using the LVM image backend for local storage in 
Nova? I thought cfriesen said once that windriver is doing high 
performance config using local LVM in nova.


--

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] [heat][all]Heat evening event on Thrusday this week

[Rico Lin]

.

2017-02-23 2:42 GMT+08:00 Rico Lin :

> Dear all
>
> We will have a PTG dinner and beer session on Thursday night 7:00
> Here is the place: http://www.maxlagersrestaurantatlanta.com/
> *location: 320 Peachtree St NE, Atlanta, GA*.
> All teams are welcome to join us.
>
>
> --
> May The Force of OpenStack Be With You,
>
> *Rico Lin*irc: ricolin
>
>


-- 
May The Force of OpenStack Be With You,

*Rico Lin*irc: ricolin
__
OpenStack Development Mailing 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 jenkins failure

[Lingxian Kong]

Thanks for letting us know, Jeremy!


Cheers,
Lingxian Kong (Larry)

On Fri, Feb 24, 2017 at 4:43 AM, Jeremy Stanley  wrote:

> On 2017-02-23 06:23:53 + (+), Guo, Ruijing wrote:
> > There are lots of openstack Jenkins failure. Anyone from
> > infrastructure team look at the issue?
>
> Jobs fail all the time; can you be more specific?
>
> There was an issue earlier today where our distributed Ubuntu
> package mirror hadn't refreshed in a few days and then updated job
> node images ended up incorrectly expecting a newer set of qemu
> packages than we were providing on the mirrors. Perhaps this is what
> you saw?
>
> Those specific failures have been resolved by fixing the condition
> which had caused the mirror to cease updating, and a change is also
> in review now to keep situations like this from arising in the
> future.
> --
> Jeremy Stanley
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] Some findings while profiling instances boot

[Dariusz Śmigiel]

We're planning to come up with some solution regarding neutron profiling.
For this purpose etherpad [1] got created.

If anyone wants to join efforts, feel free to contribute.

[1] https://etherpad.openstack.org/p/neutron-profiling

__
OpenStack Development Mailing 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] CI Q session at PTG - submit your questions!

[Chris Jones]

Hey folks

We're doing a Q session tomorrow (Friday) morning at the PTG  on TripleO
CI.

Whether you're at the PTG or not, if you have questions/confusions about
Tripleo CI, please put them in the Etherpad at:
https://etherpad.openstack.org/p/tripleo-ptg-ci-qa

-- 
Cheers,

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

[openstack-dev] [ptg][neutron] - found micro SD card

[Kevin Benton]

Hi all,

A micro SD card was found inside of a micro-to-normal size SD card adapter
in the Neutron PTG meeting room.

If it's yours you can come claim it from me in the Neutron room today or
tomorrow.

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

Re: [openstack-dev] [neutron] - Neutron team social in Atlanta on Thursday

[Duarte Cardoso, Igor]

+1

Best regards,
Igor.

From: Vasudevan, Swaminathan (PNB Roseville) 
[mailto:swaminathan.vasude...@hpe.com]
Sent: Friday, February 17, 2017 8:30 PM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [neutron] - Neutron team social in Atlanta on 
Thursday

Count me in.

From: Kevin Benton [mailto:ke...@benton.pub]
Sent: Friday, February 17, 2017 11:19 AM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [neutron] - Neutron team social in Atlanta on Thursday

Hi all,

I'm organizing a Neutron social event for Thursday evening in Atlanta somewhere 
near the venue for dinner/drinks. If you're interested, please reply to this 
email with a "+1" so I can get a general count for a reservation.

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

Re: [openstack-dev] [tripleo] Atlanta PTG

[Ben Nemec]

On 02/22/2017 03:27 AM, Marios Andreou wrote:

On 22/02/17 10:25, Carlos Camacho Gonzalez wrote:

Thanks Emilien!

I think will be enough just by sharing a mic and the Etherpad notes.


++ thanks very much Emilien - it can be very effective/useful as long as
people remember to use the mic (depending on room size, may be necessary
locally as well :) )... thanks in advance to anyone 'donating' their
laptop for the bluejeans session (extra bonus/cherry on top if you hit
'record' but I know I'm pushing it now ;) )


Note that we don't actually have a mic at this event.  The av 
capabilities of the general rooms is pretty much non-existent.




have a great day in Atlanta!



Cheers,
Carlos.

On Wed, Feb 22, 2017 at 5:16 AM, Emilien Macchi > wrote:

On Tue, Feb 21, 2017 at 11:46 AM, Sai Sindhur Malleni
> wrote:
> Is there a plan to have a google hangouts session or similar to attend
> remotely?

to be honest, mixing face 2 face & remote meetings is very challenging.
But because people want it, we'll give a try on Friday morning during
the CI sessions.

If anyone at PTG volunteers to do the same for the other sessions on
Wednesday or Thursday, feel free to do so.

> On Mon, Jan 23, 2017 at 8:45 AM, John Trowbridge > wrote:
>>
>>
>>
>> On 01/21/2017 05:37 AM, Michele Baldessari wrote:
>> > Hi Emilien,
>> >
>> > while not a design session per se, I would love to propose a
short slot
>> > for TripleO CI Q, if we have some time left. In short, I'd
like to be
>> > more useful around CI failures, but I lack the understanding of
a few
>> > aspects of our current CI (promotion, when do images get built,
etc.),
>> > that would benefit quite a bit from a short session where we
have a few
>> > CI folks in the room that could answer questions or give some tips.
>> > I know of quite few other people that are in the same boat and
maybe
>> > this will help a bit our current issue where only a few folks
always
>> > chase CI issues.
>> >
>> > If there is consensus (and some CI folks willing to attend ;)
and time
>> > for this, I'll be happy to organize this and prepare a bunch of
>> > questions ideas beforehand.
>> >
>>
>> Great idea. We have a room for three days, so it is not like summit
>> where there is really limited time.
>>
>> > Thoughts?
>> > Michele
>> >
>> > On Wed, Jan 04, 2017 at 07:26:52AM -0500, Emilien Macchi wrote:
>> >> I would like to bring this topic up on your inbox, so we can
continue
>> >> to make progress on the agenda. Feel free to follow existing
examples
>> >> in the etherpad and propose a design dession.
>> >>
>> >> Thanks,
>> >>
>> >> On Wed, Dec 21, 2016 at 9:06 AM, Emilien Macchi
>
>> >> wrote:
>> >>> General infos about PTG: https://www.openstack.org/ptg/
>> >>>
>> >>> Some useful informations about PTG/TripleO:
>> >>>
>> >>> * When? We have a room between Wednesday and Friday included.
>> >>> Important sessions will happen on Wednesday and Thursday. We'll
>> >>> probably have sessions on Friday, but it might be more
hands-on and
>> >>> hackfest, where people can enjoy the day to work together.
>> >>>
>> >>> * Let's start to brainstorm our topics:
>> >>> https://etherpad.openstack.org/p/tripleo-ptg-pike

>> >>>   Feel free to add any topic, as soon as you can. We need to
know asap
>> >>> which sessions will be share with other projects (eg:
tripleo/mistral,
>> >>> tripleo/ironic, tripleo/heat, etc).
>> >>>
>> >>>
>> >>> Please let us know any question or feedback,
>> >>> Looking forward to seeing you there!
>> >>> --
>> >>> 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 Development Mailing List (not for usage questions)
>> Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

>> 

[openstack-dev] Ocata packages for openSUSE and SLES available

[Thomas Bechtold]

Hi,

Ocata packages for openSUSE and SLES are now available at:

http://download.opensuse.org/repositories/Cloud:/OpenStack:/Ocata/

We currently maintain + test the packages for SLE 12SP2 and openSUSE
Leap 42.2.

If you find issues, please do not hesitate to report them to
opensuse-cloud at opensuse.org or to https://bugzilla.opensuse.org/

Thanks and have a lot of fun,

Tom

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

Re: [openstack-dev] [neutron] - Neutron team social in Atlanta on Thursday

[German Eichberger]

+1

Sent from my iPhone

On Feb 17, 2017, at 5:43 PM, Michael Johnson 
> wrote:

+1

Thanks for setting this up,

Michael

From: Kevin Benton [mailto:ke...@benton.pub]
Sent: Friday, February 17, 2017 11:19 AM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [neutron] - Neutron team social in Atlanta on Thursday

Hi all,

I'm organizing a Neutron social event for Thursday evening in Atlanta somewhere 
near the venue for dinner/drinks. If you're interested, please reply to this 
email with a "+1" so I can get a general count for a reservation.

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

Re: [openstack-dev] [infra][all] Project Navigator Broken

[Kenny Johnston]

On Thu, Feb 23, 2017 at 8:27 AM, Jeremy Stanley  wrote:

> On 2017-02-23 07:42:19 -0600 (-0600), Kenny Johnston wrote:
> > The project navigator[1] is no longer displaying projects.
>
> I gave the site admins a heads up and it should be fixed as of about
> 5 minutes ago.
>

Awesome, thanks!


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



-- 
Kenny Johnston | irc:kencjohnston | @kencjohnston
__
OpenStack Development Mailing 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 jenkins failure

[Jeremy Stanley]

On 2017-02-23 06:23:53 + (+), Guo, Ruijing wrote:
> There are lots of openstack Jenkins failure. Anyone from
> infrastructure team look at the issue?

Jobs fail all the time; can you be more specific?

There was an issue earlier today where our distributed Ubuntu
package mirror hadn't refreshed in a few days and then updated job
node images ended up incorrectly expecting a newer set of qemu
packages than we were providing on the mirrors. Perhaps this is what
you saw?

Those specific failures have been resolved by fixing the condition
which had caused the mirror to cease updating, and a change is also
in review now to keep situations like this from arising in the
future.
-- 
Jeremy Stanley

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

Re: [openstack-dev] [third-party][ci] Transition your devstack-gate based CI to local.conf

[Clark Boylan]

On Wed, Feb 22, 2017, at 09:36 PM, Mikhail Medvedev wrote:
> Hi third-party CI operators,
> 
> This is for those who use devstack-gate with localrc. You might have
> started seeing failures since [1] landed. This is due to a few
> devstack settings now being ignored. When devstack sees that you have
> both localrc and [[local|localrc]] section in local.conf, it only uses
> localrc file.
> 
> A solution is to move your localrc settings into [[local|localrc]]
> section of local.conf. For a temporary fix you can also pin
> devstack-gate to a version before [1], until your configuration is
> migrated.

Even better would be using the DEVSTACK_LOCAL_CONFIG var which is passed
through properly regardless of underlying configuration file type.

Clark

__
OpenStack Development Mailing 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] [infra][all] Project Navigator Broken

[Jeremy Stanley]

On 2017-02-23 07:42:19 -0600 (-0600), Kenny Johnston wrote:
> The project navigator[1] is no longer displaying projects.

I gave the site admins a heads up and it should be fixed as of about
5 minutes ago.
-- 
Jeremy Stanley

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

Re: [openstack-dev] [Neutron][FWaaS][PTG] FWaaS team gathering Thursday for lunch

[reedip banerjee]

Hi All,
The lunch is in the Grand Ballroom ( if I am correct ) in the Level 1 on
Sheraton.
So lets catch up there

On Wed, Feb 22, 2017 at 8:24 PM, German Eichberger <
german.eichber...@rackspace.com> wrote:

> All,
>
>
>
> The FWaaS team will meet for lunch at the Sheraton tomorrow, Thursday, to
> tlak about Pike priorities (https://etherpad.openstack.org/p/fwaas-pike)
> and prepare for Friday’s Advanced Srrvices session. Ping us on irc if you
> can’t find our table.
>
>
>
> German
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Thanks and Regards,
Reedip Banerjee
IRC: reedip
__
OpenStack Development Mailing 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] [infra][all] Project Navigator Broken

[Anne Gentle]

Hi Kenny,
Best place to log a bug for www.openstack.org content is here:

https://bugs.launchpad.net/openstack-org

I also see zero count for projects on Chrome for Mac this morning.

Anne

On Thu, Feb 23, 2017 at 7:42 AM, Kenny Johnston 
wrote:

> The project navigator[1] is no longer displaying projects.
>
> --
> Kenny Johnston | irc:kencjohnston | @kencjohnston
> [1]https://www.openstack.org/software/project-navigator/
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 

Read my blog: justwrite.click 
Subscribe to Docs|Code: docslikecode.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [glance] PTG summary, Wednesday, Feb 22

[Brian Rosmaita]

The Glance PTG schedule etherpad contains links to the etherpads for
each of the sessions discussed below:
https://etherpad.openstack.org/p/glance-pike-ptg-schedule

1. Short topics
dharinic led a discussion of a three recent items she's been looking
into.  First up was how the Glance limited JSON patch support could be
enhanced to allow JSON pointer references to particular tags.  Consensus
was that Glance supports the json-patch standard correctly for tags.
Although we don't completely implement json-pointer (as is clearly
documented), it doesn't make sense to do so in this case because
tags are a set (hence unordered), so you can't meaningfully index into
them.  They look like a list, but that's because of the representational
limitations of JSON.  Also, there's already a "tags" API in v2 that
allows a user to refer to individual tags by name.  Thus, we'll leave
the tags support as is.
  Next up was a discussion of how the v2 API is handling range requests
for partial downloads in v2.  Consensus was to fix this as dharinic
proposed.
  Final topic was supporting more complicated JSON schemas than Glance
currently uses.  dharinic has some ideas of how to do this and will put
up a patch where it can be discussed.

2. What's up with Glance docs?
asettle (docs PTL) met with the team to discuss what docs the Glance
team should be maintaining and what manuals are handled by the docs
team.  It became clear that the Glance docs need an information
architecture rennovation to make the content more accessible to the
various intended audiences (developers, operators, admins, end-users).
Once we get them organized better, it will be easier to reduce
redundancy and add enhancements.  Several glancers volunteered to be
contacts for asettle as she proposes a basic reorg.

3. Pike Community Goals
alex_bash reported on the two Pike goals and what the likely impact on
Glance will be.  alex_bash has been putting up patches over the past few
weeks to fix the Glance functional tests that were failing under Python
3.5, so that work is actually close to completion.  (Kudos to
alex_bash!)  The wsgi goal for Pike is limited enough (run the current
Images API in mod_wsgi in devstack) that alex_bash is optimistic that it
can be completed without too many complications.  Additionally,
alex_bash volunteered to implement the wsgi community goal, so Glance
looks to be in good shape for these.
  Patches are up for the Glance planning artifacts:
- https://review.openstack.org/#/c/437349/
- https://review.openstack.org/#/c/437354/

4. Image import refactor (session 1)
We discussed jokke's proposal for the import backend (the "stage") and
considered one or two alternatives, but ultimately decided that jokke is
on the right track for an MVP implementation in Pike.

5. The Future of glance
See the etherpad for a few things that were suggested.  The team was
pretty exhausted by the previous session, so we kept this one short.
Plus, there's the glance/glare session Thursday morning where this will
be discussed a bit more.
- https://etherpad.openstack.org/p/glance-pike-ptg-future

6. Hierarchical image access
Very lively discussion around this, in particular, whether this type of
sharing can be accommodated by our current image sharing framework.
nikhil is going to put up a spec to clarify the proposal and use cases,
and the team agreed to continue the discussion on the spec patch.

7. OSSN review
By this time we were running late, so we didn't get too far.  We
concentrated on OSSN-0075, in which we provide operator advice, but for
which we don't have a fix.  In a nutshell, the problem is that Glance
allows a user to specify an image UUID at the time of image creation.
If an operator purges the database to eliminate all soft-deleted
records, it's possible for a UUID for a trusted image to be re-used by
some other image.  We discussed introducing a policy to govern
specifying a UUID on image creation and/or modifying the glance-manage
script to purge image properties, tags, members, and locations but no
longer purge the main images table, which would prevent UUID re-use
since we'd retain all the issued UUIDs.  There are pros and cons to both
approaches.  Consensus was to consult with a database expert, and
possibly both introduce the policy and modify the purge operation and
let operators choose whether/how they want to handle this issue.


Looking forward to another productive day!
brian

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

[openstack-dev] [infra][all] Project Navigator Broken

[Kenny Johnston]

The project navigator[1] is no longer displaying projects.

-- 
Kenny Johnston | irc:kencjohnston | @kencjohnston
[1]https://www.openstack.org/software/project-navigator/
__
OpenStack Development Mailing 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]PKI token VS Fernet token

[王玺源]

Thanks for all your advices and opinions.

We'll try to solve the PKI issue and hope it can come back in the future.

About the fernet token, we'll test it with the new config options and show
you the result later. Hope it performs well.

At last, we still have one question:
For public cloud, it is very common that multi regions are deployed. And
the distance is usually very far between the regions. So the transport
delay is really a problem. Fernet token requires the data must be the same.
Because of the slow connection and high time delay, in our opinion, it
is unrealistic
that let the keystones from different regions to use the same keystone
datacenter. Any idea about this problem? Thanks.



2017-02-21 8:58 GMT-05:00 Dolph Mathews :

> It appears that you don't have caching enabled, then. Without enabling
> caching, Fernet performance is well known to be terrible, which would
> explain your benchmark results. If you run a similar benchmark with
> caching, I'd be eager to see the new configuration and benchmark results.
>
>
> On Fri, Feb 17, 2017 at 8:16 AM 王玺源  wrote:
>
>> Hi Dolph:
>>
>> We made the keystone.conf same with the example.
>>
>> [token]
>>
>> provider = fernet
>>
>>
>>
>> [fernet_tokens]   //all configuration is default
>>
>> #
>>
>> # From keystone
>>
>> #
>>
>>
>>
>> # Directory containing Fernet token keys. (string value)
>>
>> #key_repository = /etc/keystone/fernet-keys/
>>
>>
>>
>> # This controls how many keys are held in rotation by keystone-manage
>>
>> # fernet_rotate before they are discarded. The default value of 3 means
>> that
>>
>> # keystone will maintain one staged key, one primary key, and one
>> secondary
>>
>> # key. Increasing this value means that additional secondary keys will be
>> kept
>>
>> # in the rotation. (integer value)
>>
>> # max_active_keys = 3
>> Dolph Mathews 于2017年2月17日 周五上午7:22写道：
>>
>> Thank you for the data and your test scripts! As Lance and Stanek already
>> alluded, Fernet performance is very sensitive to keystone's configuration.
>> Can your share your keystone.conf as well?
>>
>> I'll also be in Atlanta and would love to talk Fernet performance, even
>> if we don't have a formal time slot on the schedule.
>>
>> On Wed, Feb 15, 2017 at 9:08 AM Lance Bragstad 
>> wrote:
>>
>> In addition to what David said, have you played around with caching in
>> keystone [0]? After the initial implementation of fernet landed, we
>> attempted to make it the default token provider. We ended up reverting the
>> default back to uuid because we hit several issues. Around the Liberty and
>> Mitaka timeframe, we reworked the caching implementation to fix those
>> issues and improve overall performance of all token formats, especially
>> fernet.
>>
>> We have a few different performance perspectives available, too. Some
>> were run nearly 2 years ago [1] and some are run today [2]. Since the
>> Newton release, we've made drastic improvements to the overall structure of
>> the token provider [3] [4] [5]. At the very least, it should make
>> understanding keystone's approach to tokens easier. Maintaining out-of-tree
>> token providers should also be easier since we cleaned up a lot of the
>> interfaces that affect developers maintaining their own providers.
>>
>> We can try and set something up at the PTG. We are getting pretty tight
>> for time slots, but I'm sure we can find some time to work through the
>> issues you're seeing (also, feel free to hop into #openstack-keystone on
>> freenode if you want to visit prior to the PTG).
>>
>>
>> [0] https://docs.openstack.org/developer/keystone/
>> configuration.html#caching-layer
>> [1] http://dolphm.com/benchmarking-openstack-keystone-token-formats/
>> [2] https://github.com/lbragstad/keystone-performance
>> [3] https://review.openstack.org/#/q/status:merged+project:
>> openstack/keystone+branch:master+topic:make-fernet-default
>> [4] https://review.openstack.org/#/q/status:merged+project:
>> openstack/keystone+branch:master+topic:cleanup-token-provider
>> [5] http://specs.openstack.org/openstack/keystone-specs/
>> specs/keystone/ocata/token-provider-cleanup.html
>>
>> On Wed, Feb 15, 2017 at 8:44 AM, David Stanek 
>> wrote:
>>
>> On 15-Feb 18:16, 王玺源 wrote:
>> > Hello everyone,
>> >   PKI/PKIZ token has been removed from keystone in Ocata. But recently
>> our
>> > production team did some test about PKI and Fernet token (With Keystone
>> > Mitaka). They found that in large-scale production environment, Fernet
>> > token's performance is not as good as PKI. Here is the test data:
>> >
>> > https://docs.google.com/document/d/12cL9bq9EARjZw9IS3YxVmYsGfdauM
>> 25NzZcdzPE0fvY/edit?usp=sharing
>>
>> This is nice to see. Thanks.
>>
>>
>> >
>> > From the data, we can see that:
>> > 1. In large-scale concurrency test, PKI is much faster than Fernet.
>> > 2. PKI token revoke can't immediately make the token invalid. 

Re: [openstack-dev] [ironic] End-of-Ocata core team updates

[Vasyl Saienko]

Thanks everyone for this great opportunity I will do my best on this new
position.
Congrats Mario, well deserved!

Devananda I hope to see you back soon, it was pleasure to work with you.

On Wed, Feb 22, 2017 at 10:33 AM, Jim Rollenhagen 
wrote:

> We've a clear majority here, I took the liberty of adding Mario and Vasyl
> while Dmitry is busy running our sessions today. Welcome to the team, y'all
> :)
>
>
> // jim
>
> On Fri, Feb 17, 2017 at 4:40 AM, Dmitry Tantsur 
> wrote:
>
>> Hi all!
>>
>> I'd like to propose a few changes based on the recent contributor
>> activity.
>>
>> I have two candidates that look very good and pass the formal barrier of
>> 3 reviews a day on average [1].
>>
>> First, Vasyl Saienko (vsaienk0). I'm pretty confident in him, his stats
>> [2] are high, he's doing a lot of extremely useful work around networking
>> and CI.
>>
>> Second, Mario Villaplana (mariojv). His stats [3] are quite high too, he
>> has been doing some quality reviews for critical patches in the Ocata cycle.
>>
>> Active cores and interested contributors, please respond with your +-1 to
>> these suggestions.
>>
>> Unfortunately, there is one removal as well. Devananda, our team leader
>> for several cycles since the very beginning of the project, has not been
>> active on the project for some time [4]. I propose to (hopefully temporary)
>> remove him from the core team. Of course, when (look, I'm not even saying
>> "if"!) he comes back to active reviewing, I suggest we fast-forward him
>> back. Thanks for everything Deva, good luck with your current challenges!
>>
>> Thanks,
>> Dmitry
>>
>> [1] http://stackalytics.com/report/contribution/ironic-group/90
>> [2] http://stackalytics.com/?user_id=vsaienko=marks
>> [3] http://stackalytics.com/?user_id=mario-villaplana-j=marks
>> [4] http://stackalytics.com/?user_id=devananda=marks
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [stable/ocata] [nova] [devstack multi-node] nova-conductor complaining about "No cell mapping found for cell0"

[Prashant Shetty]

Thanks Matt, I found out there was issue in my nova.conf on controller.
[placement] section was missing on controller nova.conf.
Looks like devstack ignores configuring nova.conf if n-cpu is not running.

I have filed https://bugs.launchpad.net/devstack/+bug/1667219 and posted
fix https://review.openstack.org/#/c/437274/.
Let me know what you think.

Thanks,
Prashant

On Wed, Feb 22, 2017 at 8:19 PM, Matt Riedemann  wrote:

> On 2/22/2017 9:33 AM, Prashant Shetty wrote:
>
>> Thanks Matt.
>>
>> Here are the steps I have performed, I dont see any error related to
>> cell0 now but n-cond still not able to detect computes after discover as
>> well :(.
>>
>> Do we need any cell setting on nova-compute nodes as well?.
>>
>> vmware@cntr11:~/nsbu_cqe_openstack/devstack$ nova service-list
>> ++--+---+--+
>> -+---++-+
>> | Id | Binary   | Host  | Zone | Status  | State |
>> Updated_at | Disabled Reason |
>> ++--+---+--+
>> -+---++-+
>> | 7  | nova-conductor   | cntr11| internal | enabled | up|
>> 2017-02-22T14:23:34.00 | -   |
>> | 9  | nova-scheduler   | cntr11| internal | enabled | up|
>> 2017-02-22T14:23:28.00 | -   |
>> | 10 | nova-consoleauth | cntr11| internal | enabled | up|
>> 2017-02-22T14:23:33.00 | -   |
>> | 11 | nova-compute | esx-ubuntu-02 | nova | enabled | up|
>> 2017-02-22T14:23:35.00 | -   |
>> | 12 | nova-compute | esx-ubuntu-03 | nova | enabled | up|
>> 2017-02-22T14:23:35.00 | -   |
>> | 13 | nova-compute | esx-ubuntu-01 | nova | enabled | up|
>> 2017-02-22T14:23:28.00 | -   |
>> | 14 | nova-compute | kvm-3 | nova | enabled | up|
>> 2017-02-22T14:23:28.00 | -   |
>> | 15 | nova-compute | kvm-1 | nova | enabled | up|
>> 2017-02-22T14:23:32.00 | -   |
>> | 16 | nova-compute | kvm-2 | nova | enabled | up|
>> 2017-02-22T14:23:32.00 | -   |
>> ++--+---+--+
>> -+---++-+
>> vmware@cntr11:~/nsbu_cqe_openstack/devstack$
>> vmware@cntr11:~/nsbu_cqe_openstack/devstack$ nova-manage cell_v2
>> map_cell0 --database_connection
>> mysql+pymysql://root:vmware@127.0.0.1/nova?charset=utf8
>> 
>> vmware@cntr11:~/nsbu_cqe_openstack/devstack$ nova-manage cell_v2
>> simple_cell_setup --transport-url
>> rabbit://stackrabbit:vmware@60.0.24.49:5672/
>> 
>>
>> Cell0 is already setup
>> vmware@cntr11:~/nsbu_cqe_openstack/devstack$ nova-manage cell_v2
>> list_cells
>> +---+--+
>> |  Name | UUID |
>> +---+--+
>> |  None | ea6bec24-058a-4ba2-8d21-57d34c01802c |
>> | cell0 | ---- |
>> +---+--+
>> vmware@cntr11:~/nsbu_cqe_openstack/devstack$ nova-manage cell_v2
>> discover_hosts --verbose
>> Found 2 cell mappings.
>> Skipping cell0 since it does not contain hosts.
>> Getting compute nodes from cell: ea6bec24-058a-4ba2-8d21-57d34c01802c
>> Found 6 computes in cell: ea6bec24-058a-4ba2-8d21-57d34c01802c
>> Checking host mapping for compute host 'kvm-3':
>> a4b175d6-f5cc-45a8-9cf2-45726293b5c5
>> Checking host mapping for compute host 'esx-ubuntu-02':
>> 70281329-590c-4cb7-8839-fd84160345b7
>> Checking host mapping for compute host 'esx-ubuntu-03':
>> 04ea75a2-789e-483e-8d0e-4b0f79e012dc
>> Checking host mapping for compute host 'kvm-1':
>> dfabae3c-4ea9-4e8f-a496-8880dd9e89d9
>> Checking host mapping for compute host 'kvm-2':
>> d1cb30f5-822c-4c18-81fb-921ca676b834
>> Checking host mapping for compute host 'esx-ubuntu-01':
>> d00f8f16-af6b-437d-8136-bc744eb2472f
>> vmware@cntr11:~/nsbu_cqe_openstack/devstack$
>>
>> ​n-sch:
>> 2017-02-22 14:26:51.467 INFO nova.scheduler.host_manager
>> [req-56d1cefb-1dfb-481d-aaff-b7b6e05f83f0 None None] Successfully synced
>> instances from host 'kvm-2'.
>> 2017-02-22 14:26:51.608 INFO nova.scheduler.host_manager
>> [req-690b1a18-a709-49b2-bfad-2a6a75a3bee2 None None] Successfully synced
>> instances from host 'kvm-3'.
>> 2017-02-22 14:27:23.366 INFO nova.filters
>> [req-1085ec50-29f7-4946-81e2-03c1378e8077 alt_demo admin] Filter
>> RetryFilter returned 0 hosts
>> 2017-02-22 14:27:23.367 INFO nova.filters
>> [req-1085ec50-29f7-4946-81e2-03c1378e8077 alt_demo admin] Filtering
>> removed all hosts for the request with instance ID
>> 'c74f394f-c805-4b5c-ba42-507dfda2c5be'. Filter results: ['RetryFilter:
>> (start: 0,