Re: [openstack-dev] [Cinder] Marking Tintri driver as unsupported

[Silvan Kaiser]

Apoorva, Sean,
after some time i managed to bring up Quobyte CI last friday which tested
fine [1,2,3] for a short time and then ran into the same issues with
manage_snapshot
related tempest tests Apoorva describes (Starting chronologically at [4]).
>From here i see two steps:
a) look into the reason for the issue with manage_snapshot tests
b) a short note on how to proceed for marking drivers with reinstated CIs
back as supported is much appreciated
Best
Silvan

[1] https://review.openstack.org/#/c/412085/4
[2] https://review.openstack.org/#/c/313140/24
[3] https://review.openstack.org/#/c/418643/6
[4] https://review.openstack.org/#/c/363010/42




2017-01-15 20:46 GMT+01:00 Apoorva Deshpande :

> Sean,
>
> We have resolved issues related to our CI infra[1][2]. At this point
> manage_snapshot related tempest tests (2) are failing, but Tintri driver
> does not support manage/unmanage snapshot functionalities.
>
> Could you please assist me on how to skip these tests? We are using sos-ci
> for our CI runs.
>
> If this satisfies the compliance requirements can I propose a patch to
> revert changes introduced by [3] and make Tintri driver SUPPORTED again?
>
> [1] http://openstack-ci.tintri.com/tintri/refs-changes-69-353069-52/
> [2] http://openstack-ci.tintri.com/tintri/refs-changes-10-419710-2/
> [3] https://review.openstack.org/#/c/411975/
>
> On Sat, Dec 17, 2016 at 6:34 PM, Apoorva Deshpande 
> wrote:
>
>> Sean,
>>
>> As communicated earlier [1][2][3], Tintri CI is facing a devstack failure
>> issue, potentially due to [4].
>> We are working on it and request you to give us more time before
>> approving the unsupported driver patch [5].
>>
>>
>> [1] https://www.mail-archive.com/openstack-dev@lists.opensta
>> ck.org/msg97085.html
>> [2] https://www.mail-archive.com/openstack-dev@lists.opensta
>> ck.org/msg97057.html
>> [3] http://eavesdrop.openstack.org/irclogs/%23openstack-
>> cinder/%23openstack-cinder.2016-12-05.log.html
>> [4] https://review.openstack.org/#/c/399550/
>> [5] https://review.openstack.org/#/c/411975/
>>
>> On Sat, Dec 17, 2016 at 2:05 AM, Sean McGinnis 
>> wrote:
>>
>>> Checking name: Tintri CI
>>> last seen: 2016-12-16 16:50:50 (0:43:36 old)
>>> last success: 2016-11-16 20:42:29 (29 days, 20:45:46 old)
>>> success rate: 19%
>>>
>>> Per Cinder's non-compliance policy [1] this patch [2] marks
>>> the driver as unsupported and deprecated and it will be
>>> approved if the issue is not corrected by the next cycle.
>>>
>>> [1] https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drive
>>> rs#Non-Compliance_Policy
>>> [2] https://review.openstack.org/#/c/411975/
>>>
>>> 
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.op
>>> enstack.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
>
>


-- 
Dr. Silvan Kaiser
Quobyte GmbH
Hardenbergplatz 2, 10623 Berlin - Germany
+49-30-814 591 800 - www.quobyte.com
Amtsgericht Berlin-Charlottenburg, HRB 149012B
Management board: Dr. Felix Hupfeld, Dr. Björn Kolbeck, Dr. Jan Stender
__
OpenStack Development Mailing 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] [kolla] kolla-build building images that are known not to work for a given base/type

[Christian Berendt]

Hello David.

Sounds reasonable. I transferred your mail into a Launchpad bug:

https://bugs.launchpad.net/kolla/+bug/1656753

Christian.

-- 
Christian Berendt
Chief Executive Officer (CEO)

Mail: bere...@betacloud-solutions.de
Web: https://www.betacloud-solutions.de

Betacloud Solutions GmbH
Teckstrasse 62 / 70190 Stuttgart / Deutschland

Geschäftsführer: Christian Berendt
Unternehmenssitz: Stuttgart
Amtsgericht: Stuttgart, HRB 756139


__
OpenStack Development Mailing 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] [congress][oslo.config][keystone] NoSuchOptError: no such option project_domain_name in group [keystone_authtoken]

[ChangBo Guo]

Did you search keyword in http://codesearch.openstack.org/.  Hope that will
help you.

2017-01-13 6:31 GMT+08:00 Eric K :

> On a freshly stacked devstack (Jan 12), attempting to access
> `cfg.CONF.keystone_authtoken.project_domain_name` gave the
> error: NoSuchOptError: no such option project_domain_name in group
> [keystone_authtoken]
>
> I’m a little confused because it’s part of the [keystone_authtoken] config
> section generated by devstack. Could anyone point me to where these options
> are declared (I’ve searched several repos) and maybe why this option
> doesn’t exist? Thanks a lot!
>
> Of all the options supplied by devstack under [keystone_authtoken], the
> following were accessible:
> memcached_servers
> signing_dir
> cafile
> auth_uri
> auth_url
> auth_type
>
> But the following were unaccessible:
> project_domain_name
> project_name
> user_domain_name
> password
> username
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


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

