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

[Robert Collins]

On 10 November 2016 at 11:00, Tony Breeds  wrote:
> On Thu, Nov 10, 2016 at 06:17:44AM +1300, Robert Collins wrote:
>> Sed doesn't exist on windows, whereas a python script can. Sed doesn't
>> handle multiple line constraints.
>
> I don't think that right now we care/handle multiline constraints but the
> windows think is important and not something I considered.

We generate multiline constraints whenever versions are different
between python 2 and 3 for the same package. That was happening when I
wrote the tool in the first place - it was one of the reasons I wrote
edit-constraints, to avoid writing silly-awkward sed. (A multiline
constraint when sedd'd will error with 'requirement already supplied'
or whatever the pip error string is.

> I think the way forward is to get openstack_requirements on pypi so we can 
> just
> pip install openstack_requirements.
>
> That'd make the script simple and still retain the cross-platform'ness needed.

Yes. And/or do the long mooted refactoring to separate out the scripts
from the current constraints and requirements.

-Rob

__
OpenStack Development Mailing 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] [lbaas] [octavia] Ocata LBaaS retrospective and next steps recap

[Gary Kotton]

Will the same DB be maintained or will the LBaaS DB be moved to that of 
Octavia. I am really concerned about this and I feel that it will cause 
production problems.

From: Kevin Benton 
Reply-To: OpenStack List 
Date: Wednesday, November 9, 2016 at 11:43 PM
To: OpenStack List 
Subject: Re: [openstack-dev] [neutron] [lbaas] [octavia] Ocata LBaaS 
retrospective and next steps recap

The people working on the migration are ensuring API compatibility and are even 
leaving in a shim on the Neutron side for some time so you don't even have to 
change endpoints initially. It should be a seamless change.

On Wed, Nov 9, 2016 at 12:28 PM, Fox, Kevin M 
mailto:kevin@pnnl.gov>> wrote:
Just please don't make this a lbv3 thing that completely breaks compatibility 
of existing lb's yet again. If its just an "point url endpoint from thing like 
x to thing like y" in one place, thats ok. I still have v1 lb's in existence 
though I have to deal with and a backwards incompatible v3 would just cause me 
to abandon lbaas all together I think as it would show the lbaas stuff is just 
not maintainable.

Thanks,
Kevin

From: Armando M. [arma...@gmail.com]
Sent: Wednesday, November 09, 2016 8:05 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron] [lbaas] [octavia] Ocata LBaaS 
retrospective and next steps recap


On 9 November 2016 at 05:50, Gary Kotton 
mailto:gkot...@vmware.com>> wrote:
Hi,
What about neutron-lbaas project? Is this project still alive and kicking to 
the merge is done or are we going to continue to maintain it? I feel like we 
are between a rock and a hard place here. LBaaS is in production and it is not 
clear the migration process. Will Octavia have the same DB models as LBaaS or 
will there be a migration?
Sorry for the pessimism but I feel that things are very unclear and that we 
cannot even indicate to our community/consumers what to use/expect.
Thanks
Gary

http://specs.openstack.org/openstack/neutron-specs/specs/newton/kill-neutron-lbaas.html


On 11/8/16, 1:36 AM, "Michael Johnson" 
mailto:johnso...@gmail.com>> wrote:

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

[openstack-dev] [ironic][ironic-python-agent]code-review about this commit https://review.openstack.org/#/c/369245/

[zhou . ya]

Hi ironic team：

I send this email to ask something about 
https://review.openstack.org/#/c/369245/ .

The jenkins has +1 for this commit.I hope you could spare some time to 
give me some advice of this commit.

If it looks good to you，could you please do the workflow？

Thank you very much.

Looking forward for your response.
Regards
zhouya
__
OpenStack Development Mailing 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] vendordata v2 ocata summit recap

[Michael Still]

This is a good summary, thanks. I finally uploaded the spec which describes
the decisions from the summit. Its here:

https://review.openstack.org/395959

Michael

On Thu, Nov 10, 2016 at 7:11 AM, Matt Riedemann 
wrote:

> Michael Still led a session on completing the vendordata v2 work that was
> started in the Newton release. The full etherpad is here:
>
> https://etherpad.openstack.org/p/ocata-nova-summit-vendoradatav2
>
> Michael started by advertising a bit what it is since it's a new feature
> and it's meant to replace the old class-path loading way of getting vendor
> metadata (and ultimately allows us to remove hooks).
>
> The majority of the session was spent discussing a gap we have in
> providing token information on the request to the vendordata server.
>
> For example, when creating a server we have a user content and token and
> can provide that information to the vendordata REST API, but on subsequent
> GETs from the guest itself we don't have a token. After quite a bit of
> discussion in the room, including with Adam and Dolph from the keystone
> team, we decided to:
>
> 1. Stash the user's roles from the initial create in the nova database and
> re-use those on subsequent GET requests.
>
> 2. Use a service token to pass the other information to the vendordata v2
> REST API so that it knows the request is coming from Nova. This was
> considered a bug fix and not a new feature so we can backport the
> functionality.
>
> Other things that are needed at some point:
>
> 1. Add some caching of the response using the Cache-Control header.
>
> 2. Add a configuration option to toggle whether or not the server create
> should fail if a vendordata response is not 200. Today if we get a non-200
> response we log a warning and return {} to the caller. Some vendordata
> scenarios require that the metadata get into the guest as soon as it's
> created or else it becomes essentially a zombie and cleaning it up later is
> painful. So provide an option to fail that server create if we can't get
> the necessary data into the guest on server create. Note that this would
> only fail the server build if using config drive since nova is the caller.
> When cloud-init is making the request from within the guest, nova has lost
> control at that point and any failures are going to have to be cleaned up
> separately.
>
> --
>
> 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
>



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

Re: [openstack-dev] [new][keystone] keystonemiddleware 2.3.4 release (liberty)

[Tony Breeds]

On Thu, Nov 10, 2016 at 01:10:45AM +, no-re...@openstack.org wrote:
> We are grateful to announce the release of:
> 
> keystonemiddleware 2.3.4: Middleware for OpenStack Identity
> 
> This release is part of the liberty stable release series.

Actually this release didn't happen the mail was generated as an unintended
side-effect of some yaml edits inside the releases repo.

https://review.openstack.org/#/q/topic:move-release-tags-out-of-gov

Sorry for the noise

Tony.


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] [new][keystone] keystoneauth1 1.1.3 release (liberty)

[Tony Breeds]

On Thu, Nov 10, 2016 at 01:10:18AM +, no-re...@openstack.org wrote:
> We are glad to announce the release of:
> 
> keystoneauth1 1.1.3: Authentication Library for OpenStack Identity
> 
> This release is part of the liberty stable release series.

Actually this release didn't happen the mail was generated as an unintended
side-effect of some yaml edits inside the releases repo.

https://review.openstack.org/#/q/topic:move-release-tags-out-of-gov

Sorry for the noise

Tony.


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] [release] change in plan for releases repo data model updates

[Rochelle Grober]

Sorry for top posting, but exchange

Automation is our friend.  Define the structure/naming of the release repo 
patches such that when they merge, they auto generate the governance patch and 
submit it.  It gives you time to run a cycle and see how things work and what a 
more elegant solution might be.

my $.02

--Rocky

-Original Message-
From: Thierry Carrez [mailto:thie...@openstack.org] 
Sent: Wednesday, November 09, 2016 5:13 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [release] change in plan for releases repo data 
model updates

Doug Hellmann wrote:
> At the summit we said we would move the data that tells us the type
> and release model for each deliverable out of the governance
> repository and into the releases repository where it is easier to
> change over time, but that we needed to think more about what might
> break by making that change. After giving it more consideration, I
> think we have to use the option 2 we discussed instead (allow local
> values to override the global values).

If we look back at the goals driving the change, this solves the
"temporarily bypass governance values" need. The main drawback (to me)
is that we continue to consider deliverable types and release model to
be a "governance" thing. Another drawback is the additional work needed
to sync changes back into the governance repo (see Tony's question).

> The list-repos command would not be able to filter on the type or
> model values early in a cycle because not enough deliverable files
> would even exist until the first milestone. That limitation would
> make the command essentially useless until close to the end of each
> cycle. Using option 2 means list-repos would continue to work all the
> time.

Devil's advocate, we could copy over the type/model values from the
previous cycle as part of the new cycle opening, and have list-repos
work all the time. That sounds like less work than tracking the
retrosyncing of each and every override back onto the governance repo...

> Using option 2 also means that instead of us having to do extra
> work to build and publish a single unified file for the project
> navigator team, they can continue to use the same input data without
> changes to their project at all.

That's a one-time work, so I don't think having to do that is unreasonable.

> I propose adding "type" and "model" fields, as we discussed, but
> making them optional. If they are not present, the values can be
> derived from the governance tags for the deliverable. Teams who
> want to change either value can then make the update in the releases
> repository with a separate patch to update the governance repo, and
> not have releases blocked by the governance change.

It feels like extra work overall. More work for teams (having to file
two separate patches) and more work for us to make sure that governance
patch is merged, doesn't slip through the cracks and doesn't introduce a
drift between the two repos.

So... not convinced :)

-- 
Thierry Carrez (ttx)

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

__
OpenStack Development Mailing 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] [manila] Barcelona Design Summit summary

[Ben Swartzlander]

On 11/04/2016 02:00 PM, Joshua Harlow wrote:

Ben Swartzlander wrote:

Thanks to gouthamr for doing these writeups and for recording!

We had a great turn out at the manila Fishbowl and working sessions.
Important notes and Action Items are below:

===
Fishbowl 1: Race Conditions
===
Thursday 27th Oct / 11:00 - 11:40 / AC Hotel -Salon Barcelona - P1
Etherpad: https://etherpad.openstack.org/p/ocata-manila-race-conditions
Video: https://www.youtube.com/watch?v=__P7zQobAQw

