date:20161107

Re: [openstack-dev] [nova] Live migrations: Post-Copy and Auto-Converge features research

2016-11-07 Thread Koniszewski, Pawel

Adding operators list, as it might be interesting for them. Please note that 
some of tested options are not available in nova, i.e., XBZRLE and 
postcopy-after-precopy. Regarding postcopy, nova automatically decides whether 
live migration should be switched to postcopy mode (only if 
live_migration_permit_post_copy is set to True, by default it is set to False), 
postcopy-after-precopy is an internal virsh command which is not exposed 
through the libvirt API.

Kind Regards,
Pawel Koniszewski

From: Vlad Nykytiuk [mailto:vnykyt...@mirantis.com]
Sent: Monday, November 7, 2016 9:35 PM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [nova] Live migrations: Post-Copy and Auto-Converge 
features research

Hi,

As you may know, currently QEMU supports several features that help live 
migrations to operate more predictively. These features are: auto-converge and 
post-copy.
I made a research on performance characteristics of these two features, you can 
find it by the following link:
https://rk4n.github.io/2016/08/10/qemu-post-copy-and-auto-converge-features/

Hope you find it helpful.

Thanks
—
Vlad

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

[openstack-dev] [openstack-infra] Please add a initial core member to meteos-core.

2016-11-07 Thread Hiroyuki Eguchi

Hello Infra Team.

I've created new projects named meteos and python-meteosclient.
Cloud you please add me (Hiroyuki Eguchi )
as a initial core member of meteos-core ?

Thanks.

--
Hiroyuki Eguchi

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

Re: [openstack-dev] [mistral] Meeting Time

2016-11-07 Thread Lingxian Kong

Hi, Dougal,

Thanks for bringing this, already replied.


Cheers,
Lingxian Kong (Larry)

On Tue, Nov 8, 2016 at 5:20 AM, Dougal Matthews  wrote:

> Hi all,
>
> We want to make sure that the Mistral meeting time is as good as possible,
> so that everyone interested can attend. To do that, please add your
> name/nick and the times that suit you to this etherpad:
>
> https://etherpad.openstack.org/p/mistral-meeting-time
>
> If we are really lucky, we will find a time in that for everyone. if we
> are slightly lucky we will find two time slots that covers everyone and the
> meeting can alternate.
>
> We may find that the current time is best for everyone, but I wanted to
> make sure.
>
> Cheers,
> Dougal
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [mistral] Promoting Dougal Matthews to the core team

2016-11-07 Thread Lingxian Kong

+1 of course!


Cheers,
Lingxian Kong (Larry)

On Tue, Nov 8, 2016 at 6:09 PM, Renat Akhmerov 
wrote:

> Hi,
>
> I’d like to promote Dougal Matthews to the Mistral core team. [1] shows
> Dougal’s Mistral contribution summary for Newton cycle.
>
> Here are the reasons why I would like to see Dougal in the core team:
>
>- He reviews a lot and provides valuable comments, especially when it
>comes to discussing design of the new features
>- He sent 18 patches in Newton cycle which may not be a big number but
>it was his first full cycle in Mistral and I believe he can do more
>- He is one of the most active team members in general and in IRC
>specifically, always open for communication and easy to talk to
>- He is an active user of Mistral which is very important for me since
>he’s capable of providing valuable practical feedback on design, usability,
>reliability etc.
>- He seems to be very excited about working on Mistral
>
>
> Besides that I believe Dougal makes a good friendly atmosphere in our
> development team daily in our IRC channel and our weekly IRC meetings.
>
> Team, I would ask you to support me in this promotion.
>
> Thanks
>
> [1] http://stackalytics.com/?module=mistral-group_id=
> d0ugal=newton=marks
>
> 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

Re: [openstack-dev] [MassivelyDistributed] bi-weekly meeting

2016-11-07 Thread Tony Breeds

On Mon, Nov 07, 2016 at 05:52:43PM +0100, lebre.adr...@free.fr wrote:
> Dear all, 
> 
> We are still looking for an irc channel for our meeting: 
> https://review.openstack.org/#/c/393899
> There is no available channels for the slot we selected during our 
> face-to-face meeting in Barcelona. 
> 
> If I'm correct, we have two possibilities: 
> - Determine another slot: the first available slot on Wednesday is at 17:00 
> UTC.

Or you could look at 1400 on Wednesday

> - Ask for the creation of a new IRC channel dedicated to our WG: something 
> line #openstack-massively-distributed

This is an option but you can't hold meetings in project specific channels as
the meeting bot only works correctly in the #openstack-meeting rooms.

We from time to time get asked to cerate a 5th meeting room.  Looking at [1] I
don't feel like we're full enough to persue that.

Yours Tony.
[1] 
https://docs.google.com/spreadsheets/d/1lQHKCQa4wQmnWpTMB3DLltY81kIChZumHLHzoMNF07c/edit?usp=sharing

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

Re: [openstack-dev] [neutron] Ocata End user and operator feedback recap

2016-11-07 Thread Oleg Bondarev

On Tue, Nov 8, 2016 at 12:22 AM, Carl Baldwin  wrote:

> Ocata End user and operator feedback recap
> 
>
> The purpose of this session was to gather feedback from end users and
> operators to help direct the efforts of developers during (at least) the
> Ocata cycle. Feedback was captured on the etherpad [1]. There was a related
> session in the operators' track [2] which may also be of interest.
>
> We began with a short discussion about client compatibility which was
> deferred to the following session specifically about the client [3].
>
> There was a discussion about if Neutron will implement cells like Nova
> has. There is currently no plan. I have heard this come up for the past
> couple of summits but there is little concrete evidence of the scale issues
> being encountered by operators. If you are running Neutron at scale, we
> could use more of your input.
>
> There was some discussion about an issue around moving a floating ip from
> one instance to another when keepalive is in use. We needed more
> information to debug this. It should be sending a gratuitous arp. Another
> keepalive issue was discussed. Too many SIGHUPs within a period of time can
> cause failover resulting in disruption. I do not know if a bug was filed
> for this to follow up. If this was you, please follow up with a link to the
> bug report.
>

https://bugs.launchpad.net/neutron/+bug/1639315 looks related


>
> There was a short discussion about Horizon support for security groups on
> a port. A bug was filed for this.
>
> Finally, there was some discussion about enabling end users to create
> Neutron L3 routers which are backed by hardware resources. There is no such
> thing yet but Neutron does have a new concept in development called "L3
> flavors". This would enable a driver (to be written) which would allow this
> sort of thing.
>
> Carl Baldwin
>
> [1] https://etherpad.openstack.org/p/ocata-neutron-
> end-user-operator-feedback
> [2] https://etherpad.openstack.org/p/newton-neutron-pain-points
> [3] https://etherpad.openstack.org/p/ocata-neutron-client
>
> __
> OpenStack Development Mailing 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][qa] Testing with ephemeral/swap disks

2016-11-07 Thread Diana Clarke

Ah yes, this gem ;)

This was my first attempt at a Tempest patch; my first contribution to
that project ever.

It was met with:

"this is the wrong approach and can never land like this"

"This as a separate test is also quite frankly overkill and unecessary."

"But if you really must have this verified in tempest..."

"But as this is today it can't ever land."

And then silence.

It was a truly welcoming experience. Perhaps a template we can use for
all new contributors going forward ;)

That said, I am actually interested in contributing further on this
front. Extend an olive branch, and point me in the right direction.

--diana

On Mon, Nov 7, 2016 at 11:03 AM, Matt Riedemann
 wrote:
> Nova has a known gap in integration testing of ephemeral/swap disks,
> especially around resizes and migrations.
>
> In Newton, Diana Clarke worked on a Tempest patch to verify the size of
> disks before and after a resize:
>
> https://review.openstack.org/#/c/338411/
>
> The QA team took issue with that patch because it creates specific flavors
> which might not work in all clouds, which is a valid concern.
>
> At the summit some of the Nova people talked about what if we just added
> ephemeral/swap to the flavors that devstack creates and puts in tempest.conf
> - then we'd get some implicit coverage of those by default. That doesn't
> really help non-devstack CI systems, but I'm not entirely sure it matters,
> at least right now.
>
> If we did have a specific test for this, like Diana's above, then we could
> just skip the test if the flavors in tempest.conf don't have ephemeral/swap
> defined. That would allow us to test this in the upstream CI, and external
> CI could also test it if they wanted to, but it wouldn't break external CI.
>
> Would that be OK? Or are there other issues with that approach?
>
> Alternatively we could work on some in-tree functional tests if those would
> work, but someone would have to investigate that. Note that the existing
> functional tests in Nova are not running libvirt, or glance, or any other
> external service - they only run a wsgi app server and a database (sqlite by
> default).
>
> There has been talk of creating a nova-dsvm-integration job (there are
> differing opinions on if that should use devstack or not) which wouldn't run
> Tempest tests, just in-tree integration tests. So they could test things
> that aren't going through the REST API, like the image cache. The problem
> with this extra job is the lack of warm bodies to work on a POC.
>
> So having brought these up - does anyone want to volunteer to explore these
> options or have issues with either one?
>
> --
>
> Thanks,
>
> Matt Riedemann
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [mistral] Meeting Time

2016-11-07 Thread Renat Akhmerov

Dougal,

I think it’s a high time we found another slot. The reason is that we keep 
losing presence of a number of core contributors on our team meetings. Mostly 
it’s about folks in North America (e.g. California), New Zealand. I know it’s 
also inconvenient for some folks in India.

Thanks for bringing this up. I tried to address this before but probably didn’t 
have enough discipline and patience to bring it to a conclusion.

I filled time intervals that work for me in the etherpad.

Renat Akhmerov
@Nokia

> On 7 Nov 2016, at 23:20, Dougal Matthews  wrote:
> 
> Hi all,
> 
> We want to make sure that the Mistral meeting time is as good as possible, so 
> that everyone interested can attend. To do that, please add your name/nick 
> and the times that suit you to this etherpad:
> 
> https://etherpad.openstack.org/p/mistral-meeting-time 
> 
> 
> If we are really lucky, we will find a time in that for everyone. if we are 
> slightly lucky we will find two time slots that covers everyone and the 
> meeting can alternate.
> 
> We may find that the current time is best for everyone, but I wanted to make 
> sure.
> 
> Cheers,
> Dougal
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing 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] [mistral] Promoting Dougal Matthews to the core team

2016-11-07 Thread Renat Akhmerov

Hi,

I’d like to promote Dougal Matthews to the Mistral core team. [1] shows 
Dougal’s Mistral contribution summary for Newton cycle.

Here are the reasons why I would like to see Dougal in the core team:
He reviews a lot and provides valuable comments, especially when it comes to 
discussing design of the new features
He sent 18 patches in Newton cycle which may not be a big number but it was his 
first full cycle in Mistral and I believe he can do more
He is one of the most active team members in general and in IRC specifically, 
always open for communication and easy to talk to
He is an active user of Mistral which is very important for me since he’s 
capable of providing valuable practical feedback on design, usability, 
reliability etc.
He seems to be very excited about working on Mistral

Besides that I believe Dougal makes a good friendly atmosphere in our 
development team daily in our IRC channel and our weekly IRC meetings.

Team, I would ask you to support me in this promotion.

Thanks

[1] 
http://stackalytics.com/?module=mistral-group_id=d0ugal=newton=marks
 


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

Re: [openstack-dev] [cinder] consistency groups in ceph

2016-11-07 Thread Victor Denisov

One more question. What is the expected behavior if you remove a
volume completely?
Should the group snapshot removed first? Should the volume snapshot be
removed from the group snapshot?
Should we keep the snapshot even if the image doesn't exist anymore?

Thanks,
Victor.

On Tue, Nov 1, 2016 at 7:02 AM, yang, xing  wrote:
> Hi Victor,
>
> Please see my answers inline below.
>
> In Newton, we added support for Generic Volume Groups.  See doc below.  CGs 
> will be migrated to Generic Volume Groups gradually.  Drivers should not 
> implement CGs any more.  Instead, it can add CG support using Generic Volume 
> Group interfaces.  I'm working on a dev doc to explain how to do this and 
> will send an email to the mailing list when I'm done.  The Generic Volume 
> Group interface is very similar to CG interface, except that the Generic 
> Volume Group requires an additional Group Type parameter to be created.  
> Using Group Type, CG can be a special type of Generic Volume Group.  Please 
> feel free to grab me on Cinder IRC if you have any questions.  My IRC handle 
> is xyang or xyang1.
>
> http://docs.openstack.org/admin-guide/blockstorage-groups.html
>
> Thanks,
> Xing
>
>
> 
> From: Victor Denisov [vdeni...@mirantis.com]
> Sent: Monday, October 31, 2016 11:29 PM
> To: openstack-dev@lists.openstack.org
> Cc: Jason Dillaman
> Subject: [openstack-dev] [cinder] consistency groups in ceph
>
> Hi,
>
> I'm working on consistency groups feature in ceph.
> My question is about what kind of behavior does cinder expect from
> storage backends.
> I'm particularly interested in what happens to consistency groups
> snapshots when I remove an image from the group:
>
> Let's imagine I have a consistency group called CG. I have images in
> the consistency group:
> Im1, Im2, Im3, Im4.
> Let's imagine we have snapshots of this consistency group:
>
> CGSnap1
> CGSnap2
> CGSnap3
>
> Snapshots of individual images in a consistency group snapshot I will call
> CGSnap2Im1 - Snapshot of image 1 from consistency group snapshot 2.
>
> Qustion 1:
> If consistency group CG has 4 images: Im1, Im2, Im3, Im4.
> Can CGSnap1 have more images than it already has: Im1, Im2, Im3, Im4, Im5.
>
> Can CGSnap1 have less images than it already has: Im1, Im2, Im3.
>
> [Xing]  Once a snapshot is taken from a CG, it can no longer be changed.  It 
> is a point-in-time copy.  CGSnap1 cannot be modified.
>
> Question 2:
> If we remove image2 from the consistency group. Does it mean that
> snapshots of this image should be removed from all the CGSnaps.
>
> Example:
> We are removing Im2.
> CGSnaps look like this:
>
> CGSnap1 - CGSnap1Im1, CGSnap1Im2, CGSnap1Im3
> CGSnap2 - CGSnap2Im1, CGSnap2Im2, CGSnap2Im3, CGSnap3Im4
> CGSnap3 - CGSnap3Im1, CGSnap3Im2, CGSnap3Im3, CGSnap3Im4
>
> What happens to snapshots: CGSnap1Im2,CGSnap2Im2, CGSnap3Im2? Do we
> remove them, do we keep them. Is it important what we do to them at
> all?
>
> [Xing] If your CG contains 4 volumes when you take the snapshot of the CG, 
> the resulting CGSnap should be associated with 4 snapshots corresponding to 
> the 4 volumes.  If you add more volumes to the CG or remove volumes from CG 
> after CGSnap was taken, it should not affect CGSnap.  It will only affect CG 
> snapshots that you take in the future.
>
> Thanks,
> Victor.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[openstack-dev] [python-keystoneclient] Return request-id to caller

2016-11-07 Thread koshiya maho

Hi Keystone devs,

Blueprint [1] related to request-ids is approved for Mitaka and 
its implementation [2] is up for review for quite a long time. 
And, I have submitted a blueprint about logging [3].
I would like to include these patch in Ocata.
Could you review it?

[1]
https://blueprints.launchpad.net/python-keystoneclient/+spec/return-request-id-to-caller

[2]
https://review.openstack.org/#/c/261188/
https://review.openstack.org/#/c/267449/
https://review.openstack.org/#/c/267456/
https://review.openstack.org/#/c/268003/

[3]
https://blueprints.launchpad.net/python-keystoneclient/+spec/log-request-id

Thank you,
--
Maho Koshiya
E-Mail : koshiya.m...@po.ntts.co.jp



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

[openstack-dev] [new][cinder] os-brick 1.8.0 release (ocata)

2016-11-07 Thread no-reply

We are chuffed to announce the release of:

os-brick 1.8.0: OpenStack Cinder brick library for managing local
volume attaches

This release is part of the ocata release series.

The source is available from:

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

Download the package from:

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

Please report issues through launchpad:

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

For more details, please see below.

Changes in os-brick 1.7.0..1.8.0


f7b8d24 Raise specific exception for an invalid protocol connector
bbd4f6e Updated from global requirements
8f59fa1 Multipath device keeps old size when extending volume
bc9cba0 Updated from global requirements
d67db13 Delete deprecated Hacking in tox.ini
4ae2389 Delete  MANIFEST.in in os-brick
66568b0 Enable release notes translation
7b46642 Replace 'assertTrue(a not in b)' with 'assertNotIn(a, b)'
e591bc7 Stop calling multipath -r when attaching/detaching iSCSI volumes
9b56150 Change assertTrue(isinstance()) with optimal assert


Diffstat (except docs and test files)
-

MANIFEST.in|  6 ---
os_brick/exception.py  |  5 ++
os_brick/initiator/connector.py|  3 +-
os_brick/initiator/connectors/fibre_channel.py |  2 +-
os_brick/initiator/connectors/iscsi.py |  8 +---
os_brick/initiator/linuxscsi.py| 56 +++---
.../initiator/connectors/test_fibre_channel.py |  4 +-
releasenotes/source/conf.py|  3 ++
requirements.txt   |  2 +-
test-requirements.txt  |  4 +-
tox.ini|  2 +-
16 files changed, 77 insertions(+), 99 deletions(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index cf0c769..1b198a1 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -14 +14 @@ oslo.service>=1.10.0 # Apache-2.0
-oslo.utils>=3.16.0 # Apache-2.0
+oslo.utils>=3.17.0 # Apache-2.0
diff --git a/test-requirements.txt b/test-requirements.txt
index d31c59f..22d93cb 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -6 +6 @@ hacking<0.11,>=0.10.0
-coverage>=3.6 # Apache-2.0
+coverage>=4.0 # Apache-2.0
@@ -9 +9 @@ python-subunit>=0.0.18 # Apache-2.0/BSD
-reno>=1.8.0 # Apache2
+reno>=1.8.0 # Apache-2.0



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

Re: [openstack-dev] [all][infra][requirements] Odd cases in requirements?

2016-11-07 Thread Tony Breeds

On Sat, Sep 03, 2016 at 07:33:42PM +0200, Andreas Jaeger wrote:
> Reviewing all the constraints work, I see that repositories have created
> some workaround around requirements install for one of these two legimit
> reasons - most often using tools/tox_install.sh from tox.ini for it:
> 
> 1) The repository is a dependency of another one and uses constraints,
> so edit upper-constraints file and allow git install.
> 
> Example:
> http://git.openstack.org/cgit/openstack/ironic-lib/tree/tools/tox_install.sh