Re: [openstack-dev] [kuryr] Ocata cycle ending and proposing new people as Kuryr cores

[Vikas Choudhary]

+1 for both.

On Sun, Jan 15, 2017 at 12:42 PM, Gal Sagie  wrote:

> +1 for both.
>
> On Sun, Jan 15, 2017 at 9:05 AM, Irena Berezovsky 
> wrote:
>
>>
>>
>> On Fri, Jan 13, 2017 at 6:49 PM, Antoni Segura Puimedon <
>> celeb...@gmail.com> wrote:
>>
>>> Hi fellow kuryrs!
>>>
>>> We are getting close to the end of the Ocata and it is time to look back
>>> and appreciate the good work all the contributors did. I would like to
>>> thank you all for the continued dedication and participation in gerrit, the
>>> weekly meetings, answering queries on IRC, etc.
>>>
>>> I also want to propose two people that I think will help us a lot as
>>> core contributors in the next cycles.
>>>
>>> For Kuryr-lib and kuryr-libnetwork I want to propose Liping Mao. Liping
>>> has been contributing a lot of since Mitaka, not just in code but in
>>> reviews catching important details and fixing bugs. It is overdue that he
>>> gets to help us even more!
>>>
>>> +1
>>
>>> For Kuryr-kubernetes I want to propose Ilya Chukhnakov. Ilya got into
>>> Kuryr at the end of the Newton cycle and has done a wonderful job in the
>>> Kubernetes integration contributing heaps of code and being an important
>>> part of the design discussions and patches. It is also time for him to
>>> start approving patches :-)
>>>
>>> +1
>>
>>>
>>> Let's have the votes until next Friday (unless enough votes are cast
>>> earlier).
>>>
>>> Regards,
>>>
>>> Toni
>>>
>>
>>
>> 
>> __
>> 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
>>
>>
>
>
> --
> Best Regards ,
>
> The G.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing 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] Patch for Eventlet so it will work IPv6 only, autodects ::1 etc

[Matt Grant]

Hi!

For when 127.0.0.1 is not there, soon to be.  Roots out one last piece of
IPv4 only in openstack.

Please find patch attached.

Thoughts please about approach.

Github repo is here:
https://github.com/grantma/deb-python-eventlet/tree/full-ipv6-defaults

Thank you!

Best Regards,

Matt Grant
diff --git a/eventlet/support/afinet.py b/eventlet/support/afinet.py
new file mode 100644
index 000..5c48b0f
--- /dev/null
+++ b/eventlet/support/afinet.py
@@ -0,0 +1,46 @@
+"""
+Test availabilty of AF_INET6 on a machine
+
+Uses socket API to determine configuration
+"""
+
+from socket import *
+
+def check_ipv6_lo_addr():
+try:
+sock = socket(AF_INET6, SOCK_STREAM)
+sock.bind(('::1', 0))
+return True
+except:
+return False
+
+def check_ipv6_hosts_file():
+if not check_ipv6_lo_addr():
+return False
+addrinfo = getaddrinfo(gethostname(), 0)
+if (addrinfo[0][0] == AF_INET6):
+return True
+return False
+
+core_use_ipv6_lo_addr = check_ipv6_lo_addr()
+use_ipv6_by_default = check_ipv6_hosts_file()
+
+ip_defaults = {}
+
+if core_use_ipv6_lo_addr:
+ip_defaults['core_lo_addr'] = '::1'
+ip_defaults['core_af_inet'] = AF_INET6
+else:
+ip_defaults['core_lo_addr'] = '127.0.0.1'
+ip_defaults['core_af_inet'] = AF_INET
+
+if use_ipv6_by_default:
+ip_defaults['af_inet'] = AF_INET6
+ip_defaults['null_addr'] = '::'
+ip_defaults['null_cidr'] = '::/0'
+ip_defaults['lo_addr'] = '::1'
+else:
+ip_defaults['af_inet'] = AF_INET
+ip_defaults['null_addr'] = '0.0.0.0'
+ip_defaults['null_cidr'] = '0.0.0.0/0'
+ip_defaults['lo_addr'] = '127.0.0.1'
diff --git a/eventlet/backdoor.py b/eventlet/backdoor.py
index 9a6797a..a282e2a 100644
--- a/eventlet/backdoor.py
+++ b/eventlet/backdoor.py
@@ -10,6 +10,7 @@ import traceback
 import eventlet
 from eventlet import hubs
 from eventlet.support import greenlets, get_errno
+from eventlet.support.afinet import ip_defaults
 
 try:
 sys.ps1
@@ -133,4 +134,4 @@ def backdoor(conn_info, locals=None):
 
 
 if __name__ == '__main__':
-backdoor_server(eventlet.listen(('127.0.0.1', 9000)), {})
+backdoor_server(eventlet.listen((ip_defaults['core_lo_addr'], 9000)), {})
diff --git a/eventlet/convenience.py b/eventlet/convenience.py
index 88343a9..8c26c27 100644
--- a/eventlet/convenience.py
+++ b/eventlet/convenience.py
@@ -5,9 +5,10 @@ from eventlet import greenpool
 from eventlet import greenthread
 from eventlet.green import socket
 from eventlet.support import greenlets as greenlet