Gist:
* We've some race conditions that have worsened over time:
* Deleting a share while snapshotting the share
* Two simultaneous delete-share calls
* Two simultaneous create-snapshot calls
* Though the end result of the race conditions is not terrible, we can
leave resources in untenable states, requiring administrative cleanup in
the worst scenario
* Any type of resource interaction must be protected in the database
with a test-and-set using the appropriate status fields
* Any test-and-set must be protected with a lock
* Locks must not be held over long running tasks: i.e, RPC Casts, driver
invocations etc.
* We need more granular state transitions: micro/transitional states
must be added per resource and judiciously used for state locking
* Ex: Shares need a 'snapshotting' state
* Ex: Share servers need states to signify setup phases, a la nova
compute instances


Just something that I've always wondered, and I know its not a easy
answer, but are there any ideas on why such simultaneous issues keep on
getting discovered so late in the software lifecycle, instead of at
design time? Not probably just a manilla question, but it strikes me as
somewhat confusing that keeps on popping up.


In the case of Manila the reason is historical. Manila forked from 
Cinder, and Cinder forked from Nova-Volume. Each inherited 
infrastructure and design choices, as well as design *assumptions* which 
didn't always remain true after the forks.


The basic problem is that the people who wrote (some of) the original 
code are no longer around and new people often assume that old stuff 
isn't broken, even when it is. Issues like concurrency problems can lay 
dormant for a long time before they pop up because they're hard to test.



Discussion Item:
* Locks in the manila-api service (or specifically, extending usage of
locks across all manila services)
* Desirable because:
* Adding test-and-set logic at the database layer may render code
unmaintainable complicated as opposed to using locking abstractions
(oslo.concurrency / tooz)
* Cinder has evolved an elegant test-and-set solution but we may not be
able to benefit from that implementation because of the lack of being
able to do multi-table updates and because the code references OVO which
manila doesn't yet support.
* Un-desirable because:
* Most distributors (RedHat/Suse/Kubernetes-based/MOS) want to run more
than one API service in active-active H/A.
* If a true distributed locking mechanism isn't used/supported, the
current file-locks would be useless in the above scenario.
* Running file locks on shared file systems is a possibility, but
applies configuration/set-up burden
* Having all the locks on the share service would allow scale out of the
API service and the share manager is really the place where things are
going wrong
* With a limited form of test-and-set, atomic state changes can still be
achieved for the API service.

Agreed:
* File locks will not help

Action Items:
(bswartz): Will propose a spec for the locking strategy
(volunteers): Act on the spec ^ and help add more transitional states
and locks (or test-and-set if any)
(gouthamr): state transition diagrams for shares/share
instances/replicas, access rules / instance access rules
(volunteers): Review ^ and add state transition diagrams for
snapshots/snapshot instances, share servers
(mkoderer): will help with determining race conditions within
manila-share with tests

=
Fishbowl 2: Data Service / Jobs Table
=
Thursday 27th Oct / 11:50 - 12:30 / AC Hotel - Salon Barcelona - P1
Etherpad:
https://etherpad.openstack.org/p/ocata-manila-data-service-jobs-table
Video: https://www.youtube.com/watch?v=Sajy2Qjqbmk


Will https://review.openstack.org/#/c/260246/ help here instead?

It's the equivalent of:

http://docs.openstack.org/developer/taskflow/jobs.html

Something to think about...



Gist:
* Currently, a synchronous RPC call is made from the API to the
share-manager/data-service that's performing a migration to get the
progress of a migration
* We need a way to record progress of long running tasks: migration,
backup, data copy etc.
* We need to introduce a jobs table so that the respective service
performing the long running task can write to the database and the API
relies on the database

Discussion Items:
* There was a suggestion to extend the jobs table to all tasks on the
share: snapshotting, creating share from s

[openstack-dev] [nova][cinder] nova/cinder cross-project ocata summit session recap

[Matt Riedemann]

On Thursday at the summit the Cinder team had a session about the 
proposed volume attach/detach API changes that John Griffith is working 
on. The etherpad for that session is here:


https://etherpad.openstack.org/p/ocata-nova-summit-cinder-session

On Friday we had a joint nova/cinder session to go over the proposals 
and POCs with the larger teams. The etherpad for that session is here:


https://etherpad.openstack.org/p/ocata-nova-summit-cinder-session

John Griffith has been working on two different versions of adding a new 
series of APIs that deal with attachment CRUD operations which nova 
would plan on using, and which should also help ease in the support for 
volume multiattach.


John's first iteration on this is slightly closer to what we already 
have today, but with Cinder storing more information (like the host 
connector and connection_info) and providing more information to Nova 
like whether or not a connection is shared - which varies based on the 
Cinder backend. That version still relies on nova to reserve (lock) the 
volume in nova-api before casting to nova-compute to create the 
attachment and connect it on the host using os-brick.


John is working on a second POC here:

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

That is slightly different and might eliminate the need for nova to call 
both os-reserve and create_attachment. Ideally nova gets to the point of 
simply creating the attachment (which locks the volume) in nova-api, 
then in nova-compute nova will update the attachment with the host 
connector (from os-brick) and then connect the volume on the host (using 
os-brick). If anything fails, nova would delete the attachment record in 
Cinder, thus unlocking the volume (like detach, terminate-connection and 
unreserve today).


One of the main issues we're still trying to sort out is nova knowing 
when it's safe to disconnect an attachment, mainly in the case of shared 
storage backends. We could have a race where nova is getting a 
connection count from cinder which basically says it's safe to 
disconnect from the host because it's the only connection (A), but 
meanwhile another request creates an attachment (B) and when nova 
disconnects A is also disconnects B. We think that we can work through 
this with a lock in nova so that you can't be attaching with a shared 
connection on a host at the same time that the shared connection is 
being detached from that host.


We also need to sort out the live migration flow where you have a 
non-multiattach volume but you're using it to create two connections for 
the same instance but on different hosts. There would most likely need 
to be some logic in the Cinder API to allow this, since otherwise 
normally you can't have more than one attachment to a non-multiattach 
volume. Supporting this, though, would make the volume-backed live 
migration flow in Nova quite simple, and would be similar to how 
Nova/Neutron plan to handle multiple port bindings during live migration.


With respect to upgrades, we haven't gotten too in-depth into that yet. 
With the proposed flows Nova would be tracking an attachment_id in the 
block_device_mappings for an instance. Nova may or may not be storing 
the connection_info anymore since Cinder would store that and Nova can 
just get it via the attachment record. But as part of an upgrade we'd 
likely need to migrate old existing BDM records to create an attachment 
record in Cinder and then store that in the nova BDM. It's TBD on if 
something like that could happen with a nova-manage command, or if it 
would be more of an online migration when operations are performed on 
older volumes.


The nova side flows with all of this are detailed in John Garbutt's nova 
spec here:


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

We're still having weekly nova/cinder cross-project meetings at 1700 UTC 
on Mondays:


http://eavesdrop.openstack.org/#Cinder,_Nova

And have started doing those with Google Hangouts to speed along the 
discussion. Ildikov has been taking notes during the IRC meeting though 
so the minutes/highlights are tracked in case the hangout isn't recorded.


All in all we are making progress, slowly but surely, on the design and 
working through some of the edge cases. If we can come to an agreement 
on the overall workflow early enough in Ocata then it might be possible 
to get the Cinder API changes in and then the Nova side can possibly get 
landed in Pike. However, given the Cinder team's focus on technical debt 
and stability for Ocata it might be a stretch. Either way, having an 
agreed on design and POC code by the end of Ocata would be a major 
accomplishment and greatly help getting volume multiattach supported in 
Pike.


--

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

Re: [openstack-dev] [kolla] How tied is kolla to matching 1:1 releases of openstack?

[Joshua Harlow]

Fox, Kevin M wrote:

currently one to one on kolla version and openstack release. so 2.0.x is 
mitaka. 3.0.x is newton.

I think if we continue forward with the helm idea it will simplify the use case 
too. as you can then match up a k8s package (with its templates) for a mitaka 
resource with the mitaka containers. So there shouldn't need to be conditional 
logic in the templates.

Thanks,
Kevin



Right cool, I'm not yet looking into the k8s+kolla stuffs,

More of just trying to get the docker images built and used and 
wondering some of these questions; I'm sure adding in k8s would help, 
but is probably not something that I could easily pull-off because we 
have existing clouds that have been running afaik before even k8s 
existed, ha. So starting at ground-zero (with just the images that get 
built).


-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] [new][keystone] keystonemiddleware 2.3.4 release (liberty)

[no-reply]

We are grateful to announce the release of:

keystonemiddleware 2.3.4: Middleware for OpenStack Identity

This release is part of the liberty stable release series.

The source is available from:

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

Download the package from:

https://tarballs.openstack.org/keystonemiddleware/

Please report issues through launchpad:

http://bugs.launchpad.net/keystonemiddleware

For more details, please see below.

Changes in keystonemiddleware 2.3.3..2.3.4
--

f9cb1e4 Updated from global requirements
e61a4cd Updated from global requirements
5277ce7 Remove bandit.yaml in favor of defaults


Diffstat (except docs and test files)
-