We had a very brief discussion about this in Barcelona.  The idea being to
create an "incubator" style script in openstack/requirements that can be the
canonical source and easily copied out to repos that need it.  I'm not
proposing auto syncing but it would be pretty easy to script.

We need "all projects"[1] to support constraints real soon now.  It seems like
the majority of projects that currently do not use constraints are because
they're also listed in constraints.

I started looking at this today using [2] as the base in the oslo.messaging
repo  The good thing about this is it doesn't "just work"  I hit the following
problem:
---
cmdargs: 
['/home/stack/projects/openstack/openstack/oslo.messaging/tools/tox_install.sh',

'https://git.openstack.org/cgit/openstack/requirements/plain/upper-constraints.txt',

'/home/stack/projects/openstack/openstack/oslo.messaging/.tox/dist/oslo.messaging-5.12.1.dev10.zip']

Processing ./.tox/dist/oslo.messaging-5.12.1.dev10.zip
Could not satisfy constraints for 'oslo.messaging': installation from path or 
url cannot be constrained to a version
---

This is because we use 'edit-constraints' to change "oslo.messaging===5.12.0" to
"-e 
file:///home/stack/projects/openstack/openstack/oslo.messaging#egg=oslo.messaging"[3]

Which doesn't match because we're installing from an sdist.

For development installs like this what we really want is a way to say
constrain all my requirements but allow this library to be unconstrained don't
we?  That seems to me what we're saying in [3].  When I'm working locally I do
something like:

---
pip install -c 
https://git.openstack.org/cgit/openstack/requirements/plain/upper-constraints.txt
 \
-r requirements.txt -r test-requirements.txt
pip install .
---

This is all leading me to think that we should just remove the constraint on
$library which can be done with something like:
--- [4]
#!/usr/bin/env bash

# Client constraint file contains this client version pin that is in conflict
# with installing the client from source. We should remove the version pin in
# the constraints file before applying it for from-source installation.
BRANCH_NAME=XXX
CLIENT_NAME=XXX

set -e

CONSTRAINTS_FILE=$1
shift

localfile="${VIRTUAL_ENV}/upper-constraints.txt"
if [[ $CONSTRAINTS_FILE != http* ]]; then
CONSTRAINTS_FILE=file://$CONSTRAINTS_FILE
fi

curl $CONSTRAINTS_FILE -k -o $localfile
sed -i~ -e "/^${CLIENT_NAME}===/d" $localfile

pip install -U -c$localfile $*
---

Using openstack_requirements is the "right" thing to do and we could still use
edit-constraints $localfile -- $CLIENT_NAME ""
do delete the entry but it seems like wasted work to me

> 2) Install a package that is not on pypi. This is typical neutron or
> horizon.
> 
> Example:
> http://git.openstack.org/cgit/openstack/neutron-lbaas/tree/tools/tox_install.sh

This is much less thought out but can't we enhance the deps in tox.ini like:

---
deps = os:neutron
   os:neutron-lbaas
   -r requirements.txt
---

and then use something like:
--- [5]
#!/usr/bin/env bash

function install_os_dep()
{
   set -- $( echo $1 | sed -e 's/:/ /')
   prefix=$1  # ignored
   project=$2

   # Now basically turn 
http://git.openstack.org/cgit/openstack/neutron-lbaas/tree/tools/tox_install.sh 
into a shell function
}
# Client constraint file contains this client version pin that is in conflict
# with installing the client from source. We should remove the version pin in
# the constraints file before applying it for from-source installation.
BRANCH_NAME=XXX
CLIENT_NAME=XXX

set -e

CONSTRAINTS_FILE=$1
shift

localfile="${VIRTUAL_ENV}/upper-constraints.txt"
if [[ $CONSTRAINTS_FILE != http* ]]; then
CONSTRAINTS_FILE=file://$CONSTRAINTS_FILE
fi

curl $CONSTRAINTS_FILE -k -o $localfile
sed -i~ -e "/^${CLIENT_NAME}===/d" $localfile

deps=""
while [ $# -gt 1 ] ; do
case "$1" in
os:*)
install_os_dep "$1"
;;
*)
  deps+="$1"
;;
shift 1
done
pip install -U -c$localfile $deps
exit $?
--- [6]

We also discussed that the right place to fix these issues could be in tox
and/or pip but as I said earlier it's a matter of balancing right vs right now
:(

Yours Tony.

[1] For now that means all deliverables listed in
openstack/governance:reference/projects.yaml, but nothing is stopping
adoption in other stackforge projects.
[2] 
http://git.openstack.org/cgit/openstack/python-neutronclient/tree/tools/tox_install.sh
[3]

Re: [openstack-dev] [mistral] Team meeting minutes/log - 11/07/2016

2016-11-07 Thread Lingxian Kong

Hi, team,

I also added my time information in that etherpad, thanks for bringing that
into discussion.


Cheers,
Lingxian Kong (Larry)

On Tue, Nov 8, 2016 at 6:01 AM, Renat Akhmerov 
wrote:

> The minutes and log of the meeting we just had:
> http://eavesdrop.openstack.org/meetings/mistral/2016/
> mistral.2016-11-07-16.01.html
> http://eavesdrop.openstack.org/meetings/mistral/2016/
> mistral.2016-11-07-16.01.log.html
>
> Thanks for joining!
>
> 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

Re: [openstack-dev] [all] Embracing new languages in OpenStack

2016-11-07 Thread Ashlee Young

Thanks, Jeremy! I don't expect much hand holding but am trying to come up to 
speed.

Sent from my iPhone

> On Nov 7, 2016, at 11:10, Jeremy Stanley  wrote:
> 
>> On 2016-11-07 10:31:22 -0800 (-0800), Ash wrote:
>> [...]
>> Here's another take on the situation. If there are people who genuinely
>> wish to see a CI pipeline that can support something like Go, perhaps you
>> can establish a prerequisite of working with the Infra team on establishing
>> the new pipeline. In my opinion, this seems to be the major gate. So, if
>> there's a clear path identified, resources provided, and the Infra team is
>> ultimately benefitted, then I'm not sure why there should be another
>> rejection. Just a thought. I know this proposal continues to come up and
>> I'm a big fan of seeing other languages supported, especially Go. But I
>> also understand that it can break things. Personally, I would even
>> volunteer to work on such an Infra effort.
> [...]
> 
> Welcome aboard! Monty's already laid some of the groundwork, but
> really most of the effort is just getting familiar with what we
> already have and how to avoid duplicating work. As has been pointed
> out we're spread pretty thin, but not so thin that we can't answer
> questions posed by someone who is driven and relatively
> self-sufficient reading documentation and looking at production
> examples. Most of the solutions implemented in our infrastructure
> come from interested members of the community at large, and we're
> proud of our ability to enable that sort of inclusive participation.
> 
> I won't pretend it isn't complex and don't expect members of the
> Infra team to have sufficient bandwidth for hand-holding and
> spoon-feeding, but we do our best to help guide contributors toward
> implementing solutions that benefit the community at large. Even if
> Go isn't a TC-sanctioned language for official OpenStack
> deliverables, having the ability to support it (or Haskel, or Ada,
> or...) in our community infrastructure eases experimentation and
> promotes language-specific innovation for unofficial repositories
> within our ecosystem.
> -- 
> Jeremy Stanley
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [Magnum] New Core Reviewers

2016-11-07 Thread Yuanying OTSUKA

+1 for both.

Best regards
-yuanying

2016年11月8日(火) 4:23 Hongbin Lu :

> +1!
>
> Both jvgrant and yatin contributed a lot to the Magnum project. It would
> be great to have both of you in the core team.
>
> Best regards,
> Hongbin
>
> > -Original Message-
> > From: Adrian Otto [mailto:adrian.o...@rackspace.com]
> > Sent: November-07-16 2:06 PM
> > To: OpenStack Development Mailing List (not for usage questions)
> > Subject: [openstack-dev] [Magnum] New Core Reviewers
> >
> > Magnum Core Team,
> >
> > I propose Jaycen Grant (jvgrant) and Yatin Karel (yatin) as new Magnum
> > Core Reviewers. Please respond with your votes.
> >
> > Thanks,
> >
> > Adrian Otto
> > ___
> > ___
> > OpenStack Development Mailing 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] [searchlight] Propose Zhenyu Zheng for Searchlight core

2016-11-07 Thread Zhenyu Zheng

Thanks a lot, there will be still so much to learn from you guys.

On Tue, Nov 1, 2016 at 4:58 PM, Lei Zhang  wrote:

> +1 for me
>
> On Thu, Oct 20, 2016 at 5:13 PM, Brian Rosmaita <
> brian.rosma...@rackspace.com> wrote:
>
>> +1 from me, I'll be happy to see Kevin on the core list.
>>
>> On 10/19/16, 10:10 AM, "McLellan, Steven"  wrote:
>>
>> Hi,
>>
>> I'd like to propose Zhenyu Zheng (Kevin_Zheng on IRC) for Searchlight
>> core. While he's most active on Nova, he's also been very active on
>> Searchlight both in commits and reviews during the Newton release and into
>> Ocata on Searchlight. Kevin's participated during the weekly meetings and
>> during the week, and his reviews have been very high quality as well as
>> numerous. This would also help move towards have greater cross-project
>> participation, especially with Nova.
>>
>> If anyone has any objections, let me know, otherwise I will add Kevin to
>> the core list at the weekend.
>>
>> Thanks!
>>
>> Steve
>>
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Horizon][DataTables] how to generate a confirmation dialog

2016-11-07 Thread John Calcote

Thanks Timur! That's exactly what I needed!

On Mon, Nov 7, 2016 at 2:50 AM, Timur Sufiev  wrote:
> Hi, John,
>
> the code you're looking for is located here:
> https://github.com/openstack/horizon/blob/master/horizon/static/horizon/js/horizon.tables.js#L227-L312
> This is bound at
> https://github.com/openstack/horizon/blob/master/horizon/static/horizon/js/horizon.forms.js#L368-L373
>
> On Sun, Nov 6, 2016 at 10:32 PM John Calcote  wrote:
>>
>> Ping. No thoughts on this from anyone?
>>
>>
>> On Nov 4, 2016 9:26 PM, "John Calcote"  wrote:
>>>
>>> Hi all -
>>>
>>> I don't see a better forum anywhere for this post - please correct me
>>> if I'm wrong.
>>>
>>> I have a django/horizon application. On one page users may delete
>>> objects. I'd like to display a modal dialog confirming the delete
>>> before submit. Can anyone tell me if there's a way to tie a
>>> confirmation dialog to a table's DeleteAction?
>>>
>>> Note - my template is a trivial table.render with multi-select enabled -
>>> e.g.,
>>>
>>> {% block main %}
>>> {{ table.render }}
>>> {% endblock %}
>>>
>>> I've searched the docs and the code, but nothing sticks out at me. I'm
>>> not a client-side expert, but I can usually find my way around in the
>>> chrome debugger.
>>>
>>> Thanks,
>>> John
>>
>> __
>> OpenStack Development Mailing 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] [Docs] Changes to docs speciality teams, meetings, and reporting

2016-11-07 Thread Lana Brindley

We now have a new docs meeting time, every second Thursday 2100, starting next 
week, on 18 November.

See you there!

L

On 04/11/16 11:23, Lana Brindley wrote:
> Hi everyone,
> 
> There was a long-running and wide-ranging conversation during Summit about 
> community engagement in the docs team, most formally at the 'Social Things' 
> session[1], and culminating in the 'Ocata Planning' session[2] on the last 
> day. I suggest you read those etherpads if you weren't at the sessions. This 
> was a major part of my PTL candidacy platform for Ocata, and I'm excited that 
> we had so much productive conversation, complete with  some action items that 
> we can implement immediately.
> 
> First of all, we have seen a drop off in both docs mailing list traffic and 
> docs meeting conversation over the past twelve months or so, even though 
> contributions have remained steady (for the openstack-manuals repo). This is 
> attributed partially to a much-improved Contributor Guide (meaning we spend 
> less time on answering the same questions over and over), and but it's also 
> apparently because conversation is splintering off into speciality team 
> groups, rather than happening in the wider context of the docs group as a 
> whole. 
> 
> So, while speciality teams are definitely valued and important, especially 
> when it comes to directing and completing specific work items, we have come 
> up with a few smaller changes we can make to try and improve our sense of 
> community:
> 
> * Speciality team meetings are now going to be restricted to once per month, 
> or on an as-needed basis.
> * The docs meeting will change to a single Euro/APAC timed meeting, every 
> second week, probably around 2100 UTC (to be  confirmed).
> * I will no longer be asking speciality team leads for a written report for 
> the newsletter. Instead, please attend the docs meeting and report there. If 
> you are not able to attend, you will have the option to provide a written 
> report ahead of time to be presented by a proxy. 
> * The newsletter will go to every second week, timed to be after the docs 
> meeting, and will contain speciality team reports and other updates from that 
> meeting.
> 
> I would like your feedback on these changes, especially if you didn't get a 
> chance to  participate in the conversation at Summit.
> 
> I will be implementing these changes over the next week or so, and there will 
> be further opportunity for you  to express your opinion on these changes as 
> we go.
> 
> Lana
> 
> 1: https://etherpad.openstack.org/p/BCN-Docs-Social
> 2: https://etherpad.openstack.org/p/BCN-Docs-OcataPlanningWG
> 

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

Re: [openstack-dev] [oslo][trove][dev] oslo_messaging.rpc message signing and verification

2016-11-07 Thread Clint Byrum

Excerpts from Amrith Kumar's message of 2016-11-07 21:00:06 +:
> * trove should have a conversation with the architecture working group to
> see if there are improvements in the architecture that could address some of
> the problems faced,

I think this is a bit premature for the arch-wg, though I think there is
something for us to do here. What may make sense is to propose that we
dive into documenting and possibly improving how agents for service vms
behave in general, as I suspect this is definitely one of those things
where a multitude of projects have come up with slightly different
patterns that all have the same inputs and outputs.

However, for now it's not in our list of proposals. We're still getting
our proposal process up and running, but it would be great to bring this
up at our next meeting for discussion, and then we might want to get a
proposal started moving through the tubes:

https://wiki.openstack.org/wiki/Meetings/Arch-WG

__
OpenStack Development Mailing 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] Embracing new languages in OpenStack

2016-11-07 Thread Joshua Harlow



Concretely - oslo.config is important because it shapes what the config
files look like. The implementation language of a particular service
shouldn't change what our config files look like, yeah?


Standards though exist for a reason (and ini files are pretty common 
across languages and such); though of course oslo.config has some very 
tight integration with openstack, the underlying ini concept it 
eventually reads/writes really isn't that special (so hopefully such a 
thing existing isn't that hard).


As a note gflags in go (which I think is the default option mechanism?) 
is alot like oslo.config (in fact oslo.config came from a python version 
of gflags way back when).


Personally though I'd prefer to just say (if I could) 'ini' file is the 
standard format for options in openstack (and drop the mix of command 
line options and configuration/ini file options).




Similarly keystoneauth - not because getting a token from keystone with
a username and password is necessarily hard- but because we're trying to
drive more service-service interactions through the catalog to reduce
the number of things an operator needs to configure directly - and also
because keystone has auth plugins that need to be supported in the new
language too. (it's a common fault in non-python client implementations
that non-password auth plugins are not covered at all)

oslo.log has similar needs - the logging for an operator needs to be
able to be routed to the same places and be in the same format as the
existing things.


Pretty sure most systems have logging that is similar to java logging 
(which afaik is where the python logging system came from/was inspired 
from); oslo.log has some specific tie-ins to oslo.config (but see above 
statement of using a ini file as the option mechanism).




oslo.messaging and oslo.db have needs where they intersect with operator
config.


I hope we aren't restricting ourselves to much because of the 
specialized libraries we have made that typically have (some level) of 
equivalent in other languages. Though of course those languages and 
libraries do not typically(?) have the tie-together that we have created 
with our libraries (for better or worse).


-Josh

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

[openstack-dev] [neutron] [lbaas] [octavia] Ocata LBaaS retrospective and next steps recap

2016-11-07 Thread Michael Johnson

Ocata LBaaS retrospective and next steps recap
--

This session lightly touched on the work in the newton cycle, but
primarily focused on planning for the Ocata release and the LBaaS spin
out of neutron and merge into the octavia project [1]. Notes were
captured on the etherpad [1].

The focus of work for Ocata in neutron-lbaas and octavia will be on
the spin out/merge and not new features.

Work has started on merging neutron-lbaas into the octavia project
with API sorting/pagination, quota support, keystone integration,
neutron-lbaas driver shim, and documentation updates. Work is still
needed for policy support, the API shim to handle capability gaps
(example: stats are by listener in octavia, but by load balancer in
neturon-lbaas), neutron api proxy, a database migration script from
the neutron database to the octavia database for existing non-octavia
load balancers, and adding the "bug for bug" neutron-lbaas v2 API to
the octavia API server.

The room agreed that since we will have a shim/proxy in neutron for
some time, updating the OpenStack client can be deferred to a future
cycle.

There is a lot of concern about Ocata being a short cycle and the
amount of work to be done. There is hope that additional resources
will help out with this task to allow us to complete the spin
out/merge for Ocata.

We discussed the current state of the active/active topology patches
and agreed that it is unlikely this will merge in Ocata. There are a
lot of open comments and work to do on the patches. It appears that
these patches may have been created against an old release and require
significant updating.

Finally there was a question about when octavia would implement
metadata tags. When we dug into the need for the tags we found that
what was really wanted is a full implementation of the flavors
framework [3] [4]. Some vendors expressed interest in finishing the
flavors framework for Octavia.

Thank you to everyone that participated in our design session and etherpad.

Michael

[1]
https://specs.openstack.org/openstack/neutron-specs/specs/newton/kill-neutron-lbaas.html
[2] https://etherpad.openstack.org/p/ocata-neutron-octavia-lbaas-session
[3]
https://specs.openstack.org/openstack/neutron-specs/specs/mitaka/neutron-flavor-framework-templates.html
[4]
https://specs.openstack.org/openstack/neutron-specs/specs/liberty/neutron-flavor-framework.html

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

Re: [openstack-dev] [Zun][Infra] Random internet disconnection in the gate

2016-11-07 Thread Hongbin Lu

Thanks for the replies from you can Jeremy. We will try to try the local
mirror. Inline replies are for your question.

On Mon, Nov 7, 2016 at 4:30 PM, Clark Boylan  wrote:

> On Mon, Nov 7, 2016, at 01:13 PM, Hongbin Lu wrote:
> > Hi infra team,
> >
> > I am working on the Zun project and we experienced random failure within
> > the gate. The error is as below:
> >
> > 2016-10-16 00:30:49.359 | ++
> > /opt/stack/new/zun/devstack/lib/zun:install_etcd_server:316 :   curl -L
> > https://github.com/coreos/etcd/releases/download/v3.0.7/
> etcd-v3.0.7-linux-amd64.tar.gz
> > -o /opt/stack/new/zun/etcd/etcd-v3.0.7-linux-amd64.tar.gz
> > 
> > curl: (7) Failed to connect to github.com port 443: Connection timed
> > out
> >
> > By searching on logstach by using a query (message:"Failed to connect to
> > github.com port 443: Connection timed out"), it looks all the failure
> > were
> > happening in node "ubuntu-*-osic-cloud1-*". Is that related to anything
> > specific to the osic cloud?
>
> OSIC is one of our ipv6 "only" clouds so connections going out to ipv4
> only hosts (like github.com) have to go through a shared NAT set up. It
> is possible that this is related to the problem.
>
> We have also seen issues where conflicts with routing tables break
> instances' ability to route packets to the router which performs NAT as
> well. Double check that you aren't overriding the routes for 10.0.0.0/8
> there.
>

I don't think we have any logic that override it.

>
> And generally the Internet is an unreliable place. We don't consume our
> git repos from github and instead mirror them ourselves, we also mirror
> ubuntu, debian, and centos packages mirrors, and pypi package mirrors
> and so on for this reason.
>
> My suggestion would be to use the etcd pacakge out of the Xenial mirror
> which should be far more reliable on any of our test hosts (mirrors are
> cloud region local caches of distributed filesystems).
>
> As a final note it is always tremendously helpful to provide at least
> one example link to the job logs that experience problems when reporting
> issues to the infra team. There is a lot of data collected which is
> useful for debugging.
>

Here is a sample link:
http://logs.openstack.org/46/380646/24/check/gate-zun-devstack-dsvm/d7c7bab/logs/devstacklog.txt.gz#_2016-10-16_00_30_49_359


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

2016-11-07 Thread Fernando J Diaz

+1 Congrats Arun, welcome to Barbican Core. 


__
OpenStack Development Mailing 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] Finish test job transition to Ubuntu Xenial

2016-11-07 Thread Clark Boylan

On Mon, Nov 7, 2016, at 01:48 PM, Clark Boylan wrote:
> How can you do this? First double check your job logs to see where your
> tests are running. The first few lines of your job console logs should
> say "[Zuul] Building remotely on ubuntu-xenial" if running on Xenial.
> Any changes to master should not run on Trusty and instead should run on
> Xenial.

Point of clarification here, stable/newton and master jobs should both
be transitioned to Xenial.

Clark


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

Re: [openstack-dev] [barbican] Nominating Arun Kant for barbican-core

2016-11-07 Thread John Wood

+1

From: Juan Antonio Osorio 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Monday, November 7, 2016 at 9:42 AM
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: Re: [openstack-dev] [barbican] Nominating Arun Kant for barbican-core


+1

On 7 Nov 2016 17:18, "Dave McCowan (dmccowan)" 
> wrote:

Arun has been a long-time terrific reviewer and contributor to Barbican.

100% +1


--Dave

On 11/7/16, 9:37 AM, "Ade Lee" > wrote:

>Hi everyone,
>
>I'd like to nominate Arun Kant for the barbican-core team.
>
>Arun has been a very active contributor to the project over the past
>few years, implementing and seeing through major features like ACLs and
>multiple secret store back-ends.  This includes providing all the
>required API documentation.
>
>He's also been active squashing bugs, and providing helpful and
>insightful reviews.
>
>As a reminder to barbican-core members, we use the voting process
>outlined in https://wiki.openstack.org/wiki/Barbican/CoreTeam to add
>members to our team.
>
>Thanks,
>Ade
>
>
>__
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: 
>openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

[openstack-dev] [All] Finish test job transition to Ubuntu Xenial

2016-11-07 Thread Clark Boylan

Hello everyone,

The infra team would really like to get the Ubuntu Xenial for testing
transition completed early this cycle. We are planning to switch any
jobs that remain on Ubuntu Trusty but should be on Ubuntu Xenial on
December 6, 2016. That gives us about a month from today to more
gracefully migrate jobs while still getting it done early enough in the
cycle to fix any issues and put it behind us. Would be great for project
teams to test if their jobs run on Xenial and propose updates to
openstack-infra/project-config as necessary to switch to Ubuntu Xenial.

How can you do this? First double check your job logs to see where your
tests are running. The first few lines of your job console logs should
say "[Zuul] Building remotely on ubuntu-xenial" if running on Xenial.
Any changes to master should not run on Trusty and instead should run on
Xenial.

If you have jobs still running on trusty the next step is to fire up a
Xenial instance locally and run that test to see if it works. Usually
this will mean running the appropriate tox target or if using
devstack-gate you can grab the reproduce.sh script for that job and run
that script locally.

If everything works, then push a change to
openstack-infra/project-config. We have been using a job name suffix of
-ubuntu-xenial to indicate jobs should run on xenial. An example change
that does this can be found at [0].

If you run into failures hopefully you can iterate on them locally using
your Xenial test setup, get them fixed, then update the job location.

This work is important because it helps ensure that OpenStack functions
on more "modern" linuxes. We get shiny new things like newer versions of
libvirt and ovs. We also get to stop worrying about upstart.

As always I and the rest of the infra team are happy to help should you
have questions or concerns or just need eyeballs to help debug problems.

[0] https://review.openstack.org/#/c/348078

Thank you
Clark

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

Re: [openstack-dev] [Zun][Infra] Random internet disconnection in the gate

2016-11-07 Thread Clark Boylan

On Mon, Nov 7, 2016, at 01:13 PM, Hongbin Lu wrote:
> Hi infra team,
> 
> I am working on the Zun project and we experienced random failure within
> the gate. The error is as below:
> 
> 2016-10-16 00:30:49.359 | ++
> /opt/stack/new/zun/devstack/lib/zun:install_etcd_server:316 :   curl -L
> https://github.com/coreos/etcd/releases/download/v3.0.7/etcd-v3.0.7-linux-amd64.tar.gz
> -o /opt/stack/new/zun/etcd/etcd-v3.0.7-linux-amd64.tar.gz
> 
> curl: (7) Failed to connect to github.com port 443: Connection timed
> out
> 
> By searching on logstach by using a query (message:"Failed to connect to
> github.com port 443: Connection timed out"), it looks all the failure
> were
> happening in node "ubuntu-*-osic-cloud1-*". Is that related to anything
> specific to the osic cloud?

OSIC is one of our ipv6 "only" clouds so connections going out to ipv4
only hosts (like github.com) have to go through a shared NAT set up. It
is possible that this is related to the problem.

We have also seen issues where conflicts with routing tables break
instances' ability to route packets to the router which performs NAT as
well. Double check that you aren't overriding the routes for 10.0.0.0/8
there.

And generally the Internet is an unreliable place. We don't consume our
git repos from github and instead mirror them ourselves, we also mirror
ubuntu, debian, and centos packages mirrors, and pypi package mirrors
and so on for this reason.

My suggestion would be to use the etcd pacakge out of the Xenial mirror
which should be far more reliable on any of our test hosts (mirrors are
cloud region local caches of distributed filesystems).

As a final note it is always tremendously helpful to provide at least
one example link to the job logs that experience problems when reporting
issues to the infra team. There is a lot of data collected which is
useful for debugging.

Clark

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

Re: [openstack-dev] [Zun][Infra] Random internet disconnection in the gate

2016-11-07 Thread Jeremy Stanley

On 2016-11-07 16:13:04 -0500 (-0500), Hongbin Lu wrote:
> I am working on the Zun project and we experienced random failure within
> the gate. The error is as below:
> 
> 2016-10-16 00:30:49.359 | ++
> /opt/stack/new/zun/devstack/lib/zun:install_etcd_server:316 :   curl -L
> https://github.com/coreos/etcd/releases/download/v3.0.7/etcd-v3.0.7-linux-amd64.tar.gz
> -o /opt/stack/new/zun/etcd/etcd-v3.0.7-linux-amd64.tar.gz
> 
> curl: (7) Failed to connect to github.com port 443: Connection timed out

Yes, connectivity to github.com can be iffy even on the best of
days, so relying on it within CI jobs is always a bit problematic.

> By searching on logstach by using a query (message:"Failed to connect to
> github.com port 443: Connection timed out"), it looks all the failure were
> happening in node "ubuntu-*-osic-cloud1-*". Is that related to anything
> specific to the osic cloud?

Since osic-cloud1 provides the majority of our job capacity these
days, it's just as likely the sample size is too small to show the
error impacting other providers as well. It's also possible the IPv4
NAT for OSIC is overloaded, given that those job nodes only have
global addresses for IPv6 and I don't see any  records for
github.com.

Regardless, there is a plan to implement provider-local mirroring of
arbitrary file dependencies which would allow jobs to consume those
without connecting over the wider Internet. In this case, etcd
tarballs might be something well suited to this, or you could
consider trying to use Ubuntu's etcd package (I'm unsure what you
have DevStack doing with etcd so it's hard to know if this is a
viable alternative for you).
-- 
Jeremy Stanley

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

[openstack-dev] [neutron] Ocata End user and operator feedback recap

2016-11-07 Thread Carl Baldwin

Ocata End user and operator feedback recap


The purpose of this session was to gather feedback from end users and
operators to help direct the efforts of developers during (at least) the
Ocata cycle. Feedback was captured on the etherpad [1]. There was a related
session in the operators' track [2] which may also be of interest.

We began with a short discussion about client compatibility which was
deferred to the following session specifically about the client [3].

There was a discussion about if Neutron will implement cells like Nova has.
There is currently no plan. I have heard this come up for the past couple
of summits but there is little concrete evidence of the scale issues being
encountered by operators. If you are running Neutron at scale, we could use
more of your input.

There was some discussion about an issue around moving a floating ip from
one instance to another when keepalive is in use. We needed more
information to debug this. It should be sending a gratuitous arp. Another
keepalive issue was discussed. Too many SIGHUPs within a period of time can
cause failover resulting in disruption. I do not know if a bug was filed
for this to follow up. If this was you, please follow up with a link to the
bug report.

There was a short discussion about Horizon support for security groups on a
port. A bug was filed for this.

Finally, there was some discussion about enabling end users to create
Neutron L3 routers which are backed by hardware resources. There is no such
thing yet but Neutron does have a new concept in development called "L3
flavors". This would enable a driver (to be written) which would allow this
sort of thing.

Carl Baldwin

[1]
https://etherpad.openstack.org/p/ocata-neutron-end-user-operator-feedback
[2] https://etherpad.openstack.org/p/newton-neutron-pain-points
[3] https://etherpad.openstack.org/p/ocata-neutron-client
__
OpenStack Development Mailing 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] [Zun][Infra] Random internet disconnection in the gate

2016-11-07 Thread Hongbin Lu

Hi infra team,

I am working on the Zun project and we experienced random failure within
the gate. The error is as below:

2016-10-16 00:30:49.359 | ++
/opt/stack/new/zun/devstack/lib/zun:install_etcd_server:316 :   curl -L
https://github.com/coreos/etcd/releases/download/v3.0.7/etcd-v3.0.7-linux-amd64.tar.gz
-o /opt/stack/new/zun/etcd/etcd-v3.0.7-linux-amd64.tar.gz

curl: (7) Failed to connect to github.com port 443: Connection timed out

By searching on logstach by using a query (message:"Failed to connect to
github.com port 443: Connection timed out"), it looks all the failure were
happening in node "ubuntu-*-osic-cloud1-*". Is that related to anything
specific to the osic cloud?

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-dev] [nova] Problem with Quota and servers spawned in groups

2016-11-07 Thread Sławek Kapłoński

Hello,

Some time ago I found that there is problem with unconsistent behaviour
(IMHO) of Nova API when user wants to spawn bunch of instances in server
group (affinity or anti-affinity). I described it in [1].
I also made some summary how Nova is working in different cases of
spawning instances. Results are like below:

+-+---+---++-+
| QUOTAS  |   |   | 
   | |
+--+--+ min_count | max_count |  number of spawned 
instances   | Expected result |
|instances | server_group_members |   |   | 
   | |
+==+==+===+===++=+
|10|  5   | 3 | 4 | 4   
   |4|
+--+--+---+---++-+
|10|  5   | 6 | 9 |Quota exceeded, too 
many servers|Group Quota  |
|  |  |   |   |in group (HTTP 403)  
   |exceeded |
+--+--+---+---++-+
|10|  5   | 3 | 6 |Quota exceeded, too 
many servers|5|
|  |  |   |   |in group (HTTP 403)  
   | |
+--+--+---+---++-+
|10|  5   | 3 |11 |Quota exceeded, too 
many servers|5|
|  |  |   |   |in group (HTTP 403)  
   | |
+--+--+---+---++-+
|10|  5   | 6 |11 |Quota exceeded, too 
many servers|Group Quota  |
|  |  |   |   |in group (HTTP 403)  
   |exceeded |
+--+--+---+---++-+
|10|  5   | 3 | - | 3   
   |3|
+--+--+---+---++-+
|10|  5   | 6 | - |Quota exceeded, too 
many servers|Group Quota  |
|  |  |   |   |in group (HTTP 403)  
   |exceeded |
+--+--+---+---++-+
|10|  5   | 11| - |Quota exceeded for 
instances:   |Servers Quota|
|  |  |   |   |Requested 11, but 
already used 0|exceeded |
|  |  |   |   | of 10 instances 
   | |
+--+--+---+---++-+
|10|  5   | - | 3 | 3   
   |3|
+--+--+---+---++-+
|10|  5   | - | 6 |Quota exceeded, too 
many servers|Group Quota  |
|  |  |   |   |in group (HTTP 403)  
   |exceeded |
+--+--+---+---++-+
|10|  5   | - | 11|Quota exceeded, too 
many servers|Group Quota  |
|  |  |   |   |in group (HTTP 403)  
   |exceeded |
+--+--+---+---++-+

In "expected result" I described behaviour which I suppose that is should be
there.
Can You maybe check it and tell me if I'm right here and there is really bug as
described in [1]?

I also made some patch to fix it [2] so please review it if You think that it
is worth to fix this behaviour.

[1] https://bugs.launchpad.net/nova/+bug/1623809
[2] https://review.openstack.org/#/c/371592/

-- 
Best regards / Pozdrawiam
Sławek Kapłoński
sla...@kaplonski.pl



signature.asc
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:

[openstack-dev] [oslo][trove][dev] oslo_messaging.rpc message signing and verification

2016-11-07 Thread Amrith Kumar

At the oslo-meeeting[1] on 11/7 we discussed a proposal[2] to enable message
signing and verification for oslo_messaging.rpc. The use-case for this is to
ensure that when RPC's are used with service VM's there is a possible attack
vector that involves a compromised service VM. While there are several other
mitigations that make this harder, adding message signing was felt to be an
added layer of protection.

The essence of the proposal is that asymmetric keys would be used to sign
and verify messages. A control plane keypair, and a keypair per service VM
would be used. Consumers of oslo_messaging.rpc would register callbacks in
the client and server, and a signing callback would be invoked for each
message that was to be sent and a verification callback would be invoked for
each message received. The manner of signing and verification would be left
up to the consumer. In the reference implementation, Trove would use
asymmetric keypairs for signing and verification to ensure that the message
was in fact from a legitimate source, and the source could be used to
further determine whether the message was appropriate or not.

At the meeting, the primary questions that I sought to address were:

 do we believe that it is still interesting to oslo to support message
signing and verification for oslo_messaging/rpc
 are we ok with an approach where oslo_messaging/rpc provides a framework
for consumers to define the signer and verifier, and not directly perform
the signing and verification

The discussion at the meeting (transcript at [1]) surfaced the following:

 the use of oslo_messaging/rpc by service vm's is not a pattern that is
favored; service vm's should instead make calls to a REST API or some kind
of service hook to inform the controlling service to then poll the service
VM, 
 there is no necessity to do the message signing and verification in
oslo.messaging, it can be done using a decorator in the consumer,
 while signing and verification can be done in the consumer, it is much
cleaner and makes handling upgrades much easier if it was done in
oslo.messaging as oslo_messaging.rpc could treat the signature as special
message metadata which the consumer cannot do; all the consumer can do is
insert and manipulate formal parameters to an RPC call,
 trove should have a conversation with the architecture working group to
see if there are improvements in the architecture that could address some of
the problems faced,
 if signing were implemented in oslo.messaging, the entire message
(including version, and other fields like namespace) can be signed; if it
were implemented in the consumer, not all fields can be signed. Furthermore,
if signing and verification were driven from oslo.messaging, the impact on
consumers would be dramatically lower, and handling of upgrades would also
be much easier.

It was my take-away from the meeting that the proposed use-case did not seem
like a sufficient reason to introduce message signing and verification into
oslo_messaging.rpc, at this stage. I'll take the recommendations of the
meeting and instead implement this using the decorators and hooks proposed
and the implementation will not be part of oslo.

Thanks,

-amrith

[1]
http://eavesdrop.openstack.org/meetings/oslo/2016/oslo.2016-11-07-16.00.log.
html
[2] https://etherpad.openstack.org/p/secure-oslo-messaging



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] [release] New hacking 0.12.0

2016-11-07 Thread Ken'ichi Ohmichi

Hi,

Today a new hacking 0.12.0 is released.
The release contains a new hacking rule:

[H904] Delay string interpolations at logging calls.

BTW, the hacking repo starts containing reno since this release but it
is not used yet.
Please check the git history (or
https://review.openstack.org/#/c/343824) if wanting to know the
detail.

Thanks
Ken Ohmichi

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

[openstack-dev] [new][quality] hacking 0.12.0 release

2016-11-07 Thread no-reply

We are joyful to announce the release of:

hacking 0.12.0: OpenStack Hacking Guideline Enforcement

Download the package from:

https://pypi.python.org/pypi/hacking

For more details, please see below.




__
OpenStack Development Mailing 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] Live migrations: Post-Copy and Auto-Converge features research

2016-11-07 Thread Vlad Nykytiuk

Hi,

As you may know, currently QEMU supports several features that help live 
migrations to operate more predictively. These features are: auto-converge and 
post-copy. 
I made a research on performance characteristics of these two features, you can 
find it by the following link:
https://rk4n.github.io/2016/08/10/qemu-post-copy-and-auto-converge-features/ 


Hope you find it helpful.

Thanks
—
Vlad

__
OpenStack Development Mailing 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] Embracing new languages in OpenStack

2016-11-07 Thread Dean Troyer