+from eventlet.support.afinet import ip_defaults
 
 
-def connect(addr, family=socket.AF_INET, bind=None):
+def connect(addr, family=ip_defaults['af_inet'], bind=None):
 """Convenience function for opening client sockets.
 
 :param addr: Address of the server to connect to.  For TCP sockets, this is a (host, port) tuple.
@@ -22,7 +23,7 @@ def connect(addr, family=socket.AF_INET, bind=None):
 return sock
 
 
-def listen(addr, family=socket.AF_INET, backlog=50):
+def listen(addr, family=ip_defaults['af_inet'], backlog=50):
 """Convenience function for opening server sockets.  This
 socket can be used in :func:`~eventlet.serve` or a custom ``accept()`` loop.
 
diff --git a/eventlet/greenio/base.py b/eventlet/greenio/base.py
index 042f7d8..ee2950f 100644
--- a/eventlet/greenio/base.py
+++ b/eventlet/greenio/base.py
@@ -8,6 +8,7 @@ import warnings
 import eventlet
 from eventlet.hubs import trampoline, notify_opened, IOClosed
 from eventlet.support import get_errno, six
+from eventlet.support.afinet import ip_defaults
 
 __all__ = [
 'GreenSocket', '_GLOBAL_DEFAULT_TIMEOUT', 'set_nonblocking',
@@ -129,7 +130,7 @@ class GreenSocket(object):
 # This placeholder is to prevent __getattr__ from creating an infinite call loop
 fd = None
 
-def __init__(self, family=socket.AF_INET, *args, **kwargs):
+def __init__(self, family=ip_defaults['af_inet'], *args, **kwargs):
 should_set_nonblocking = kwargs.pop('set_nonblocking', True)
 if isinstance(family, six.integer_types):
 fd = _original_socket(family, *args, **kwargs)
diff --git a/eventlet/support/greendns.py b/eventlet/support/greendns.py
index 8d5c7d6..eb9075c 100644
--- a/eventlet/support/greendns.py
+++ b/eventlet/support/greendns.py
@@ -41,6 +41,8 @@ from eventlet.green import os
 from eventlet.green import time
 from eventlet.green import select
 from eventlet.support import six
+from eventlet.support.afinet import ip_defaults
+from eventlet.support.afinet import use_ipv6_by_default
 
 
 def import_patched(module_name):
@@ -72,6 +74,11 @@ for pkg in dns.rdtypes.ANY.__all__:
 del import_patched
 sys.path.pop(0)
 
+# Done here to prevent import nesting errors
+if use_ipv6_by_default:
+def_rdtype = dns.rdatatype.
+else:
+def_rdtype = dns.rdatatype.A
 
 socket = _socket_nodns
 
@@ -302,7 +309,7 @@ class ResolverProxy(object):
 self._resolver = 

[openstack-dev] [tripleo] tripleoclient release : January 19th

[Emilien Macchi]

https://releases.openstack.org/ocata/schedule.html

It's time to release python-tripleoclient this week.
We still have 15 bugs in progress targeted for ocata-3.
https://goo.gl/R2hO4Z

Please triage them to pike-1 unless they are critical or high, so we
need to fix them afterward and backport it to stable/ocata.

We'll release the client by Thursday 19th end of day.
Please let us know any blocker,
-- 
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

Re: [openstack-dev] [tripleo] Release notes in TripleO

[Emilien Macchi]

On Sun, Jan 15, 2017 at 1:29 PM,   wrote:
> Does that applies to drivers also?

It applies to every projects mentioned in the list, features / bugs
related to drivers included.

> -Original Message-
> From: Ben Nemec [mailto:openst...@nemebean.com]
> Sent: Wednesday, January 11, 2017 8:49 AM
> To: OpenStack Development Mailing List (not for usage questions) 
> 
> Subject: Re: [openstack-dev] [tripleo] Release notes in TripleO
>
>
>
> On 01/11/2017 08:24 AM, Emilien Macchi wrote:
>> On Wed, Jan 11, 2017 at 9:21 AM, Emilien Macchi  wrote:
>>> Greetings,
>>>
>>> OpenStack has been using reno [1] to manage release notes for a while
>>> now and it has been proven to be super useful.
>>> Puppet OpenStack project adopted it in Mitaka and since then we loved it.
>>> The path to use reno in a project is not that simple. People need to
>>> get used of adding a release note every time they submit a patch that
>>> fix a bug or add a new feature. This thing takes time and will
>>> require some involvement from the team.
>>> Though the benefits are really here:
>>> - our users will understand what new features we have developed
>>> - our users will learn deprecations.
>>> - developers will have a way to communicate with non-devs, expressing
>>> the work done in TripleO (eg: to product managers, etc).
>>>
>>> This is an example of a release note:
>>> https://github.com/openstack/puppet-nova/blob/master/releasenotes/not
>>> es/nova-placement-30566167309fd124.yaml
>>>
>>> And the output:
>>> http://docs.openstack.org/releasenotes/puppet-nova/unreleased.html
>>>
>>> So here's a plan proposal:
>>> 1) Emilien to add all CI jobs and required bits to have reno in
>>> TripleO (already done for python-tripleoclient). I'm doing the rest
>>> of the projects this week.
>>
>> I forgot to mention which projects we would target for Ocata:
>> - python-tripleoclient
>> - puppet-tripleo
>> - tripleo-common
>> - tripleo-heat-templates
>> - tripleo-puppet-elements
>> - tripleo-ui
>> - tripleo-validations
>> - tripleo-quickstart and tripleo-quickstart-extras
>
> +instack-undercloud
>
> Otherwise this all sounds good to me.  Adding reno to more tripleo projects 
> has been on my todo list for months.
>
>>
>>> 2) Emilien with the team (please ping me if you volunteer to help) to
>>> write Ocata release notes before the release (we have ~ one month).
>>> 3) Once 1) is done, I would ask to the team to use it.
>>>
>>> Regarding 3), here are some thoughts:
>>> During pike-1 and pike-2:
>>> I wouldn't -1 a patch that does't have a release note, but rather
>>> comment and give some guidance to the committer and ask if it's
>>> something doable. Otherwise, proposing a patch on top of it with the
>>> release note. That way, we don't force people to use it immediately,
>>> but instead giving them some guidance on why and how to use it,
>>> directly in the review.
>>> During pike-3:
>>> Start -1 patches which don't have a release note. I think 3 or 4
>>> months is fair to learn how to use reno (it takes less than 5 min to
>>> create a good release note).
>>>
>>> Any feedback is highly welcome, let's make TripleO releases better!
>>>
>>> Thanks,
>>>
>>> [1] http://docs.openstack.org/developer/reno
>>> --
>>> 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
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



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