bandit.yaml   | 134 --
keystonemiddleware/audit.py   |  13 ++-
keystonemiddleware/auth_token/__init__.py |   4 +-
keystonemiddleware/auth_token/_request.py |   3 +-
keystonemiddleware/echo/__main__.py   |   3 +-
requirements.txt  |   4 +-
tox.ini   |  10 ++-
7 files changed, 23 insertions(+), 148 deletions(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index 4d39b22..a2710b6 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -5 +5 @@
-Babel>=1.3
+Babel!=2.3.0,!=2.3.1,!=2.3.2,!=2.3.3,>=1.3 # BSD
@@ -13 +13 @@ pycadf>=1.1.0
-python-keystoneclient!=1.8.0,>=1.6.0
+python-keystoneclient!=1.8.0,<3.0.0,>=1.6.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

[openstack-dev] [new][keystone] keystoneauth1 1.1.3 release (liberty)

[no-reply]

We are glad to announce the release of:

keystoneauth1 1.1.3: Authentication Library for OpenStack Identity

This release is part of the liberty stable release series.

The source is available from:

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

Download the package from:

https://tarballs.openstack.org/keystoneauth1/

Please report issues through launchpad:

http://bugs.launchpad.net/keystoneauth

For more details, please see below.

Changes in keystoneauth1 1.1.2..1.1.3
-

aa122e7 Swap the order of username deprecation


Diffstat (except docs and test files)
-

keystoneauth1/loading/_plugins/identity/generic.py | 5 ++---
keystoneauth1/loading/_plugins/identity/v2.py  | 7 +++
keystoneauth1/loading/_plugins/identity/v3.py  | 5 ++---
4 files changed, 8 insertions(+), 11 deletions(-)




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

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

[Michael Johnson]

Kevin,

Yep, totally understand.

This is not a V3, it is simply moving the API from running under
neutron to running under the octavia API process.  It will still be
the LBaaSv2 API, just a new endpoint (though the old endpoint will
work for some time into the future).

Michael

On Wed, Nov 9, 2016 at 12:28 PM, Fox, Kevin M  wrote:
> Just please don't make this a lbv3 thing that completely breaks
> compatibility of existing lb's yet again. If its just an "point url endpoint
> from thing like x to thing like y" in one place, thats ok. I still have v1
> lb's in existence though I have to deal with and a backwards incompatible v3
> would just cause me to abandon lbaas all together I think as it would show
> the lbaas stuff is just not maintainable.
>
> Thanks,
> Kevin
> 
> From: Armando M. [arma...@gmail.com]
> Sent: Wednesday, November 09, 2016 8:05 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [neutron] [lbaas] [octavia] Ocata LBaaS
> retrospective and next steps recap
>
>
>
> On 9 November 2016 at 05:50, Gary Kotton  wrote:
>>
>> Hi,
>> What about neutron-lbaas project? Is this project still alive and kicking
>> to the merge is done or are we going to continue to maintain it? I feel like
>> we are between a rock and a hard place here. LBaaS is in production and it
>> is not clear the migration process. Will Octavia have the same DB models as
>> LBaaS or will there be a migration?
>> Sorry for the pessimism but I feel that things are very unclear and that
>> we cannot even indicate to our community/consumers what to use/expect.
>> Thanks
>> Gary
>
>
> http://specs.openstack.org/openstack/neutron-specs/specs/newton/kill-neutron-lbaas.html
>
>>
>>
>> On 11/8/16, 1:36 AM, "Michael Johnson"  wrote:
>>
>> 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
>>
>>
>> __
>> OpenStack Developm

Re: [openstack-dev] [kolla] How tied is kolla to matching 1:1 releases of openstack?

[Fox, Kevin M]

currently one to one on kolla version and openstack release. so 2.0.x is 
mitaka. 3.0.x is newton.

I think if we continue forward with the helm idea it will simplify the use case 
too. as you can then match up a k8s package (with its templates) for a mitaka 
resource with the mitaka containers. So there shouldn't need to be conditional 
logic in the templates.

Thanks,
Kevin

From: Joshua Harlow [harlo...@fastmail.com]
Sent: Wednesday, November 09, 2016 1:59 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [kolla] How tied is kolla to matching 1:1 releases 
of openstack?

Fox, Kevin M wrote:
> I think its kind of in the same vein as the rest of the openstack services. 
> It might, (and probably will) work with n-1&  n services in the same system. 
> But it all depends on either:
> 1. The things that are actually tested
> or
> 2. Luck
>
> I've been testing the kolla-kubernetes deployment tools with 2.0.x containers 
> and 3.0.x containers, so those should work. any other combination might work 
> but I no idea if they actually will work as its untested.
>
> More gate testing would help and be welcome. :)
>
> Thanks,
> Kevin

Agreed on gate testing, I'm just not sure the general direction people
would want. I've done cross n-1 and n and n-2 and such and jinja2
templates start to have a bunch of if conditions to handle specific
releases peculiarities.

As far as 2.0.x containers and 3.0.x containers, what version of
openstack projects compose 2.0.x, is there a mapping of something like:

3.0.x:
   - nova:
  branches_supported: [stable/newton]
   - glance:
  branches_supported: [stable/newton, stable/mitaka]


Or is it just assumed that the mapping is sorta known? Unsure quite how
to correlate a given kolla release to what underlying projects it can
build into images or deploy or manage (is this online somewhere, or do I
just have to dig through the code) :-P

-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 Development Mailing 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] [lbaas] [octavia] Ocata LBaaS retrospective and next steps recap

[Fox, Kevin M]

Ok. cool. thanks. :)

Kevin

From: Kevin Benton [ke...@benton.pub]
Sent: Wednesday, November 09, 2016 1:43 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron] [lbaas] [octavia] Ocata LBaaS 
retrospective and next steps recap

The people working on the migration are ensuring API compatibility and are even 
leaving in a shim on the Neutron side for some time so you don't even have to 
change endpoints initially. It should be a seamless change.

On Wed, Nov 9, 2016 at 12:28 PM, Fox, Kevin M 
mailto:kevin@pnnl.gov>> wrote:
Just please don't make this a lbv3 thing that completely breaks compatibility 
of existing lb's yet again. If its just an "point url endpoint from thing like 
x to thing like y" in one place, thats ok. I still have v1 lb's in existence 
though I have to deal with and a backwards incompatible v3 would just cause me 
to abandon lbaas all together I think as it would show the lbaas stuff is just 
not maintainable.

Thanks,
Kevin

From: Armando M. [arma...@gmail.com]
Sent: Wednesday, November 09, 2016 8:05 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron] [lbaas] [octavia] Ocata LBaaS 
retrospective and next steps recap



On 9 November 2016 at 05:50, Gary Kotton 
mailto:gkot...@vmware.com>> wrote:
Hi,
What about neutron-lbaas project? Is this project still alive and kicking to 
the merge is done or are we going to continue to maintain it? I feel like we 
are between a rock and a hard place here. LBaaS is in production and it is not 
clear the migration process. Will Octavia have the same DB models as LBaaS or 
will there be a migration?
Sorry for the pessimism but I feel that things are very unclear and that we 
cannot even indicate to our community/consumers what to use/expect.
Thanks
Gary

http://specs.openstack.org/openstack/neutron-specs/specs/newton/kill-neutron-lbaas.html


On 11/8/16, 1:36 AM, "Michael Johnson" 
mailto:johnso...@gmail.com>> wrote:

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

[openstack-dev] [valence] Valence week IRC meeting is at Wednesdays, 15:00 HRS UTC

[Bhandaru, Malini K]

USA folks, remember we have daylight savings time in effect now. So one hour 
earlier.

Regards,
Malini

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

Re: [openstack-dev] [kolla][kubernetes]kolla-kubernetes achitectures spec

[Ryan Hallisey]

Forgot to include the link to the spec :)

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

Thanks,
Ryan

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

[openstack-dev] [glance] spec proposal freeze

[Brian Rosmaita]

Just a friendly reminder that the Glance Spec Proposal Freeze is imminent:
All Glance, python-glanceclient, and glance_store specs must be proposed
as patches to the glance-specs repository by 23:59 UTC on Thursday 10
November 2016.

The purpose of the proposal freeze is to allow sufficient time for the
specs to be reviewed, revised, and merged before the Spec Freeze on Friday
25 November at 23:59 UTC.

cheers,
brian


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

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

[Tony Breeds]

On Wed, Nov 09, 2016 at 12:00:27PM +0100, Ihar Hrachyshka wrote:

> I believe sed is the way to go. There is not much we get from
> edit-constraints at this point, and it untangles the script from zuul-cloner
> that would be needed to fetch requirements repo.
> 
> It seems like the way to go. Wanna propose a patch for a repo
> (oslo.messaging) to iterate on it in gerrit?

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

Yours Tony.


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

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

[Tony Breeds]

On Thu, Nov 10, 2016 at 06:17:44AM +1300, Robert Collins wrote:
> Sed doesn't exist on windows, whereas a python script can. Sed doesn't
> handle multiple line constraints.

I don't think that right now we care/handle multiline constraints but the
windows think is important and not something I considered.

I think the way forward is to get openstack_requirements on pypi so we can just
pip install openstack_requirements.

That'd make the script simple and still retain the cross-platform'ness needed.

Yours Tony.


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] [kolla] How tied is kolla to matching 1:1 releases of openstack?

[Joshua Harlow]

Fox, Kevin M wrote:

I think its kind of in the same vein as the rest of the openstack services. It 
might, (and probably will) work with n-1&  n services in the same system. But 
it all depends on either:
1. The things that are actually tested
or
2. Luck

I've been testing the kolla-kubernetes deployment tools with 2.0.x containers 
and 3.0.x containers, so those should work. any other combination might work 
but I no idea if they actually will work as its untested.

More gate testing would help and be welcome. :)

Thanks,
Kevin


Agreed on gate testing, I'm just not sure the general direction people 
would want. I've done cross n-1 and n and n-2 and such and jinja2 
templates start to have a bunch of if conditions to handle specific 
releases peculiarities.


As far as 2.0.x containers and 3.0.x containers, what version of 
openstack projects compose 2.0.x, is there a mapping of something like:


3.0.x:
  - nova:
 branches_supported: [stable/newton]
  - glance:
 branches_supported: [stable/newton, stable/mitaka]


Or is it just assumed that the mapping is sorta known? Unsure quite how 
to correlate a given kolla release to what underlying projects it can 
build into images or deploy or manage (is this online somewhere, or do I 
just have to dig through the code) :-P


-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

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

[Kevin Benton]

The people working on the migration are ensuring API compatibility and are
even leaving in a shim on the Neutron side for some time so you don't even
have to change endpoints initially. It should be a seamless change.

On Wed, Nov 9, 2016 at 12:28 PM, Fox, Kevin M  wrote:

> Just please don't make this a lbv3 thing that completely breaks
> compatibility of existing lb's yet again. If its just an "point url
> endpoint from thing like x to thing like y" in one place, thats ok. I still
> have v1 lb's in existence though I have to deal with and a backwards
> incompatible v3 would just cause me to abandon lbaas all together I think
> as it would show the lbaas stuff is just not maintainable.
>
> Thanks,
> Kevin
> --
> *From:* Armando M. [arma...@gmail.com]
> *Sent:* Wednesday, November 09, 2016 8:05 AM
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* Re: [openstack-dev] [neutron] [lbaas] [octavia] Ocata LBaaS
> retrospective and next steps recap
>
>
>
> On 9 November 2016 at 05:50, Gary Kotton  wrote:
>
>> Hi,
>> What about neutron-lbaas project? Is this project still alive and kicking
>> to the merge is done or are we going to continue to maintain it? I feel
>> like we are between a rock and a hard place here. LBaaS is in production
>> and it is not clear the migration process. Will Octavia have the same DB
>> models as LBaaS or will there be a migration?
>> Sorry for the pessimism but I feel that things are very unclear and that
>> we cannot even indicate to our community/consumers what to use/expect.
>> Thanks
>> Gary
>>
>
> http://specs.openstack.org/openstack/neutron-specs/specs/
> newton/kill-neutron-lbaas.html
>
>
>>
>> On 11/8/16, 1:36 AM, "Michael Johnson"  wrote:
>>
>> 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/ne
>> wton/kill-neutron-lbaas.html
>> [2] https://etherpad.openstack.org/p/ocata-neutron-octavia-lbaas
>> -session
>> [3] https://specs.openstack.org/openstack/neutron-specs/specs/mi
>> taka/neutron-flavor-framework-templates.html
>> [4] https://specs.openstack.org/openstack/neutron-specs/specs/li
>> berty/neutron-flavor-framework.html
>>
>> 
>> __
>> 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 que

[openstack-dev] Sharing Cloudkitty Mascot

[Christophe Sauthier]

Hello developer mailing list folks,

Like every other project in OpenStack, Cloudkitty has also received a 
draft logo.


While that mascot has been widely shared amonsgt the other member of 
the Cloudkitty's community, I thought that some developpers from other 
teams migth be happy to have a look at thay great work...


I hope you'll enjoy it as much as we did.

All the best

  Christophe

Christophe Sauthier   Mail : 
christophe.sauth...@objectif-libre.com

CEO   Mob : +33 (0) 6 16 98 63 96
Objectif LibreURL : www.objectif-libre.com
Au service de votre Cloud Twitter : @objectiflibre

Suivez les actualités OpenStack en français en vous abonnant à la Pause 
OpenStack

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

[openstack-dev] [TripleO] dhclient spawned by dhcp-all-interfaces doesn't exit when os-net-config runs

[Dan Sneddon]

I just opened a bug [1] for behavior which has recently been observed
when deploying nodes with TripleO. The problem is that the dhclient
processes that are being started by the dhcp-all-interfaces element in
disk-image-builder are not stopping after os-net-config runs.

Step 1) Image deploys with udev rule to create
dhcp-interface@.service, which configures each interface via DHCP.

Step 2) The deployment scripts run, including os-net-config, which
configures and restarts the interfaces. The udev rule is removed.

At this point, the dhclient which was created by the udev rule is no
longer needed, except it is still running and configuring IP and routes
on the interface, possibly in conflict with the desired configuration.
For instance, the same IP appearing on a bridge and on an interface, or
a rogue default route and IP that hijack the default route.

I believe this behavior is new in RHEL 7.3, but I don't know if any
versions of CentOS are affected yet (testing is in progress).

Running 'systemctl restart network' after os-net-config runs will kill
the dhclient processes, so inserting that into the scripts after
os-net-config is run is one possible workaround, although the brief
interruption in networking might cause unknown issues in
high-availability environments.

Does anyone have a suggestion for a kinder, gentler, less hacky
approach than either restarting the network service or running kill on
the dhclient processes? Also, does anyone have any idea why running
"ifdown " followed by "ifup " doesn't stop the dhclient
process started by the udev rule? Or why this behavior appears to be
new to RHEL 7.3?

[1] - https://bugs.launchpad.net/tripleo/+bug/1640598

-- 
Dan Sneddon |  Senior Principal OpenStack Engineer
dsned...@redhat.com |  redhat.com/openstack
dsneddon:irc|  @dxs:twitter

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

[openstack-dev] [glance] rolling upgrade virtual design session Friday 11 Nov

[Brian Rosmaita]

The poll has closed and the winning time for the Glance virtual design
session on zero downtime rolling upgrades will be 14:00 UTC on Friday, 11
November 2016.  The virtual design session will be held in an on-air
Google hangout which should allow it to be recorded (though of course it
would be better to attend it live).

The link to the hangout will be posted in the #openstack-glance channel on
Freenode approximately 10 minutes before the session.

cheers,
brian





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

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

[Fox, Kevin M]

Just please don't make this a lbv3 thing that completely breaks compatibility 
of existing lb's yet again. If its just an "point url endpoint from thing like 
x to thing like y" in one place, thats ok. I still have v1 lb's in existence 
though I have to deal with and a backwards incompatible v3 would just cause me 
to abandon lbaas all together I think as it would show the lbaas stuff is just 
not maintainable.

Thanks,
Kevin

From: Armando M. [arma...@gmail.com]
Sent: Wednesday, November 09, 2016 8:05 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron] [lbaas] [octavia] Ocata LBaaS 
retrospective and next steps recap



On 9 November 2016 at 05:50, Gary Kotton 
mailto:gkot...@vmware.com>> wrote:
Hi,
What about neutron-lbaas project? Is this project still alive and kicking to 
the merge is done or are we going to continue to maintain it? I feel like we 
are between a rock and a hard place here. LBaaS is in production and it is not 
clear the migration process. Will Octavia have the same DB models as LBaaS or 
will there be a migration?
Sorry for the pessimism but I feel that things are very unclear and that we 
cannot even indicate to our community/consumers what to use/expect.
Thanks
Gary

http://specs.openstack.org/openstack/neutron-specs/specs/newton/kill-neutron-lbaas.html


On 11/8/16, 1:36 AM, "Michael Johnson" 
mailto:johnso...@gmail.com>> wrote:

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


__
OpenStack Development Mailing 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:un

[openstack-dev] [neutron] Barcelona summit "neutron-agent retrospective" recap

[Kevin Benton]

There were three main topics discussed during the neutron-agent
retrospective session: deprecating the CLI OVS interfaces, refactoring the
agent to use the callback framework, and eliminating the L2pop driver.

Deprecating the CLI OVS Interfaces

We now have native replacements for shelling out to ovs-vsctl and ovs-ofctl
using a python ovsdb interface and the RYU openflow code, respectively.
Currently, it's an operator configuration option to choose the native vs
legacy interfaces. The native interfaces were the default for the last
cycle, so we would like to deprecate the legacy interfaces and remove them
in Pike.

This appeared to have general consensus, contingent on fixing a few parity
bugs with the CLI interface for handling flows. If using the CLI interfaces
is critical to a use case, please reply to this email because we will
proceed with the deprecation otherwise.

Refactoring the agent to use the callback framework
--
We need to refactor some of the main OVS agent file to make it more
maintainable. The file itself contains over 2000 lines of python and the
methods are insanely long and complex, making unit testing difficult and
questionable in its efficacy. This makes adding new features scary, which
slows down development.

While there was nobody against refactoring the agent, we decided to defer
this work due to the short nature of this cycle and the potential conflicts
it will have with the next bullet point.

However, any refactoring required for other development activities
(features or fixes), will not be blocked.

Eliminating L2pop as a mechanism driver

L2pop calculates information on the fly to determine tunnel termination
endpoints. This is racey (out of order tunnel notifications are not
handled) and leads to lots of complexity involving lookups to agent tables,
etc. This also makes it very difficult to integrate external devices
because they have no way of informing the agents of their tunnel
termination endpoint.

We'd like to formalize the tunnel termination point by adding it to the
port binding data model just like other encapsulation details (bound
segment, segmentation id, etc). This will allow mech drivers to bind ports
not based on agents and allow seamless integration with agent-based ports.
The L2pop server-side logic would go away since agents would setup
forwarding entries just based on the latest data on the port models
delivered via push notifications.

This will require some changes on the server side in the port binding
process to have the mech drivers provide the tunnel termination point as
part of the binding details. The agent side will also require a few changes
to have its tunnel forming logic be derived from push notifications instead
of tunnel and fdb notifications.

This change will likely need a small spec to scope out the new port binding
process.

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

Re: [openstack-dev] [kolla] How tied is kolla to matching 1:1 releases of openstack?

[Fox, Kevin M]

I think its kind of in the same vein as the rest of the openstack services. It 
might, (and probably will) work with n-1 & n services in the same system. But 
it all depends on either:
1. The things that are actually tested
or
2. Luck

I've been testing the kolla-kubernetes deployment tools with 2.0.x containers 
and 3.0.x containers, so those should work. any other combination might work 
but I no idea if they actually will work as its untested.

More gate testing would help and be welcome. :)

Thanks,
Kevin

From: Joshua Harlow [harlo...@fastmail.com]
Sent: Wednesday, November 09, 2016 9:28 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [kolla] How tied is kolla to matching 1:1 releases 
of openstack?

Hi kolla folks,

As I am (and others at godaddy) are working through integrating kolla
image building into our jenkins pipeline(s),

Currently the pipeline is the following (taking an example of glance),

# Checkout stage
1. Checkout kolla at X tag/branch
2. Checkout glance at Y tag/branch
3. Checkout internal-deploy repo (which has patches for various
projects) at Z tag/branch
4. Checkout requirements repo at Y tag/branch (same Y as #2)

# Test stage
5. Create a virtualenv for glance using constraints from #4
6. Run testr and capture the results of tests and make sure those work
(or fail here)
7. Patch glance using patches from #3
8. Retest glance using same routine as #6 and make sure those work (or
fail here)