On Mon, Nov 7, 2016 at 1:32 PM, Flavio Percoco  wrote:
> I agree with Monty here. If I were to "prioritize" the work on these
> libraries,
> I'd say parity on the operator's side of things should be the priority. The
> rest
> of the libraries could be implemented as they are needed.
>
> I don't think they all need to be implemented but I do think some of them
> should, especially because I believe the process of adding a new language
> should
> also involve building the ecosystem within the openstack community for that
> language to exist and be consumed.
>
> Wether this should be a hard requirement or not is something that we can
> talk
> more about. What I would like to avoid is a scenario were the service/team
> requesting the addition of the language doesn't use any of the common tools
> that
> exist today and we end up adding a new language and dropping all the work on
> compatibility to teams coming after. I believe this is exactly the scenario
> that
> we're in right now.

I agree with the overall concern, however I'm looking at it
(specifically the Swift Hummingbird proposal from May) as a step to
get there without biting off the entire chunk at once.  The infra
work, the community work, the packaging all is enough to handle at
once, this particular situation doesn't require oslo(-like) libraries
to gain benefit of work we need to do anyway.

dt

-- 

Dean Troyer
dtro...@gmail.com

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

Re: [openstack-dev] [all] Embracing new languages in OpenStack

2016-11-07 Thread Doug Hellmann

Excerpts from Flavio Percoco's message of 2016-11-07 11:32:06 -0800:
> On 07/11/16 12:16 -0600, Monty Taylor wrote:
> >On 11/07/2016 11:58 AM, Hayes, Graham wrote:
> >> On 07/11/2016 17:14, Flavio Percoco wrote:
> >>> Greetings,
> >>>
> >>> I literally just posted a thing on my blog with some thoughts of what I'd 
> >>> expect
> >>> any new language being proposed for OpenStack to cover before it can be
> >>> accepted.
> >>>
> >>> The goal is to set the expectations right for what's needed for new 
> >>> languages to
> >>> be accepted in the community. During the last evaluation of the Go 
> >>> proposal I
> >>> raised some concerns but I also said I was not closed to discussing this 
> >>> again
> >>> in the future. It's clear we've not documented expectations yet and this 
> >>> is a
> >>> first step to get that going before a new proposal comes up and we start
> >>> discussing this topic again.
> >>>
> >>> I don't think a blog post is the "way we should do this" but it was my 
> >>> way to
> >>> dump what's in my brain before working on something official (which I'll 
> >>> do
> >>> this/next week).
> >>>
> >>> I also don't think this list is perfect. It could either be too 
> >>> restrictive or
> >>> too open but it's a first step. I won't paste the content of my post in 
> >>> this
> >>> email but I'll provide a tl;dr and eventually come back with the actual
> >>> reference document patch. I thought I'd drop this here in case people 
> >>> read my
> >>> post and were confused about what's going on there.
> >>>
> >>> Ok, here's the TL;DR of what I believe we should know/do before accepting 
> >>> a new
> >>> language into the community:
> >>
> >> Its a great starting point, but there is one issue:
> >>
> >> This is a *huge* amount of work to get into place, for the TC to still
> >> potentially refuse the language. (I know you covered this in your blog
> >> post, but I think there is a level of underestimation there.)
> >
> >Yes, it is absolutely a huge amount of work for sure, and I think your
> >point is important.
> >
> >>
> >>> - Define a way to share code/libraries for projects using the language
> >>
> >> ++ - Definitely needed
> >>
> >>> - Work on a basic set of libraries for OpenStack base services
> >>
> >> What do we include here? You called out these:
> >>
> >> keystoneauth / keystone-client
> >> oslo.config
> >> oslo.db
> >> oslo.messaging
> >>
> >> We need to also include
> >>
> >> oslo.log
> >>
> >> Do they *all* need to be implemented? Just some? Do they need feature
> >> parity?
> >
> >To me the most important piece is feature parity on the operator
> >interaction side.
> >
> >Concretely - oslo.config is important because it shapes what the config
> >files look like. The implementation language of a particular service
> >shouldn't change what our config files look like, yeah?
> >
> >Similarly keystoneauth - not because getting a token from keystone with
> >a username and password is necessarily hard- but because we're trying to
> >drive more service-service interactions through the catalog to reduce
> >the number of things an operator needs to configure directly - and also
> >because keystone has auth plugins that need to be supported in the new
> >language too. (it's a common fault in non-python client implementations
> >that non-password auth plugins are not covered at all)
> >
> >oslo.log has similar needs - the logging for an operator needs to be
> >able to be routed to the same places and be in the same format as the
> >existing things.
> >
> >oslo.messaging and oslo.db have needs where they intersect with operator
> >config.
> 
> 
> I agree with Monty here. If I were to "prioritize" the work on these 
> libraries,
> I'd say parity on the operator's side of things should be the priority. The 
> rest
> of the libraries could be implemented as they are needed.
> 
> I don't think they all need to be implemented but I do think some of them
> should, especially because I believe the process of adding a new language 
> should
> also involve building the ecosystem within the openstack community for that
> language to exist and be consumed.
> 
> Wether this should be a hard requirement or not is something that we can talk
> more about. What I would like to avoid is a scenario were the service/team
> requesting the addition of the language doesn't use any of the common tools 
> that
> exist today and we end up adding a new language and dropping all the work on
> compatibility to teams coming after. I believe this is exactly the scenario 
> that
> we're in right now.

Right. It's much more important to me that a system be put in place
to produce and manage the libraries than that they are created in
any particular order. Oslo came after Swift and Nova, but we've
learned that building shared libraries is an important part of our
community's answer to the call for consistency that needs to extend
to new languages from the beginning of their adoption.

> >> For example the previous discussion

[openstack-dev] [ironic] weekly subteam report

2016-11-07 Thread Loo, Ruby

Hi,

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

Bugs (dtantsur)
===
- Stats (diff between 31 Oct 2016 and 07 Nov 2016)
- Ironic: 233 bugs + 218 wishlist items (+7). 33 new, 180 in progress (+5), 1 
critical, 28 high (-1) and 23 incomplete (+4)
- Inspector: 13 bugs + 21 wishlist items. 3 new (-1), 9 in progress, 0 
critical, 1 high and 3 incomplete
- Nova bugs with Ironic tag: 11. 1 new, 0 critical, 1 high

Network isolation (Neutron/Ironic work) (jroll, TheJulia, devananda)

* trello: 
https://trello.com/c/HWVHhxOj/1-multi-tenant-networking-network-isolation
- status: portgroups patches need reviews: 
https://review.openstack.org/#/q/topic:bug/1618754
- portgroup spec (in nova) needs approval before nova spec freeze deadline Nov 
17: https://review.openstack.org/#/c/387534/
- Attach/Detach spec needs approval https://review.openstack.org/#/c/317636/ to 
be accepted by Nova folks (nova BP is ready to be approved, waiting on ironic 
spec being approved; see 14:39 at 
http://eavesdrop.openstack.org/meetings/nova/2016/nova.2016-11-03-14.00.log.html)

Gate improvements (jlvillal, lucasagomes, dtantsur)
===
- lucas is working on switching the CI to pxe_ipmitool completely
- multi-node CI job: devstack-gate patches landed last week. Still a few 
non-Ironic patches to get landed.
- Proposed improvements to the devstack plugin BM network simulation (should 
make multitenancy testing and grenade testing less crappy): 
https://review.openstack.org/#/c/392959/ (sambetts)

Generic boot-from-volume (TheJulia, dtantsur, lucasagomes)
==
* trello: https://trello.com/c/UttNjDB7/13-generic-boot-from-volume
- status: Specification has landed.
- reviews needed for volume connection work: 
https://review.openstack.org/#/q/status:open+project:openstack/ironic+branch:master+topic:bug/1526231

Driver composition (dtantsur)
=
* trello: https://trello.com/c/fTya14y6/14-driver-composition
- status: driver composition spec was amended to cover the defaults
- the first patches are posted, still a lot of ahead: 
https://review.openstack.org/#/q/status:open+topic:bug/1524745

Notifications (mariojv)
===
* trello: https://trello.com/c/MD8HNcwJ/17-notifications
- Provision state change notifications need reviews: 
https://review.openstack.org/#/c/348437/

Rolling upgrades and grenade-partial (xek)
==
* trello: https://trello.com/c/GAlhSzLm/2-rolling-upgrades-and-grenade-partial
- spec needs to be updated

Enhanced root device hints (lucasagomes)

* trello: https://trello.com/c/f9DTEvDB/21-enhanced-root-device-hints
- Pretty much completed, only docs missing: 
https://review.openstack.org/#/c/386714/

Drivers:

DRAC (mgould/lucas/dtantsur)

- dtantsur is fixing a few bugs in python-dracclient, then firing a release
- per summit discussion, python-dracclient may leave ironic governance

.

Until next week,
--ruby

[0] https://etherpad.openstack.org/p/IronicWhiteBoard

__
OpenStack Development Mailing 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] Embracing new languages in OpenStack

2016-11-07 Thread Flavio Percoco


On 07/11/16 12:16 -0600, Monty Taylor wrote:

On 11/07/2016 11:58 AM, Hayes, Graham wrote:

On 07/11/2016 17:14, Flavio Percoco wrote:

Greetings,

I literally just posted a thing on my blog with some thoughts of what I'd expect
any new language being proposed for OpenStack to cover before it can be
accepted.

The goal is to set the expectations right for what's needed for new languages to
be accepted in the community. During the last evaluation of the Go proposal I
raised some concerns but I also said I was not closed to discussing this again
in the future. It's clear we've not documented expectations yet and this is a
first step to get that going before a new proposal comes up and we start
discussing this topic again.

I don't think a blog post is the "way we should do this" but it was my way to
dump what's in my brain before working on something official (which I'll do
this/next week).

I also don't think this list is perfect. It could either be too restrictive or
too open but it's a first step. I won't paste the content of my post in this
email but I'll provide a tl;dr and eventually come back with the actual
reference document patch. I thought I'd drop this here in case people read my
post and were confused about what's going on there.

Ok, here's the TL;DR of what I believe we should know/do before accepting a new
language into the community:


Its a great starting point, but there is one issue:

This is a *huge* amount of work to get into place, for the TC to still
potentially refuse the language. (I know you covered this in your blog
post, but I think there is a level of underestimation there.)


Yes, it is absolutely a huge amount of work for sure, and I think your
point is important.




- Define a way to share code/libraries for projects using the language


++ - Definitely needed


- Work on a basic set of libraries for OpenStack base services


What do we include here? You called out these:

keystoneauth / keystone-client
oslo.config
oslo.db
oslo.messaging

We need to also include

oslo.log

Do they *all* need to be implemented? Just some? Do they need feature
parity?


To me the most important piece is feature parity on the operator
interaction side.

Concretely - oslo.config is important because it shapes what the config
files look like. The implementation language of a particular service
shouldn't change what our config files look like, yeah?

Similarly keystoneauth - not because getting a token from keystone with
a username and password is necessarily hard- but because we're trying to
drive more service-service interactions through the catalog to reduce
the number of things an operator needs to configure directly - and also
because keystone has auth plugins that need to be supported in the new
language too. (it's a common fault in non-python client implementations
that non-password auth plugins are not covered at all)

oslo.log has similar needs - the logging for an operator needs to be
able to be routed to the same places and be in the same format as the
existing things.

oslo.messaging and oslo.db have needs where they intersect with operator
config.



I agree with Monty here. If I were to "prioritize" the work on these libraries,
I'd say parity on the operator's side of things should be the priority. The rest
of the libraries could be implemented as they are needed.

I don't think they all need to be implemented but I do think some of them
should, especially because I believe the process of adding a new language should
also involve building the ecosystem within the openstack community for that
language to exist and be consumed.

Wether this should be a hard requirement or not is something that we can talk
more about. What I would like to avoid is a scenario were the service/team
requesting the addition of the language doesn't use any of the common tools that
exist today and we end up adding a new language and dropping all the work on
compatibility to teams coming after. I believe this is exactly the scenario that
we're in right now.


For example the previous discussion about Go had 2 components that would
have required at most 2 of these base libraries (and I think that was
mainly on the Designate side - the swift implementation did not need
any (I think - I am open to correction)


- Define how the deliverables are distributed


++ - but this needs to be done with the release management teams input.
What I think is reasonable may not be something that they are interested
in supporting.


Absolutely. I mentioned in the post that working with the release team is key
for this.


- Define how stable maintenance will work


++


- Setup the CI pipelines for the new language


This requires the -infra team dedicate (what are already stretched)
resources to a theoretical situation, doing work that may be thrown
away if the TC rejects a language.



Ditto... Regardless of how swamped the infra team is, I believe this requires
working with them. Actually, I don't see the infra team being

Re: [openstack-dev] [Magnum] New Core Reviewers

2016-11-07 Thread Hongbin Lu

+1!

Both jvgrant and yatin contributed a lot to the Magnum project. It would be 
great to have both of you in the core team.

Best regards,
Hongbin

> -Original Message-
> From: Adrian Otto [mailto:adrian.o...@rackspace.com]
> Sent: November-07-16 2:06 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: [openstack-dev] [Magnum] New Core Reviewers
> 
> Magnum Core Team,
> 
> I propose Jaycen Grant (jvgrant) and Yatin Karel (yatin) as new Magnum
> Core Reviewers. Please respond with your votes.
> 
> Thanks,
> 
> Adrian Otto
> ___
> ___
> OpenStack Development Mailing 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] Embracing new languages in OpenStack

2016-11-07 Thread Monty Taylor

On 11/07/2016 12:51 PM, John Dickinson wrote:
> 
> 
> On 7 Nov 2016, at 10:31, Ash wrote:
> 
>> On Mon, Nov 7, 2016 at 9:58 AM, Hayes, Graham  wrote:
>>
>>> On 07/11/2016 17:14, Flavio Percoco wrote:
 Greetings,

 I literally just posted a thing on my blog with some thoughts of what
>>> I'd expect
 any new language being proposed for OpenStack to cover before it can be
 accepted.

 The goal is to set the expectations right for what's needed for new
>>> languages to
 be accepted in the community. During the last evaluation of the Go
>>> proposal I
 raised some concerns but I also said I was not closed to discussing this
>>> again
 in the future. It's clear we've not documented expectations yet and this
>>> is a
 first step to get that going before a new proposal comes up and we start
 discussing this topic again.

 I don't think a blog post is the "way we should do this" but it was my
>>> way to
 dump what's in my brain before working on something official (which I'll
>>> do
 this/next week).

 I also don't think this list is perfect. It could either be too
>>> restrictive or
 too open but it's a first step. I won't paste the content of my post in
>>> this
 email but I'll provide a tl;dr and eventually come back with the actual
 reference document patch. I thought I'd drop this here in case people
>>> read my
 post and were confused about what's going on there.

 Ok, here's the TL;DR of what I believe we should know/do before
>>> accepting a new
 language into the community:
>>>
>>> Its a great starting point, but there is one issue:
>>>
>>> This is a *huge* amount of work to get into place, for the TC to still
>>> potentially refuse the language. (I know you covered this in your blog
>>> post, but I think there is a level of underestimation there.)
>>>
>>>
 - Define a way to share code/libraries for projects using the language
>>>
>>> ++ - Definitely needed
>>>
 - Work on a basic set of libraries for OpenStack base services
>>>
>>> What do we include here? You called out these:
>>>
>>> keystoneauth / keystone-client
>>> oslo.config
>>> oslo.db
>>> oslo.messaging
>>>
>>> We need to also include
>>>
>>> oslo.log
>>>
>>> Do they *all* need to be implemented? Just some? Do they need feature
>>> parity?
>>>
>>> For example the previous discussion about Go had 2 components that would
>>> have required at most 2 of these base libraries (and I think that was
>>> mainly on the Designate side - the swift implementation did not need
>>> any (I think - I am open to correction)
>>>
 - Define how the deliverables are distributed
>>>
>>> ++ - but this needs to be done with the release management teams input.
>>> What I think is reasonable may not be something that they are interested
>>> in supporting.
>>>
 - Define how stable maintenance will work
>>>
>>> ++
>>>
 - Setup the CI pipelines for the new language
>>>
>>> This requires the -infra team dedicate (what are already stretched)
>>> resources to a theoretical situation, doing work that may be thrown
>>> away if the TC rejects a language.
>>>
>> Here's another take on the situation. If there are people who genuinely
>> wish to see a CI pipeline that can support something like Go, perhaps you
>> can establish a prerequisite of working with the Infra team on establishing
>> the new pipeline. In my opinion, this seems to be the major gate. So, if
>> there's a clear path identified, resources provided, and the Infra team is
>> ultimately benefitted, then I'm not sure why there should be another
>> rejection. Just a thought. I know this proposal continues to come up and
>> I'm a big fan of seeing other languages supported, especially Go. But I
>> also understand that it can break things. Personally, I would even
>> volunteer to work on such an Infra effort.
>>
>> BTW, it is quite possible that another group might feel the same
>> constraints. It's perfectly reasonable. But if we can overcome such
>> obstacles, would the TC still have a concern?
> 
> 
> Here's the notes we had from last May when we started the Golang discussion 
> where we started working through these questions.
> 
> https://etherpad.openstack.org/p/golang-infra-issues-to-solve

I've just added a few more notes to it - turns out time has elapsed
since last May. :)

>>>
>>> I foresee these requirements as a whole being overly onerous, and
>>> having the same result as saying "no new languages".
>>>
>>> I think that there should be base research into all of these, but the
>>> requirements for some of these to be fully completed could be basically
>>> impossible.
>>>

 The longer and more detailed version is here:

 https://blog.flaper87.com/embracing-other-languages-openstack.html

 Stay tuned,
 Flavio

>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for

Re: [openstack-dev] [all] Embracing new languages in OpenStack

2016-11-07 Thread Jeremy Stanley

On 2016-11-07 10:31:22 -0800 (-0800), Ash wrote:
[...]
> Here's another take on the situation. If there are people who genuinely
> wish to see a CI pipeline that can support something like Go, perhaps you
> can establish a prerequisite of working with the Infra team on establishing
> the new pipeline. In my opinion, this seems to be the major gate. So, if
> there's a clear path identified, resources provided, and the Infra team is
> ultimately benefitted, then I'm not sure why there should be another
> rejection. Just a thought. I know this proposal continues to come up and
> I'm a big fan of seeing other languages supported, especially Go. But I
> also understand that it can break things. Personally, I would even
> volunteer to work on such an Infra effort.
[...]

Welcome aboard! Monty's already laid some of the groundwork, but
really most of the effort is just getting familiar with what we
already have and how to avoid duplicating work. As has been pointed
out we're spread pretty thin, but not so thin that we can't answer
questions posed by someone who is driven and relatively
self-sufficient reading documentation and looking at production
examples. Most of the solutions implemented in our infrastructure
come from interested members of the community at large, and we're
proud of our ability to enable that sort of inclusive participation.