Re: [openstack-dev] [nova][puppet][tripleo][kolla][fuel] Let's talk nova cell v2 deployments and upgrades

[Matt Riedemann]

On 1/13/2017 6:56 PM, Matt Riedemann wrote:

On 1/13/2017 2:05 PM, Matt Riedemann wrote:


Documenting this is going to be a priority. We should have something up
for review in Nova by next week (like Monday), at least a draft.



Dan Smith has a start on the docs here:

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



We got some more updates in the cells v2 wiki here:

https://wiki.openstack.org/wiki/Nova-Cells-v2

We now have patches up for creating, listing and deleting cells v2 cells.

Dan Smith has a patch up to fix the cell0 DB connection naming (it was 
using the API DB connection but should be the main DB connection), this 
is going to require a change to the from-newton upgrade script in 
grenade (those patches are also update in grenade and devstack).


We've had good review on Dan's initial docs patch so I expect that to be 
merged on Monday.


--

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] [RDO][DLRN] DLRN worker downtime during the weekend

[Javier Pena]

> Hi RDO,
> 
> We need to run some maintenance operations on the DLRN instance next weekend,
> starting on Friday 13 @ 19:00 UTC. These are required to reduce the storage
> usage of the master and newton workers. The impact is:
> 
> - During the weekend, no new packages will be processed for the centos-master
> and centos-newton workers
> - The existing repositories will be available as usual.
> 
> I will send a follow-up e-mail once the maintenance has been finished. Please
> do not hesitate to contact me if you have any concerns.
> 

The maintenance is now completed, and all workers are building packages again.

Please reach out to us if you find any issue.

Regards,
Javier

> Regards,
> Javier
> 
> __
> OpenStack Development Mailing 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] [TripleO][CI]

[Sagi Shnaidman]

Hi, all

FYI, the periodic TripleO nonha jobs fail because of introspection failure,
there is opened bug in mistral:

Ironic introspection fails because unexpected keyword "insecure"
https://bugs.launchpad.net/tripleo/+bug/1656692

and marked as promotion blocker.

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

Re: [openstack-dev] [Cinder] Marking Tintri driver as unsupported

[Apoorva Deshpande]

Sean,

We have resolved issues related to our CI infra[1][2]. At this point
manage_snapshot related tempest tests (2) are failing, but Tintri driver
does not support manage/unmanage snapshot functionalities.

Could you please assist me on how to skip these tests? We are using sos-ci
for our CI runs.

If this satisfies the compliance requirements can I propose a patch to
revert changes introduced by [3] and make Tintri driver SUPPORTED again?

[1] http://openstack-ci.tintri.com/tintri/refs-changes-69-353069-52/
[2] http://openstack-ci.tintri.com/tintri/refs-changes-10-419710-2/
[3] https://review.openstack.org/#/c/411975/

On Sat, Dec 17, 2016 at 6:34 PM, Apoorva Deshpande 
wrote:

> Sean,
>
> As communicated earlier [1][2][3], Tintri CI is facing a devstack failure
> issue, potentially due to [4].
> We are working on it and request you to give us more time before approving
> the unsupported driver patch [5].
>
>
> [1] https://www.mail-archive.com/openstack-dev@lists.
> openstack.org/msg97085.html
> [2] https://www.mail-archive.com/openstack-dev@lists.
> openstack.org/msg97057.html
> [3] http://eavesdrop.openstack.org/irclogs/%23openstack-cinder/%
> 23openstack-cinder.2016-12-05.log.html
> [4] https://review.openstack.org/#/c/399550/
> [5] https://review.openstack.org/#/c/411975/
>
> On Sat, Dec 17, 2016 at 2:05 AM, Sean McGinnis 
> wrote:
>
>> Checking name: Tintri CI
>> last seen: 2016-12-16 16:50:50 (0:43:36 old)
>> last success: 2016-11-16 20:42:29 (29 days, 20:45:46 old)
>> success rate: 19%
>>
>> Per Cinder's non-compliance policy [1] this patch [2] marks
>> the driver as unsupported and deprecated and it will be
>> approved if the issue is not corrected by the next cycle.
>>
>> [1] https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drive
>> rs#Non-Compliance_Policy
>> [2] https://review.openstack.org/#/c/411975/
>>
>> 
>> __
>> 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] [tripleo] Release notes in TripleO