# Kolla stage
9. Setup kolla-build.conf with sections for glance (setup to take the
glance tested as a local
 directory) and sections for openstack-base (which == the
requirements repo from #4) and
 create a template-overrides.j2 with various specific kolla overrides
10. Build images (or fail here)
11. Upload images to artifactory (WIP here)

 Stage next 

So the general question I have is that kolla has tags/branches that
match glance and other openstack releases but I'm not really sure how
tightly bound kolla is to those same tags/branches,

For example right now I am taking kolla at stable/newton but glance and
requirements at stable/liberty,

This seems to work (ya!) but I don't quite know if this is really
recommended, is kolla really tied to the same branches of the other
openstack projects,

With the projects moving to more independent releases is there any
suggested policy, will kolla work with what project releases?

Some range of releases that will work, won't work...?

Ie, kolla stable/newton for example will work with A, B, C, ... branches
of [neutron, glance...]?

Should kolla have a known working list, stating the above in some
location inside of the kolla repo (so people know)?

Thoughts? Comments?

-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 Development Mailing 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] vendordata v2 ocata summit recap

[Matt Riedemann]

Michael Still led a session on completing the vendordata v2 work that 
was started in the Newton release. The full etherpad is here:


https://etherpad.openstack.org/p/ocata-nova-summit-vendoradatav2

Michael started by advertising a bit what it is since it's a new feature 
and it's meant to replace the old class-path loading way of getting 
vendor metadata (and ultimately allows us to remove hooks).


The majority of the session was spent discussing a gap we have in 
providing token information on the request to the vendordata server.


For example, when creating a server we have a user content and token and 
can provide that information to the vendordata REST API, but on 
subsequent GETs from the guest itself we don't have a token. After quite 
a bit of discussion in the room, including with Adam and Dolph from the 
keystone team, we decided to:


1. Stash the user's roles from the initial create in the nova database 
and re-use those on subsequent GET requests.


2. Use a service token to pass the other information to the vendordata 
v2 REST API so that it knows the request is coming from Nova. This was 
considered a bug fix and not a new feature so we can backport the 
functionality.


Other things that are needed at some point:

1. Add some caching of the response using the Cache-Control header.

2. Add a configuration option to toggle whether or not the server create 
should fail if a vendordata response is not 200. Today if we get a 
non-200 response we log a warning and return {} to the caller. Some 
vendordata scenarios require that the metadata get into the guest as 
soon as it's created or else it becomes essentially a zombie and 
cleaning it up later is painful. So provide an option to fail that 
server create if we can't get the necessary data into the guest on 
server create. Note that this would only fail the server build if using 
config drive since nova is the caller. When cloud-init is making the 
request from within the guest, nova has lost control at that point and 
any failures are going to have to be cleaned up separately.


--

Thanks,

Matt Riedemann


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

[openstack-dev] [kolla][kubernetes]kolla-kubernetes achitectures spec

[Ryan Hallisey]

Hey folks,

The kolla-kubernetes architecture spec has been under review
for a day now. The plan is to keep it open for 7 days after
the initial review was posted (November 8th).  Therefore, voting on
the spec will commence on November 15th. So be sure to add any input
you may have before that date.

For folks that are curious about OpenStack on Kubernetes, it is worth a
read since there are a lot of good ideas being thrown around.

Thanks,
-Ryan

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

[Dan Sneddon]

On 11/04/2016 10:40 AM, 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 from me, Michele has been contributing for a long time.

-- 
Dan Sneddon

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

[Clay Gerrard]

On Wed, Nov 9, 2016 at 3:14 AM, Chris Dent  wrote:

>
> As a community we don't want to be bound together by rules, we want
> to be enabled by processes that support making and doing things
> effectively. The things that we make and do is what binds us
> together.
>

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

[openstack-dev] [kolla] How tied is kolla to matching 1:1 releases of openstack?

[Joshua Harlow]

Hi kolla folks,

As I am (and others at godaddy) are working through integrating kolla 
image building into our jenkins pipeline(s),


Currently the pipeline is the following (taking an example of glance),

# Checkout stage
1. Checkout kolla at X tag/branch
2. Checkout glance at Y tag/branch
3. Checkout internal-deploy repo (which has patches for various 
projects) at Z tag/branch

4. Checkout requirements repo at Y tag/branch (same Y as #2)

# Test stage
5. Create a virtualenv for glance using constraints from #4
6. Run testr and capture the results of tests and make sure those work 
(or fail here)

7. Patch glance using patches from #3
8. Retest glance using same routine as #6 and make sure those work (or 
fail here)


# Kolla stage
9. Setup kolla-build.conf with sections for glance (setup to take the 
glance tested as a local
directory) and sections for openstack-base (which == the 
requirements repo from #4) and

create a template-overrides.j2 with various specific kolla overrides
10. Build images (or fail here)
11. Upload images to artifactory (WIP here)

 Stage next 

So the general question I have is that kolla has tags/branches that 
match glance and other openstack releases but I'm not really sure how 
tightly bound kolla is to those same tags/branches,


For example right now I am taking kolla at stable/newton but glance and 
requirements at stable/liberty,


This seems to work (ya!) but I don't quite know if this is really 
recommended, is kolla really tied to the same branches of the other 
openstack projects,


With the projects moving to more independent releases is there any 
suggested policy, will kolla work with what project releases?


Some range of releases that will work, won't work...?

Ie, kolla stable/newton for example will work with A, B, C, ... branches 
of [neutron, glance...]?


Should kolla have a known working list, stating the above in some 
location inside of the kolla repo (so people know)?


Thoughts? Comments?

-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

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

[Robert Collins]

Sed doesn't exist on windows, whereas a python script can. Sed doesn't
handle multiple line constraints.

Rob

On 10 Nov 2016 12:00 AM, "Ihar Hrachyshka"  wrote:

>
> > On 8 Nov 2016, at 04:07, Tony Breeds  wrote:
> >
> > 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
>
> I believe sed is the way to go. There is not much we get from
> edit-constraints at this point, and it untangles the script from
> zuul-cloner that would be needed to fetch requirements repo.
>
> It seems like the way to go. Wanna propose a patch for a repo
> (oslo.messaging) to iterate on it in gerrit?
>
> 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] [Openstack] [all][infra][requirements] Odd cases in requirements?

[John Villalovos]

Ah, thanks a lot for that info :) I think that is what I need.

On Wed, Nov 9, 2016 at 7:36 AM, Jeremy Stanley  wrote:

> On 2016-11-09 07:19:04 -0800 (-0800), John Villalovos wrote:
> > Sort of related, what is the plan for supporting requirements which are
> > Python 3 only packages?
> >
> > In particular the package: mypy-lang
> > https://pypi.python.org/pypi/mypy-lang
> [...]
>
> If you only want mypy-lang installed when the interpreter is Python
> 3.3 or later (what their trove classifiers seem to imply for
> supported versions), use the following environment marker syntax:
>
> mypy-lang;python_version>='3.3'
>
> (see dnspython3 in global-requirements.txt for a similar example)
>
> https://pip.pypa.io/en/stable/reference/pip_install/#
> requirement-specifiers
> https://www.python.org/dev/peps/pep-0426/#environment-markers
> --
> 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] Anyone want to meetup at KubeCon?

[Steve Martinelli]

You can try finding Brad Topol, he's presently at Kubecon and familiar with
all things Keystone.

On Tue, Nov 8, 2016 at 4:49 PM, Stephen McQuaid 
wrote:

> We have been developing a keystone authz webhook for easy integration.  If
> anyone is interested we can look at open-sourcing it
>
>
>
> Stephen McQuaid
>
> *Sr. Software Engineer | Kubernetes & Openstack*
>
> *GoDaddy*
>
>
>
> M: 484.727.8383 | O: 669.600.5852
>
> smcqu...@godaddy.com
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] FOSDEM 2017: Call For Proposals -- Virtualization & IaaS DevRoom

[Kashyap Chamarthy]

===

The call for proposals is now open for the Virtualization & IaaS devroom
at the upcoming FOSDEM 2017, to be hosted on February 4, 2017.

This year will mark FOSDEM’s 17th anniversary as one of the
longest-running free and open source software developer events,
attracting thousands of developers and users from all over the world.
FOSDEM will be held once again in Brussels, Belgium, on February 4 & 5,
2017.

---
Important Dates
---

*Submission deadline*: *18 November 2016*
Acceptance notifications: 04 December 2016
Final schedule announcement: 11 December 2016
Devroom: 04 February 2017 (one day)

-
About the Devroom
-

The Virtualization & IaaS devroom will feature session topics such as
open source hypervisors and virtual machine managers such as Xen
Project, KVM, QEMU, bhyve, and VirtualBox, and
Infrastructure-as-a-Service projects such as Apache CloudStack,
OpenStack, oVirt, OpenNebula, and Ganeti.

This devroom will host presentations that focus on topics of shared
interest, such as KVM; libvirt; shared storage; virtualized networking;
cloud security; clustering and high availability; interfacing with
multiple hypervisors; hyperconverged deployments; and scaling across
hundreds or thousands of servers.

Presentations in this devroom will be aimed at developers working on
these platforms who are looking to collaborate and improve shared
infrastructure or solve common problems. We seek topics that encourage
dialog between projects and continued work post-FOSDEM.


Submit Your Proposal


All submissions must be made via the Pentabarf event planning site.

https://penta.fosdem.org/submission/FOSDEM17

If you have not used Pentabarf before, you will need to create an
account.  If you submitted proposals for FOSDEM in previous years, you
can use your existing account.

After creating the account, select Create Event to start the submission
process. Make sure to select Virtualisation and IaaS devroom from the
Track list. Please fill out all the required fields, and provide a
meaningful abstract and description of your proposed session.

-
Submission Guidelines
-

- We expect more proposals than we can possibly accept, so it is vitally
  important that you submit your proposal on or before the deadline.
  Late submissions are unlikely to be considered.

- All presentation slots are 45 minutes, with 35 minutes planned for
  presentations, and 10 minutes for Q&A.

- All presentations will be recorded and made available under Creative
  Commons licenses. In the Submission notes field, please indicate that
  you agree that your presentation will be licensed under the
  CC-By-SA-4.0 or CC-By-4.0 license and that you agree to have your
  presentation recorded. For example:

"If my presentation is accepted for FOSDEM, I hereby agree to
license all recordings, slides, and other associated materials under
the Creative Commons Attribution Share-Alike 4.0 International
License.  Sincerely, ."

- In the Submission notes field, please also confirm that if your talk
  is accepted, you will be able to attend FOSDEM and deliver your
  presentation. We will not consider proposals from prospective speakers
  who are unsure whether they will be able to secure funds for travel
  and lodging to attend FOSDEM. (Sadly, we are not able to offer travel
  funding for prospective speakers.)

---
Call for Volunteers
---

We are also looking for volunteers to help run the devroom. We need
assistance watching time for the speakers, and helping with video for
the devroom. Please contact Brian Proffitt (bkp at redhat.com), for more
information.

--
Questions?
--

If you have any questions about this devroom, please send your questions
to our devroom mailing list. 

iaas-virt-devr...@lists.fosdem.org

You can also subscribe to the list to receive updates about important
dates, session announcements, and to connect with other attendees.

===

-- 
/kashyap

__
OpenStack Development Mailing 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] Please review, tripleo ci transition to the quickstart tool set

[Gabriele Cerami]

On 08 Nov, Wesley Hayutin wrote:

> [3], please if you have time review the etherpad and respond with any
> questions, suggestions or concerns.

Hi,

I added a step on the PRE phase (line 192) in [3] regarding logs.
Coming from TripleO CI developers may feel lost when they try to debug a
failure.


> [1]
> https://blueprints.launchpad.net/tripleo/+spec/use-tripleo-quickstart-and-tripleo-quickstart-extras-for-the-tripleo-ci-toolset
> [2] https://review.openstack.org/#/c/386250/
> [3] https://etherpad.openstack.org/p/tripleo-ci-transition-to-quickstart
> -- next part --
> An HTML attachment was scrubbed...
> URL: 
> 

__
OpenStack Development Mailing 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][nova][cinder][horizon][all] properties / metadata for resources

[Dean Troyer]

On Tue, Nov 8, 2016 at 4:12 PM, Gage Hugo  wrote:
> The idea is that a cloud admin could define a list of keys that they need
> for their setup within keystone's configuration file, then only those keys
> will be valid for storing values in the project properties table.  Then each
> call would check against the list of valid keys and deny any calls that are
> sent with an invalid key.

Please do not do this, it throws fuel onto the interoperability file
we still have not put out.

One actual technical drawback to doing this is that none of the
OpenStack services can depend on any of those keys actually being
defined, so this is still effectively just a single-deployment
'extras' field, with the only advance being that all rows may have the
same set of keys, depending on how the configuration changes over
time.

> This idea seems to help with the issue to avoid allowing anyone to throw any
> arbitrary values into these project properties vs just a set number of
> values.

It may feel that way, but it really does not help at all.  From a
cloud consumer point of view (including tools developed and used by
deployers, possibly across multiple cloud deployments) this is no help
at all.

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] Anyone want to meetup at KubeCon?

[Morgan Fainberg]

On Nov 8, 2016 4:53 PM, "Stephen McQuaid"  wrote:
>
> We have been developing a keystone authz webhook for easy integration.
If anyone is interested we can look at open-sourcing it
>
>
>
> Stephen McQuaid
>
> Sr. Software Engineer | Kubernetes & Openstack
>
> GoDaddy
>
>
>
> M: 484.727.8383 | O: 669.600.5852
>
> smcqu...@godaddy.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
>

If I was not out of town and away from the Pacific Northwest I would have
enjoyed meeting up for these discussions. Unfortunately, I won't be back to
PNW (and closeish to Seattle) until Saturday.

--Morgan
__
OpenStack Development Mailing 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 - Timeslot ?

[Thierry Carrez]

Thierry Carrez wrote:
> lebre.adr...@free.fr wrote:
>> After Thierry's cleaning, the possibilities are the following ones: 
>>
>> Wednesday 14 UTC (odd week)
>> Wednesday 17 UTC 
>> Thursday 14 UTC (odd week)
>> Thursday 16 UTC (even week)
>> Thursday 17 UTC (even week)
> 
> Thursday 15 UTC is also an option.
> 
> Also note that Thursday 14 UTC is currently taken. Trying to free up the
> slot with https://review.openstack.org/#/c/395509 but they may want to
> keep it.

A slot just opened for Wednesday 15 UTC, so I revived your original
proposal[1]. If you're still interested in that one let me know and I'll
approve the change.

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

-- 
Thierry Carrez (ttx)

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

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

[Michael Johnson]

Hi Gary,

Our intent is to merge neutron-lbaas into the Octavia project.  When
this is complete, the neutron-lbaas project will remain for some time
as a light weight shim/proxy that provides the legacy neutron endpoint
experience.

The database models are already very similar to the existing
neutron-lbaas models (by design) and we will finish aligning these as
part of the merge work.  For example, the names that were added to
some objects will be added in the octavia database as well.

We are also planing a migration from the neutron LBaaSv2 database to
the octavia database.  This should not impact existing running load
balancers.

Michael



On Wed, Nov 9, 2016 at 5:50 AM, Gary Kotton  wrote:
> Hi,
> What about neutron-lbaas project? Is this project still alive and kicking to 
> the merge is done or are we going to continue to maintain it? I feel like we 
> are between a rock and a hard place here. LBaaS is in production and it is 
> not clear the migration process. Will Octavia have the same DB models as 
> LBaaS or will there be a migration?
> Sorry for the pessimism but I feel that things are very unclear and that we 
> cannot even indicate to our community/consumers what to use/expect.
> Thanks
> Gary
>
> On 11/8/16, 1:36 AM, "Michael Johnson"  wrote:
>
> 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
>
>
> __
> OpenStack Development Mailing 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

[Dan Prince]

+1 from me.

Dan

On Fri, 2016-11-04 at 13:40 -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!
> 
> Thanks,

__
OpenStack Development Mailing 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] [lbaas] [octavia] Ocata LBaaS retrospective and next steps recap

[Armando M.]

On 9 November 2016 at 05:50, Gary Kotton  wrote:

> Hi,
> What about neutron-lbaas project? Is this project still alive and kicking
> to the merge is done or are we going to continue to maintain it? I feel
> like we are between a rock and a hard place here. LBaaS is in production
> and it is not clear the migration process. Will Octavia have the same DB
> models as LBaaS or will there be a migration?
> Sorry for the pessimism but I feel that things are very unclear and that
> we cannot even indicate to our community/consumers what to use/expect.
> Thanks
> Gary
>

http://specs.openstack.org/openstack/neutron-specs/specs/newton/kill-neutron-lbaas.html


>
> On 11/8/16, 1:36 AM, "Michael Johnson"  wrote:
>
> 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
>
>
> __
> OpenStack Development Mailing 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] [Openstack] [all][infra][requirements] Odd cases in requirements?

[Jeremy Stanley]

On 2016-11-09 07:19:04 -0800 (-0800), John Villalovos wrote:
> Sort of related, what is the plan for supporting requirements which are
> Python 3 only packages?
> 
> In particular the package: mypy-lang
> https://pypi.python.org/pypi/mypy-lang
[...]

If you only want mypy-lang installed when the interpreter is Python
3.3 or later (what their trove classifiers seem to imply for
supported versions), use the following environment marker syntax:

mypy-lang;python_version>='3.3'

(see dnspython3 in global-requirements.txt for a similar example)

https://pip.pypa.io/en/stable/reference/pip_install/#requirement-specifiers
https://www.python.org/dev/peps/pep-0426/#environment-markers
-- 
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] [OpenStack-docs] [openstack deployment] Adding deployment guides to docs.o.o

[Alexandra Settle]

Hi everyone,

A discussion was held in the OpenStack manuals social track at the Barcelona 
summit and we agreed to start including deployment projects, with appropriate 
installation guide(s), into the docs.o.o site. 
Similar to what we have done with the Installation Tutorials.

After working heavily with the OpenStack-Ansible team over the last few cycles, 
I have worked to ensure their Installation Guide is of the same standard as our 
manuals docs – following the Contributor guide and OpenStack manuals formatting 
– and have proposed their guide as the guinea pig for this transition.

At the moment, we are working on the best way to publish. Experimenting with 
the OpenStack-Ansible guide, we have the following patches in motion:

· https://review.openstack.org/391499 (Deployment gate jobs)

· https://review.openstack.org/391486 (Putting the OpenStack-Ansible 
guide into the manuals cookie cutter)

All deployment projects will have the opportunity to include their individual 
installation guides – to be called, “Deployment Guides” (this is open for 
discussion if others have better ideas).

If anyone is able to help with getting these patches merged to forge an easy 
pathway for other deployment guides, that would be amazing. I am looking to get 
some help in identifying what is the best path to publish to, and help with the 
index files.

If any of the deployment projects are interested in getting involved, let us 
know and we can work together to make this transition ☺

Thanks,

Alexandra Settle

Information Developer II
Rackspace Private Cloud Powered By OpenStack
London, United Kingdom


Rackspace Limited is a company registered in England & Wales (company 
registered number 03897010) whose registered office is at 5 Millington Road, 
Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy can be 
viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail message may 
contain confidential or privileged information intended for the recipient. Any 
dissemination, distribution or copying of the enclosed material is prohibited. 
If you receive this transmission in error, please notify us immediately by 
e-mail at ab...@rackspace.com and delete the original message. Your cooperation 
is appreciated.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[John Villalovos]

Sort of related, what is the plan for supporting requirements which are
Python 3 only packages?

In particular the package: mypy-lang
https://pypi.python.org/pypi/mypy-lang

I was considering adding some type hints to the ironic-lib project in the
future. But it needs to run the mypy program to do the type hint checking
and it is a Python 3 only program. Current workaround is to put it into
tox.ini.

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

Re: [openstack-dev] [AODH] event-alarm timeout discussion

[Julien Danjou]

On Mon, Sep 26 2016, Zhai, Edwin wrote:

> Do you have any idea to resolve this race condition?

So following our discussion at the summit, I went ahead and wrote a spec
about that feature:

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

Comments are welcome obviously!

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


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

[openstack-dev] [fuel][tripleo] Fuel and TripleO Cross-Project Integration

[Vladimir Kuklin]

Stackers

During OpenStack summit in Barcelona we had a rather productive
cross-project integration session between Fuel and TripleO projects [0].
More precisely we discussed the following:

1. Services composition and deployment workflow control
2. Complex networking configuration (bonds, offloading, etc.)
3. Post-deployment cluster management, i.e. day-2 operations
4. Approaches to reference architecture recomposition, e.g. in-flight
database vertical scaling
5. Upgrades
6. Provisioning and disks partitioning

The most interesting part of integration would be to consider integration
of deployment and post-deployment orchestration approaches and services
composition. The further steps are to start working on:

1. Cross-project specification on workflow management, e.g. for upgrades
and day-2 operations
2. Look into possibility of Mistral integration as a workflow execution
tool within the designed model
3. Consider integration of Fuel provisioning, network configuration and
disk partitioning with Ironic and TripleO

[0] https://etherpad.openstack.org/p/fuel-ocata-fuel-tripleo-integration

I would suggest that we add discussing this into TripleO or Fuel IRC
meeting agenda next week.

Please let me know what are you thoughts on this.

-- 
Yours Faithfully,
Vladimir Kuklin,
Fuel Library Tech Lead,
Mirantis, Inc.
+7 (495) 640-49-04
+7 (926) 702-39-68
Skype kuklinvv
35bk3, Vorontsovskaya Str.
Moscow, Russia,
www.mirantis.com 
www.mirantis.ru
vkuk...@mirantis.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [horizon] USE_SSL

[Luke Hinds]

On Wed, Nov 9, 2016 at 1:56 PM, Rob Cresswell 
wrote:

> Was that ever in local_settings? I couldnt find any mention of it.
>

Yes, seems to have stopped being used around Kilo:

http://docs.openstack.org/kilo/config-reference/content/configure-dashboard.html


> The Django docs are probably your best bet for information: https://docs.
> djangoproject.com/en/1.10/topics/security/#ssl-https
>
> Rob
>
> On 9 November 2016 at 13:23, Luke Hinds  wrote:
>
>> Hi,
>>
>> I have noted that USE_SSL is no longer in local_settings.py
>>
>> I have not had any luck in having google find the background of why this
>> was removed for first django (if it has?)  and horizon.
>>
>> From what I can see, it seems related to django views.
>>
>> Does anyone understand the context of this being removed. I don't require
>> the use of the parameter myself, I more want to update the security guide
>> which recommends toggling it to true when using SSL.
>>
>> Thanks,
>>
>> Luke
>>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Luke Hinds | NFV Partner Engineering | Office of Technology | Red Hat
e: lhi...@redhat.com | irc: lhinds @freenode | m: +44 77 45 63 98 84 | t: +44
12 52 36 2483
__
OpenStack Development Mailing 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] important changes to pep8 python jobs

[Ian Cordasco]

 

-Original Message-
From: Paul Belanger 
Reply: OpenStack Development Mailing List (not for usage questions) 

Date: November 8, 2016 at 17:19:40
To: openstack-dev@lists.openstack.org 
Subject:  Re: [openstack-dev] [all] important changes to pep8 python jobs

> On Tue, Nov 08, 2016 at 02:58:38PM -0500, Paul Belanger wrote:
> > On Thu, Nov 03, 2016 at 12:29:09PM -0400, Paul Belanger wrote:
> > > Greetings,
> > >
> > > We (openstack-infra) are proposing a change to the current pep8[1] job for
> > > python jobs, and would like to bring your attention to it.
> > >
> > > We'll be removing the extra-index-url field from pip.conf which forces 
> > > the job
> > > to manually build any missing wheels as dependencies. The reason for 
> > > this, is
> > > to force a way for jobs to ensure the proper OS dependencies are 
> > > installed.
> > >
> > > There is a chance your project pep8 job may break, which is why we are 
> > > sending
> > > out this email. We encourage each project to be using bindep[2], binary
> > > dependency management tool, to ensure any OS packages are needed. If your
> > > project needs a specific binary to be installed to compile your project, 
> > > simply
> > > add it to the bindep.txt file in your project repo.
> > >
> > > We'll be approving the change on Nov. 16, 2016 and send out another 
> > > message as
> > > we move closer to the date.
> > >
> > > If you have any questions, feel free to reply or use #openstack-infra on
> > > freenode.
> > >
> > Greetings,
> >
> > A quick reminder that we plan on making this change next week.
> >
> > It was also suggested we create a job-template[3] for projects who wish to 
> > add
> > an experimental job to test a project. Feel free to propose a change to
> > project-config and use the 'check experimental' command to run the job.
> >
> We've actually went a head and added[4] the experimental job to both 
> python-jobs
> and python-db-jobs templates for JJB. So, if your project is using them, you 
> can
> now run 'check experimental' to see if pep8 still passes. If not, this is a
> good time to update bindep.txt with the missing dependencies.

This is *very* helpful. Thank you, all for adding this to the JJB templates. :)

--  
Ian Cordasco


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

[openstack-dev] Fwd: Re: [requirements][kolla][security] pycrypto vs cryptography

[Ian Cordasco]

Apparently Paul's email didn't make it through, so I'm forwarding it
to y'all since it pertinent information.

-Original Message-
From: Paul Kehrer 
Reply: Paul Kehrer 
Date: November 8, 2016 at 23:39:32
To: Ian Cordasco , OpenStack Development
Mailing List (not for usage questions)

Subject:  Re: [openstack-dev] [requirements][kolla][security] pycrypto
vs cryptography

> Cryptography will build just fine against a FIPS OpenSSL (1.0.0 or newer, 
> although we’re
> in the process of dropping < 1.0.1 support in the next several months). It is 
> a supported
> configuration, but enabling FIPS mode (if it’s not on by default) is not 
> something cryptography
> currently exposes (FIPS_mode_set). Rob and Ian’s points about the value of 
> FIPS are
> generally in line with my own opinions. In the absence of an audit 
> requirement I’d recommend
> looking for well-vetted and widely used libraries above trying to meet a 
> specific compliance
> regime.
>
> -Paul
>
> On 11/9/16, 5:11 AM, "Ian Cordasco" wrote:
>
> -Original Message-
> From: Rob C
> Reply: OpenStack Development Mailing List (not for usage questions)
>
> Date: November 7, 2016 at 07:39:57
> To: OpenStack Development Mailing List (not for usage questions)
>
> Subject: Re: [openstack-dev] [requirements][kolla][security] pycrypto
> vs cryptography
>
> > 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.
>
> At this point PyCrypto actively tells users that it's not supported or
> developed. They've been pushing people towards Cryptogrpahy.
>
> > 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
>
> I would strongly suggest you read Rob's link. It's very enlightening
> to know why, while FIPS may be a requirement, it's not necessarily
> beneficial from a security standpoint. It's also ridiculously
> expensive and restrictive.
>
> I've CC'd one of the lead developers from the Cryptography project to
> comment on this. I would hazard a guess that one could compile
> Cryptography against a version of OpenSSL that is FIPS compliant, but
> I doubt it'll be considered supported. I know Cryptography recently
> dropped support for a few older versions of OpenSSL, and to work with
> that you'd have to stick to an older version of Cryptography.
>
> Can I ask why FIPS compliance is a requirement for Kolla? This seems
> like an odd request for a deployment project.
>
> > 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
>
> --
> Ian Cordasco
>
>
>

--
Ian Cordasco

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

Re: [openstack-dev] [horizon] USE_SSL

[Rob Cresswell]

Was that ever in local_settings? I couldnt find any mention of it. The Django 
docs are probably your best bet for information: 
https://docs.djangoproject.com/en/1.10/topics/security/#ssl-https

Rob

On 9 November 2016 at 13:23, Luke Hinds 
mailto:lhi...@redhat.com>> wrote:
Hi,

I have noted that USE_SSL is no longer in local_settings.py

I have not had any luck in having google find the background of why this was 
removed for first django (if it has?)  and horizon.

From what I can see, it seems related to django views.

Does anyone understand the context of this being removed. I don't require the 
use of the parameter myself, I more want to update the security guide which 
recommends toggling it to true when using SSL.

Thanks,

Luke

__
OpenStack Development Mailing 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] [lbaas] [octavia] Ocata LBaaS retrospective and next steps recap

[Gary Kotton]

Hi,
What about neutron-lbaas project? Is this project still alive and kicking to 
the merge is done or are we going to continue to maintain it? I feel like we 
are between a rock and a hard place here. LBaaS is in production and it is not 
clear the migration process. Will Octavia have the same DB models as LBaaS or 
will there be a migration?
Sorry for the pessimism but I feel that things are very unclear and that we 
cannot even indicate to our community/consumers what to use/expect.
Thanks
Gary

On 11/8/16, 1:36 AM, "Michael Johnson"  wrote:

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


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

[Ash]

On Wed, Nov 9, 2016 at 3:14 AM, Chris Dent  wrote:

> On Tue, 8 Nov 2016, Ash wrote:
>
> I couldn't agree more. I don't like change for the sake of change (in any
>> aspect of my life). So in my mind this would have to be a way to better
>> bind us.
>>
>
> Here, have some tortured metaphors:
>
> Something that feels like it gets under-emphasised in this conversation
> is that change is coming whatever we do. As a community we can either
> move quickly and stay ahead of the change and see it as a productive
> development that we can surf or we can dilly dally and get drowned by a
> wave that collapses over us.
>
> Ecosystems must evolve and change because the world evolves and changes.
> If we try to control this stuff too much what we will be doing is taking
> the oxygen out of the system and snuffing the flame of excitement and
> innovation.
>
> As a community we don't want to be bound together by rules, we want
> to be enabled by processes that support making and doing things
> effectively. The things that we make and do is what binds us
> together.
>
> The conversations about additional languages in this community have
> been one our most alarmingly regressive and patronizing. They seem
> to be bred out of fear rather than hope and out of lack of faith in
> each other than in trust. We've got people who want to build stuff.
> Isn't that the important part?
>
> Let's just get on with making stuff and work out the problems (and of
> course there will be many, there always are) as they happen. That's
> what we do.


Well said, Chris!

>
>
> --
> Chris Dent   ┬─┬ノ( º _ ºノ)https://anticdent.org/
> freenode: cdent tw: @anticdent
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing 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

[Miles Gould]

On 09/11/16 07:34, Renat Akhmerov wrote:

Ok, thank you all!

Dougal, welcome to the core team! I’m hoping for fruitful collaboration
with you :)


Congratulations, Dougal!

Miles

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

[openstack-dev] [horizon] USE_SSL

[Luke Hinds]

Hi,

I have noted that USE_SSL is no longer in local_settings.py

I have not had any luck in having google find the background of why this
was removed for first django (if it has?)  and horizon.

>From what I can see, it seems related to django views.

Does anyone understand the context of this being removed. I don't require
the use of the parameter myself, I more want to update the security guide
which recommends toggling it to true when using SSL.

Thanks,

Luke
__
OpenStack Development Mailing 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] [release] change in plan for releases repo data model updates

[Thierry Carrez]

Doug Hellmann wrote:
> At the summit we said we would move the data that tells us the type
> and release model for each deliverable out of the governance
> repository and into the releases repository where it is easier to
> change over time, but that we needed to think more about what might
> break by making that change. After giving it more consideration, I
> think we have to use the option 2 we discussed instead (allow local
> values to override the global values).

If we look back at the goals driving the change, this solves the
"temporarily bypass governance values" need. The main drawback (to me)
is that we continue to consider deliverable types and release model to
be a "governance" thing. Another drawback is the additional work needed
to sync changes back into the governance repo (see Tony's question).

> The list-repos command would not be able to filter on the type or
> model values early in a cycle because not enough deliverable files
> would even exist until the first milestone. That limitation would
> make the command essentially useless until close to the end of each
> cycle. Using option 2 means list-repos would continue to work all the
> time.

Devil's advocate, we could copy over the type/model values from the
previous cycle as part of the new cycle opening, and have list-repos
work all the time. That sounds like less work than tracking the
retrosyncing of each and every override back onto the governance repo...

> Using option 2 also means that instead of us having to do extra
> work to build and publish a single unified file for the project
> navigator team, they can continue to use the same input data without
> changes to their project at all.

That's a one-time work, so I don't think having to do that is unreasonable.

> I propose adding "type" and "model" fields, as we discussed, but
> making them optional. If they are not present, the values can be
> derived from the governance tags for the deliverable. Teams who
> want to change either value can then make the update in the releases
> repository with a separate patch to update the governance repo, and
> not have releases blocked by the governance change.

It feels like extra work overall. More work for teams (having to file
two separate patches) and more work for us to make sure that governance
patch is merged, doesn't slip through the cracks and doesn't introduce a
drift between the two repos.

So... not convinced :)

-- 
Thierry Carrez (ttx)

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

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

[Chris Dent]

On Tue, 8 Nov 2016, Ash wrote:


I couldn't agree more. I don't like change for the sake of change (in any
aspect of my life). So in my mind this would have to be a way to better
bind us.


Here, have some tortured metaphors:

Something that feels like it gets under-emphasised in this conversation
is that change is coming whatever we do. As a community we can either
move quickly and stay ahead of the change and see it as a productive
development that we can surf or we can dilly dally and get drowned by a
wave that collapses over us.

Ecosystems must evolve and change because the world evolves and changes.
If we try to control this stuff too much what we will be doing is taking
the oxygen out of the system and snuffing the flame of excitement and
innovation.

As a community we don't want to be bound together by rules, we want
to be enabled by processes that support making and doing things
effectively. The things that we make and do is what binds us
together.

The conversations about additional languages in this community have
been one our most alarmingly regressive and patronizing. They seem
to be bred out of fear rather than hope and out of lack of faith in
each other than in trust. We've got people who want to build stuff.
Isn't that the important part?

Let's just get on with making stuff and work out the problems (and of
course there will be many, there always are) as they happen. That's
what we do.

--
Chris Dent   ┬─┬ノ( º _ ºノ)https://anticdent.org/
freenode: cdent tw: @anticdent__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Thierry Carrez]

lebre.adr...@free.fr wrote:
> After Thierry's cleaning, the possibilities are the following ones: 
> 
> Wednesday 14 UTC (odd week)
> Wednesday 17 UTC 
> Thursday 14 UTC (odd week)
> Thursday 16 UTC (even week)
> Thursday 17 UTC (even week)

Thursday 15 UTC is also an option.

Also note that Thursday 14 UTC is currently taken. Trying to free up the
slot with https://review.openstack.org/#/c/395509 but they may want to
keep it.

-- 
Thierry Carrez (ttx)

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

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

[Ihar Hrachyshka]

> On 8 Nov 2016, at 04:07, Tony Breeds  wrote:
> 
> 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

I believe sed is the way to go. There is not much we get from edit-constraints 
at this point, and it untangles the script from zuul-cloner that would be 
needed to fetch requirements repo.

It seems like the way to go. Wanna propose a patch for a repo (oslo.messaging) 
to iterate on it in gerrit?

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

Re: [openstack-dev] [tripleo] possible backports for stable/newton

[Alan Pevec]

> Since our cherry picks don't seem to be considered equivalents by git
> (probably because of modified commit messages)

I'd like to understand why is that, do you have an example?
It should work when recommendation[*] is followed.

Cheers,
Alan

[*]  
http://docs.openstack.org/project-team-guide/stable-branches.html#change-ids

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

[Steven Dake (stdake)]

Daviey,

I pointed this out to Pavo as well a few weeks ago.  I’m not sure if it 
mattered or not.

Regards
-steve


From: Dave Walker mailto:em...@daviey.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Tuesday, November 8, 2016 at 2:01 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [requirements][kolla][security] pycrypto vs 
cryptography

Hey Steve,

All of the credential generation is optional right?  I mean, as far as kolla is 
concerned - it doesn't *need* to generate the passwords... If 
/etc/kolla/passwords.yml is created outside of kolla-genpwd, then kolla isn't 
creating any credentials itself and the algorithm, entropy and policy is 
transparent to kolla.

On 8 November 2016 at 21:50, Steven Dake (stdake) 
mailto:std...@cisco.com>> wrote:
Ok,

Pavo has told me he has exceptions in place for everything related to Kolla.  
He says as long as we don’t use MD5, he is good to go for a 232 node deploy 
with more to follow (assuming Kolla works out of the box at that scale - we 
have only tested 123 node scale).

We do some basic PRNG to generate passwords, and some PKCS#11 (iirc) algos to 
generate passwords, and we also generate some ssh public/private keys.

Hope the security context helps.

Thanks everyone on his thread for providing guidance.  RobC++ on article.

Regards
-steve




On 11/8/16, 1:46 PM, "Clint Byrum" mailto:cl...@fewbar.com>> 
wrote:

>Excerpts from Ian Cordasco's message of 2016-11-08 16:11:26 -0500:
>> Can I ask why FIPS compliance is a requirement for Kolla? This seems
>> like an odd request for a deployment project.
>>
>
>Guessing it's for the modules that need to communicate securely with
>OpenStack itself.
>
>__
>OpenStack Development Mailing 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] [MassivelyDistributed] bi-weekly meeting - Timeslot ?

[lebre . adrien]

Dear all 


After Thierry's cleaning, the possibilities are the following ones: 

Wednesday 14 UTC (odd week)
Wednesday 17 UTC 
Thursday 14 UTC (odd week)
Thursday 16 UTC (even week)
Thursday 17 UTC (even week)

Please add +1 for the slot that is the most convenient from your side. 
I would appreciate to book it ASAP. 

Thanks
ad_rien_
- Mail original -
> De: "Ken Giusti" 
> À: "lebre adrien" 
> Envoyé: Lundi 7 Novembre 2016 20:00:35
> Objet: Re: [openstack-dev] [MassivelyDistributed] bi-weekly meeting
> 
> Wed 17:00 UTC works for me.
> 
> On Mon, Nov 7, 2016 at 11:52 AM,   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.
> > - 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
> 
> 
> 
> --
> Ken Giusti  (kgiu...@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] [mistral] Promoting Dougal Matthews to the core team

[Dougal Matthews]

Thanks everyone, looking forward to helping out more!

Cheers,
Dougal


On 9 November 2016 at 07:34, Renat Akhmerov 
wrote:

> Ok, thank you all!
>
> Dougal, welcome to the core team! I’m hoping for fruitful collaboration
> with you :)
>
> Renat Akhmerov
> @Nokia
>
> On 8 Nov 2016, at 17:18, Anastasia Kuznetsova 
> wrote:
>
> +1 from my side!
>
> On Tue, Nov 8, 2016 at 11:34 AM, Gershenzon, Michal (Nokia - IL) <
> michal.gershen...@nokia.com> wrote:
>
>> +1
>>
>> J
>>
>>
>>
>> Michal Gershenzon
>> Software Engineer, CloudBand
>> Application & Analytics , Nokia
>> Contact number: +972 9 793 3163
>>
>>
>>
>> *From:* Deja, Dawid [mailto:dawid.d...@intel.com]
>> *Sent:* Tuesday, November 08, 2016 10:21 AM
>> *To:* openstack-dev@lists.openstack.org
>> *Subject:* Re: [openstack-dev] [mistral] Promoting Dougal Matthews to
>> the core team
>>
>>
>>
>> +1
>>
>>
>>
>> It's good to have you on board Dougal!
>>
>>
>>
>> Dawid Deja
>>
>>
>>
>> On Tue, 2016-11-08 at 19:46 +1300, Lingxian Kong wrote:
>>
>> +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&user_id=d0
>> ugal&release=newton&metric=marks
>>
>>
>>
>> Renat Akhmerov
>>
>> @Nokia
>>
>>
>>
>>
>> 
>> __
>> 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:unsubscrib
>> e 
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> --
> Best regards,
> Anastasia Kuznetsova
> __
> OpenStack Development Mailing 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] [tricircle]agenda of weekly meeting Nov.9

[joehuang]

Hello, team,

Agenda of Nov.9 weekly meeting:

  1.  Tricircle big-tent application info share
  2.  Ocata feature development discussion

How to join:
#  IRC meeting: https://webchat.freenode.net/?channels=openstack-meeting on 
every Wednesday starting from UTC 13:00.


If you  have other topics to be discussed in the weekly meeting, please reply 
the mail.

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