I won't pretend it isn't complex and don't expect members of the
Infra team to have sufficient bandwidth for hand-holding and
spoon-feeding, but we do our best to help guide contributors toward
implementing solutions that benefit the community at large. Even if
Go isn't a TC-sanctioned language for official OpenStack
deliverables, having the ability to support it (or Haskel, or Ada,
or...) in our community infrastructure eases experimentation and
promotes language-specific innovation for unofficial repositories
within our ecosystem.
-- 
Jeremy Stanley


signature.asc
Description: 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] [Magnum] New Core Reviewers

2016-11-07 Thread Adrian Otto

Magnum Core Team,

I propose Jaycen Grant (jvgrant) and Yatin Karel (yatin) as new Magnum Core 
Reviewers. Please respond with your votes.

Thanks,

Adrian Otto
__
OpenStack Development Mailing 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] Embracing new languages in OpenStack

2016-11-07 Thread John Dickinson



On 7 Nov 2016, at 10:31, Ash wrote:

> On Mon, Nov 7, 2016 at 9:58 AM, Hayes, Graham  wrote:
>
>> On 07/11/2016 17:14, Flavio Percoco wrote:
>>> Greetings,
>>>
>>> I literally just posted a thing on my blog with some thoughts of what
>> I'd expect
>>> any new language being proposed for OpenStack to cover before it can be
>>> accepted.
>>>
>>> The goal is to set the expectations right for what's needed for new
>> languages to
>>> be accepted in the community. During the last evaluation of the Go
>> proposal I
>>> raised some concerns but I also said I was not closed to discussing this
>> again
>>> in the future. It's clear we've not documented expectations yet and this
>> is a
>>> first step to get that going before a new proposal comes up and we start
>>> discussing this topic again.
>>>
>>> I don't think a blog post is the "way we should do this" but it was my
>> way to
>>> dump what's in my brain before working on something official (which I'll
>> do
>>> this/next week).
>>>
>>> I also don't think this list is perfect. It could either be too
>> restrictive or
>>> too open but it's a first step. I won't paste the content of my post in
>> this
>>> email but I'll provide a tl;dr and eventually come back with the actual
>>> reference document patch. I thought I'd drop this here in case people
>> read my
>>> post and were confused about what's going on there.
>>>
>>> Ok, here's the TL;DR of what I believe we should know/do before
>> accepting a new
>>> language into the community:
>>
>> Its a great starting point, but there is one issue:
>>
>> This is a *huge* amount of work to get into place, for the TC to still
>> potentially refuse the language. (I know you covered this in your blog
>> post, but I think there is a level of underestimation there.)
>>
>>
>>> - Define a way to share code/libraries for projects using the language
>>
>> ++ - Definitely needed
>>
>>> - Work on a basic set of libraries for OpenStack base services
>>
>> What do we include here? You called out these:
>>
>> keystoneauth / keystone-client
>> oslo.config
>> oslo.db
>> oslo.messaging
>>
>> We need to also include
>>
>> oslo.log
>>
>> Do they *all* need to be implemented? Just some? Do they need feature
>> parity?
>>
>> For example the previous discussion about Go had 2 components that would
>> have required at most 2 of these base libraries (and I think that was
>> mainly on the Designate side - the swift implementation did not need
>> any (I think - I am open to correction)
>>
>>> - Define how the deliverables are distributed
>>
>> ++ - but this needs to be done with the release management teams input.
>> What I think is reasonable may not be something that they are interested
>> in supporting.
>>
>>> - Define how stable maintenance will work
>>
>> ++
>>
>>> - Setup the CI pipelines for the new language
>>
>> This requires the -infra team dedicate (what are already stretched)
>> resources to a theoretical situation, doing work that may be thrown
>> away if the TC rejects a language.
>>
> Here's another take on the situation. If there are people who genuinely
> wish to see a CI pipeline that can support something like Go, perhaps you
> can establish a prerequisite of working with the Infra team on establishing
> the new pipeline. In my opinion, this seems to be the major gate. So, if
> there's a clear path identified, resources provided, and the Infra team is
> ultimately benefitted, then I'm not sure why there should be another
> rejection. Just a thought. I know this proposal continues to come up and
> I'm a big fan of seeing other languages supported, especially Go. But I
> also understand that it can break things. Personally, I would even
> volunteer to work on such an Infra effort.
>
> BTW, it is quite possible that another group might feel the same
> constraints. It's perfectly reasonable. But if we can overcome such
> obstacles, would the TC still have a concern?


Here's the notes we had from last May when we started the Golang discussion 
where we started working through these questions.

https://etherpad.openstack.org/p/golang-infra-issues-to-solve


>
>>
>> I foresee these requirements as a whole being overly onerous, and
>> having the same result as saying "no new languages".
>>
>> I think that there should be base research into all of these, but the
>> requirements for some of these to be fully completed could be basically
>> impossible.
>>
>>>
>>> The longer and more detailed version is here:
>>>
>>> https://blog.flaper87.com/embracing-other-languages-openstack.html
>>>
>>> Stay tuned,
>>> Flavio
>>>
>>
>>
>> __
>> OpenStack Development Mailing 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

Re: [openstack-dev] [nova][qa] Testing with ephemeral/swap disks

2016-11-07 Thread Chris Friesen


On 11/07/2016 10:03 AM, Matt Riedemann wrote:

Nova has a known gap in integration testing of ephemeral/swap disks, especially
around resizes and migrations.

In Newton, Diana Clarke worked on a Tempest patch to verify the size of disks
before and after a resize:

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

The QA team took issue with that patch because it creates specific flavors which
might not work in all clouds, which is a valid concern.

At the summit some of the Nova people talked about what if we just added
ephemeral/swap to the flavors that devstack creates and puts in tempest.conf -
then we'd get some implicit coverage of those by default. That doesn't really
help non-devstack CI systems, but I'm not entirely sure it matters, at least
right now.

If we did have a specific test for this, like Diana's above, then we could just
skip the test if the flavors in tempest.conf don't have ephemeral/swap defined.
That would allow us to test this in the upstream CI, and external CI could also
test it if they wanted to, but it wouldn't break external CI.

Would that be OK? Or are there other issues with that approach?


This sounds like a start...given that we default to no preallocation, the real 
increased disk consumption should be minimal.


Chris

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

Re: [openstack-dev] [all] Embracing new languages in OpenStack

2016-11-07 Thread Ash

On Mon, Nov 7, 2016 at 9:58 AM, Hayes, Graham  wrote:

> On 07/11/2016 17:14, Flavio Percoco wrote:
> > Greetings,
> >
> > I literally just posted a thing on my blog with some thoughts of what
> I'd expect
> > any new language being proposed for OpenStack to cover before it can be
> > accepted.
> >
> > The goal is to set the expectations right for what's needed for new
> languages to
> > be accepted in the community. During the last evaluation of the Go
> proposal I
> > raised some concerns but I also said I was not closed to discussing this
> again
> > in the future. It's clear we've not documented expectations yet and this
> is a
> > first step to get that going before a new proposal comes up and we start
> > discussing this topic again.
> >
> > I don't think a blog post is the "way we should do this" but it was my
> way to
> > dump what's in my brain before working on something official (which I'll
> do
> > this/next week).
> >
> > I also don't think this list is perfect. It could either be too
> restrictive or
> > too open but it's a first step. I won't paste the content of my post in
> this
> > email but I'll provide a tl;dr and eventually come back with the actual
> > reference document patch. I thought I'd drop this here in case people
> read my
> > post and were confused about what's going on there.
> >
> > Ok, here's the TL;DR of what I believe we should know/do before
> accepting a new
> > language into the community:
>
> Its a great starting point, but there is one issue:
>
> This is a *huge* amount of work to get into place, for the TC to still
> potentially refuse the language. (I know you covered this in your blog
> post, but I think there is a level of underestimation there.)
>
>
> > - Define a way to share code/libraries for projects using the language
>
> ++ - Definitely needed
>
> > - Work on a basic set of libraries for OpenStack base services
>
> What do we include here? You called out these:
>
> keystoneauth / keystone-client
> oslo.config
> oslo.db
> oslo.messaging
>
> We need to also include
>
> oslo.log
>
> Do they *all* need to be implemented? Just some? Do they need feature
> parity?
>
> For example the previous discussion about Go had 2 components that would
> have required at most 2 of these base libraries (and I think that was
> mainly on the Designate side - the swift implementation did not need
> any (I think - I am open to correction)
>
> > - Define how the deliverables are distributed
>
> ++ - but this needs to be done with the release management teams input.
> What I think is reasonable may not be something that they are interested
> in supporting.
>
> > - Define how stable maintenance will work
>
> ++
>
> > - Setup the CI pipelines for the new language
>
> This requires the -infra team dedicate (what are already stretched)
> resources to a theoretical situation, doing work that may be thrown
> away if the TC rejects a language.
>
Here's another take on the situation. If there are people who genuinely
wish to see a CI pipeline that can support something like Go, perhaps you
can establish a prerequisite of working with the Infra team on establishing
the new pipeline. In my opinion, this seems to be the major gate. So, if
there's a clear path identified, resources provided, and the Infra team is
ultimately benefitted, then I'm not sure why there should be another
rejection. Just a thought. I know this proposal continues to come up and
I'm a big fan of seeing other languages supported, especially Go. But I
also understand that it can break things. Personally, I would even
volunteer to work on such an Infra effort.

BTW, it is quite possible that another group might feel the same
constraints. It's perfectly reasonable. But if we can overcome such
obstacles, would the TC still have a concern?

>
> I foresee these requirements as a whole being overly onerous, and
> having the same result as saying "no new languages".
>
> I think that there should be base research into all of these, but the
> requirements for some of these to be fully completed could be basically
> impossible.
>
> >
> > The longer and more detailed version is here:
> >
> > https://blog.flaper87.com/embracing-other-languages-openstack.html
> >
> > Stay tuned,
> > Flavio
> >
>
>
> __
> OpenStack Development Mailing 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] Embracing new languages in OpenStack

2016-11-07 Thread Monty Taylor

On 11/07/2016 11:58 AM, Hayes, Graham wrote:
> On 07/11/2016 17:14, Flavio Percoco wrote:
>> Greetings,
>>
>> I literally just posted a thing on my blog with some thoughts of what I'd 
>> expect
>> any new language being proposed for OpenStack to cover before it can be
>> accepted.
>>
>> The goal is to set the expectations right for what's needed for new 
>> languages to
>> be accepted in the community. During the last evaluation of the Go proposal I
>> raised some concerns but I also said I was not closed to discussing this 
>> again
>> in the future. It's clear we've not documented expectations yet and this is a
>> first step to get that going before a new proposal comes up and we start
>> discussing this topic again.
>>
>> I don't think a blog post is the "way we should do this" but it was my way to
>> dump what's in my brain before working on something official (which I'll do
>> this/next week).
>>
>> I also don't think this list is perfect. It could either be too restrictive 
>> or
>> too open but it's a first step. I won't paste the content of my post in this
>> email but I'll provide a tl;dr and eventually come back with the actual
>> reference document patch. I thought I'd drop this here in case people read my
>> post and were confused about what's going on there.
>>
>> Ok, here's the TL;DR of what I believe we should know/do before accepting a 
>> new
>> language into the community:
> 
> Its a great starting point, but there is one issue:
> 
> This is a *huge* amount of work to get into place, for the TC to still
> potentially refuse the language. (I know you covered this in your blog
> post, but I think there is a level of underestimation there.)

Yes, it is absolutely a huge amount of work for sure, and I think your
point is important.

> 
>> - Define a way to share code/libraries for projects using the language
> 
> ++ - Definitely needed
> 
>> - Work on a basic set of libraries for OpenStack base services
> 
> What do we include here? You called out these:
> 
> keystoneauth / keystone-client
> oslo.config
> oslo.db
> oslo.messaging
> 
> We need to also include
> 
> oslo.log
> 
> Do they *all* need to be implemented? Just some? Do they need feature
> parity?

To me the most important piece is feature parity on the operator
interaction side.

Concretely - oslo.config is important because it shapes what the config
files look like. The implementation language of a particular service
shouldn't change what our config files look like, yeah?

Similarly keystoneauth - not because getting a token from keystone with
a username and password is necessarily hard- but because we're trying to
drive more service-service interactions through the catalog to reduce
the number of things an operator needs to configure directly - and also
because keystone has auth plugins that need to be supported in the new
language too. (it's a common fault in non-python client implementations
that non-password auth plugins are not covered at all)

oslo.log has similar needs - the logging for an operator needs to be
able to be routed to the same places and be in the same format as the
existing things.

oslo.messaging and oslo.db have needs where they intersect with operator
config.

> For example the previous discussion about Go had 2 components that would
> have required at most 2 of these base libraries (and I think that was
> mainly on the Designate side - the swift implementation did not need
> any (I think - I am open to correction)
> 
>> - Define how the deliverables are distributed
> 
> ++ - but this needs to be done with the release management teams input.
> What I think is reasonable may not be something that they are interested
> in supporting.
> 
>> - Define how stable maintenance will work
> 
> ++
> 
>> - Setup the CI pipelines for the new language
> 
> This requires the -infra team dedicate (what are already stretched)
> resources to a theoretical situation, doing work that may be thrown
> away if the TC rejects a language.
> 
> I foresee these requirements as a whole being overly onerous, and
> having the same result as saying "no new languages".
> 
> I think that there should be base research into all of these, but the
> requirements for some of these to be fully completed could be basically
> impossible.

Having a solution for deliverable distribution, stable maintenance,
shared requirements management and caching/mirroring for the gate are
things I personally think are pre-requisites. They're conceptually hard
but not necessarily a giant amount of hands-on-ground work. (some work,
but not an excessive amount) They represent the parts of the
intra-developer social contract that exists within the structures of how
we operate on repositories.

I would think that library coverage needs a plan, but doesn't need to be
_finished_ - until such a time as the deliverable in question needs to
be delivered. Or, put another way - we need to have a clear list of
things and a mechanism for doing them - but we don't need a

Re: [openstack-dev] [Neutron][neutron-lbaas][octavia] Not be able to ping loadbalancer ip

2016-11-07 Thread Michael Johnson

Hi Wanjing,

You are not seeing the network interfaces for the VIP and member
networks because they are inside a network namespace for security
reasons.  You can see these by issuing "sudo ip netns exec
amphora-haproxy ifconfig -a".

I'm not sure what version of octavia and neutron you are using, but
the issue you noted about "dns_name" was fixed here:
https://review.openstack.org/#/c/337939/

Michael


On Thu, Nov 3, 2016 at 11:29 AM, Wanjing Xu (waxu)  wrote:
> Going through the log , I saw the following error on o-hm
>
> 2016-11-03 03:31:06.441 19560 ERROR
> octavia.controller.worker.controller_worker request_ids=request_ids)
> 2016-11-03 03:31:06.441 19560 ERROR
> octavia.controller.worker.controller_worker BadRequest: Unrecognized
> attribute(s) 'dns_name'
> 2016-11-03 03:31:06.441 19560 ERROR
> octavia.controller.worker.controller_worker Neutron server returns
> request_ids: ['req-1daed46e-ce79-471c-a0af-6d86d191eeb2']
>
> And it seemed that I need to upgrade my neutron client.  While I am planning
> to do it, could somebody please send me the document on how this vip is
> supposed to plug into the lbaas vm and what the failover is about ?
>
> Thanks!
> Wanjing
>
>
> From: Cisco Employee 
> Reply-To: "OpenStack Development Mailing List (not for usage questions)"
> 
> Date: Wednesday, November 2, 2016 at 7:04 PM
> To: "OpenStack Development Mailing List (not for usage questions)"
> 
> Subject: [openstack-dev] [Neutron][neutron-lbaas][octavia] Not be able to
> ping loadbalancer ip
>
> So I bring up octavia using devstack (stable/mitaka).   I created a
> loadbalander and a listener(not create member yet) and start to look at how
> things are connected to each other.  I can ssh to amphora vm and I do see a
> haproxy is up with front end point to my listener.  I tried to ping (from
> dhcp namespace) to the loadbalancer ip, and ping could not go through.  I am
> wondering how packet is supposed to reach this amphora vm.  I can see that
> the vm is launched on both network(lb_mgmt network and my vipnet), but I
> don’t see any nic associated with my vipnet:
>
> ubuntu@amphora-dad2f14e-76b4-4bd8-9051-b7a5627c6699:~$ ifconfig -a
> eth0  Link encap:Ethernet  HWaddr fa:16:3e:b4:b2:45
>   inet addr:192.168.0.4  Bcast:192.168.0.255  Mask:255.255.255.0
>   inet6 addr: fe80::f816:3eff:feb4:b245/64 Scope:Link
>   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>   RX packets:2496 errors:0 dropped:0 overruns:0 frame:0
>   TX packets:2626 errors:0 dropped:0 overruns:0 carrier:0
>   collisions:0 txqueuelen:1000
>   RX bytes:307518 (307.5 KB)  TX bytes:304447 (304.4 KB)
>
> loLink encap:Local Loopback
>   inet addr:127.0.0.1  Mask:255.0.0.0
>   inet6 addr: ::1/128 Scope:Host
>   UP LOOPBACK RUNNING  MTU:65536  Metric:1
>   RX packets:212 errors:0 dropped:0 overruns:0 frame:0
>   TX packets:212 errors:0 dropped:0 overruns:0 carrier:0
>   collisions:0 txqueuelen:0
>   RX bytes:18248 (18.2 KB)  TX bytes:18248 (18.2 KB)
>
> localadmin@dmz-eth2-ucs1:~/devstack$ nova list
> +--+--+++-+---+
> | ID   | Name
> | Status | Task State | Power State | Networks
> |
> +--+--+++-+---+
> | 557a3de3-a32e-419d-bdf5-41d92dd2333b |
> amphora-dad2f14e-76b4-4bd8-9051-b7a5627c6699 | ACTIVE | -  | Running
> | lb-mgmt-net=192.168.0.4; vipnet=100.100.100.4 |
> +--+--+++-+———+
>
> And it seemed that amphora created a port from the vipnet for its vrrp_ip,
> but now sure how it is used and how it is supposed to help packet to reach
> loadbalancer ip
>
> It will be great if somebody can help on this, especially on network side.
>
> Thanks
> Wanjing
>
>
> __
> OpenStack Development Mailing 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] Embracing new languages in OpenStack

2016-11-07 Thread Hayes, Graham