[Arkady.Kanevsky]

Does that applies to drivers also?

-Original Message-
From: Ben Nemec [mailto:openst...@nemebean.com] 
Sent: Wednesday, January 11, 2017 8:49 AM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [tripleo] Release notes in TripleO



On 01/11/2017 08:24 AM, Emilien Macchi wrote:
> On Wed, Jan 11, 2017 at 9:21 AM, Emilien Macchi  wrote:
>> Greetings,
>>
>> OpenStack has been using reno [1] to manage release notes for a while 
>> now and it has been proven to be super useful.
>> Puppet OpenStack project adopted it in Mitaka and since then we loved it.
>> The path to use reno in a project is not that simple. People need to 
>> get used of adding a release note every time they submit a patch that 
>> fix a bug or add a new feature. This thing takes time and will 
>> require some involvement from the team.
>> Though the benefits are really here:
>> - our users will understand what new features we have developed
>> - our users will learn deprecations.
>> - developers will have a way to communicate with non-devs, expressing 
>> the work done in TripleO (eg: to product managers, etc).
>>
>> This is an example of a release note:
>> https://github.com/openstack/puppet-nova/blob/master/releasenotes/not
>> es/nova-placement-30566167309fd124.yaml
>>
>> And the output:
>> http://docs.openstack.org/releasenotes/puppet-nova/unreleased.html
>>
>> So here's a plan proposal:
>> 1) Emilien to add all CI jobs and required bits to have reno in 
>> TripleO (already done for python-tripleoclient). I'm doing the rest 
>> of the projects this week.
>
> I forgot to mention which projects we would target for Ocata:
> - python-tripleoclient
> - puppet-tripleo
> - tripleo-common
> - tripleo-heat-templates
> - tripleo-puppet-elements
> - tripleo-ui
> - tripleo-validations
> - tripleo-quickstart and tripleo-quickstart-extras

+instack-undercloud

Otherwise this all sounds good to me.  Adding reno to more tripleo projects has 
been on my todo list for months.

>
>> 2) Emilien with the team (please ping me if you volunteer to help) to 
>> write Ocata release notes before the release (we have ~ one month).
>> 3) Once 1) is done, I would ask to the team to use it.
>>
>> Regarding 3), here are some thoughts:
>> During pike-1 and pike-2:
>> I wouldn't -1 a patch that does't have a release note, but rather 
>> comment and give some guidance to the committer and ask if it's 
>> something doable. Otherwise, proposing a patch on top of it with the 
>> release note. That way, we don't force people to use it immediately, 
>> but instead giving them some guidance on why and how to use it, 
>> directly in the review.
>> During pike-3:
>> Start -1 patches which don't have a release note. I think 3 or 4 
>> months is fair to learn how to use reno (it takes less than 5 min to 
>> create a good release note).
>>
>> Any feedback is highly welcome, let's make TripleO releases better!
>>
>> Thanks,
>>
>> [1] http://docs.openstack.org/developer/reno
>> --
>> 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
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [heat][TripleO] Adding interfaces to environment files?

[Jiri Tomasek]

On 8.6.2016 11:15, Steven Hardy wrote:

On Tue, Jun 07, 2016 at 03:57:31PM -0400, Jay Dobies wrote:

All,

We've got some requirements around adding some interfaces to the heat
environment file format, for example:

1. Now that we support passing un-merged environment files to heat, it'd be
good to support an optional description key for environments,

I've never understood why the environment file doesn't have a description
field itself. Templates have descriptions, and IMO it makes sense for an
environment to describe what its particular additions to the
parameters/registry do.

I'd be happy to write that patch, but I wanted to first double check that
there wasn't a big philosophical reason why it shouldn't have a description.

AFAIK there are two reasons:

1. Until your recent work landed, any description would be destroyed by the
client when it merged the environments

2. We've got no way to retrieve the environment descriptions from heat (as
Zane mentioned in his reply).

I'm suggesting we fix (2) as a followup step to your work to add an API
that returns the merged environment, e.g add an API that returns the files
map associated with a stack, and one that can list the environments in use
(not just the resolved/merged environment).


such that we
could add an API (in addition to the one added by jdob to retrieve the
merged environment for a running stack) that can retrieve
all-the-environments and we can easily tell which one does what (e.g to
display in a UI perhaps)

I'm not sure I follow. Are you saying the API would return the list of
descriptions, or the actual contents of each environment file that was
passed in?

The actual contents, either by passing a list of environment filenames, and
providing another API that can return the files map containing the files,
or by having one API call that can return a map of filenames to content for
all environments passed via environment_files.

