Re: [openstack-dev] [nova] How to use resource_providers for shared disk resources (NFS)

[Shewale, Bhagyashri]

Hi Jay,

Thank you for information. :)

Thank you,

Bhagyashri

-Original Message-
From: Jay Pipes [mailto:jaypi...@gmail.com] 
Sent: Monday, January 30, 2017 11:31 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [nova] How to use resource_providers for shared 
disk resources (NFS)

On 01/30/2017 05:55 AM, Shewale, Bhagyashri wrote:
> Hi nova devs,
>
> How can I use placement api's if my instance path is mounted on shared 
> storage server (e.g. NFS)?
>
> I am trying to set multinode setup with NFS shared storage for all 
> nodes to share disk resources along with placement services. As of now 
> it is creating resource providers for each of the compute node and 
> adds the DISK_GB for each resource provider.

Correct. Well, I mean that this behaviour is expected (and is the identical 
behaviour that exists in Nova today with the non-placement API).

We have not yet merged code that handles the correct accounting of shared 
storage, unfortunately. :(

When we merge all the code that handles shared storage [1], you should be able 
to do something like the following:

STORAGE_UUID=`openstack aggregate-create "my NFS storage pool"` openstack 
aggregate-host-associated $STORAGE_UUID $UUID_COMPUTE1 openstack 
aggregate-host-associated $STORAGE_UUID $UUID_COMPUTE2

Add some inventory to the aggregate, like so:

PUT /resource_providers/$STORAGE_UUID/inventories
{
   "DISK_GB": {
 "total": 1000,
 "reserved": 0,
 "min_unit": 10,
 "max_unit": 1000,
 "allocation_ratio": 1.0
   }
}

and then the compute nodes will just "auto-heal" themselves, removing "local" 
DISK_GB inventories and using the DISK_GB inventory of the storage pool.

But, again, this code isn't yet merged.

We're making slow but steady progress, but I can't tell you when the code will 
fully land, unfortunately.

Best,
-jay

[1] Code that builds upon this patch: 
https://review.openstack.org/#/c/407309/

> For example below are my environment details:
>
> NODE A: compute
> NODE B: controller + compute
>
> Following entries are made in resource_providers table:
>
> +-+-++--+++--+
>
> | created_at  | updated_at  | id |
> uuid | name   |
> generation | can_host |
>
> +-+-++--+++--+
>
> | 2017-01-30 06:49:17 | 2017-01-30 09:12:06 |  1 |
> 6cbbaf2b-5b8c-4f38-8b34-ee23791056a6 | openstack-VirtualBox   |
> 3 |0 |
>
> | 2017-01-30 09:02:29 | 2017-01-30 09:11:03 |  3 |
> bad71c26-8f36-43ea-abf4-bdbeffda9e54 | openstack-VirtualBox-1 |
> 2 |0 |
>
> +-+-++--+++--+
>
>
>
> Following are the entries of inventories tables, of which 89 indicates 
> the DISK_GB (size of shared storage):
>
>
>
> +-+-++--+---+---+--+--+--+---+--+
>
> | created_at  | updated_at  | id | resource_provider_id
> | resource_class_id | total | reserved | min_unit | max_unit | 
> | step_size allocation_ratio |
>
> +-+-++--+---+---+--+--+--+---+--+
>
> | 2017-01-30 06:49:19 | 2017-01-30 09:10:37 |  1 |1
> | 0 | 1 |0 |1 |1 | 1
> |   16 |
>
> | 2017-01-30 06:49:19 | 2017-01-30 09:10:37 |  2 |1
> | 1 | 11210 |  512 |1 |11210 | 1
> |  1.5 |
>
> | 2017-01-30 06:49:19 | 2017-01-30 09:10:37 |  3 |1
> | 2 |89 |0 |1 |   89 | 1
> |1 |
>
> | 2017-01-30 09:02:31 | 2017-01-30 09:11:03 |  7 |3
> | 0 | 1 |0 |1 |1 | 1
> |   16 |
>
> | 2017-01-30 09:02:31 | 2017-01-30 09:11:03 |  8 |3
> | 1 | 10253 |  512 |1 |10253 | 1
> |  1.5 |
>
> | 2017-01-30 09:02:31 | 2017-01-30 09:11:03 |  9 |3
> | 2 |89 |0 |1 |   89 | 1
> |1 |
>
> +-+-++--+---+---+--+--+--+---+--+
>
>
>
> However still I am able to create the instances over the size of 
> actual shared storage.
>
>
>
> Please let me know how to configure resource_providers in case of 
> shared storage 

Re: [openstack-dev] [ux] Future of the OpenStack UX team

[Thierry Carrez]

Shamail wrote:
>> Sorry for not noticing this thread and replying earlier.
>>
>> I've now reviewed the minutes from the meeting, and I support thingee's 
>> suggestion of having a UX working group. This way, UX can get the attention 
>> it rightly deserves. Without the research and guidelines provided by the UX 
>> team, user-facing projects (such as Docs) will be poorer. I believe that 
>> it's in Foundations best interests to ensure that UX work is ongoing, and 
>> adequately supported, in the same way as Marketing and other user outreach 
>> services. 
> +1
>>
>> I am happy to work with Foundation (on behalf of the Docs team) to determine 
>> how this would work in practice.
> I'm happy to help as well.  The Product working group recently started using 
> Personas in our user stories and I also participated in the Personas workshop 
> with the UX team.

This working group will need a driver/leader/steward to set up at least
the first meetings and see who would be ready to do what in UX land.

Any volunteer ?

-- 
Thierry Carrez (ttx)

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

[openstack-dev] [Horizon] Meeting at 20:00 UTC this Wednesday, 1st February

[Richard Jones]

Hi folks,

The Horizon team will be having our next meeting at 20:00 UTC this
Wednesday, 1st February in #openstack-meeting-3

Meeting agenda is here: https://wiki.openstack.org/wiki/Meetings/Horizon

Anyone is welcome to to add agenda items and everyone interested in
Horizon is encouraged to attend.


Cheers,

Richard

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

[openstack-dev] [nova] Apparently cells v1 doesn't want you swapping volumes

[Matt Riedemann]

We've got a gate blocker introduced today:

https://bugs.launchpad.net/devstack/+bug/1660511

I've got patches up to nova and devstack (first one in wins) to fix the 
issue by blacklisting testing swap volume in the cells v1 job.


This is an FYI since I've been seeing nova changes in the gate get 
kicked out because of this bug.


--

Thanks,

Matt Riedemann

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

[openstack-dev] [Infra][Tacker] Creating feature branch for Tacker

[Digambar Patil]

Hello Infra team,

I am implementing new API framework in tacker based on Falcon. We have
decided to create separate branch for this so that we can push all the code
to feature branch and once dev is completed, will merge branch to master.
So we need to create Feature/branch in Tacker.

Reference Spec - https://review.openstack.org/#/c/368511/ - submitted

Can someone help create feature branch from Infra team ?

Thanks,
Digambar
__
OpenStack Development Mailing 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] Device tag in the API breaks in the old microversion

[Matt Riedemann]

On 1/26/2017 8:32 PM, Artom Lifshitz wrote:

Since the consensus is to fix this with a new microversion, I've
submitted some patches:

* https://review.openstack.org/#/c/426030/
  A spec for the new microversion in case folks want one.


Merged.



* https://review.openstack.org/#/c/424759/
  The new microversion itself. I've already had feedback from Alex and
Ghanshyam (thanks guys!), and I've tried to address it.


+2 from me, +1 from gmann. The Tempest patch for the 2.42 microversion 
is here:


https://review.openstack.org/#/c/426991/1



* https://review.openstack.org/#/c/425876/
  A patch to - as Alex and Sean suggested - stop passing plain string
version to the schema extension point.



Needs some work.

--

Thanks,

Matt Riedemann

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

[openstack-dev] [nova] nova-status upgrade check failing in grenade run

[Matt Riedemann]

I've got a patch up to grenade to try and integrate the nova-status 
upgrade check command as part of the upgrade from newton to ocata:


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

That's failing one of the checks in nova-status, the details are in a 
bug report I've created:


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

With the decision to allow a fallback in the filter scheduler if the 
minimum nova-compute version in the deployment isn't new enough, I think 
we can loosen this check in nova-status for Ocata, and make it strict 
again in Pike when we remove that fallback in the filter scheduler.


I'm posting to the list to get thoughts since I've marked this as 
ocata-rc-potential so time is a factor.


--

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] [Neutron] Towards better stability of gate jobs

[Kevin Benton]

+1. Also, if you cant see why a particular job failed, ask in the
openstack-neutron IRC channel to get more eyes on it.

On Jan 30, 2017 9:39 AM, "Jakub Libosvar"  wrote:

> Hi all,
>
> we've been struggling with functional and fullstack jobs for a while
> now and we'd like to bring a better stability to it as the failure rate
> is still quite high. This is getting annoying, specifically for voting
> functional job, which makes it sometimes harder to get some of our
> beautiful precious patches merged.
>
> The very basic pillar on the way to improve the jobs is to understand
> what is wrong with them. Without having an overview of current failures
> it's very hard to make any improvement.
>
> Hence I'd like to ask you for help. When you see a failed job, don't
> just 'recheck' with the best hope that your patch won't get hit by gate
> failure again. Take a minute, please, open the failure and eventually
> report a new bug.
>
> Armando already sent similar email in the past [1], where he
> encouraged to have a look at the failure and report a bug. I have also
> sent a new policy to our docs with recommended steps [2]. Ideas on
> improvement are very welcome!
>
> It's really crucial to get a better grasp of our job failures and I
> believe if we can make this a habit into our day to day work, it will
> really make a difference at the job stability.
>
> Thank you.
> Jakub
>
> [1] http://lists.openstack.org/pipermail/openstack-dev/2016-Augu
> st/100801.html
> [2] https://review.openstack.org/#/c/426829/
>
> __
> OpenStack Development Mailing 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] [ironic] this week's priorities and subteam reports

[Loo, Ruby]

Hi,

We are jovial to present this week's priorities and subteam report for Ironic. 
As usual, this is pulled directly from the Ironic whiteboard[0] and formatted.

This Week's Priorities (as of the weekly ironic meeting)

1. Continue reviewing driver composition things (see notes below, some of the 
WIP patches are ready other than docs/reno): 
https://review.openstack.org/#/q/status:open+topic:bug/1524745
2. portgroups and attach/detach tempest tests and docs: 
https://review.openstack.org/382476
3. other docs, bug fixes
3.1. dtantsur to find bugs potentially requiring attention and throw them 
at people
3.2. vdrok to find doc patches that need attention