On 07/11/2016 17:14, Flavio Percoco wrote:
> Greetings,
>
> I literally just posted a thing on my blog with some thoughts of what I'd 
> expect
> any new language being proposed for OpenStack to cover before it can be
> accepted.
>
> The goal is to set the expectations right for what's needed for new languages 
> to
> be accepted in the community. During the last evaluation of the Go proposal I
> raised some concerns but I also said I was not closed to discussing this again
> in the future. It's clear we've not documented expectations yet and this is a
> first step to get that going before a new proposal comes up and we start
> discussing this topic again.
>
> I don't think a blog post is the "way we should do this" but it was my way to
> dump what's in my brain before working on something official (which I'll do
> this/next week).
>
> I also don't think this list is perfect. It could either be too restrictive or
> too open but it's a first step. I won't paste the content of my post in this
> email but I'll provide a tl;dr and eventually come back with the actual
> reference document patch. I thought I'd drop this here in case people read my
> post and were confused about what's going on there.
>
> Ok, here's the TL;DR of what I believe we should know/do before accepting a 
> new
> language into the community:

Its a great starting point, but there is one issue:

This is a *huge* amount of work to get into place, for the TC to still
potentially refuse the language. (I know you covered this in your blog
post, but I think there is a level of underestimation there.)


> - Define a way to share code/libraries for projects using the language

++ - Definitely needed

> - Work on a basic set of libraries for OpenStack base services

What do we include here? You called out these:

keystoneauth / keystone-client
oslo.config
oslo.db
oslo.messaging

We need to also include

oslo.log

Do they *all* need to be implemented? Just some? Do they need feature
parity?

For example the previous discussion about Go had 2 components that would
have required at most 2 of these base libraries (and I think that was
mainly on the Designate side - the swift implementation did not need
any (I think - I am open to correction)

> - Define how the deliverables are distributed

++ - but this needs to be done with the release management teams input.
What I think is reasonable may not be something that they are interested
in supporting.

> - Define how stable maintenance will work

++

> - Setup the CI pipelines for the new language

This requires the -infra team dedicate (what are already stretched)
resources to a theoretical situation, doing work that may be thrown
away if the TC rejects a language.

I foresee these requirements as a whole being overly onerous, and
having the same result as saying "no new languages".

I think that there should be base research into all of these, but the
requirements for some of these to be fully completed could be basically
impossible.

>
> The longer and more detailed version is here:
>
> https://blog.flaper87.com/embracing-other-languages-openstack.html
>
> Stay tuned,
> Flavio
>


__
OpenStack Development Mailing 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][octavia] Spec: Deploy Octavia with OpenStack-Ansible

2016-11-07 Thread Michael Johnson

Thank you Major!

I will try to get a pass on this early in the week.

I agree with you that taking this one step at a time is probably best.
TLS offloading (requiring barbican) is a common use case, but we can
work on that as a follow up.

Michael

On Wed, Nov 2, 2016 at 6:42 AM, Major Hayden  wrote:
> Hey folks,
>
> I drafted a spec yesterday for deploying Octavia with OpenStack-Ansible.  The 
> spec review[0] is pending and you can go straight to the rendered version[1] 
> if you want to take a look.
>
> We proposed this before in the Liberty release, but we ended up implementing 
> only LBaaSv2 with the agent-based load balancers.  Octavia has come a long 
> way and is definitely ready for use in Newton/Ocata.
>
> Most of the spec is fairly straightforward, but there are still two open 
> questions that may need to be answered in the implementation steps:
>
> 1) Do we generate the amphora (LB) image on the fly
>with DIB with each deployment? Or, do we pre-build
>it and download it during the deployment?
>
> It might be easier to use DIB in the development stages and then figure out a 
> cached image solution as the role becomes a little more mature.
>
> 2) Do we want to implement SSL offloading (Barbican
>is required) now or tackle that later?
>
> I'd lean towards deploying Octavia without SSL offloading first, and then add 
> in the Barbican support afterwards.  My gut says it's better to the basic 
> functionality working well first before we begin adding on extras.
>
> Your feedback is definitely welcomed! :)
>
> [0] https://review.openstack.org/392205
> [1] 
> http://docs-draft.openstack.org/05/392205/2/check/gate-openstack-ansible-specs-docs-ubuntu-xenial/8f1eec1//doc/build/html/specs/ocata/octavia.html
>
> --
> Major Hayden
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

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

Re: [openstack-dev] [neutron] [neutron-lbaas][octavia] Error in installing octavia via devstack on ubuntu stable/mitaka

2016-11-07 Thread Michael Johnson

Nope, we included these changes in Newton.

Michael


On Tue, Nov 1, 2016 at 4:11 AM, Ihar Hrachyshka  wrote:
> Michael Johnson  wrote:
>
>> Hi Wanjing,
>>
>> I responded to you in IRC but you may have logged off by the time I
>> was able to respond.
>>
>> You are correct that this is an issue.  We just this week noticed it.
>> It was an oversight that is causing the amphora agent to clone the
>> master branch amphora agent code instead of the stable/mitaka version.
>>
>> There are two patches up that will fix this:
>> https://review.openstack.org/390896
>> https://review.openstack.org/391063
>>
>
> (For the latter ^) Don't we need a similar one for stable/newton?
>
> Ihar
>
>
> __
> OpenStack Development Mailing 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] Why ML2 does not supprot update network provider attributes

2016-11-07 Thread Kevin Benton

True. I think if you just want to add segments, making use of the new
segments API added as part of the routed networks work would be the way to
go.

On Mon, Nov 7, 2016 at 9:19 AM, Robert Kukura 
wrote:

> I'm not sure unbinding ports is necessary unless the segment that a port
> has bound is removed or modified. A reasonable compromise might be for ML2
> to allow adding new segments, which should not require unbinding/rebinding
> ports, but not allow removing or modifying existing segments.
>
> -Bob
>
> On 11/5/16 7:59 PM, Kevin Benton wrote:
>
> To allow that we would have to unbind every port in the network and then
> rebind it with the new segment info generated from changing the provider
> attributes. This requires quite a bit of orchestration code in ML2 (to
> handle failures, etc) that doesn't exist right now.
>
> On Sat, Nov 5, 2016 at 7:50 AM, zhuna  wrote:
>
>> Dear,
>>
>>
>>
>> Neutron RESTful API support update network provider attributes, but ML2
>> raises error when update network provider attributes (in function
>> _raise_if_updates_provider_attributes), can anyone tell me why ML2 does
>> not support it?
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> BR
>>
>> Juno
>>
>>
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] Embracing new languages in OpenStack

2016-11-07 Thread Jordan Pittier

Again ? Are we going to have that discussion every 3 months... ?

On Mon, Nov 7, 2016 at 6:09 PM, Flavio Percoco  wrote:

> Greetings,
>
> I literally just posted a thing on my blog with some thoughts of what I'd
> expect
> any new language being proposed for OpenStack to cover before it can be
> accepted.
>
> The goal is to set the expectations right for what's needed for new
> languages to
> be accepted in the community. During the last evaluation of the Go
> proposal I
> raised some concerns but I also said I was not closed to discussing this
> again
> in the future. It's clear we've not documented expectations yet and this
> is a
> first step to get that going before a new proposal comes up and we start
> discussing this topic again.
>
> I don't think a blog post is the "way we should do this" but it was my way
> to
> dump what's in my brain before working on something official (which I'll do
> this/next week).
>
> I also don't think this list is perfect. It could either be too
> restrictive or
> too open but it's a first step. I won't paste the content of my post in
> this
> email but I'll provide a tl;dr and eventually come back with the actual
> reference document patch. I thought I'd drop this here in case people read
> my
> post and were confused about what's going on there.
>
> Ok, here's the TL;DR of what I believe we should know/do before accepting
> a new
> language into the community:
>
> - Define a way to share code/libraries for projects using the language
> - Work on a basic set of libraries for OpenStack base services
> - Define how the deliverables are distributed
> - Define how stable maintenance will work
> - Setup the CI pipelines for the new language
>
> The longer and more detailed version is here:
>
> https://blog.flaper87.com/embracing-other-languages-openstack.html
>
> Stay tuned,
> Flavio
>
> --
> @flaper87
> Flavio Percoco
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>

-- 
 

__
OpenStack Development Mailing 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] Why ML2 does not supprot update network provider attributes

2016-11-07 Thread Robert Kukura

I'm not sure unbinding ports is necessary unless the segment that a port 
has bound is removed or modified. A reasonable compromise might be for 
ML2 to allow adding new segments, which should not require 
unbinding/rebinding ports, but not allow removing or modifying existing 
segments.


-Bob


On 11/5/16 7:59 PM, Kevin Benton wrote:
To allow that we would have to unbind every port in the network and 
then rebind it with the new segment info generated from changing the 
provider attributes. This requires quite a bit of orchestration code 
in ML2 (to handle failures, etc) that doesn't exist right now.


On Sat, Nov 5, 2016 at 7:50 AM, zhuna > wrote:


Dear,

Neutron RESTful API support update network provider attributes,
but ML2 raises error when update network provider attributes (in
function _raise_if_updates_provider_attributes), can anyone tell
me why ML2 does not support it?

BR

Juno


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

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev





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


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

[openstack-dev] [all] Embracing new languages in OpenStack

2016-11-07 Thread Flavio Percoco


Greetings,

I literally just posted a thing on my blog with some thoughts of what I'd expect
any new language being proposed for OpenStack to cover before it can be
accepted.

The goal is to set the expectations right for what's needed for new languages to
be accepted in the community. During the last evaluation of the Go proposal I
raised some concerns but I also said I was not closed to discussing this again
in the future. It's clear we've not documented expectations yet and this is a
first step to get that going before a new proposal comes up and we start
discussing this topic again.

I don't think a blog post is the "way we should do this" but it was my way to
dump what's in my brain before working on something official (which I'll do
this/next week).

I also don't think this list is perfect. It could either be too restrictive or
too open but it's a first step. I won't paste the content of my post in this
email but I'll provide a tl;dr and eventually come back with the actual
reference document patch. I thought I'd drop this here in case people read my
post and were confused about what's going on there.

Ok, here's the TL;DR of what I believe we should know/do before accepting a new
language into the community:

- Define a way to share code/libraries for projects using the language
- Work on a basic set of libraries for OpenStack base services
- Define how the deliverables are distributed
- Define how stable maintenance will work
- Setup the CI pipelines for the new language

The longer and more detailed version is here:

https://blog.flaper87.com/embracing-other-languages-openstack.html

Stay tuned,
Flavio

--
@flaper87
Flavio Percoco


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

[openstack-dev] [mistral] Team meeting minutes/log - 11/07/2016

2016-11-07 Thread Renat Akhmerov

The minutes and log of the meeting we just had:
http://eavesdrop.openstack.org/meetings/mistral/2016/mistral.2016-11-07-16.01.html
 

http://eavesdrop.openstack.org/meetings/mistral/2016/mistral.2016-11-07-16.01.log.html
 


Thanks for joining!

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

Re: [openstack-dev] [glare] Few questions regarding OpenStack Glare

2016-11-07 Thread Mikhail Fedosin

Hi Moshe! Thank you for your interest in the project. I answered your
questions below.

On Mon, Nov 7, 2016 at 3:13 PM, Elisha, Moshe (Nokia - IL) <
moshe.eli...@nokia.com> wrote:

> Hi,
>
>
>
> My name is Moshe Elisha and I work at CloudBand, Nokia.
>
> I watched "Glare - A Unified Binary Repository for OpenStack[1]" and it
> looks very nice and useful.
>
>
>
> We are considering using Glare as a standalone artifacts repository.
>
> We have two main use cases:
>
> A. Create a custom artifact_type which basically has one archive file
> (BLOB).
>
> B. Use "images" artifact type to store images.
>
>
>
> I have a few questions that I couldn't find the answer for and I would
> appreciate it if you could please reply:
>
>
>
> 1.  What dependencies does Glare have on other OpenStack services? Is
> it only a dependency in Keystone?
>
Glare may be a standalone service: for example for App-Catalog we use it
with custom auth middleware without Keystone. Another optional dependency
is Swift.

> 2.  I saw that there is a way to implement a "validate_upload" hook.
> Is there a support for an async validation process (in case validation
> process is long)?
>
For big files uploads we're going to implement integration with OpenStack
Mistral to have them as asynchronous tasks. Currently all uploads are
synchronous.

> 3.  Is there a way to define the "backend" used per artifact_type?
> For example, "heat_templates" will be stored on "File system" and "images"
> will be stored on "Ceph"?
>
For your particular case - yes. You may specify function
"get_default_store" for you artifact type and return desired backend. It's
highly flexible and allows to define your backend dynamically, based on
user's context, current artifact values or blob name. Unfortunately
glance_store doesn't support several backends of one type, like 3 different
cephs. I believe it will be achieved during Ocata cycle and we'll be able
to talk about true multibackendness :)

> 4.  Were there talks about a "Database" backend? Probably only
> relevant for some artifact types.
>
For doing this we will have to add new driver to glance_store and I'm 100%
sure that glance community will be against this initiative. But it's
doable: in the worst case we can get rid of glance_store library and add
all the necessary functionality right in Glare repo.

> 5.  Disregarding the "backend" used – is there anything that prevents
> Glare from running in HA active/active mode?
>
I do not see any obstacles.

> 6.  With regards to "backend" – which of the currently supported
> backends is preferable in order to achieve HA active/active mode?
>
If I understand you correctly - all, except 'file'.

> 7.  I noticed that there is a puppet-glare[2] project. Can you please
> share the status of that project?
>
Frankly speaking I don't know. Some Mirantis folks worked on it a month
ago, but now they don't. All I know - this puppet is good enough for
deploying new App-Catalog with Glare backend.

> 8.  Is there any work being done for creating RPMs for glare?
>
Afaik no. We need a volunteer from RDO community for this.

>
>
> [1] https://www.youtube.com/watch?v=uBtqdXciF4A
>
> [2] https://github.com/openstack/puppet-glare
>
> [3] https://github.com/openstack-packages
>
>
>
>
>
> Thanks!
>
>
>
>
>
> Moshe Elisha,
>
> R Director,
>
> CloudBand Network Director, 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] [MassivelyDistributed] bi-weekly meeting

2016-11-07 Thread lebre . adrien

Dear all, 

We are still looking for an irc channel for our meeting: 
https://review.openstack.org/#/c/393899
There is no available channels for the slot we selected during our face-to-face 
meeting in Barcelona. 

If I'm correct, we have two possibilities: 
- Determine another slot: the first available slot on Wednesday is at 17:00 UTC.
- Ask for the creation of a new IRC channel dedicated to our WG: something line 
#openstack-massively-distributed

Please let me ASAP know whether the first solution is feasible, if not I should 
see with the Infra team whether we can register the new IRC by Wednesday. 

Thanks in advance, 
ad_rien_ 
https://wiki.openstack.org/wiki/Massively_Distributed_Clouds

__
OpenStack Development Mailing 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] Useful tool for easier viewing of IRC logs online

2016-11-07 Thread Christopher Aedo

On Mon, Nov 7, 2016 at 7:09 AM, Jimmy McArthur  wrote:
> Hi all - Wanted to circle back on this now that we're clear of the Summit
> madness. Someone had asked for assistance on getting OpenStackID up and
> running on this. Is that still a need? If so, let me know how we can help.

Jimmy, I know you and I briefly discussed something else relating to
IRC and authenticating with OpenStack ID.  It has to do with infra
hosting an instance of "The Lounge" IRC client, as outlined in this
spec[1].

If that's what you were thinking of, I'm definitely still interested
in getting your view on whether or not integrating auth via OpenStack
ID is something you could help with :)

[1]: https://review.openstack.org/319506

-Christopher



> Thank you,
> Jimmy
>
> Chris Dent
> September 21, 2016 at 3:47 PM
> On Wed, 21 Sep 2016, Boden Russell wrote:
>
>
> For channels that are configured to have purplerbot running, you can
> get that with p!spy. See https://anticdent.org/purple-irc-bot.html
>
> If you want the bot added to a channel let me know, or run your own;
> the code is linked from the blog post.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> Boden Russell
> September 21, 2016 at 1:22 PM
>
> Nice thanks!
>
> I've always wanted a tool that could alert me of "missed mentions" when
> I'm offline IRC rather than having to manually parse the IRC logs for
> those times I'm offline. However I'm guessing that falls outside the
> scope of this tool or could be done with some other tool (I haven't
> investigated yet)?
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> Asselin, Ramy
> September 19, 2016 at 11:54 AM
>
> Very nice, thanks!
>
> Only change I’ll suggest is to allow it to be enabled by default J
>
> Ramy
>
>
>
> From: Bashmakov, Alexander [mailto:alexander.bashma...@intel.com]
> Sent: Friday, September 16, 2016 2:26 PM
> To: OpenStack Development Mailing List (not for usage questions)
> 
> Subject: [openstack-dev] [all] Useful tool for easier viewing of IRC logs
> online
>
>
>
> Hello Stackers,
>
>
>
> If you ever find yourself needing to peruse OpenStack IRC logs online
> (http://eavesdrop.openstack.org/irclogs/) and if you use the Chrome browser
> to do it, then the following tool may come in handy:
>
>
>
> https://chrome.google.com/webstore/detail/openstack-eavesdrop-irc-f/lcmadadicbflcamibnpplpgdcdahkade
>
>
>
> It’s a simple extension to filter messages of the type: “ has quit”
> and “ has joined”, which makes the log much more compact and readable.
>
>
>
> Source code is here: https://github.com/abashmak/chrome-irc-filter
>
>
>
> Comments, suggestions are welcome.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __
> OpenStack Development Mailing 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] [mistral] Meeting Time

2016-11-07 Thread Dougal Matthews

Hi all,

We want to make sure that the Mistral meeting time is as good as possible,
so that everyone interested can attend. To do that, please add your
name/nick and the times that suit you to this etherpad:

https://etherpad.openstack.org/p/mistral-meeting-time

If we are really lucky, we will find a time in that for everyone. if we are
slightly lucky we will find two time slots that covers everyone and the
meeting can alternate.

We may find that the current time is best for everyone, but I wanted to
make sure.

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

[openstack-dev] [nova][qa] Testing with ephemeral/swap disks

2016-11-07 Thread Matt Riedemann

Nova has a known gap in integration testing of ephemeral/swap disks, 
especially around resizes and migrations.


In Newton, Diana Clarke worked on a Tempest patch to verify the size of 
disks before and after a resize:


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

The QA team took issue with that patch because it creates specific 
flavors which might not work in all clouds, which is a valid concern.


At the summit some of the Nova people talked about what if we just added 
ephemeral/swap to the flavors that devstack creates and puts in 
tempest.conf - then we'd get some implicit coverage of those by default. 
That doesn't really help non-devstack CI systems, but I'm not entirely 
sure it matters, at least right now.


If we did have a specific test for this, like Diana's above, then we 
could just skip the test if the flavors in tempest.conf don't have 
ephemeral/swap defined. That would allow us to test this in the upstream 
CI, and external CI could also test it if they wanted to, but it 
wouldn't break external CI.


Would that be OK? Or are there other issues with that approach?

Alternatively we could work on some in-tree functional tests if those 
would work, but someone would have to investigate that. Note that the 
existing functional tests in Nova are not running libvirt, or glance, or 
any other external service - they only run a wsgi app server and a 
database (sqlite by default).


There has been talk of creating a nova-dsvm-integration job (there are 
differing opinions on if that should use devstack or not) which wouldn't 
run Tempest tests, just in-tree integration tests. So they could test 
things that aren't going through the REST API, like the image cache. The 
problem with this extra job is the lack of warm bodies to work on a POC.


So having brought these up - does anyone want to volunteer to explore 
these options or have issues with either one?


--

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] [Openstack-operators] [keystone][tripleo][ansible][puppet][all] changing default token format

2016-11-07 Thread Matt Fischer

How to add yourself to Planet OpenStack:
https://wiki.openstack.org/wiki/AddingYourBlog

As for SuperUser you could reach out to them if you think it's interesting
for users/operators. Generally they'll want to publish it there first then
you follow-up with your blog post a few days later.

On Mon, Nov 7, 2016 at 8:17 AM, Lance Bragstad  wrote:

> That's a good idea. Is there a page detailing the process for contributing
> to the OpenStack Blog? I did some checking but haven't found any resources
> yet. I also asked in #openstack and #openstack-doc.
>
> On Thu, Nov 3, 2016 at 11:04 AM, Rochelle Grober <
> rochelle.gro...@huawei.com> wrote:
>
>> a blog post on the OpenStack sore might be good. superuser? there are
>> folks reading this who can help
>>
>> Sent from HUAWEI AnyOffice
>> *From:*Lance Bragstad
>> *To:*OpenStack Development Mailing List (not for usage questions),
>> openstack-operat...@lists.openstack.org,
>> *Date:*2016-11-03 08:11:20
>> *Subject:*Re: [openstack-dev] [keystone][tripleo][ansible][puppet][all]
>> changing default token format
>>
>> I totally agree with communicating this the best we can. I'm adding the
>> operator list to this thread to increase visibility.
>>
>> If there are any other methods folks think of for getting the word out,
>> outside of what we've already done (release notes, email threads, etc.),
>> please let me know. I'd be happy to drive those communications.
>>
>> On Thu, Nov 3, 2016 at 9:45 AM, Alex Schultz  wrote:
>>
>>> Hey Steve,
>>>
>>> On Thu, Nov 3, 2016 at 8:29 AM, Steve Martinelli 
>>> wrote:
>>> > Thanks Alex and Emilien for the quick answer. This was brought up at
>>> the
>>> > summit by Adam, but I don't think we have to prevent keystone from
>>> changing
>>> > the default. TripleO and Puppet can still specify UUID as their desired
>>> > token format; it is not deprecated or slated for removal. Agreed?
>>> >
>>>
>>> My email was not to tell you to stop.I was just letting you know that
>>> your change does not affect the puppet modules because we define our
>>> default as UUID.  It was just as a heads up to others on this email
>>> that this change should not affect anyone consuming the puppet modules
>>> because our default is still UUID and will be even after keystone's
>>> default changes.
>>>
>>> Thanks,
>>> -Alex
>>>
>>> > On Thu, Nov 3, 2016 at 10:23 AM, Alex Schultz 
>>> wrote:
>>> >>
>>> >> Hey Steve,
>>> >>
>>> >> On Thu, Nov 3, 2016 at 8:11 AM, Steve Martinelli <
>>> s.martine...@gmail.com>
>>> >> wrote:
>>> >> > As a heads up to some of keystone's consuming projects, we will be
>>> >> > changing
>>> >> > the default token format from UUID to Fernet. Many patches have
>>> merged
>>> >> > to
>>> >> > make this possible [1]. The last 2 that you probably want to look
>>> at are
>>> >> > [2]
>>> >> > and [3]. The first flips a switch in devstack to make fernet the
>>> >> > selected
>>> >> > token format, the second makes it default in Keystone itself.
>>> >> >
>>> >> > [1] https://review.openstack.org/#/q/topic:make-fernet-default
>>> >> > [2] DevStack patch: https://review.openstack.org/#/c/367052/
>>> >> > [3] Keystone patch: https://review.openstack.org/#/c/345688/
>>> >> >
>>> >>
>>> >> Thanks for the heads up. In puppet openstack we had already
>>> >> anticipated this and attempted to do the same for the
>>> >> puppet-keystone[0] module as well.  Unfortunately after merging it, we
>>> >> found that tripleo wasn't yet prepared to handle the HA implementation
>>> >> of fernet tokens so we had to revert it[1].  This shouldn't impact
>>> >> anyone currently consuming puppet-keystone as we define uuid as the
>>> >> default for now. Our goal is to do something similar this cycle but
>>> >> there needs to be some further work in the downstream consumers to
>>> >> either define their expected default (of uuid) or support fernet key
>>> >> generation correctly.
>>> >>
>>> >> Thanks,
>>> >> -Alex
>>> >>
>>> >> [0] https://review.openstack.org/#/c/389322/
>>> >> [1] https://review.openstack.org/#/c/392332/
>>> >>
>>> >> >
>>> >> > 
>>> __
>>> >> > OpenStack Development Mailing 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.op
>>> enstack.org?subject:unsubscribe
>>> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>> >
>>> >
>>> >
>>> > 
>>> __
>>> > OpenStack Development Mailing List (not for usage questions)
>>> > Unsubscribe:

Re: [openstack-dev] [barbican] Nominating Arun Kant for barbican-core

2016-11-07 Thread Juan Antonio Osorio

+1

On 7 Nov 2016 17:18, "Dave McCowan (dmccowan)"  wrote:

>
> Arun has been a long-time terrific reviewer and contributor to Barbican.
>
> 100% +1
>
>
> --Dave
>
> On 11/7/16, 9:37 AM, "Ade Lee"  wrote:
>
> >Hi everyone,
> >
> >I'd like to nominate Arun Kant for the barbican-core team.
> >
> >Arun has been a very active contributor to the project over the past
> >few years, implementing and seeing through major features like ACLs and
> >multiple secret store back-ends.  This includes providing all the
> >required API documentation.
> >
> >He's also been active squashing bugs, and providing helpful and
> >insightful reviews.
> >
> >As a reminder to barbican-core members, we use the voting process
> >outlined in https://wiki.openstack.org/wiki/Barbican/CoreTeam to add
> >members to our team.
> >
> >Thanks,
> >Ade
> >
> >
> >___
> ___
> >OpenStack Development Mailing 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] [keystone][tripleo][ansible][puppet][all] changing default token format

2016-11-07 Thread Lance Bragstad

That's a good idea. Is there a page detailing the process for contributing
to the OpenStack Blog? I did some checking but haven't found any resources
yet. I also asked in #openstack and #openstack-doc.

On Thu, Nov 3, 2016 at 11:04 AM, Rochelle Grober  wrote:

> a blog post on the OpenStack sore might be good. superuser? there are
> folks reading this who can help
>
> Sent from HUAWEI AnyOffice
> *From:*Lance Bragstad
> *To:*OpenStack Development Mailing List (not for usage questions),
> openstack-operat...@lists.openstack.org,
> *Date:*2016-11-03 08:11:20
> *Subject:*Re: [openstack-dev] [keystone][tripleo][ansible][puppet][all]
> changing default token format
>
> I totally agree with communicating this the best we can. I'm adding the
> operator list to this thread to increase visibility.
>
> If there are any other methods folks think of for getting the word out,
> outside of what we've already done (release notes, email threads, etc.),
> please let me know. I'd be happy to drive those communications.
>
> On Thu, Nov 3, 2016 at 9:45 AM, Alex Schultz  wrote:
>
>> Hey Steve,
>>
>> On Thu, Nov 3, 2016 at 8:29 AM, Steve Martinelli 
>> wrote:
>> > Thanks Alex and Emilien for the quick answer. This was brought up at the
>> > summit by Adam, but I don't think we have to prevent keystone from
>> changing
>> > the default. TripleO and Puppet can still specify UUID as their desired
>> > token format; it is not deprecated or slated for removal. Agreed?
>> >
>>
>> My email was not to tell you to stop.I was just letting you know that
>> your change does not affect the puppet modules because we define our
>> default as UUID.  It was just as a heads up to others on this email
>> that this change should not affect anyone consuming the puppet modules
>> because our default is still UUID and will be even after keystone's
>> default changes.
>>
>> Thanks,
>> -Alex
>>
>> > On Thu, Nov 3, 2016 at 10:23 AM, Alex Schultz 
>> wrote:
>> >>
>> >> Hey Steve,
>> >>
>> >> On Thu, Nov 3, 2016 at 8:11 AM, Steve Martinelli <
>> s.martine...@gmail.com>
>> >> wrote:
>> >> > As a heads up to some of keystone's consuming projects, we will be
>> >> > changing
>> >> > the default token format from UUID to Fernet. Many patches have
>> merged
>> >> > to
>> >> > make this possible [1]. The last 2 that you probably want to look at
>> are
>> >> > [2]
>> >> > and [3]. The first flips a switch in devstack to make fernet the
>> >> > selected
>> >> > token format, the second makes it default in Keystone itself.
>> >> >
>> >> > [1] https://review.openstack.org/#/q/topic:make-fernet-default
>> >> > [2] DevStack patch: https://review.openstack.org/#/c/367052/
>> >> > [3] Keystone patch: https://review.openstack.org/#/c/345688/
>> >> >
>> >>
>> >> Thanks for the heads up. In puppet openstack we had already
>> >> anticipated this and attempted to do the same for the
>> >> puppet-keystone[0] module as well.  Unfortunately after merging it, we
>> >> found that tripleo wasn't yet prepared to handle the HA implementation
>> >> of fernet tokens so we had to revert it[1].  This shouldn't impact
>> >> anyone currently consuming puppet-keystone as we define uuid as the
>> >> default for now. Our goal is to do something similar this cycle but
>> >> there needs to be some further work in the downstream consumers to
>> >> either define their expected default (of uuid) or support fernet key
>> >> generation correctly.
>> >>
>> >> Thanks,
>> >> -Alex
>> >>
>> >> [0] https://review.openstack.org/#/c/389322/
>> >> [1] https://review.openstack.org/#/c/392332/
>> >>
>> >> >
>> >> > 
>> __
>> >> > OpenStack Development Mailing 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.op
>> enstack.org?subject:unsubscribe
>> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >
>> >
>> >
>> > 
>> __
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe: openstack-dev-requ...@lists.op
>> enstack.org?subject:unsubscribe
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>

Re: [openstack-dev] [barbican] Nominating Arun Kant for barbican-core

2016-11-07 Thread Dave McCowan (dmccowan)


Arun has been a long-time terrific reviewer and contributor to Barbican.

100% +1


--Dave

On 11/7/16, 9:37 AM, "Ade Lee"  wrote:

>Hi everyone, 
>
>I'd like to nominate Arun Kant for the barbican-core team.
>
>Arun has been a very active contributor to the project over the past
>few years, implementing and seeing through major features like ACLs and
>multiple secret store back-ends.  This includes providing all the
>required API documentation.
>
>He's also been active squashing bugs, and providing helpful and
>insightful reviews.
>
>As a reminder to barbican-core members, we use the voting process
>outlined in https://wiki.openstack.org/wiki/Barbican/CoreTeam to add
>members to our team.
>
>Thanks,
>Ade
>
>
>__
>OpenStack Development Mailing 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] Useful tool for easier viewing of IRC logs online

2016-11-07 Thread Jimmy McArthur

Hi all - Wanted to circle back on this now that we're clear of the 
Summit madness. Someone had asked for assistance on getting OpenStackID 
up and running on this. Is that still a need? If so, let me know how we 
can help.


Thank you,
Jimmy


Chris Dent 
September 21, 2016 at 3:47 PM
On Wed, 21 Sep 2016, Boden Russell wrote:


For channels that are configured to have purplerbot running, you can
get that with p!spy. See https://anticdent.org/purple-irc-bot.html

If you want the bot added to a channel let me know, or run your own;
the code is linked from the blog post.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Boden Russell 
September 21, 2016 at 1:22 PM

Nice thanks!

I've always wanted a tool that could alert me of "missed mentions" when
I'm offline IRC rather than having to manually parse the IRC logs for
those times I'm offline. However I'm guessing that falls outside the
scope of this tool or could be done with some other tool (I haven't
investigated yet)?

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Asselin, Ramy 
September 19, 2016 at 11:54 AM

Very nice, thanks!

Only change I'll suggest is to allow it to be enabled by default J

Ramy

*From:* Bashmakov, Alexander [mailto:alexander.bashma...@intel.com]
*Sent:* Friday, September 16, 2016 2:26 PM
*To:* OpenStack Development Mailing List (not for usage questions) 

*Subject:* [openstack-dev] [all] Useful tool for easier viewing of IRC 
logs online


Hello Stackers,

If you ever find yourself needing to peruse OpenStack IRC logs online 
(http://eavesdrop.openstack.org/irclogs/) and if you use the Chrome 
browser to do it, then the following tool may come in handy:


https://chrome.google.com/webstore/detail/openstack-eavesdrop-irc-f/lcmadadicbflcamibnpplpgdcdahkade

It's a simple extension to filter messages of the type: " has 
quit" and " has joined", which makes the log much more compact 
and readable.


Source code is here: https://github.com/abashmak/chrome-irc-filter

Comments, suggestions are welcome.

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


__
OpenStack Development Mailing 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 Michele Baldessari part of core team

2016-11-07 Thread John Trowbridge



On 11/04/2016 01:40 PM, Emilien Macchi wrote:
> MIchele Baldessari (bandini on IRC) has consistently demonstrated high
> levels of contributions in TripleO projects, specifically in High
> Availability area where's he's for us a guru (I still don't understand
> how pacemaker works, but hopefully he does).
> 
> He has done incredible work on composable services and also on
> improving our HA configuration by following reference architectures.
> Always here during meetings, and on #tripleo to give support to our
> team, he's a great team player and we are lucky to have him onboard.
> I believe he would be a great core reviewer on HA-related work and we
> expect his review stats to continue improving as his scope broadens
> over time.
> 
> As usual, feedback is welcome and please vote for this proposal!
> 
> Thanks,
> 

+1 I thought he was already core :P.

__
OpenStack Development Mailing 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 Michele Baldessari part of core team

2016-11-07 Thread Steven Hardy

On Fri, Nov 04, 2016 at 01:40:43PM -0400, Emilien Macchi wrote:
> MIchele Baldessari (bandini on IRC) has consistently demonstrated high
> levels of contributions in TripleO projects, specifically in High
> Availability area where's he's for us a guru (I still don't understand
> how pacemaker works, but hopefully he does).
> 
> He has done incredible work on composable services and also on
> improving our HA configuration by following reference architectures.
> Always here during meetings, and on #tripleo to give support to our
> team, he's a great team player and we are lucky to have him onboard.
> I believe he would be a great core reviewer on HA-related work and we
> expect his review stats to continue improving as his scope broadens
> over time.
> 
> As usual, feedback is welcome and please vote for this proposal!

+1 agreed, Michele has done a lot of great work recently and will make an
excellent addition to the core reviewers group.

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

[openstack-dev] [barbican] Nominating Arun Kant for barbican-core

2016-11-07 Thread Ade Lee

Hi everyone, 

I'd like to nominate Arun Kant for the barbican-core team.

Arun has been a very active contributor to the project over the past
few years, implementing and seeing through major features like ACLs and
multiple secret store back-ends.  This includes providing all the
required API documentation.

He's also been active squashing bugs, and providing helpful and
insightful reviews.

As a reminder to barbican-core members, we use the voting process
outlined in https://wiki.openstack.org/wiki/Barbican/CoreTeam to add
members to our team.

Thanks,
Ade


__
OpenStack Development Mailing 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] python-wsmanclient future

2016-11-07 Thread Dmitry Tantsur


Hi folks!

In view of the Ironic governance discussion [1] I'd like to talk about 
wsmanclient [2] future.


This project was created to split away wsman code from python-dracclient to be 
reused in other drivers (I can only think of AMT right now). This was never 
finished: dracclient still uses its internal wsman implementation.


To make it worse, the guy behind this effort (ifarkas) has left our team, 
python-dracclient is likely to leave Ironic governance per [1], and the AMT 
driver is going to leave the Ironic tree.


At least the majority of the folks currently behind dracclient (Miles, Lucas and 
myself) do not have resources to continue this wsmanclient effort. Unless 
somebody is ready to take over both wsmanclient itself and the effort to port 
dracclient, I suggest we abandon wsmanclient.


Any thoughts?

[1] https://review.openstack.org/#/c/392685/
[2] https://github.com/openstack/python-wsmanclient

__
OpenStack Development Mailing 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][kolla][security] pycrypto vs cryptography

2016-11-07 Thread Rob C

Good question, I know issues around this have arisen before.

I think the main points have been covered well already, for my part I will
always lean toward the better supported or actively developed project.

I understand the desire to look for FIPS 140-2 compliance, however I'd
caution about this being the only deciding factor, it makes software
development messy as only specific implementations can be validated. If you
want to update code to make improvements etc you can need a whole
re-validation. I'm not saying that FIPS 140-2 doesn't have value but I know
of software projects that have used known-bad implementations that had
certification rather use an updated version with no issues - (like I said,
it gets messy).

The OpenSSL guys wrote a good article on FIPS validation, how they tackled
it and some of the impact etc [1]

-Rob

[1] https://www.openssl.org/docs/fipsnotes.html

On Sun, Nov 6, 2016 at 4:44 PM, Jeremy Stanley  wrote:

> On 2016-11-06 14:59:03 + (+), Jeremy Stanley wrote:
> > On 2016-11-06 08:05:51 + (+), Steven Dake (stdake) wrote:
> [...]
> > > An orthogonal question I have received from one of our community
> > > members (Pavo on irc) is whether pycrypto (or if we move to
> > > cryptography) provide FIPS-140-2 compliance.
> >
> > My understanding is that if you need, for example, a FIPS-compliant
> > AES implementation under the hood, then this is dependent more on
> > what backend libraries you're using... e.g.,
> > https://www.openssl.org/docs/fips.html
> > https://www.openssl.org/docs/fipsvalidation.html
>
> I should clarify, I was referring specifically to
> pyca/cryptography's OpenSSL backend. In contrast the pycrypto
> maintainers seem to have copied and forked a variety of algorithms
> (some of which seem to be based NIST/FIPS reference implementations
> for C or backports from bits of Py3K stdlib but have undergone
> subsequent modification), so very likely have not been put through
> any sort of direct compliance validation:
> https://github.com/dlitz/pycrypto/blob/master/src/AES.c
> https://github.com/dlitz/pycrypto/blob/master/src/SHA512.c
> et cetera...
> --
> Jeremy Stanley
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone] new keystone core (breton)

2016-11-07 Thread De Rose, Ronald

Congrats Boris!  Awesome!

-Ron

From: Steve Martinelli [mailto:s.martine...@gmail.com]
Sent: Monday, October 31, 2016 12:47 PM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: [openstack-dev] [keystone] new keystone core (breton)

I want to welcome Boris Bobrov (breton) to the keystone core team. Boris has 
been a contributor for some time and is well respected by the keystone team for 
bringing real-world operator experience and feedback. He has recently become 
more active in terms of code contributions and bug triaging. Upon interacting 
with Boris, you quickly realize he has a high standard for quality and keeps us 
honest.

Thanks for all your hard work Boris, I'm happy to have you on the team.

Steve Martinelli
stevemar

__
OpenStack Development Mailing 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] [glare] Few questions regarding OpenStack Glare

2016-11-07 Thread Elisha, Moshe (Nokia - IL)

Hi,

My name is Moshe Elisha and I work at CloudBand, Nokia.
I watched "Glare - A Unified Binary Repository for OpenStack[1]" and it looks 
very nice and useful.

We are considering using Glare as a standalone artifacts repository.
We have two main use cases:

A. Create a custom artifact_type which basically has one archive file 
(BLOB).

B. Use "images" artifact type to store images.

I have a few questions that I couldn't find the answer for and I would 
appreciate it if you could please reply:


1.  What dependencies does Glare have on other OpenStack services? Is it 
only a dependency in Keystone?

2.  I saw that there is a way to implement a "validate_upload" hook. Is 
there a support for an async validation process (in case validation process is 
long)?

3.  Is there a way to define the "backend" used per artifact_type? For 
example, "heat_templates" will be stored on "File system" and "images" will be 
stored on "Ceph"?

4.  Were there talks about a "Database" backend? Probably only relevant for 
some artifact types.

5.  Disregarding the "backend" used - is there anything that prevents Glare 
from running in HA active/active mode?

6.  With regards to "backend" - which of the currently supported backends 
is preferable in order to achieve HA active/active mode?

7.  I noticed that there is a puppet-glare[2] project. Can you please share 
the status of that project?

8.  Is there any work being done for creating RPMs for glare?

[1] https://www.youtube.com/watch?v=uBtqdXciF4A
[2] https://github.com/openstack/puppet-glare
[3] https://github.com/openstack-packages


Thanks!


Moshe Elisha,
R Director,
CloudBand Network Director, 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-dev] [nova] Follow up on BCN review cadence discussions

2016-11-07 Thread Matthew Booth

I'd like to follow up on the discussions we had in Barcelona around review
cadence. I took a lot away from these discussions, and I thought they were
extremely productive. I think the summary of the concerns was:

  Nova is a complex beast, very few people know even most of it well.
  There are areas of Nova where mistakes are costly and hard to rectify
later.
  A large amount of good code does not merge quickly.
  The pool of active core reviewers is very much smaller than the total
pool of contributors.
  The barrier to entry for Nova core is very high.

There was more, but I think most people agreed on the above.

Just before summit I pitched a subsystem maintainer model here:

http://lists.openstack.org/pipermail/openstack-dev/2016-September/104093.html

Reading over this again, I still think this is worth trialling: it pushes
the burden of initial detailed review further out, whilst ensuring that a
core will still check that no wider issues have been missed. Bearing in
mind that the primary purpose is to reduce the burden on core reviewers of
any individual patch, I think this will work best if we aggressively push
initial review down as far as possible.

I'm still not sure what the best description of 'domain' is, though. Other
projects seem to have defined this as: the reviewer should, in good faith,
know when they're competent to give a +2 and when they're not. I suspect
this is too loose for us, but I'm sure we could come up with something.

I'd expect the review burden of a maintainer of an active area of code to
be as heavy as a core reviewer's, so this probably shouldn't be taken
lightly. If we were to trial it, I'd also recommend starting with a small
number of maintainers (about 3, perhaps), preferably technical-leaders of
active sub-teams. Any trial should be the topic of a retrospective at the
PTG.

I'd like to re-iterate that what I'd personally like to achieve is:

  "Good code should merge quickly."

There are likely other ways to achieve this, and if any of them are better
than this one then I'm in favour. However, I think we can try this one with
limited risk and initial up-front effort.

Thanks,

Matt
-- 
Matthew Booth
Red Hat Engineering, Virtualisation Team

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

[openstack-dev] [Openstack-operators] [OpenStack-docs] [OpenStack-dev] [docs] Project upgrade notes

2016-11-07 Thread darren chan

Hi everyone,
There was an operations community discussion during the Ocata summit to include 
upgrade notes from the developer documentation in the Operations Guide. The 
spec can be reviewed here:
 https://review.openstack.org/#/c/394261/
Feedback and comments are appreciated!
Thanks,
Darren  __
OpenStack Development Mailing 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] [Karbor] Feel free to add your topic for Karbor Weekly Meeting

2016-11-07 Thread edison xiang

Hi guys,

Karbor weekly meeting will be held at 2016-11-08 0900 UTC
#openstack-meeting.

Please feel free to add your topics here.

https://wiki.openstack.org/wiki/Meetings/Karbor

Thanks very much.


Best Regards,

xiangxinyong
__
OpenStack Development Mailing 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] Newton release this week

2016-11-07 Thread Tomas Sedovic


On 11/06/2016 05:24 PM, James Slagle wrote:

TripleO plans to do an updated Newton release this upcoming week to
pick up the critical fixes that have been backported to stable/newton
since the original Newton release.

My plan as of now is to request the release on Wednesday November 9th.
I'll use this initial patch[1] from Emilien when I do, and update the
respective hash's in that review to be the latest on the newton branch
from each repository.

If there are any concerns, or something that needs to be included in
this release but you don't feel it will have merged by November 9th,
please let me know asap.


Hey James,

This is a fairly important bug for the post-deployment validations:

https://bugs.launchpad.net/tripleo/+bug/1635226

fixed by:

https://review.openstack.org/#/c/391093/
https://review.openstack.org/#/c/390854/

The patches have (imho) been good to go for a few days, but we couldn't 
merge them due to the CI issues.


It would be great if we could get them in the release, too. I'll create 
the backports as soon as they merge in master.


Tomas




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




__
OpenStack Development Mailing 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 Michele Baldessari part of core team

2016-11-07 Thread Dougal Matthews

On 6 November 2016 at 19:54, James Slagle  wrote:

> On Fri, Nov 4, 2016 at 1:40 PM, Emilien Macchi  wrote:
> > MIchele Baldessari (bandini on IRC) has consistently demonstrated high
> > levels of contributions in TripleO projects, specifically in High
> > Availability area where's he's for us a guru (I still don't understand
> > how pacemaker works, but hopefully he does).
> >
> > He has done incredible work on composable services and also on
> > improving our HA configuration by following reference architectures.
> > Always here during meetings, and on #tripleo to give support to our
> > team, he's a great team player and we are lucky to have him onboard.
> > I believe he would be a great core reviewer on HA-related work and we
> > expect his review stats to continue improving as his scope broadens
> > over time.
>
> +1! bandini has been a great resource for all things pacemaker and has
> also shown an ability to branch out and dive into any aspect of
> TripleO.
>

+1


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

Re: [openstack-dev] [Horizon] Can not connect to Openstack Dashboard

2016-11-07 Thread Rob Cresswell (rcresswe)

Hi!

It sounds like there’s nothing wrong with your customisations at all; you’ve 
followed the standard workflow there. I think the final line of the error log 
is key here: "RuntimeError: Unable to create a new session key. It is likely 
that the cache is unavailable.”

Sounds to me something interrupted memcached, or your connection to it. That’s 
where I’d start.

Rob


On 5 Nov 2016, at 10:17, Alioune 
> wrote:

Hi all,

I've installed Openstack Prod env with Fuel and I would like to customize the 
dashboard by using my own logo.png and logo-splash.png.

I've changed all logo and logo-splash in these folders and restarted services 
apache2 and memcached :

/usr/share/openstack-dashboard/openstack_dashboard/themes/vendor/static/img/
/var/lib/openstack-dashboard/static/themes/vendor/img/
/usr/lib/python2.7/dist-packages/openstack_dashboard/static/dashboard/img/
/var/lib/openstack-dashboard/static/dashboard/img/

After that I was able to connect to the dashboard with my customizations but 
few hours after I got the error in [1]. All others openstack services ares 
correctly running in commands lines.

Someone knows what's wrong with my configurations ?
How to customize the horizon to avoid such an error ?

Best Regards,

[1] http://paste.openstack.org/show/588038/

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

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

Re: [openstack-dev] [Horizon][DataTables] how to generate a confirmation dialog

2016-11-07 Thread Timur Sufiev

Hi, John,

the code you're looking for is located here:
https://github.com/openstack/horizon/blob/master/horizon/static/horizon/js/horizon.tables.js#L227-L312
This is bound at
https://github.com/openstack/horizon/blob/master/horizon/static/horizon/js/horizon.forms.js#L368-L373

On Sun, Nov 6, 2016 at 10:32 PM John Calcote  wrote:

> Ping. No thoughts on this from anyone?
>
> On Nov 4, 2016 9:26 PM, "John Calcote"  wrote:
>
> Hi all -
>
> I don't see a better forum anywhere for this post - please correct me
> if I'm wrong.
>
> I have a django/horizon application. On one page users may delete
> objects. I'd like to display a modal dialog confirming the delete
> before submit. Can anyone tell me if there's a way to tie a
> confirmation dialog to a table's DeleteAction?
>
> Note - my template is a trivial table.render with multi-select enabled -
> e.g.,
>
> {% block main %}
> {{ table.render }}
> {% endblock %}
>
> I've searched the docs and the code, but nothing sticks out at me. I'm
> not a client-side expert, but I can usually find my way around in the
> chrome debugger.
>
> Thanks,
> John
>
> __
> OpenStack Development Mailing 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] [mistral] Team meeting - 11/07/2016

2016-11-07 Thread Renat Akhmerov

Hi,

We’ll have a team meeting today at 16.00 UTC.

Agenda:
Review action items
Current status (progress, issues, roadblocks, further plans)
Summit summary
Open discussion

You’re welcome to join us.

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-dev] [networking-vsphere] problem with setup regarding specs

2016-11-07 Thread Odintsov Vladislav

Hi all.


I'm trying to setup test lab on Openstack Mitaka RDO working simultaneously 
with VLAN and VXLAN network types without SDN. I'm trying to setup ESXi as a 
hypervisor (not only ESXi, but it doesn't matter), and I've got troubles.


My setup:

1 controller node (db, keystone, horizon, nova-{api,conductor,schuduler}, 
glance, memcached, rabbit)

1 network node (neutron-server) (hostname: bc01 in logs/examples)

1 vCenter

2 ESXi hosts

2 neutron-ovsvapp-agents (as described on reference scheme: 
https://wiki.openstack.org/wiki/Neutron/Networking-vSphere - one VM per ESXi 
host; hostnames ovsvapp1, ovsvapp2 in logs/examples)

1 nova-compute VM for managing vSphere cluster (hostname: ovsvapp-nova in 
logs/examples).


When I try to spawn VM, I got error "No valid host was found. There are not 
enough hosts available.".

If I look in nova-compute logs, I see traces:


2016-11-07 11:47:12.715 10441 ERROR nova.compute.manager 
[req-1c94993d-69a0-48d7-ac5f-262f99961b16 18db55ec3559448ba25299cb6bd90504 
bb18be7ce13c44a78419769b4feed0fc - - -] Instance failed network setup after 1 
attempt(s)
2016-11-07 11:47:12.715 10441 ERROR nova.compute.manager Traceback (most recent 
call last):
2016-11-07 11:47:12.715 10441 ERROR nova.compute.manager   File 
"/usr/lib/python2.7/site-packages/nova/compute/manager.py", line 1570, in 
_allocate_network_async
2016-11-07 11:47:12.715 10441 ERROR nova.compute.manager 
bind_host_id=bind_host_id)
2016-11-07 11:47:12.715 10441 ERROR nova.compute.manager   File 
"/usr/lib/python2.7/site-packages/nova/network/neutronv2/api.py", line 729, in 
allocate_for_instance
2016-11-07 11:47:12.715 10441 ERROR nova.compute.manager 
self._delete_ports(neutron, instance, created_port_ids)
2016-11-07 11:47:12.715 10441 ERROR nova.compute.manager   File 
"/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 220, in __exit__
2016-11-07 11:47:12.715 10441 ERROR nova.compute.manager 
self.force_reraise()
2016-11-07 11:47:12.715 10441 ERROR nova.compute.manager   File 
"/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 196, in 
force_reraise
2016-11-07 11:47:12.715 10441 ERROR nova.compute.manager 
six.reraise(self.type_, self.value, self.tb)
2016-11-07 11:47:12.715 10441 ERROR nova.compute.manager   File 
"/usr/lib/python2.7/site-packages/nova/network/neutronv2/api.py", line 718, in 
allocate_for_instance
2016-11-07 11:47:12.715 10441 ERROR nova.compute.manager 
security_group_ids, available_macs, dhcp_opts)
2016-11-07 11:47:12.715 10441 ERROR nova.compute.manager   File 
"/usr/lib/python2.7/site-packages/nova/network/neutronv2/api.py", line 305, in 
_create_port
2016-11-07 11:47:12.715 10441 ERROR nova.compute.manager raise 
exception.PortBindingFailed(port_id=port_id)
2016-11-07 11:47:12.715 10441 ERROR nova.compute.manager PortBindingFailed: 
Binding failed for port ef43e4f0-4db7-405c-b4d5-c621aaa3884b, please check 
neutron logs for more information.
2016-11-07 11:47:12.715 10441 ERROR nova.compute.manager
2016-11-07 11:47:12.716 10441 ERROR nova.compute.manager 
[req-1c94993d-69a0-48d7-ac5f-262f99961b16 18db55ec3559448ba25299cb6bd90504 
bb18be7ce13c44a78419769b4feed0fc - - -] [instance: 
5ea7de1b-06a2-4ba1-8f54-d00203496f2a] Instance failed to spawn
2016-11-07 11:47:12.716 10441 ERROR nova.compute.manager [instance: 
5ea7de1b-06a2-4ba1-8f54-d00203496f2a] Traceback (most recent call last):
2016-11-07 11:47:12.716 10441 ERROR nova.compute.manager [instance: 
5ea7de1b-06a2-4ba1-8f54-d00203496f2a]   File 
"/usr/lib/python2.7/site-packages/nova/compute/manager.py", line 2218, in 
_build_resources
2016-11-07 11:47:12.716 10441 ERROR nova.compute.manager [instance: 
5ea7de1b-06a2-4ba1-8f54-d00203496f2a] yield resources
2016-11-07 11:47:12.716 10441 ERROR nova.compute.manager [instance: 
5ea7de1b-06a2-4ba1-8f54-d00203496f2a]   File 
"/usr/lib/python2.7/site-packages/nova/compute/manager.py", line 2064, in 
_build_and_run_instance
2016-11-07 11:47:12.716 10441 ERROR nova.compute.manager [instance: 
5ea7de1b-06a2-4ba1-8f54-d00203496f2a] block_device_info=block_device_info)
2016-11-07 11:47:12.716 10441 ERROR nova.compute.manager [instance: 
5ea7de1b-06a2-4ba1-8f54-d00203496f2a]   File 
"/usr/lib/python2.7/site-packages/nova/virt/vmwareapi/driver.py", line 381, in 
spawn
2016-11-07 11:47:12.716 10441 ERROR nova.compute.manager [instance: 
5ea7de1b-06a2-4ba1-8f54-d00203496f2a] admin_password, network_info, 
block_device_info)
2016-11-07 11:47:12.716 10441 ERROR nova.compute.manager [instance: 
5ea7de1b-06a2-4ba1-8f54-d00203496f2a]   File 
"/usr/lib/python2.7/site-packages/nova/virt/vmwareapi/vmops.py", line 724, in 
spawn
2016-11-07 11:47:12.716 10441 ERROR nova.compute.manager [instance: 
5ea7de1b-06a2-4ba1-8f54-d00203496f2a] metadata)
2016-11-07 11:47:12.716 10441 ERROR nova.compute.manager [instance: 
5ea7de1b-06a2-4ba1-8f54-d00203496f2a]   File 
"/usr/lib/python2.7/site-packages/nova/virt/vmwareapi/vmops.py", line 304, in

Re: [openstack-dev] [vote] Re: [kolla] Propose removal of TrivialFix requirement

2016-11-07 Thread Martin André

On Sun, Nov 6, 2016 at 7:52 PM, Steven Dake (stdake)  wrote:
> This may have got lost in the noise of the last few days of ml.  As a
> result, I am tagging with [vote].  I currently count 7 +1’s but again – lots
> of mailing list traffic so I may be off on my counting.
>
>
>
> For all core reviewers:
>
> In the future to help inc0 out with tallying the votes for votes core
> reviewers propose, please tag the email with [vote].
>
>
>
> Regards
>
> -steve
>
>
>
>
>
> From: Paul Bourke 
> Reply-To: "OpenStack Development Mailing List (not for usage questions)"
> 
> Date: Thursday, November 3, 2016 at 6:21 AM
> To: "OpenStack Development Mailing List (not for usage questions)"
> 
> Subject: [openstack-dev] [kolla] Propose removal of TrivialFix requirement
>
>
>
> Kolleagues,
>
>
>
> How do people feel above removing the requirement of having TrivialFix
>
> in commit messages where a bug/bp is not required?
>
>
>
> I'm seeing a lot of valid and important commits being held up because of
>
> this, in my opinion, unnecessary requirement. It also causes friction
>
> for new contributers to the project.
>
>
>
> Are there any major benefits we're getting from the use of this tag that
>
> I'm missing?

This is my feeling as well. The tag really should only be used as an
indication given to the reviewers rather than as a way to enforce a
policy where all commits should have tags.

+1 for not requiring a TrivialFix tag in the commit message where
there is no related bp/bug.

Martin

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

2016-11-07 Thread Hugh Blemings


Hi,

In this weeks Lwood I've begun the process of listing the summaries from 
Barcelona;


http://hugh.blemings.id.au/2016/11/07/lwood-20161106/

If (as I expect) more summaries come through I'll create a standalone 
blog post which will contain all of them as I did for Austin [1]


Both are/will appear on planet.openstack.org too.

Cheers,
Hugh



[1] 
http://hugh.blemings.id.au/2016/05/17/openstack-summit-austin-2016-summary-of-summaries/


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

85 matches

Mail list logo