Basically, I think we should expose all data as passed to create_stack in
it's original form, and (as you already added) in it's post-processed form
e.g the merged environment.


Currently, the environment is merged before we do anything with it. We'd
have to change that to store... I'm not entirely sure. Multiple environments
in the DB per stack? Is there a raw_environment in the DB that we would
leverage?

We just need to store the environment_files list - we already store the
environment files in the files map

https://review.openstack.org/#/c/241662/17/heat/engine/service.py

So, we need to store environment_files as well as the output of
_merge_environments, then add some sort of API to expose both that list and
the files map.

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


I'd like to revive this discussion. Fairly often the environment is used 
to define certain feature. It would be really beneficial if environment 
itself could carry its documentation and it was possible to 
programmatically retrieve it. Optional metadata section would be IMHO a 
good solution. HOT spec already has such section in template resources 
section [1].


[1] 
http://docs.openstack.org/developer/heat/template_guide/hot_spec.html#resources-section


-- Jirka

__
OpenStack Development Mailing 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] [Vitrage] About alarms reported by datasource and the alarms generated by vitrage evaluator

[Yujun Zhang]

About fault and alarm, what I was thinking about the causal/deducing chain
in root cause analysis.

Fault state means the resource is not fully functional and it is evaluated
by related indicators. There are alarms on events like power loss or
measurands like CPU high, memory low, temperature high. There are also
alarms based on deduced state, such as "host fault", "instance fault".

So an example chain would be

   - "FAULT: power line cut off" =(monitor)=> "ALARM: host power loss"
   =(inspect)=> "FAULT: host is unavailable" =(action)=> "ALARM: host fault"
   - "FAULT: power line cut off" =(monitor)=> "ALARM: host power loss"
   =(inspect)=> "FAULT: host is unavailable" =(inspect)=> "FAULT: instance is
   unavailable" =(action)=> "ALARM: instance fault"

If we omit the resource, then we get the causal chain as it is in Vitrage

   - "ALARM: host power loss" =(causes)=> "ALARM: host fault"
   - "ALARM: host power loss" =(causes)=> "ALARM: instance fault"

But what the user care about might be there "FAULT: power line cut off"
causes all these alarms. What I haven't made clear yet is the equivalence
between fault and alarm.

I may have made it more complex with my *immature* thoughts. It could be
even more complex if we consider multiple upstream causes and downstream
outcome. It may be an interesting topic to be discussed in design session.

On Sun, Jan 15, 2017 at 9:21 PM Afek, Ifat (Nokia - IL) 
wrote:

> Hi Yinliyin,
>
>
>
> There are two use cases:
>
> One is yours, where you have a single monitor that generates “real”
> alarms, and Vitrage that generates deduced alarms.
>
> Another is where someone has a few monitors, and there might be a
> collision/equivalence between their alarms.
>
>
>
> The solution that you suggested might solve the first use case, but I
> wouldn’t want to ignore the second one, which is also valid.
>
>
>
> Regarding some of your specific suggestions:
>
> 1.   In templates, we only define the alarm entity for the datasource
> that the alarm is reported by, such as Nagios.
>
> [Ifat] This will only work for a single monitor.
>
>2.  When evaluator deduce an alarm, it would raise the alarm with
> the type set to be the datasource that would report the alarm, not be
> vitrage.
>
> [Ifat] I don’t think this is right. In Vitrage Alarm view in the UI,
> displaying the deduced alarm as “Nagios” is misleading, since Nagios did
> not report this alarm.
>
>
>
> I can think of a solution that is specific to the deduced alarms case,
> where we will replace a Vitrage alarm with a “real” alarm whenever there is
> a collision. This solution is easier, but we should carefully examine all
> use cases to make sure there is no ambiguity. However, for the more general
> use case I would prefer the option that we discussed in a previous mail, of
> having two (or more) alarms connected with a ‘equivalent’ relationship.
>
>
>
> What do you think?
>
> Ifat.
>
>
>
>
>
> *From: *"yinli...@zte.com.cn" 
> *Date: *Saturday, 14 January 2017 at 09:57
>
> · It won’t solve the general problem of two different monitors
> that raise the same alarm
>
> ·   [yinliyin] Generally, we would only deploy one monitor for a
> same alarm.
>
> · It won’t solve possible conflicts of timestamp and severity
> between different monitors
>
> ·  [yinliyin] Please see the following contents.
>
> · It will make the decision of when to delete the alarm more
> complex (delete it when the deduced alarm is deleted? When Nagios alarm is
> deleted? both? And how to change the timestamp and severity in these cases?)
>
> ·  [yinliyin] Please see the following contents.
>
>The following is the basic idea of solving the problem in this
> situation:
>
>1.  In templates, we only define the alarm entity for the
> datasource that the alarm is reported by, such as Nagios.
>
>2.  When evaluator deduce an alarm, it would raise the alarm with
> the type set to be the datasource that would report the alarm, not be
> vitrage.
>
>3.  When entity_graph get the events from the "evaluator_queue"(all
> the alarms in the "evaluator_queue" are deduced alarms), it queries the
> graph to find out whether there was a same alarm reported  by datasource.
> If  it was true,  it would discard the alarm.
>
>   4.  When entity_graph get the events from "queue",  it queries the
> graph to find out whether there was a same alarm deduced by evaluator. If
> it was true, it would replace the alarm in the graph with the newly arrived
> alarm reported by the datasource.
>
>  5.  When the evaluator deduced that an alarm would be deleted, it
> deletes the alarm whatever the generation type of the alarm be(Generated by
> datasource or deduced by evaluator).
>
>  6. When datasource reports recover event of an alarm, entity_graph
> would query graph to find out whether the alarm was exist. If the alarm was
> not exist, entity_graph would 