Bugs (dtantsur)
===
- Stats (diff between 23 Jan 2017 and 30 Jan 2017)
- Ironic: 230 bugs (+3) + 233 wishlist items (-4). 22 new (+3), 187 in progress 
(-3), 0 critical, 27 high (-1) and 29 incomplete (-2)
- Inspector: 13 bugs (+2) + 22 wishlist items (-2). 2 new (+2), 13 in progress 
(-3), 0 critical, 2 high (-1) and 4 incomplete
- Nova bugs with Ironic tag: 10. 0 new, 0 critical, 0 high

Portgroups support (sambetts, vdrok)

* trello: https://trello.com/c/KvVjeK5j/29-portgroups-support
- status as of most recent weekly meeting:
- tempest tests https://review.openstack.org/382476 need review
- documentation (need to be written still)

CI refactoring (dtantsur, lucasagomes)
==
* trello: https://trello.com/c/c96zb3dm/32-ci-refactoring
- status as of most recent weekly meeting:
- UEFI patches are merged!
- Project-config patch adding an experimental job: 
https://review.openstack.org/#/c/424576/

Rolling upgrades and grenade-partial (rloo, jlvillal)
=
* trello: 
https://trello.com/c/GAlhSzLm/2-rolling-upgrades-and-grenade-with-multi-node
- status as of most recent weekly meeting:
- leaning towards moving this to Pike.
- patches need reviews: https://review.openstack.org/#/q/topic:bug/1526283.
- concerns about https://review.openstack.org/#/c/420728/ (Add 
compatibility with Newton when creating a node)
- had irc discussion about status: 
http://eavesdrop.openstack.org/irclogs/%23openstack-ironic/%23openstack-ironic.2017-01-23.log.html#t2017-01-23T16:17:41
- Testing work:
- The final tempest "smoke" test is failing after the grenade run in 
the multi-tenant grenade job.
- 
http://logs.openstack.org/49/422149/5/experimental/gate-grenade-dsvm-ironic-multitenant-ubuntu-xenial-nv/74c9ed9/console.html
- Believe that this issue is due to the network getting changed 
after Grenade finishes and then we lose connectivity to the Ironic node.
- The grenade portion passes for the multi-tenant grenade job
- 
http://logs.openstack.org/49/422149/5/experimental/gate-grenade-dsvm-ironic-multitenant-ubuntu-xenial-nv/74c9ed9/logs/grenade.sh.summary.txt.gz
- Testing being done in: https://review.openstack.org/#/c/422149/
- This needs multi-node testing, and multi-node has a very low 
probability of working in Ocata

Generic boot-from-volume (TheJulia)
===
* trello: https://trello.com/c/UttNjDB7/13-generic-boot-from-volume
- status as of most recent weekly meeting:
- API side changes for volume connector information has a procedural -2 
until we can begin making use of the data in the conductor, but should stil be 
reviewed
- https://review.openstack.org/#/c/214586/
- This change has been rebased on top of the iPXE template update 
revision to support cinder/iscsi booting.
- Boot from volume/storage cinder interface is up for review
- Last patch set for cinder common client interface was reverted in a 
rebase.  TheJulia expects to address this Monday afternoon.
- 
https://review.openstack.org/#/q/status:open+project:openstack/ironic+branch:master+topic:bug/1559691
- Original volume connection information client patches
- They need OSC support added into the revisions.
- These changes should be expected to land once Pike opens.
- 
https://review.openstack.org/#/q/status:open+project:openstack/python-ironicclient+branch:master+topic:bug/1526231

Driver composition (dtantsur, jroll)

* trello: https://trello.com/c/fTya14y6/14-driver-composition
- gerrit topic: https://review.openstack.org/#/q/status:open+topic:bug/1524745
- status as of most recent weekly meeting:
- we're now able to load hardware types on start-up! \o/
- next steps (some yet to be written/finished) as of 23 Jan 2017:
- API changes for setting hardware types and interfaces
- ready for review
- https://review.openstack.org/417970
- https://review.openstack.org/#/c/424720/
- still todo:
- update 

Re: [openstack-dev] [requirements][ffe] Jinja2 2.9.5 upper constraint

[Major Hayden]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 01/30/2017 02:38 PM, Doug Hellmann wrote:
> If we only update the constraint list, it would not be safe to
> release something that relied on the features in the newer version,
> because our minimum version in the global requirements list will
> then be wrong.

I've gone ahead and abandoned the patch for now. It's not critical at the 
moment and 2.8.1 should be acceptable for Ocata.

Thanks, though!

- --
Major Hayden
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJYj7SnAAoJEHNwUeDBAR+xpGcP/24gEQq//FLwpiLHvHZRlOe+
Vh7zKzvSrU2KdPUo8dhM6pQdvtqR/j/NnyhkjCqTHyBwj3aG89kFxhpieOTtfy05
frSjzqXcjRG7RPHmTmA6HTkk4b2B+hK/BXgqCaNSzF1mNBoxAhgd54nWYANdp5Z/
887dpiHYNMtxQ1VWusHrJb/6eefEMybfZH9EqrFgHLzwkITzdmdSFycsdlNnrIMo
JtHI5iXxnJ8UX1JKnCEWPG+rpPQ83kp3Vs9Hdx3G7zlZhKafnEDOvdo0JnDzDyVp
pD5vzlr9kfwoCtbH5+dCS3rRAT43IjvaqSXKLzMx7pZpWbQyl4wC8+RMyhRYcmnN
uVC3uGzuo3jPCmS15Xcq0uBv36iUrqaw75g6wW3eHsFlqKd9HwA05fs2Z73gkdET
M6fIva+yjAjTLGFsQS6H452duohxHBqijIfzCNvzEDhb6u7tuG7R2DYx/Yv3czg7
rMDW59Yvt/156H/+Z/zje6NcSyljHK1ACvFh1vWY6uh5j42hCBF64sl3Q8Pxcbsr
50b0QAwUX+YlPkxyLCedEatDZB3ZxV/KvPthCQtRbUv9tkseGRV38USWfC6o51kG
3uI6rOcFsdLAT85Vq8KKSqJFAdYhV56gPRZ9wcXlgSUPK/u1/d7mQXNg1HcMbCFd
E810NXJvHf7uJUT1kBYe
=UBla
-END PGP SIGNATURE-

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

Re: [openstack-dev] [QA] Gate Jobs failing after patch for bug/1628016

[White, Joshua L]

Thanks Andrea!

For the first I will do as advised.  I will just add the prefix before the name 
then append the path afterwards.

For the second test with end_marker I will just make that upper case 
(‘ZzzzObject1234567890’) a lower case (‘Object1234567890’) I believe this 
was the intended behavior and ‘Z’ was a typo since when adding the beginning 
marker earlier in the code a capital ‘A’ ('AaaaObject1234567890') was correctly 
used because ‘A’ is the lowest letter but ‘z’ is the highest letter and should 
start for end marker.

Josh


From: Andrea Frittoli [mailto:andrea.fritt...@gmail.com]
Sent: Monday, January 30, 2017 10:42 AM
To: OpenStack Development Mailing List (not for usage questions) 
; ghanshyamm...@gmail.com; 
zhu.bingb...@99cloud.net; Daryl Walleck 
Subject: Re: [openstack-dev] [QA] Gate Jobs failing after patch for bug/1628016


On Mon, Jan 30, 2017 at 3:25 PM White, Joshua L 
> wrote:

Hi Team,



I would like to get your feedback on the gate jobs failing and how to alleviate 
the issue.

The gate jobs are failing once the prefix is actually added for these tests 
jobs below:

1. test_list_container_contents_with_path

Issue:
For some reason whoever coded this test hardcoded the file path and name 
("Swift/TestObject").
Which means when the prefix is added instead of '-TestObject' its 
'-Swift/TestObject' resulting in the failure because the path is wrong.


Objects with slashes in their name are used to setup paths.
You could change the test so that it uses rand_name for the part after the path 
only, e.g. Swift/-TestObject, or you could change the params to match 
the random path.


2. test_list_container_contents_with_end_marker

Issue:
This test will only pass if the prefix begins with a capital letter.  
'' works but '' fails

This is because the marker starts with "Z" which comes before any low case 
letter in ascii order. You could change the end marker, or even better you 
could build the end marker dynamically based on the prefix to make sure it 
comes after the object name.

andrea

I am trying to find the correct way to fix these issues without doing something 
that’s just hacky.

Please see patch for reference: https://review.openstack.org/#/c/397504/

Thanks,

Joshua White
irc: jlwhite


__
OpenStack Development Mailing 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] [trove][Neutron] Towards better stability of gate jobs

[Amrith Kumar]

I'd like to add the same call-to-action for Trove as well.

When you see a gate failure, please don't simply recheck. Let's start
tracking failure patterns in Launchpad and fix them. I know this is a change
from what we've been doing a lot of in Trove of late so I realize that it
will take some time before we get used to it.

But, it is an improvement worth aspiring to.

Thanks,

-amrith

> -Original Message-
> From: Jakub Libosvar [mailto:jlibo...@redhat.com]
> Sent: Monday, January 30, 2017 11:37 AM
> To: openstack-dev@lists.openstack.org
> Subject: [openstack-dev] [Neutron] Towards better stability of gate jobs
> 
> Hi all,
> 
> we've been struggling with functional and fullstack jobs for a while now
> and we'd like to bring a better stability to it as the failure rate is
> still quite high. This is getting annoying, specifically for voting
> functional job, which makes it sometimes harder to get some of our
> beautiful precious patches merged.
> 
> The very basic pillar on the way to improve the jobs is to understand what
> is wrong with them. Without having an overview of current failures it's
> very hard to make any improvement.
> 
> Hence I'd like to ask you for help. When you see a failed job, don't just
> 'recheck' with the best hope that your patch won't get hit by gate failure
> again. Take a minute, please, open the failure and eventually report a new
> bug.
> 
> Armando already sent similar email in the past [1], where he encouraged to
> have a look at the failure and report a bug. I have also sent a new policy
> to our docs with recommended steps [2]. Ideas on improvement are very
> welcome!
> 
> It's really crucial to get a better grasp of our job failures and I
> believe if we can make this a habit into our day to day work, it will
> really make a difference at the job stability.
> 
> Thank you.
> Jakub
> 
> [1]
> http://lists.openstack.org/pipermail/openstack-dev/2016-August/100801.html
> [2] https://review.openstack.org/#/c/426829/
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

Re: [openstack-dev] [Openstack-stable-maint] Stable check of openstack/glance failed

[Ian Cordasco]

-Original Message-
From: A mailing list for the OpenStack Stable Branch test reports.

Reply: openstack-dev@lists.openstack.org 
Date: January 30, 2017 at 00:16:19
To: openstack-stable-ma...@lists.openstack.org

Subject:  [Openstack-stable-maint] Stable check of openstack/glance failed

> Build failed.
>
> - periodic-glance-docs-mitaka 
> http://logs.openstack.org/periodic-stable/periodic-glance-docs-mitaka/384794b/
> : FAILURE in 3m 09s

I've created an issue for
https://bugs.launchpad.net/glance/+bug/1660444. I am fairly confident
this is related to the fact that pypa/setuptools recently started hard
depending (instead of vendoring) on its dependencies. Older versions
of pip don't recognize that setuptools' dependencies must be installed
before it is installed.

--
Ian Cordasco

__
OpenStack Development Mailing 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] [requirements][ffe] Jinja2 2.9.5 upper constraint

[Doug Hellmann]

Excerpts from Major Hayden's message of 2017-01-30 11:55:39 -0600:
> Hello there,
> 
> I just submitted a patch[0] to bump Jinja2's upper constraint to 2.9.5.
> 
> We previously set the upper constraint to 2.8.1[1] when a change appeared 
> that broke Ansible. The bug caused the `groupby` filter to return a 
> namedtuple and it was fixed later in 2.9.5, which was released[2] two days 
> ago.  Other than that bug, the 2.9.0-2.9.4 releases worked fine.
> 
> Version 2.9.5 also contains two new tests[3] which are very helpful for the 
> openstack-ansible-security role.
> 
> Would it be possible to get the upper constraint for Jinja2 changed for 
> Ocata?  Thanks!
> 
> [0] https://review.openstack.org/#/c/426857/
> [1] https://review.openstack.org/#/c/418494/
> [2] https://github.com/pallets/jinja/releases/tag/2.9.5
> [3] https://github.com/pallets/jinja/pull/624
> 

If we only update the constraint list, it would not be safe to
release something that relied on the features in the newer version,
because our minimum version in the global requirements list will
then be wrong.

Doug

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

Re: [openstack-dev] [kolla] Contributors welcome to kolla-kubernetes 0.5.0

[Vikram Hosakote (vhosakot)]

Yes, I'd like to contribute to the blueprints and will ask questions in the 
kolla
IRC channel.

Regards,
Vikram Hosakote
IRC:  vhosakot

From: "Steven Dake (stdake)" >
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: Wednesday, January 18, 2017 at 12:07 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
>
Subject: [openstack-dev] [kolla] Contributors welcome to kolla-kubernetes 0.5.0

Hey folks,

The release team released kolla-kubernetes 0.4.0 Sunday January 15th.  Now we 
are in 0.5.0 development which lasts one month.

The general architecture of OpenStack based deployments with a Kubernetes 
underlay is taking form.  There are 5 blueprints in 0.5.0 which we expect 
should land prior to the PTG:
https://launchpad.net/kolla-kubernetes/+milestone/0.5.0

If you have personal interest in any of these blueprints, the fact that they 
are "assigned" doesn't mean there isn't a contribution to be made.  If you 
click through to an individual blueprint, you can see the "Work Items" field 
which contains each work item that needs addressing in each of these master 
blueprints.  For each master blueprint, there may be 10+ work items or more.

The goal of these "master" blueprints is to distribute the work among the 
development community.  There should be enough to work from in the whiteboard 
patches to produce an implementation.

Feel free to change "unassigned" to your Launchpad id for any of the blueprint 
work items.  The person assigned is responsible for tracking the state of the 
blueprint's work items or generally leading the effort around those blueprints 
as has been done in other Kolla deliverables.

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

Re: [openstack-dev] [requirements][neutron][ffe] Jinja2 2.9.5 upper constraint

[Davanum Srinivas]

Matthew, Major,

I am ok with just upper-constraints. If it were g-r then we would have
to re-release 2 oslo libs at least.
http://codesearch.openstack.org/?q=jinja2=fosho=.*require.*%5C.txt=oslo.middleware,oslo.reports

Thanks,
Dims

On Mon, Jan 30, 2017 at 2:30 PM, Matthew Thode
 wrote:
> On 01/30/2017 11:55 AM, Major Hayden wrote:
>> Hello there,
>>
>> I just submitted a patch[0] to bump Jinja2's upper constraint to 2.9.5.
>>
>> We previously set the upper constraint to 2.8.1[1] when a change appeared 
>> that broke Ansible. The bug caused the `groupby` filter to return a 
>> namedtuple and it was fixed later in 2.9.5, which was released[2] two days 
>> ago.  Other than that bug, the 2.9.0-2.9.4 releases worked fine.
>>
>> Version 2.9.5 also contains two new tests[3] which are very helpful for the 
>> openstack-ansible-security role.
>>
>> Would it be possible to get the upper constraint for Jinja2 changed for 
>> Ocata?  Thanks!
>>
>> [0] https://review.openstack.org/#/c/426857/
>> [1] https://review.openstack.org/#/c/418494/
>> [2] https://github.com/pallets/jinja/releases/tag/2.9.5
>> [3] https://github.com/pallets/jinja/pull/624
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
> This'll impact neutron as well and I'd like their ack on this.  Though
> it generally looks fine to me.
>
> --
> Matthew Thode (prometheanfire)
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



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

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

Re: [openstack-dev] [Zun] Propose a change of the Zun core team membership

[Hongbin Lu]

Hi all,

Thanks for the votes. According to the feedback, this proposal is approved. 
Welcome Kevin to the core team.

Best regards,
Hongbin

-Original Message-
From: Qiming Teng [mailto:teng...@linux.vnet.ibm.com] 
Sent: January-29-17 6:54 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Zun] Propose a change of the Zun core team 
membership

+1 to both.

On Mon, Jan 23, 2017 at 10:56:00PM +, Hongbin Lu wrote:
> Hi Zun cores,
> 
> I proposed a change of Zun core team membership as below:
> 
> + Kevin Zhao (kevin-zhao)
> - Haiwei Xu (xu-haiwei)
> 
> Kevin has been working for Zun for a while, and made significant 
> contribution. He submitted several non-trivial patches with high quality. One 
> of his challenging task is adding support of container interactive mode, and 
> it looks he is capable to handle this challenging task (his patches are under 
> reviews now). I think he is a good addition to the core team. Haiwei is a 
> member of the initial core team. Unfortunately, his activity dropped down in 
> the past a few months.
> 
> According to the OpenStack Governance process [1], we require a minimum of 4 
> +1 votes from Zun core reviewers within a 1 week voting window (consider this 
> proposal as a +1 vote from me). A vote of -1 is a veto. If we cannot get 
> enough votes or there is a veto vote prior to the end of the voting window, 
> this proposal is rejected.
> 
> [1] https://wiki.openstack.org/wiki/Governance/Approved/CoreDevProcess
> 
> Best regards,
> Hongbin
> 

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


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

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

Re: [openstack-dev] [requirements][neutron][ffe] Jinja2 2.9.5 upper constraint

[Matthew Thode]

On 01/30/2017 11:55 AM, Major Hayden wrote:
> Hello there,
> 
> I just submitted a patch[0] to bump Jinja2's upper constraint to 2.9.5.
> 
> We previously set the upper constraint to 2.8.1[1] when a change appeared 
> that broke Ansible. The bug caused the `groupby` filter to return a 
> namedtuple and it was fixed later in 2.9.5, which was released[2] two days 
> ago.  Other than that bug, the 2.9.0-2.9.4 releases worked fine.
> 
> Version 2.9.5 also contains two new tests[3] which are very helpful for the 
> openstack-ansible-security role.
> 
> Would it be possible to get the upper constraint for Jinja2 changed for 
> Ocata?  Thanks!
> 
> [0] https://review.openstack.org/#/c/426857/
> [1] https://review.openstack.org/#/c/418494/
> [2] https://github.com/pallets/jinja/releases/tag/2.9.5
> [3] https://github.com/pallets/jinja/pull/624
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 

This'll impact neutron as well and I'd like their ack on this.  Though
it generally looks fine to me.

-- 
Matthew Thode (prometheanfire)



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] [requirements][ffe] oslo.context 2.12.1 in upper-constraints

[Matthew Thode]

On 01/30/2017 12:20 PM, Davanum Srinivas wrote:
> Team,
> 
> We have a fix in oslo.context for the problem reported over the weekend:
> http://lists.openstack.org/pipermail/openstack-dev/2017-January/49.html
> 
> A fix to disable warnings was merged into master, then cherry-picked
> to stable/ocata. Let's please update the upper-constraints with this
> new version.
> 
> Thanks,
> Dims
> 

UC only is fine with me

-- 
Matthew Thode (prometheanfire)



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

[openstack-dev] [requirements][ffe] oslo.context 2.12.1 in upper-constraints

[Davanum Srinivas]

Team,

We have a fix in oslo.context for the problem reported over the weekend:
http://lists.openstack.org/pipermail/openstack-dev/2017-January/49.html

A fix to disable warnings was merged into master, then cherry-picked
to stable/ocata. Let's please update the upper-constraints with this
new version.

Thanks,
Dims

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

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

Re: [openstack-dev] [nova] How to use resource_providers for shared disk resources (NFS)

[Jay Pipes]

On 01/30/2017 05:55 AM, Shewale, Bhagyashri wrote:

Hi nova devs,

How can I use placement api's if my instance path is mounted on shared
storage server (e.g. NFS)?

I am trying to set multinode setup with NFS shared storage for all nodes
to share disk resources along with placement services. As of now it is
creating resource providers for each of the compute node and adds the
DISK_GB for each resource provider.


Correct. Well, I mean that this behaviour is expected (and is the 
identical behaviour that exists in Nova today with the non-placement API).


We have not yet merged code that handles the correct accounting of 
shared storage, unfortunately. :(


When we merge all the code that handles shared storage [1], you should 
be able to do something like the following:


STORAGE_UUID=`openstack aggregate-create "my NFS storage pool"`
openstack aggregate-host-associated $STORAGE_UUID $UUID_COMPUTE1
openstack aggregate-host-associated $STORAGE_UUID $UUID_COMPUTE2

Add some inventory to the aggregate, like so:

PUT /resource_providers/$STORAGE_UUID/inventories
{
  "DISK_GB": {
"total": 1000,
"reserved": 0,
"min_unit": 10,
"max_unit": 1000,
"allocation_ratio": 1.0
  }
}

and then the compute nodes will just "auto-heal" themselves, removing 
"local" DISK_GB inventories and using the DISK_GB inventory of the 
storage pool.


But, again, this code isn't yet merged.

We're making slow but steady progress, but I can't tell you when the 
code will fully land, unfortunately.


Best,
-jay

[1] Code that builds upon this patch: 
https://review.openstack.org/#/c/407309/



For example below are my environment details:

NODE A: compute
NODE B: controller + compute

Following entries are made in resource_providers table:

+-+-++--+++--+

| created_at  | updated_at  | id |
uuid | name   |
generation | can_host |

+-+-++--+++--+

| 2017-01-30 06:49:17 | 2017-01-30 09:12:06 |  1 |
6cbbaf2b-5b8c-4f38-8b34-ee23791056a6 | openstack-VirtualBox   |
3 |0 |

| 2017-01-30 09:02:29 | 2017-01-30 09:11:03 |  3 |
bad71c26-8f36-43ea-abf4-bdbeffda9e54 | openstack-VirtualBox-1 |
2 |0 |

+-+-++--+++--+



Following are the entries of inventories tables, of which 89 indicates
the DISK_GB (size of shared storage):



+-+-++--+---+---+--+--+--+---+--+

| created_at  | updated_at  | id | resource_provider_id
| resource_class_id | total | reserved | min_unit | max_unit | step_size
| allocation_ratio |

+-+-++--+---+---+--+--+--+---+--+

| 2017-01-30 06:49:19 | 2017-01-30 09:10:37 |  1 |1
| 0 | 1 |0 |1 |1 | 1
|   16 |

| 2017-01-30 06:49:19 | 2017-01-30 09:10:37 |  2 |1
| 1 | 11210 |  512 |1 |11210 | 1
|  1.5 |

| 2017-01-30 06:49:19 | 2017-01-30 09:10:37 |  3 |1
| 2 |89 |0 |1 |   89 | 1
|1 |

| 2017-01-30 09:02:31 | 2017-01-30 09:11:03 |  7 |3
| 0 | 1 |0 |1 |1 | 1
|   16 |

| 2017-01-30 09:02:31 | 2017-01-30 09:11:03 |  8 |3
| 1 | 10253 |  512 |1 |10253 | 1
|  1.5 |

| 2017-01-30 09:02:31 | 2017-01-30 09:11:03 |  9 |3
| 2 |89 |0 |1 |   89 | 1
|1 |

+-+-++--+---+---+--+--+--+---+--+



However still I am able to create the instances over the size of actual
shared storage.



Please let me know how to configure resource_providers in case of shared
storage servers are used for disk resources.



Thank you,



Bhagyashri


__
Disclaimer: This email and any attachments are sent in strictest confidence
for the sole use of the addressee and may contain legally privileged,
confidential, and proprietary data. If you are not the intended recipient,
please advise the sender by replying promptly to this email and then delete
and destroy this email 

Re: [openstack-dev] [TC][Glance][Nova][TripleO][Heat][Mistral][Ironic][Murano] Glare

[Mikhail Fedosin]

Serg, you forgot that Glare v1 != Glare v0.1. And there is a small issue -
Glare v0.1 is deprecated. So I'm just wondering what are your future plans
about Glare v1. Will you use it or simply copy the v0.1 code into Murano
repo?

Best,
Mike

On Thu, Jan 26, 2017 at 2:03 AM, Serg Melikyan 
wrote:

> I would like to comment a little bit regarding usage of Glare in
> Murano and Mirantis OpenStack:
>
> > How much have these projects adopted Glare?
> Glare is preferred backend for storing murano packages, which provides
> versioning capabilities (they are not available without it)
>
> >Is Glare being deployed already?
> Mirantis OpenStack 9.0 by default is deploying Murano with Glare used
> as a backend.
>
> >What projects are the main consumers of Glare?
> Murano
>
> On Wed, Jan 25, 2017 at 2:56 PM, Mike Perez  wrote:
> > On 18:16 Jan 24, Mikhail Fedosin wrote:
> >> Hey, Flavio :) Thanks for your questions!
> >>
> >> As you said currently only Nokia's adopting Glare for its own platform,
> but
> >> if we talk about OpenStack, that I believe Mistral will start to use it
> >> soon.
> >> In my opinion Glare's adoption is low due to the fact that the project
> is
> >> not included under Big Tent. I think it will be changed soon, because
> now
> >> I'm finishing Glare v1 API proposal, and when it's done we will apply
> under
> >> BT.
> >>
> >> About Glance v2 API - as I said they are +- the same with several
> cosmetic
> >> differences (in Glance status is called 'queued', in Glare we renamed
> it to
> >> 'drafted', and so on). For this reason I'm going to implement a
> middleware,
> >> that will provide a full Image API v2 for Glare (even with unnecessary
> >> '/v2' prefix) and glance clients will be able to communicate with it as
> >> with Glance. It's definitely doable and we can discuss it more detailed
> >> during the PTG.
> >
> > Both Flavio and Doug asked you to expand on the issues with the Glance
> API. Can
> > you please expand on that.
> >
> > --
> > Mike Perez
> >
> > 
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
> unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
>
>
> --
> Serg Melikyan, Development Manager at Mirantis, Inc.
> http://mirantis.com | smelik...@mirantis.com
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [TC][Glance][Nova][TripleO][Heat][Mistral][Ironic][Murano] Glare

[Mikhail Fedosin]

Thanks Renat! I agree, currently we do not have a specific plan, and also
several required features, like storing small blobs in database, are not
merged yet. We definitely should talk about it more detailed during (and
probably before) PTG. At least one session will be dedicated directly to
this and all people are welcome to participate!

Best,
Mike



On Fri, Jan 27, 2017 at 7:26 AM, Renat Akhmerov 
wrote:

>
> On 26 Jan 2017, at 22:29, Dougal Matthews  wrote:
>
>
>
> On 24 January 2017 at 16:16, Mikhail Fedosin  wrote:
>
>> Hey, Flavio :) Thanks for your questions!
>>
>> As you said currently only Nokia's adopting Glare for its own platform,
>> but if we talk about OpenStack, that I believe Mistral will start to use it
>> soon.
>>
>
> Has there been some discussion surrounding Mistral and Glare? I'd be
> interested in reading more about those plans and ideas.
>
>
> Dougal, I’ve cherished this idea for a long time and discussed it with a
> few people, but informally.
> I believe we didn’t have any official discussions around it yet. I
> included the corresponding topic
> to our PTG etherpad to finally get this going. Mike and will bring this
> topic up to discussion.
> I believe it’s worth it. We can also discuss basics before the PTG too,
> but in a separate thread.
>
> Renat Akhmerov
> @Nokia
>
>
> __
> OpenStack Development Mailing 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] [requirements][ffe] Jinja2 2.9.5 upper constraint

[Major Hayden]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hello there,

I just submitted a patch[0] to bump Jinja2's upper constraint to 2.9.5.

We previously set the upper constraint to 2.8.1[1] when a change appeared that 
broke Ansible. The bug caused the `groupby` filter to return a namedtuple and 
it was fixed later in 2.9.5, which was released[2] two days ago.  Other than 
that bug, the 2.9.0-2.9.4 releases worked fine.

Version 2.9.5 also contains two new tests[3] which are very helpful for the 
openstack-ansible-security role.

Would it be possible to get the upper constraint for Jinja2 changed for Ocata?  
Thanks!

[0] https://review.openstack.org/#/c/426857/
[1] https://review.openstack.org/#/c/418494/
[2] https://github.com/pallets/jinja/releases/tag/2.9.5
[3] https://github.com/pallets/jinja/pull/624
- --
Major Hayden
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJYj34YAAoJEHNwUeDBAR+xvCAQAJjzgtP+u8LyQN0C/jZ5Xbe3
OXNO9ENTzPIaGNLt0Tu+vxtFD7n/3V3sksvd4oJC9IfuEWOCBASD8WzBMrPsaJ6n
yfuyomemoJnNA8GOVUjGzkOyjZyCnEiiXeHsffsog81She7J4BCCyVmMM+NZYTob
cTabwgQCLRUFcmdCOkDsnYyFhc6QZL4QNB3ERi6dMSfwMigmAvfYWqULuLR/puHI
907ePIa5zfbEzUxcEpRMo+m/NdEiE6ILCHWvrWGFzcvo/12wBE6QlrCDKfzVQCt2
GTq3/Dr4gaSeAjzGei5XR8I3IIQ27iCeFfFKiRACd1Dj4xP1IG/BI+7uJSlDotCp
UQKmysBjCHolaGsfziwQD5162c57j7MPnBiLPU1tOXYphqkQBVKyd79TPWjxQjah
LA+pXK9XBs8YtSUNz0xgGr7NtvfivkIyUdhlbzjcKlsfEc9y3b6Qv4m2Ye3Ixdsv
WJ50eZK4wtCZZsXO5fq2oFUHPPofz5+nfFOCaySfw9rz+3pSiw1eVK8wVNzdKaRw
JOZpEzh7JAWTLfO+cOTQhlE0S4SqKLmcdjCw9qOf4zAya5nhHPBUescQmzSHmPoB
X+K69W3Tr9Db6D35OK0fXDoT7q9IeSSNCv8enNcxXUK66CsywUPpcSUmlUg4I4E3
Y2/uzCSbHSgNexf8Tjc7
=TUs4
-END PGP SIGNATURE-

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

Re: [openstack-dev] [tripleo] Proposing Honza Pokorny core on tripleo-ui

[Honza Pokorny]

Thanks everyone!

On 2017-01-30 10:45, Emilien Macchi wrote:
> Honza, you're now core on tripleo-ui project. Thanks for your hard
> work and congrats!
> 
> On Fri, Jan 27, 2017 at 2:45 AM, Dougal Matthews  wrote:
> > +1!
> >
> > On 25 January 2017 at 15:28, Steven Hardy  wrote:
> >>
> >> On Tue, Jan 24, 2017 at 08:52:51AM -0500, Emilien Macchi wrote:
> >> > I have been discussed with TripleO UI core reviewers and it's pretty
> >> > clear Honza's work has been valuable so we can propose him part of
> >> > Tripleo UI core team.
> >> > His quality of code and reviews make him a good candidate and it would
> >> > also help the other 2 core reviewers to accelerate the review process
> >> > in UI component.
> >> >
> >> > Like usual, this is open for discussion, Tripleo UI core and TripleO
> >> > core, please vote.
> >>
> >> +1
> >>
> >> __
> >> OpenStack Development Mailing 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

__
OpenStack Development Mailing 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] [aodh][vitrage] Aodh generic alarms

[gordon chung]

On 29/01/17 08:52 AM, Afek, Ifat (Nokia - IL) wrote:
> On 26/01/2017, 20:09, "Julien Danjou"  wrote:
>
>> On Thu, Jan 26 2017, gordon chung wrote:
>>
>>> On 26/01/17 11:41 AM, Julien Danjou wrote:
>>
>>> and vitrage would be an alarm orchestrator?
>>
>> Yup, something like that. It could be the one driving Zabbix and
>> creating alarms for Zabbix in Aodh when a new host is plugged for
>> example.
>
> Vitrage could be enhanced to become an alarm orchestrator.
> The question is – do you want Vitrage to be one?
> And how would you describe the role of an alarm orchestrator/manager?
>
>

i don't really have an opinion on the orchestrator role although it 
seems to be leaning that way.

i'll re-ask a question i had earlier since i'm not entirely clear of 
proposal (if it's still relevant):

if we store a vitrage alarm in aodh, what would the use case be for
querying it? the alarm occurred and vitrage has already sent a
notification warning. if i were to query aodh, what additional
information would i be retrieving?

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

Re: [openstack-dev] [magnum][kuryr] python-k8sclient vs client-python (was Fwd: client-python Beta Release)

[Antoni Segura Puimedon]

On Thu, Jan 26, 2017 at 12:41 PM, Davanum Srinivas 
wrote:

> Team,
>
> A bit of history, we had a client generated from swagger definition for a
> while in Magnum, we plucked it out into python-k8sclient which then got
> used by fuel-ccp, kuryr etc. Recently the kuberneted team started an effort
> called client-python. Please see 1.0.0b1 announcement.
>
> * It's on pypi[1] and readthedocs[2]
> * i've ported the e2e tests in python-k8sclient that runs against an
> actual k8s setup and got that working
> * i've looked at various tests in kuryr, fuel-ccp, magnum etc to see what
> could be ported as well. most of it is merged already. i have a couple of
> things in progress
>
> So, when client-python hits 1.0.0, Can we please mothball our
> python-k8sclient and switch over to the k8s community supported option?
> Can you please evaluate what's missing so we can make sure those things
> get into 1.0.0 final?
>

I am all for this. Thanks for the good work Davanum! I think this is a
perfect case where the OpenStack Community can give back to other upstream
communities and we should improve client-python where we need.


>
> Thanks,
> Dims
>
> [1] https://pypi.python.org/pypi/kubernetes
> [2] http://kubernetes.readthedocs.io/en/latest/kubernetes.html
>
> -- Forwarded message --
> From: 'Mehdy Bohlool' via Kubernetes developer/contributor discussion <
> kubernetes-...@googlegroups.com>
> Date: Wed, Jan 25, 2017 at 8:34 PM
> Subject: client-python Beta Release
> To: Kubernetes developer/contributor discussion <
> kubernetes-...@googlegroups.com>, kubernetes-us...@googlegroups.com
>
>
> Python client is now in beta. Please find more information here:
> https://github.com/kubernetes-incubator/client-python/
> releases/tag/v1.0.0b1
>
> You can reach the maintainers of this project at SIG API Machinery
> .
> If you have any problem with the client or any suggestions, please file an
> issue .
>
>
> Mehdy Bohlool |  Software Engineer |  me...@google.com |  mbohlool@github
> 
>
> --
> You received this message because you are subscribed to the Google Groups
> "Kubernetes developer/contributor discussion" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to kubernetes-dev+unsubscr...@googlegroups.com.
> To post to this group, send email to kubernetes-...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/ms
> gid/kubernetes-dev/CACd0WeG3O1t%3DXt7AGykyK7CcLmVYyJAB918c%2
> BXvteqVrW3nb7A%40mail.gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>
>
>
> --
> Davanum Srinivas :: https://twitter.com/dims
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing 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] Gate Jobs failing after patch for bug/1628016

[Andrea Frittoli]

On Mon, Jan 30, 2017 at 3:25 PM White, Joshua L 
wrote:

> Hi Team,
>
>
>
> I would like to get your feedback on the gate jobs failing and how to
> alleviate the issue.
>
>
>
> The gate jobs are failing once the prefix is actually added for these
> tests jobs below:
>
>
>
> 1. *test_list_container_contents_with_path*
>
>
>
> Issue:
>
> For some reason whoever coded this test hardcoded the file path and
> name ("Swift/TestObject").
>
> Which means when the prefix is added instead of '-TestObject'
> its '-Swift/TestObject' resulting in the failure because the path
> is wrong.
>
>
>

Objects with slashes in their name are used to setup paths.
You could change the test so that it uses rand_name for the part after the
path only, e.g. Swift/-TestObject, or you could change the params
to match the random path.


>
>
2. *test_list_container_contents_with_end_marker*
>
>
>
> Issue:
>
> This test will only pass if the prefix begins with a capital letter.
> '' works but '' fails
>
>
>
This is because the marker starts with "Z" which comes before any low case
letter in ascii order. You could change the end marker, or even better you
could build the end marker dynamically based on the prefix to make sure it
comes after the object name.

andrea

>
>
> I am trying to find the correct way to fix these issues without doing
> something that’s just hacky.
>
>
>
> Please see patch for reference: https://review.openstack.org/#/c/397504/
>
>
>
> Thanks,
>
>
>
> Joshua White
>
> irc: jlwhite
>
>
>
>
> __
> OpenStack Development Mailing 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] [neutron] [classifier] No Common Classification Framework meeting

[Duarte Cardoso, Igor]

Hi,

There will be no Common Classification Framework this week.
The PTG PoC is still being worked on and is starting to look good, kudos to 
David for most of the work so far.

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-dev] [Neutron] Towards better stability of gate jobs

[Jakub Libosvar]

Hi all,

we've been struggling with functional and fullstack jobs for a while
now and we'd like to bring a better stability to it as the failure rate
is still quite high. This is getting annoying, specifically for voting
functional job, which makes it sometimes harder to get some of our
beautiful precious patches merged.

The very basic pillar on the way to improve the jobs is to understand
what is wrong with them. Without having an overview of current failures
it's very hard to make any improvement.

Hence I'd like to ask you for help. When you see a failed job, don't
just 'recheck' with the best hope that your patch won't get hit by gate
failure again. Take a minute, please, open the failure and eventually
report a new bug.

Armando already sent similar email in the past [1], where he
encouraged to have a look at the failure and report a bug. I have also
sent a new policy to our docs with recommended steps [2]. Ideas on
improvement are very welcome!

It's really crucial to get a better grasp of our job failures and I
believe if we can make this a habit into our day to day work, it will
really make a difference at the job stability.

Thank you.
Jakub

[1] 
http://lists.openstack.org/pipermail/openstack-dev/2016-August/100801.html

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

__
OpenStack Development Mailing 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] CI Squad Meeting Summary (week 5)

[Paul Belanger]

On Mon, Jan 30, 2017 at 03:07:42PM +0100, Gabriele Cerami wrote:
> On 30 Jan, Paul Belanger wrote:
> 
> > Before you go out an implement some sort of in-repo configuration for 
> > testing, I
> > strongly encourage you to read up on our Zuulv3 spec[3], as we are providing
> > this functionality.  What is comes down to, you'll be able to focus on 
> > writing
> > tests, where zuul does all the test configuration and provisioning.
> > 
> > [3] 
> > https://specs.openstack.org/openstack-infra/infra-specs/specs/zuulv3.html
> 
> This is not about provisioning, we concluded we don't want to deal with
> that, quickstart just offers a simple virthost provisioning to improve
> user experience, but users (or other tools) have to deal with any more
> complex topology that may be needed.
> But as this tool was implemented with reproducibility in mind, we don't
> want to consider just uptream as its consumer.
> 
> This effort on the configuration just aims in associating a job name to
> a defined set of features we want to test during tripleo deployment.
> For example:
> When quickstart is called to test a periodic HA ovb on newton, what's
> the best way to build and pass a configuration to quickstart that
> contains all the variables to activate exactly all the features we want
> to test ?
> Passing the right configuration will require some automation, and maybe
> zuul can help at least upsteam, but creating the configuration is a
> manual process, and the results should be consumable by anyone.
> We are focusing on this second part, and I can't see any overlap in zuul
> for that.
> 
I would still encourage you to look at the work we are doing for zuulv3. While
you don't have to directly depend on it for local reproducibility, we do have
some plans to make the concept of 'reproduce.sh' able to run the ansible
playbooks we have created today.

As for passing data, we do something like this today. Zuul has a set of
variables[4] we need to pass into ansible, and Monty came up with a great way to
achieve this using the environment keyword[5].

Continuing on this topic, there even was a patch recently to nodepool to write
out facts for primary / sub nodes, which we could then load into zuul and read
dynamic configuration.

I'm not saying zuul will fix all the things, just talk a look into it before
implementing something only for TripleO.

[4] 
http://logs.openstack.org/24/425924/2/gate/gate-neutron-pep8-ubuntu-xenial/184b89e/_zuul_ansible/vars.yaml
[5] 
http://logs.openstack.org/24/425924/2/gate/gate-neutron-pep8-ubuntu-xenial/184b89e/_zuul_ansible/playbook

__
OpenStack Development Mailing 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] Proposing Sergey (Sagi) Shnaidman for core on tripleo-ci

[Emilien Macchi]

Sagi, you're now core on TripleO CI repo. Thanks for your hard work on
tripleo-quickstart transition, and also helping by keeping CI in good
shape, your work is amazing!

Congrats!

Note: I couldn't add you to tripleo-ci group, but only to tripleo-core
(Gerrit permissions), which mean you can +2 everything but we trust
you to use it only on tripleo-ci. I'll figure out the Gerrit
permissions later.

On Fri, Jan 27, 2017 at 2:43 AM, Dougal Matthews  wrote:
> +1!
>
> On 26 January 2017 at 18:36, Harry Rybacki  wrote:
>>
>> On Thu, Jan 26, 2017 at 12:25 PM, Martin André  wrote:
>> > On Tue, Jan 24, 2017 at 6:03 PM, Juan Antonio Osorio
>> >  wrote:
>> >> Sagi (sshnaidm on IRC) has done significant work in TripleO CI (both
>> >> on the current CI solution and in getting tripleo-quickstart jobs for
>> >> it); So I would like to propose him as part of the TripleO CI core
>> >> team.
>> >>
>> >> I think he'll make a great addition to the team and will help move CI
>> >> issues forward quicker.
>> >
>> > +1
>> >
>> +1
>>
>> >> Best Regards,
>> >>
>> >>
>> >>
>> >> --
>> >> Juan Antonio Osorio R.
>> >> jaosorior
>> >>
>> >>
>> >>
>> >> __
>> >> OpenStack Development Mailing List (not for usage questions)
>> >> Unsubscribe:
>> >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >>
>> >
>> >
>> > __
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe:
>> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
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] [All projects that use Alembic] Absence of pk on alembic_version table

[Mike Bayer]

On 01/24/2017 04:49 AM, Kirill Proskurin wrote:

HI!

Thing is, running Galera without enforcing it very bad idea for
production use. Permissive mode was added more or less for testing
purposes, running real production with it is dangerous, since it's not
enforcing the mandatory Galera requirement, one of them is a "All
tables must have a primary key".


Any application that wishes to run Galera in PK-enforcing mode may do 
so, by simply adding a primary key constraint to the alembic_version 
table beforehand if one is not already present.   Openstack applications 
may add a migration that does this automatically as well.


But beyond that, I disagree with this characterization.  Galera's 
documentation does not state "All tables must have a primary key", it 
states, "Do not use tables without a primary key", and the reasons they 
list do not affect Alembic's use case except in one potential edge case 
(although the documentation is too vague to know if it's real or not), 
for which the above workaround that the Openstack application add a PK 
constraint up front would mitigate.



Reviewing Galera's documentation on this subject:


http://galeracluster.com/documentation-webpages/limitations.html

"Do not use tables without a primary key."

OK, nevertheless they are giving us the choice.   Let's see why that is:


"When tables lack a primary key, rows can appear in different order on 
different nodes in your cluster. "


The Alembic versioning table typically stores exactly one row, or in the 
case of an Openstack application using multiple branches like Neutron 
may store several rows, however there is no ordering requirement on this 
table when they are SELECTed.  Additionally, relational database tables 
have no defined ordering in *any* case, so a SELECT that has no ORDER BY 
yet which expects a specific ordering is already broken.


The other case for intrinsic ordering is that concurrent UPDATE 
statements on a table may produce different row locking behavior; so 
that an UPDATE applied to a table may apply differently depending on 
which galera node is accessed.   This is a non-issue for the alembic 
version table because this table is only accessed by a single process 
during an upgrade operation and is not subject to any concurrency.


"As such, queries like SELECT...LIMIT... can return different results."

You should *never* run SELECT..LIMIT without an ORDER BY on any 
relational database so this point is moot.


"Additionally, on such tables the DELETE statement is unsupported."

Here we have the first issue that can be a problem.   The 
alembic_version table is normally not subject to a DELETE operation. 
The feature in which DELETE is used is if a project is using branches 
that merge together - when an upgrade across a merge point is made, the 
additional rows in the table for the merged points are DELETEd.


Currently, I'm not sure if any openstack project is merging any branches 
together.   If they are, they should include a migration that manually 
adds a primary key constraint to the alembic_version table.  That is, 
each Openstack project can address this issue directly just by including 
a migration that adds a primary key constraint to the alembic_version table.


In my testing, I cannot locate the nature of the "is unsupported" 
statement.   The DELETE statement does in fact work "fine" on a Galera 
cluster table that has no primary key, the correct row is deleted and 
the correct result is replicated to the other nodes.   So if 
"unsupported" means, "may fail under load", "doesn't work with the 
AUTO_INCREMENT feature" (which Alembic does not use) "may fail 
randomly", or simply, "works fine we just don't want to test it", is not 
clear.   But again, the upstream Alembic fix isn't as essential as much 
as it is that a project that is merging branches together makes sure 
they perform an ALTER against the alembic_version table to add a primary 
key constraint if one does not exist already.



"Note - If you have a table without a primary key, it is always possible 
to add an AUTO_INCREMENT column to the table without breaking your 
application. "


this cryptic statement suggests that perhaps Galera's AUTO_INCREMENT 
feature is the concern they have with DELETE.  Alembic does not use the 
AUTO_INCREMENT feature on this table.


Overall, Galera's notes on this subject do not indicate that an 
application with an un-constrained alembic_version table is dangerous in 
any way, with the possible exception of a branch merge operation for 
which the risk can be mitigated by adding the primary key constraint to 
the table.Additional detail as to the "DELETE is not supported" 
comment would be helpful.






 You cant disable a single check, you

could only disable them all and this could lead to some serious
problems, like data loss or corruption.

If OS wants support Galera, it needs to comply with the Galera
requirements.

On Mon, Jan 23, 2017 at 9:59 PM, Ihar Hrachyshka 

Re: [openstack-dev] [tripleo] Update TripleO core members

[Emilien Macchi]

Flavio, Steve, you're now core in TripleO !

Flavio: core on tripleo-common and tripleo-heat-templates
docker bits.
Steve: os-collect-config and also docker bits in
tripleo-common and tripleo-heat-templates.

Thanks for your hard work, keep rocking!
Congrats :-)

On Fri, Jan 27, 2017 at 2:44 AM, Dougal Matthews  wrote:
> +1!
>
> On 23 January 2017 at 19:03, Emilien Macchi  wrote:
>>
>> Greeting folks,
>>
>> I would like to propose some changes in our core members:
>>
>> - Remove Jay Dobies who has not been active in TripleO for a while
>> (thanks Jay for your hard work!).
>> - Add Flavio Percoco core on tripleo-common and tripleo-heat-templates
>> docker bits.
>> - Add Steve Backer on os-collect-config and also docker bits in
>> tripleo-common and tripleo-heat-templates.
>>
>> Indeed, both Flavio and Steve have been involved in deploying TripleO
>> in containers, their contributions are very valuable. I would like to
>> encourage them to keep doing more reviews in and out container bits.
>>
>> As usual, core members are welcome to vote on the changes.
>>
>> Thanks,
>> --
>> Emilien Macchi
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __
> OpenStack Development Mailing 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] [Requirements] Freeze

[Dmitry Mescheryakov]

No worries, good to know I did not miss anything about release procedures
:-)

Thanks,

Dmitry

On Mon, Jan 30, 2017 at 6:51 PM, Matthew Thode 
wrote:

> On 01/30/2017 03:24 AM, Dmitry Mescheryakov wrote:
> > Hello Matthew,
> >
> > I see that you have frozen my
> > CR https://review.openstack.org/#/c/425132/ , but it is for
> > stable/newton. Should not freeze apply to master only?
> >
> > Thanks,
> >
> > Dmitry
> >
>
> Yep, fixed, sorry about that.
>
>
> --
> Matthew Thode (prometheanfire)
>
> __
> OpenStack Development Mailing 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] [tripleo] Proposing Honza Pokorny core on tripleo-ui

[Emilien Macchi]

Honza, you're now core on tripleo-ui project. Thanks for your hard
work and congrats!

On Fri, Jan 27, 2017 at 2:45 AM, Dougal Matthews  wrote:
> +1!
>
> On 25 January 2017 at 15:28, Steven Hardy  wrote:
>>
>> On Tue, Jan 24, 2017 at 08:52:51AM -0500, Emilien Macchi wrote:
>> > I have been discussed with TripleO UI core reviewers and it's pretty
>> > clear Honza's work has been valuable so we can propose him part of
>> > Tripleo UI core team.
>> > His quality of code and reviews make him a good candidate and it would
>> > also help the other 2 core reviewers to accelerate the review process
>> > in UI component.
>> >
>> > Like usual, this is open for discussion, Tripleo UI core and TripleO
>> > core, please vote.
>>
>> +1
>>
>> __
>> OpenStack Development Mailing 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

[openstack-dev] [nova] TODOs before ocata rc1

[Matt Riedemann]

I've started an etherpad for at least my own sanity to track TODOs 
before we can cut the rc1 tag for Ocata:


https://etherpad.openstack.org/p/nova-ocata-rc1-todos

This is mostly going to identifying release-critical bugs that we need 
to fix and closing gaps on release notes and documentation.


--

Thanks,

Matt Riedemann

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

[openstack-dev] [QA] Gate Jobs failing after patch for bug/1628016

[White, Joshua L]

Hi Team,



I would like to get your feedback on the gate jobs failing and how to alleviate 
the issue.

The gate jobs are failing once the prefix is actually added for these tests 
jobs below:

1. test_list_container_contents_with_path

Issue:
For some reason whoever coded this test hardcoded the file path and name 
("Swift/TestObject").
Which means when the prefix is added instead of '-TestObject' its 
'-Swift/TestObject' resulting in the failure because the path is wrong.

2. test_list_container_contents_with_end_marker

Issue:
This test will only pass if the prefix begins with a capital letter.  
'' works but '' fails


I am trying to find the correct way to fix these issues without doing something 
that’s just hacky.

Please see patch for reference: https://review.openstack.org/#/c/397504/

Thanks,

Joshua White
irc: jlwhite


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

[openstack-dev] [nova] Next notification meeting

[Balazs Gibizer]

Hi,

The next notification subteam meeting will be held on 2017.01.31 17:00 
UTC [1] on #openstack-meeting-4.


Cheers,
gibi

[1]
https://www.timeanddate.com/worldclock/fixedtime.html?iso=20170131T17


__
OpenStack Development Mailing 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] PTG topics

[James Page]

Hi Team

We're only a few weeks off the PTG, so I think its about time we started
the ball rolling on planning our time out over the Monday/Tuesday.

I've created an etherpad so we can brainstorm a schedule for the two days:

  https://etherpad.openstack.org/p/openstack-charms-ptg-pike

If you're attending the PTG, please put you irc nic down at the top of the
pad, so we can track who's coming along and which topics each person is
interested in.

I'm keen that we use the time for discussion and planning of objectives for
the next 6 months, but also to ensure that if people need to spend time
working on a specific challenge, we can accommodate that as well.

See you all in Atlanta!

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

Re: [openstack-dev] [Requirements] Freeze

[Matthew Thode]

On 01/30/2017 03:24 AM, Dmitry Mescheryakov wrote:
> Hello Matthew,
> 
> I see that you have frozen my
> CR https://review.openstack.org/#/c/425132/ , but it is for
> stable/newton. Should not freeze apply to master only?
> 
> Thanks,
> 
> Dmitry
> 

Yep, fixed, sorry about that.


-- 
Matthew Thode (prometheanfire)

__
OpenStack Development Mailing 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] CI Squad Meeting Summary (week 5)

[Gabriele Cerami]

On 30 Jan, Paul Belanger wrote:

> Before you go out an implement some sort of in-repo configuration for 
> testing, I
> strongly encourage you to read up on our Zuulv3 spec[3], as we are providing
> this functionality.  What is comes down to, you'll be able to focus on writing
> tests, where zuul does all the test configuration and provisioning.
> 
> [3] https://specs.openstack.org/openstack-infra/infra-specs/specs/zuulv3.html

This is not about provisioning, we concluded we don't want to deal with
that, quickstart just offers a simple virthost provisioning to improve
user experience, but users (or other tools) have to deal with any more
complex topology that may be needed.
But as this tool was implemented with reproducibility in mind, we don't
want to consider just uptream as its consumer.

This effort on the configuration just aims in associating a job name to
a defined set of features we want to test during tripleo deployment.
For example:
When quickstart is called to test a periodic HA ovb on newton, what's
the best way to build and pass a configuration to quickstart that
contains all the variables to activate exactly all the features we want
to test ?
Passing the right configuration will require some automation, and maybe
zuul can help at least upsteam, but creating the configuration is a
manual process, and the results should be consumable by anyone.
We are focusing on this second part, and I can't see any overlap in zuul
for that.

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

Re: [openstack-dev] [tripleo] CI Squad Meeting Summary (week 5)

[Paul Belanger]

On Mon, Jan 30, 2017 at 01:37:56PM +0100, Attila Darazs wrote:
> In the spirit of "better late than never", here's a summary of our CI Squad
> meeting.
> 
> Time: Thursdays, 15:30-16:30 UTC
> Place: https://bluejeans.com/4113567798/
> 
> 
> Configuration management in TripleO CI
> ==
> 
> There was a design meeting organized by Gabrielle (thanks!) to discuss how
> to solve the problem of configuring the new Quickstart jobs.
> 
> There are multiple approaches for this problem, and it's difficult to find a
> balance from having a single definite config file per job (too much
> duplication) to parsing the job name and handling every option with coding
> logic in the testing system (hard to reproduce/know what's happening).
> 
Before you go out an implement some sort of in-repo configuration for testing, I
strongly encourage you to read up on our Zuulv3 spec[3], as we are providing
this functionality.  What is comes down to, you'll be able to focus on writing
tests, where zuul does all the test configuration and provisioning.

[3] https://specs.openstack.org/openstack-infra/infra-specs/specs/zuulv3.html

> What emerged from the still ongoing discussion is identifying three config
> sections:
> 
> * provisioner: e.g. libvirt, OVB or nodepool based jobs and the related
> configution to allow quickstart to work on these systems
>
I would suggest not spending too much time on your provisioner, once zuulv3
lands, it will potentially no longer be needed.  Additionally, if you want to do
provisioning, take a look at the linch-pin project, Clint Savage @ Red Hat has a
ansible provisioner too. Or, leverage the new nodepool APIs to get testing
resources.

> * release: one config file for release, config/release (we already have
> these)
> * config: one config file for general config, config/general_config
> 
> It seems useful to give a neutral name for a certain set of functionalities
> tested in certain CI jobs instead of the misleading names of "ha/nonha"
> (when in fact they test a lot more). "featureset01", "featureset02", etc.
> looks like a good candidate for naming them.
> 
> So we could end up with jobs like "tripleo-ovb-featureset01-newton", with
> the featureset matrix documented somewhere like tripleo-ci.
> 
Again, please look into the zuulv3 spec, I think you'll find some of this is
overlap.
> 
> Smaller topics
> ==
> 
> * Both the OVB and nodepool jobs are working apart from generic setbacks
> like the python-pandas issue breaking our jobs.
> 
> * Our blocker/bottleneck for transition is now the above discussed
> configuration management.
> 
> * The "Quickstart transition checklist" is now hosted on google docs
> here[1].
> 
> * We are having trouble keeping track of the issues in upstream CI. Using an
> invidual trello board instead of the current etherpad was suggested. We're
> going to try this solution out this week and post updates.
> 
> * Emilien mentioned the new additonal composable upgrades testing in TripelO
> CI[2].
> 
> * We had a bug triage/squashing event last Friday. Started moving bugs from
> the "tripleo-quickstart" project to "tripleo" and tag them as ci/quickstart,
> to ease the scheduling of bugs.
> 
> * Also managed to make a big improvment on the tripleo-quickstart bug count,
> going from 65 open bugs to 42, and from 37 new bugs to 21.
> 
> Full meeting minutes can be found here:
> 
> https://etherpad.openstack.org/p/tripleo-ci-squad-meeting
> 
> Best regards,
> Attila
> 
> [1] 
> https://docs.google.com/document/d/1Mb_t5Qe-Lnh0uaXy0ubX9y4k65Q4D_aw-49eZOqoviQ/edit?pli=1
> [2] https://review.openstack.org/425727
> 
> __
> OpenStack Development Mailing 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] [placement] placement api request analysis

[Chris Dent]

On Thu, 26 Jan 2017, Chris Dent wrote:

On Wed, 25 Jan 2017, Chris Dent wrote:

#B3
The new GET to /placement/allocations is happening when the
resource tracker calls _update_usage_from_instance, which is always
being called becuause is_new_instance is always true in that method,
even when the instance is not "new". This is happening because the
tracked_instaces dict is _always_ getting cleared before
_update_usage_from_instance is being called. Which is weird because
it appears that it is that method's job to update tracked_instances.
If I remove the clear() the get on /placement/allocations goes away.
But I'm not sure what else this will break. The addition of that line
was a long time ago, in this change (I think):
https://review.openstack.org/#/c/13182/


I made a bug about this:

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

and have the gate looking at what breaks if the clear goes away:

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


Nothing broke, but discussion in IRC[1] suggests that the clearing
of tracked_instances is effectively a safety valve for those cases
where events which are supposed to change the state of an instance
somehow get lost or incorrect recorded. By flushing
tracked_instances are more complete accounting is performed.

This is something that ought to be fixed, but will require more
focused testing so presumably is a "later". We should figure it out,
though, because it is responsible for much of the traffic related to
checking allocations.

Meanwhile, the fix to comparing old and new compute node objects[2]
has merged. This removes 3 repeated (assuming no other changes) per
periodic job.

That means the current calculation for number of requests per
periodic job is:

  The requests done via _init_compute_node:
  GET aggregates to update local aggregates map1
  GET inventories to compare with current inventory1
  Calls from _update_usage_from_instances:
remove_deleted_instances
  GET all the allocations for this resource provide1
_update_usage_from_instance
  GET allocations for consumer uuid1 per instance

3 + .

We can change this by:

* adding more smarts in _init_compute_node, but this impacts both
  our concept of "self-healing" inventory and the ability to
  dynamically manage aggregate associations

* adding more smarts with how tracked_instances is cleared or at
  least how the instances being tracked impacts when or how often a
  get allocations for consumer uuid is called

[1] Conversation between melwitt, cfriesen, superdan, me:
http://p.anticdent.org/3bbY

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

--
Chris Dent ¯\_(ツ)_/¯   https://anticdent.org/
freenode: cdent tw: @anticdent__
OpenStack Development Mailing 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] [trove] status of the gate

[Amrith Kumar]

The issues plaguing the gate have been addressed with the help of Andrey
Kurilin, Jian Song and Tin Lam. Thanks y'all for your patches which were
merged and helped unblock the gate[1].

As noted in the commit message there, this change includes some low quality
band-aid which needs to be redone before we get to Ocata. But for the
present, the gate is running again.

-amrith

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

> -Original Message-
> From: Amrith Kumar [mailto:amrith.ku...@gmail.com]
> Sent: Sunday, January 29, 2017 12:06 PM
> To: 'OpenStack Development Mailing List (not for usage questions)'
> 
> Subject: [trove] status of the gate
> 
> All:
> 
> There are at least a couple of issues that are currently impacting the
> trove
> gate and I'm getting to the bottom of it. The currently known problems are
> being handled in a single commit[1].
> 
> This currently emcompasses the issues identified in three independent
> commits, none of which will be able to merge by themselves [2], [3], and
> [4].
> 
> There is at least one more issue that I have to wrestle to the ground and
> it
> appears to be some change to the structure of oslo_context that isn't
> immediately apparent (at least that's the current hunch).
> 
> In the meanwhile, rechecks and changes to trove, and python-troveclient
> will
> merely fail after taking up some useless time in the gate.
> 
> I'll try and get this resolved soon, sorry for the delay.
> 
> -amrith
> 
> [1] https://review.openstack.org/#/c/426535/
> [2] https://review.openstack.org/#/c/425857/
> [3] https://review.openstack.org/#/c/423086/
> [4] https://review.openstack.org/#/c/412497/
> 
> 
> --
> Amrith Kumar
> GPG: 0x5e48849a9d21a29b



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

[openstack-dev] [trove][tc][stable] trove core team coverage this week

[Amrith Kumar]

Over the next couple of days, some members of the trove core team will be
traveling and others have commitments that may cause brief periods when
there is no one around immediately to respond on IRC.

For anything that needs urgent attention, please email me directly and I
will try to get back to you as soon as I can. For something urgent, please
include a telephone number where I can call you. Thanks for understanding.

-amrith

--
Amrith Kumar
GPG: 0x5e48849a9d21a29b



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

[openstack-dev] [tripleo] CI Squad Meeting Summary (week 5)

[Attila Darazs]

In the spirit of "better late than never", here's a summary of our CI 
Squad meeting.


Time: Thursdays, 15:30-16:30 UTC
Place: https://bluejeans.com/4113567798/


Configuration management in TripleO CI
==

There was a design meeting organized by Gabrielle (thanks!) to discuss 
how to solve the problem of configuring the new Quickstart jobs.


There are multiple approaches for this problem, and it's difficult to 
find a balance from having a single definite config file per job (too 
much duplication) to parsing the job name and handling every option with 
coding logic in the testing system (hard to reproduce/know what's 
happening).


What emerged from the still ongoing discussion is identifying three 
config sections:


* provisioner: e.g. libvirt, OVB or nodepool based jobs and the related 
configution to allow quickstart to work on these systems
* release: one config file for release, config/release (we already have 
these)

* config: one config file for general config, config/general_config

It seems useful to give a neutral name for a certain set of 
functionalities tested in certain CI jobs instead of the misleading 
names of "ha/nonha" (when in fact they test a lot more). "featureset01", 
"featureset02", etc. looks like a good candidate for naming them.


So we could end up with jobs like "tripleo-ovb-featureset01-newton", 
with the featureset matrix documented somewhere like tripleo-ci.



Smaller topics
==

* Both the OVB and nodepool jobs are working apart from generic setbacks 
like the python-pandas issue breaking our jobs.


* Our blocker/bottleneck for transition is now the above discussed 
configuration management.


* The "Quickstart transition checklist" is now hosted on google docs 
here[1].


* We are having trouble keeping track of the issues in upstream CI. 
Using an invidual trello board instead of the current etherpad was 
suggested. We're going to try this solution out this week and post updates.


* Emilien mentioned the new additonal composable upgrades testing in 
TripelO CI[2].


* We had a bug triage/squashing event last Friday. Started moving bugs 
from the "tripleo-quickstart" project to "tripleo" and tag them as 
ci/quickstart, to ease the scheduling of bugs.


* Also managed to make a big improvment on the tripleo-quickstart bug 
count, going from 65 open bugs to 42, and from 37 new bugs to 21.


Full meeting minutes can be found here:

https://etherpad.openstack.org/p/tripleo-ci-squad-meeting

Best regards,
Attila

[1] 
https://docs.google.com/document/d/1Mb_t5Qe-Lnh0uaXy0ubX9y4k65Q4D_aw-49eZOqoviQ/edit?pli=1

[2] https://review.openstack.org/425727

__
OpenStack Development Mailing 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][Dev] Changes coming to Product WG & Enterprise WG

[Hugh Blemings]

On 28/01/2017 02:56, Barrett, Carol L wrote:

After 35+ yrs in the Technology Industry, I have decided it’s time for a
change. I will be retiring from Intel on February 2^nd .



OpenStack has been a highlight of my career and I owe much of that to
you all. It’s been a pleasure knowing and working with you.



Yih Leong Sun (aka Leong) will be taking on the Leadership role for the
Enterprise WG and the co-leadership role of the Product Work Group,
along with Shamail Tahir. You will see other folks taking on additional
roles as part of my overall transition plan. I know you will help them
in their new roles.



Best wishes for your continued success – I’ll be cheering for OpenStack
from the bleachers!


Good luck Carol - whatever you involve yourself with from herein will be 
richer for your contributions as we have been richer for your all that 
you have done for OpenStack.


Thank you!

Kind Regards,
Hugh



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

[openstack-dev] [nova] How to use resource_providers for shared disk resources (NFS)

[Shewale, Bhagyashri]

Hi nova devs,

How can I use placement api's if my instance path is mounted on shared storage 
server (e.g. NFS)?

I am trying to set multinode setup with NFS shared storage for all nodes to 
share disk resources along with placement services. As of now it is creating 
resource providers for each of the compute node and adds the DISK_GB for each 
resource provider.

For example below are my environment details:

NODE A: compute
NODE B: controller + compute

Following entries are made in resource_providers table:

+-+-++--+++--+
| created_at  | updated_at  | id | uuid 
| name   | generation | can_host |
+-+-++--+++--+
| 2017-01-30 06:49:17 | 2017-01-30 09:12:06 |  1 | 
6cbbaf2b-5b8c-4f38-8b34-ee23791056a6 | openstack-VirtualBox   |  3 |
0 |
| 2017-01-30 09:02:29 | 2017-01-30 09:11:03 |  3 | 
bad71c26-8f36-43ea-abf4-bdbeffda9e54 | openstack-VirtualBox-1 |  2 |
0 |
+-+-++--+++--+

Following are the entries of inventories tables, of which 89 indicates the 
DISK_GB (size of shared storage):

+-+-++--+---+---+--+--+--+---+--+
| created_at  | updated_at  | id | resource_provider_id | 
resource_class_id | total | reserved | min_unit | max_unit | step_size | 
allocation_ratio |
+-+-++--+---+---+--+--+--+---+--+
| 2017-01-30 06:49:19 | 2017-01-30 09:10:37 |  1 |1 |   
  0 | 1 |0 |1 |1 | 1 |  
 16 |
| 2017-01-30 06:49:19 | 2017-01-30 09:10:37 |  2 |1 |   
  1 | 11210 |  512 |1 |11210 | 1 |  
1.5 |
| 2017-01-30 06:49:19 | 2017-01-30 09:10:37 |  3 |1 |   
  2 |89 |0 |1 |   89 | 1 |  
  1 |
| 2017-01-30 09:02:31 | 2017-01-30 09:11:03 |  7 |3 |   
  0 | 1 |0 |1 |1 | 1 |  
 16 |
| 2017-01-30 09:02:31 | 2017-01-30 09:11:03 |  8 |3 |   
  1 | 10253 |  512 |1 |10253 | 1 |  
1.5 |
| 2017-01-30 09:02:31 | 2017-01-30 09:11:03 |  9 |3 |   
  2 |89 |0 |1 |   89 | 1 |  
  1 |
+-+-++--+---+---+--+--+--+---+--+

However still I am able to create the instances over the size of actual shared 
storage.

Please let me know how to configure resource_providers in case of shared 
storage servers are used for disk resources.

Thank you,

Bhagyashri

__
Disclaimer: This email and any attachments are sent in strictest confidence
for the sole use of the addressee and may contain legally privileged,
confidential, and proprietary data. If you are not the intended recipient,
please advise the sender by replying promptly to this email and then delete
and destroy this email and any attachments without any further use, copying
or forwarding.__
OpenStack Development Mailing 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] minutes from todays IRC meeting

[James Page]

Hi All

Here are the links from todays Charms IRC meeting:

 Agenda:
https://etherpad.openstack.org/p/openstack-charms-weekly-meeting-20170129
 Minutes:
http://eavesdrop.openstack.org/meetings/charms/2017/charms.2017-01-30-10.03.html
 Minutes (text):
http://eavesdrop.openstack.org/meetings/charms/2017/charms.2017-01-30-10.03.txt
 Log:
http://eavesdrop.openstack.org/meetings/charms/2017/charms.2017-01-30-10.03.log.html

Our next team meeting is at 1700 UTC on the 6th February in
#openstack-meeting-4

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

Re: [openstack-dev] [openstack-ansible] Proposing Amy Marrich for core

[Jean-Philippe Evrard]

Hello,

Ofc it’s a +1!

Thanks Amy for all the work :)

Best regards,
JP

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

Date: Friday, 27 January 2017 at 14:29
To: "OpenStack Development Mailing List (not for usage questions)" 

Cc: "a...@demarco.com" , Andy McCrae 

Subject: [openstack-dev] [openstack-ansible] Proposing Amy Marrich for core

Hi OpenStack-Ansible team,

I would like to propose Amy Marrich for the core team for OpenStack-Ansible.

Amy has been consistently in the top 10 reviewers for our team in the last 30 
[1] and 90 [2] days, respectively, this release alone.

She has been an active and diligent member of the OpenStack-Ansible team since 
the end of 2015 and has continuously provided assistance for code and 
documentation reviews.

I think she will make a great addition to the core team and will help move code 
and doc issues forward quicker.

+1 from me

Thanks,

Alex

[1] http://stackalytics.com/report/contribution/openstackansible-group/30
[2] http://stackalytics.com/report/contribution/openstackansible-group/90









Rackspace Limited is a company registered in England & Wales (company 
registered number 03897010) whose registered office is at 5 Millington Road, 
Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy can be 
viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail message may 
contain confidential or privileged information intended for the recipient. Any 
dissemination, distribution or copying of the enclosed material is prohibited. 
If you receive this transmission in error, please notify us immediately by 
e-mail at ab...@rackspace.com and delete the original message. Your cooperation 
is appreciated.
__
OpenStack Development Mailing 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] [Requirements] Freeze

[Dmitry Mescheryakov]

Hello Matthew,

I see that you have frozen my CR https://review.openstack.org/#/c/425132/ ,
but it is for stable/newton. Should not freeze apply to master only?

Thanks,

Dmitry

On Wed, Jan 25, 2017 at 12:22 AM, Matthew Thode 
wrote:

> We are going to be freezing Thursday at ~20:00 UTC.
>
> So if you need any changes we'll be needing needing them in soon, with
> reasoning.  Thanks.
>
> --
> Matthew Thode (prometheanfire)
>
>
> __
> OpenStack Development Mailing 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] [ux] Future of the OpenStack UX team

[Shamail]

> On Jan 30, 2017, at 5:51 AM, Lana Brindley  wrote:
> 
> Hi Thierry,
> 
> Sorry for not noticing this thread and replying earlier.
> 
> I've now reviewed the minutes from the meeting, and I support thingee's 
> suggestion of having a UX working group. This way, UX can get the attention 
> it rightly deserves. Without the research and guidelines provided by the UX 
> team, user-facing projects (such as Docs) will be poorer. I believe that it's 
> in Foundations best interests to ensure that UX work is ongoing, and 
> adequately supported, in the same way as Marketing and other user outreach 
> services. 
+1
> 
> I am happy to work with Foundation (on behalf of the Docs team) to determine 
> how this would work in practice.
I'm happy to help as well.  The Product working group recently started using 
Personas in our user stories and I also participated in the Personas workshop 
with the UX team.

Thanks,
Shamail 

> 
> Thanks,
> Lana
> 
>> On 05/01/17 00:43, Thierry Carrez wrote:
>> Hi everyone,
>> 
>> Piet recently reached out to me to explain that he won't be able to
>> continue in his role as OpenStack UX team's PTL. Since he created the
>> team and spent a lot of time coordinating its activities, that raises
>> the question of the future of the OpenStack UX team.
>> 
>> The situation was discussed at the TC meeting yesterday[1] and the
>> general feeling was that there was a lot of value in a separate team
>> centralizing things like Persona definition and facilitating
>> properly-conducted UX surveys. That said, if nobody is able to dedicate
>> the time that effort needs, we could also disband the centralized team
>> and encourage every project to adopt the tools and techniques that were
>> built and introduced by the UX team in the past years.
>> 
>> So... What are your thoughts on those options ? Do we have a volunteer
>> (or more than one) to take over UX PTLship ?
>> 
>> [1]
>> http://eavesdrop.openstack.org/meetings/tc/2017/tc.2017-01-03-20.00.log.html#l-404
>> 
> 
> -- 
> Lana Brindley
> Technical Writer
> Rackspace Cloud Builders Australia
> http://lanabrindley.com
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [all][elections] PTL nomination period is now over

[Lana Brindley]

Yes, I replied on the other thread. Thanks :)

L

On 30/01/17 16:48, Kendall Nelson wrote:
> Yes of course :) Did you want to schedule a meeting or just discuss here 
> more? 
> 
> I've seen some discussion about making UX to a working group? 
> 
> -Kendall (diablo_rojo) 
> 
> On Sun, Jan 29, 2017, 7:46 PM Lana Brindley  > wrote:
> 
> Hi Kendall,
> 
> I'd like to discuss the future of the UX project with you, if that's OK?
> 
> Lana
> 
> On 30/01/17 11:05, Kendall Nelson wrote:
> > Hello All!
> >
> > PTL Nomination is now over. The official candidate list is available on 
> the election website[0].
> >
> > There is only 1project without candidates, so according to this 
> resolution[1], the TC we'll have to appoint a new PTL for OpenStack UX.
> >
> > There are 5projects that will have an election: Ironic, Keystone, 
> Neutron, Quality Assurance and Stable Branch Maintenance.The details for 
> those will be posted shortly after we setup the CIVS system.
> >
> > Thank you,
> >
> > [0]: http://governance.openstack.org/election/# 
> pike 
> -ptl-candidates
>  
> > [1]: 
> http://governance.openstack.org/resolutions/20141128-elections-process-for-leaderless-programs.html
> >
> >
> > 
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: 
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe 
> 
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> 
> --
> Lana Brindley
> Technical Writer
> Rackspace Cloud Builders Australia
> http://lanabrindley.com
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe 
> 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 

-- 
Lana Brindley
Technical Writer
Rackspace Cloud Builders Australia
http://lanabrindley.com



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