Re: [openstack-dev] [release][ptl] not planning to serve as release PTL for Pike

[Paul Belanger]

On Fri, Jan 13, 2017 at 03:00:17PM -0500, Doug Hellmann wrote:
> I announced this at the release team meeting on 6 Jan, but thought
> I should also post to the list as well:  I do not plan to serve as
> the Release Management team PTL for the Pike release cycle.
> 
> It has been my pleasure to serve as PTL, and we've almost finished
> the automation work that I envisioned when I joined the team. Now
> I would like to shift my focus to some other projects within the
> community.  I will still be an active member of the Release Management
> team, helping with new initiatives and reviews for releases.
> 
> Doug
> 
Thanks for all your efforts driving the automation of OpenStack releases. Great
work.

---
Paul

__
OpenStack Development Mailing 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] bug #1655656

[Abed Abu-Dbai]

Hi,

I updated the description accordingly
 
https://bugs.launchpad.net/devstack/+bug/1655656

Thanks,
Abed

__
OpenStack Development Mailing 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] [vitrage] code organization for trace generator and

[Yujun Zhang]

I heard the exrex story from Elisha, though I didn't quite understand the
rule of allowed library in OpenStack.

I have also kept it in static datasource, but it was not so convenient to
jump over these long files to find the static datasource related function

On Sun, Jan 15, 2017 at 5:24 PM Afek, Ifat (Nokia - IL) 
wrote:

> Hi Yujun,
>
>
>
> The motivation in building the mocks this way was that we could easily
> generate a series of events which are different from one another. There
> used to be a distinction between ‘static fields’ and ‘dynamic fileds’, and
> a library named exrex was used to generate random values by regex
> definitions (e.g. "instance-[0-9]{7}"). We were then contacted by the infra
> team that exrex was not a known library in OpenStack (did not appear in
> global-requirements), and we decided to remove it. You can still see in the
> code leftovers from the old implementation.
>
>
>
> I’m not sure if all datasources need the ability to generate a series of
> events. But since this is the way it was built, I decided to keep the
> structure in the Doctor datasourcde that I’ve recently written.
>
>
>
> I’ll be happy to also hear Elisha’s opinion about it, as he created this
> mechanism.
>
>
>
> Best Regards,
>
> Ifat.
>
>
>
>
>
> *From: *Yujun Zhang 
> *Reply-To: *"OpenStack Development Mailing List (not for usage
> questions)" 
> *Date: *Friday, 13 January 2017 at 09:43
> *To: *"OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> *Subject: *[openstack-dev] [vitrage] code organization for trace
> generator and
>
>
>
> Hi, Root Causers
>
>
>
> In the implementation of static driver unit test, the most difficult part
> I've encountered is the mock driver and trace generator.
>
>
>
> Is there any particular reason to put all mock driver and transformer
> specs in the same file `trace_generator.py` and `mock_driver.py`? Would it
> be easier to maintain and extend if we organize the specs and drivers in
> datasource, e.g. `mock.static`, `mock.nova.host` and etc?
>
>
>
> --
>
> Yujun
> __
> OpenStack Development Mailing 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] 答复: Re: [Vitrage] About alarms reported by datasource and the alarms generated by vitrage evaluator

[Afek, Ifat (Nokia - IL)]

Hi Yinliyin,

There are two use cases:
One is yours, where you have a single monitor that generates “real” alarms, and 
Vitrage that generates deduced alarms.
Another is where someone has a few monitors, and there might be a 
collision/equivalence between their alarms.

The solution that you suggested might solve the first use case, but I wouldn’t 
want to ignore the second one, which is also valid.

Regarding some of your specific suggestions:

1.   In templates, we only define the alarm entity for the datasource that 
the alarm is reported by, such as Nagios.
[Ifat] This will only work for a single monitor.
   2.  When evaluator deduce an alarm, it would raise the alarm with the 
type set to be the datasource that would report the alarm, not be vitrage.
[Ifat] I don’t think this is right. In Vitrage Alarm view in the UI, displaying 
the deduced alarm as “Nagios” is misleading, since Nagios did not report this 
alarm.

I can think of a solution that is specific to the deduced alarms case, where we 
will replace a Vitrage alarm with a “real” alarm whenever there is a collision. 
This solution is easier, but we should carefully examine all use cases to make 
sure there is no ambiguity. However, for the more general use case I would 
prefer the option that we discussed in a previous mail, of having two (or more) 
alarms connected with a ‘equivalent’ relationship.

What do you think?
Ifat.


From: "yinli...@zte.com.cn" 
Date: Saturday, 14 January 2017 at 09:57


· It won’t solve the general problem of two different monitors that 
raise the same alarm

·   [yinliyin] Generally, we would only deploy one monitor for a same 
alarm.

· It won’t solve possible conflicts of timestamp and severity between 
different monitors

·  [yinliyin] Please see the following contents.

· It will make the decision of when to delete the alarm more complex 
(delete it when the deduced alarm is deleted? When Nagios alarm is deleted? 
both? And how to change the timestamp and severity in these cases?)

·  [yinliyin] Please see the following contents.


   The following is the basic idea of solving the problem in this situation:

   1.  In templates, we only define the alarm entity for the datasource 
that the alarm is reported by, such as Nagios.

   2.  When evaluator deduce an alarm, it would raise the alarm with the 
type set to be the datasource that would report the alarm, not be vitrage.

   3.  When entity_graph get the events from the "evaluator_queue"(all the 
alarms in the "evaluator_queue" are deduced alarms), it queries the graph to 
find out whether there was a same alarm reported  by datasource. If  it was 
true,  it would discard the alarm.

  4.  When entity_graph get the events from "queue",  it queries the graph 
to find out whether there was a same alarm deduced by evaluator. If it was 
true, it would replace the alarm in the graph with the newly arrived alarm 
reported by the datasource.

 5.  When the evaluator deduced that an alarm would be deleted, it deletes 
the alarm whatever the generation type of the alarm be(Generated by datasource 
or deduced by evaluator).

 6. When datasource reports recover event of an alarm, entity_graph would 
query graph to find out whether the alarm was exist. If the alarm was not 
exist, entity_graph would discard the 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

Re: [openstack-dev] [Vitrage] About alarms reported by datasource and the alarms generated by vitrage evaluator

[Afek, Ifat (Nokia - IL)]

From: Yujun Zhang 
Date: Thursday, 12 January 2017 at 17:37

On Thu, Jan 12, 2017 at 5:12 PM Afek, Ifat (Nokia - IL) 
> wrote:

'deduced' vs 'monitored' would be good enough for most cases. Unless we have 
identify some real use case, I also think there is no need for bring in 
quantitative indicator like counter or probability.

[Ifat] I agree.

Personally, I don’t think this is needed. I think that if Nagios reports an 
error, then it is confident enough without getting it from another monitor.

You are right. We would consider a reported alarm as a reliable indicator of 
fault. What I was thinking about is: when we the alarm is not seen, can we be 
sure there is no fault?

Another situation is slow upstream alarm with fast downstream alarm. I don't 
have an actual example for the moment, so please allow me to imagine an extreme 
condition.

Suppose host fault will cause instance fault. But due to some restriction, the 
host fault is scanned every 1 hour, but instance fault can be scanned every 1 
second. Now, we get alarms from 10 instance in the same host. Can we deduce 
that the host is likely in fault status? And we may raise a "deduced" alarm on 
the host and trigger an immediate scan which may result in a "monitored" alarm. 
In this way, we reduce the time of detecting the root cause, i.e host fault.

[Ifat] I understand the use case.


An alternative solution is to distinguish fault from alarm. Alarm is actually a 
reflection of fault status.  Beside the directly linked alarm, fault status can 
also be deduced from downstream alarms. I haven't think over this model yet, it 
just flashed over my mind. Any comments are welcome.

[Ifat] Isn’t ‘fault vs. alarm’ just a different terminology for ‘deduced vs. 
monitored’?


__
OpenStack Development Mailing 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] [vitrage] code organization for trace generator and

[Afek, Ifat (Nokia - IL)]

Hi Yujun,

The motivation in building the mocks this way was that we could easily generate 
a series of events which are different from one another. There used to be a 
distinction between ‘static fields’ and ‘dynamic fileds’, and a library named 
exrex was used to generate random values by regex definitions (e.g. 
"instance-[0-9]{7}"). We were then contacted by the infra team that exrex was 
not a known library in OpenStack (did not appear in global-requirements), and 
we decided to remove it. You can still see in the code leftovers from the old 
implementation.

I’m not sure if all datasources need the ability to generate a series of 
events. But since this is the way it was built, I decided to keep the structure 
in the Doctor datasourcde that I’ve recently written.

I’ll be happy to also hear Elisha’s opinion about it, as he created this 
mechanism.

Best Regards,
Ifat.


From: Yujun Zhang 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Friday, 13 January 2017 at 09:43
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: [openstack-dev] [vitrage] code organization for trace generator and

Hi, Root Causers

In the implementation of static driver unit test, the most difficult part I've 
encountered is the mock driver and trace generator.

Is there any particular reason to put all mock driver and transformer specs in 
the same file `trace_generator.py` and `mock_driver.py`? Would it be easier to 
maintain and extend if we organize the specs and drivers in datasource, e.g. 
`mock.static`, `mock.nova.host` and etc?

--
Yujun
__
OpenStack Development Mailing 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] [Octavia] - LBaaS and IPv6

[Nir Magnezi]

Yes.

On Sun, Jan 8, 2017 at 2:07 PM, Alex Stafeyev  wrote:

> Hi,
> Does lbaas support LB in ipv6 network?
>
> tnx
>
> --
> Alexander Stafeyev
> QE Engineer, Neutron, Openstack
> Red Hat
>
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev