Re: [openstack-dev] [kolla] Kolla-ansible is available

[Jeffrey Zhang]

On Wed, Nov 16, 2016 at 9:10 AM, Fox, Kevin M  wrote:

> whats the plan for genconfig? its based on ansible right now, but may fit
> better as a non ansible specific tool?


the core issue is: k8s depends on the ansible configuration file.
now Kolla is split. how the kolla-k8s generate the configuration file? if
it still re-use the ansible configuration file. we do not need any change.



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

Re: [openstack-dev] [kolla] Kolla-ansible is available

[Jeffrey Zhang]

On Wed, Nov 16, 2016 at 1:53 AM, Michał Jastrzębski 
wrote:

> Hello,
>
> I wanted to thank Steve for doing the work, but kolla-ansible is now
> open for business:)
>
> Couple of clarifications how it's going to work:
>
> 1. Currently Kolla-ansible is copy from kolla repo. We will need to
> propose patches to remove docker from it. Also remove ansible bits
> from kolla.
> 2. Any outstanding ansible change should be closed and re-posted to
> kolla-ansible repo.
> 3. Build gates should be dropped from kolla-ansible, deploy gates
> should be removed from kolla
>
​How about do not remove the deploy gates from kolla.
​

​Imaging that, when made some change for certain Dockerfile, ​it is hard
for kolla-ansible and kolla-k8s to notice such change until new patch
trigger deploy gate. this is especially common in stable branch.

4. Core team for kolla-ansible is copy of kolla core team, but teams
> are separate and at some point might diverge from each other.
> 5. Kolla-ansible has it's own launchpad and we should migrate all
> relevant bugs and blueprints out there.
> 6. Kolla-ansibe will use same version number as Kolla (so first tag
> will be 4.0.0b1)
>
> Questions?
>
> Regards,
> Michal
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



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

Re: [openstack-dev] [heat][tripleo] New repository for software-config elements

[Rico Lin]

2016-11-16 5:08 GMT+08:00 Steve Baker :

>
>
> On Tue, Nov 15, 2016 at 10:26 PM, Thomas Herve  wrote:
>
>> Hi all,
>>
>> Historically elements to create images using software config were
>> developed in the heat-templates repository, which turned out to mean
>> that this had to be packaged, etc. Today we were asked if tags could
>> be added to help maintaining the packages. Before we do that, I wonder
>> if we should extract the elements in a different repository. We
>> already have tests which are only applicable to this specific subset
>> of the repo, so it shouldn't be too hard.
>>
>> In summary: let's create a new repository
>> heat-software-config-elements, and move everything from
>> hot/software-config/elements/ in the heat-templates repository to it
>> (and the associated tests).
>>
>> Thoughts?
>>
>>
> Yes, these have definitely outgrown their current home.
>
> RDO already generates the following sub-packages from heat-templates:
> python-heat-agent
> python-heat-agent-puppet
> python-heat-agent-ansible
> python-heat-agent-apply-config
> python-heat-agent-hiera
>
> Therefore can I suggest we call the new repository "heat-agents"?
>
> I do wonder about the usefulness of the diskimage-builder elements-based
> directory layout, since image builders can just install the package. But I
> suppose having elements will be useful for heat-agents CI jobs, and a more
> appropriate layout doesn't occur to me currently.
>
> Also we should consider if we want to retain the git history of these
> files in the new repo - I'm in favour if its not too much effort and the
> resulting history looks clean.
>
>
`heat-agents` sounds  good (hope `agent` is not destracted to anyone).
We already have a new docker-cmd hook landing there might be some other
hooks from other project that are under planing, so it might be a good
timing to get it done.
__
OpenStack Development Mailing 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][tricircle][neutron]Tricircle now is one of OpenStack Big-Tent project

[Shinobu Kinjo]

Great!

 - Shinobu

On Wed, Nov 16, 2016 at 3:39 PM, joehuang  wrote:

> Hi all,
>
> Tricircle was officially accepted yesterday as a big-tent project.
>
> The purpose of the Tricircle project is to provide networking automation
> across Neutron in multi-region OpenStack clouds deployment.
>
> Use cases for the Tricircle are described in
> https://wiki.openstack.org/wiki/Tricircle#Use_Cases.
>
> A brief introduction of Tricircle is provided here:
>
> Each OpenStack cloud includes its own Nova, Cinder and Neutron, the
> Neutron servers in these OpenStack clouds are called local Neuron
> servers, all these local Neutron servers will be configured with the
> Tricircle Local Neutron Plugin. A seperate Neutron server will be
> installed and run standalone as the coordinator of networking automation
> across local Neutron servers, this Neutron server will be configured
> with the Tricircle Central Neutron Plugin, and is called central
> Neutron server.
>
> Leverage the Tricircle Central Neutron Plugin and the Tricircle Local
> Neutron Plugin configured in these Neutron servers, the Tricircle can
> ensure the IP address pool, IP/MAC address allocation and network
> segment allocation being managed globally without conflict, and the
> Tricircle handles tenant oriented data link layer(Layer2) or network
> layer(Layer3) networking automation across local Neutron servers,
> resources like VMs, bare metal or containers of the tenant can
> communicate with each other via Layer2 or Layer3, no matter in which
> OpenStack cloud these resources are running on.
>
> How to start in Tricircle:
> 1. The best entry point for the Tricircle project is its wiki page:
> https://wiki.openstack.org/wiki/Tricircle. Source code repository is
> https://github.com/openstack/tricircle.
>
> 2. You can play it through devstack:
> https://github.com/openstack/tricircle/blob/master/doc/source/multi-node-
> installation-devstack.rst
>
> 3. The design blueprint provides general overview on the ongoing discussion
> on the design:
> https://docs.google.com/document/d/1zcxwl8xMEpxVCqLTce2-dUOtB-
> ObmzJTbV1uSQ6qTsY/edit#
>
> We are trying to tackle common use cases and challenges in OpenStack
> multi-region cloud area, We welcome new contributors who wish to join our
> effort.
>
> We are holding a weekly IRC meeting:
> Weekly on Wednesdays at 1300 UTC, IRC channel: #openstack-meeting
> Project IRC channel and other resources could be found here:
> https://wiki.openstack.org/wiki/Tricircle#Resources.
>
> And everyone is welcome.
>
> (Neutron subject is also included in the mail title, inter-communication
> and collaboration between Neutron and Tricircle is greatly welcome)
>
> 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
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [all][tricircle][neutron]Tricircle now is one of OpenStack Big-Tent project

[joehuang]

Hi all,

Tricircle was officially accepted yesterday as a big-tent project.

The purpose of the Tricircle project is to provide networking automation
across Neutron in multi-region OpenStack clouds deployment.

Use cases for the Tricircle are described in
https://wiki.openstack.org/wiki/Tricircle#Use_Cases.

A brief introduction of Tricircle is provided here:

Each OpenStack cloud includes its own Nova, Cinder and Neutron, the
Neutron servers in these OpenStack clouds are called local Neuron
servers, all these local Neutron servers will be configured with the
Tricircle Local Neutron Plugin. A seperate Neutron server will be
installed and run standalone as the coordinator of networking automation
across local Neutron servers, this Neutron server will be configured
with the Tricircle Central Neutron Plugin, and is called central
Neutron server.

Leverage the Tricircle Central Neutron Plugin and the Tricircle Local
Neutron Plugin configured in these Neutron servers, the Tricircle can
ensure the IP address pool, IP/MAC address allocation and network
segment allocation being managed globally without conflict, and the
Tricircle handles tenant oriented data link layer(Layer2) or network
layer(Layer3) networking automation across local Neutron servers,
resources like VMs, bare metal or containers of the tenant can
communicate with each other via Layer2 or Layer3, no matter in which
OpenStack cloud these resources are running on.

How to start in Tricircle:
1. The best entry point for the Tricircle project is its wiki page:
https://wiki.openstack.org/wiki/Tricircle. Source code repository is
https://github.com/openstack/tricircle.

2. You can play it through devstack:
https://github.com/openstack/tricircle/blob/master/doc/source/multi-node-installation-devstack.rst

3. The design blueprint provides general overview on the ongoing discussion
on the design:
https://docs.google.com/document/d/1zcxwl8xMEpxVCqLTce2-dUOtB-ObmzJTbV1uSQ6qTsY/edit#

We are trying to tackle common use cases and challenges in OpenStack
multi-region cloud area, We welcome new contributors who wish to join our
effort.

We are holding a weekly IRC meeting:
Weekly on Wednesdays at 1300 UTC, IRC channel: #openstack-meeting
Project IRC channel and other resources could be found here:
https://wiki.openstack.org/wiki/Tricircle#Resources.

And everyone is welcome.

(Neutron subject is also included in the mail title, inter-communication
and collaboration between Neutron and Tricircle is greatly welcome)

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

Re: [openstack-dev] [neutron] OVO support

[Kevin Benton]

We won't be able to take a hard and fast rule on this just because of the
way Neutron currently works and the semantics we offer the mechanism
drivers and extensions in ML2.

Right now when a port is created in ML2, we allow extensions and mechanism
drivers to make changes as part of the same transaction. If we completely
defer transaction handling to the OVO framework, it will break these
semantics.

We can certainly work to move as much of the handling for simpler cases
(e.g. security group rule creation) into the OVO framework, but there are
others like the one above where we will need to start a transaction first
and leave it open across multiple operations.

On Tue, Nov 15, 2016 at 6:15 AM, Morales, Victor 
wrote:

> My two cents on this.
>
> OVO is going to be the new layer to access to DB model classes, therefore
> all the calls to the database(ensuring that there is an opened session) and
> the process to receive(validating fields) and/or return data(determining if
> a specific column exists) should be managed by OVO classes internally, so
> that’s also my understanding.
>
> Regards,
> Victor Morales
>
> From:  Gary Kotton 
> Reply-To:  "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> Date:  Tuesday, November 15, 2016 at 3:06 AM
> To:  OpenStack List 
> Subject:  [openstack-dev] [neutron] OVO support
>
>
> Hi,
> It seems like a lot of the object work is being done under database
> transactions. My understanding is that the objects should take care of this
> internally.
> Any thoughts?
> Thanks
> Gary
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [neutron][lbaasv2][octavia] Not able to create loadbalancer

[Ganpat Agarwal]

Hi All,

I am using devstack stable/newton branch and have deployed octavia for
neutron-lbaasv2.

Here is my local.conf

[[local|localrc]]
HOST_IP=10.0.2.15
DATABASE_PASSWORD=$ADMIN_PASSWORD
MYSQL_PASSWORD=$ADMIN_PASSWORD
RABBIT_PASSWORD=$ADMIN_PASSWORD
SERVICE_PASSWORD=$ADMIN_PASSWORD
SERVICE_TOKEN=tokentoken
DEST=/opt/stack

# Disable Nova Network and enable Neutron
disable_service n-net
enable_service q-svc
enable_service q-agt
enable_service q-dhcp
enable_service q-l3
enable_service q-meta

# Enable LBaaS v2
enable_plugin neutron-lbaas
https://git.openstack.org/openstack/neutron-lbaas stable/newton
enable_plugin octavia https://git.openstack.org/openstack/octavia
stable/newton
enable_service q-lbaasv2
enable_service octavia
enable_service o-cw
enable_service o-hm
enable_service o-hk
enable_service o-api

# Neutron options
Q_USE_SECGROUP=True
FLOATING_RANGE="172.18.161.0/24"
FIXED_RANGE="10.0.0.0/24"
Q_FLOATING_ALLOCATION_POOL=start=172.18.161.250,end=172.18.161.254
PUBLIC_NETWORK_GATEWAY="172.18.161.1"
PUBLIC_INTERFACE=eth0

LOG=True
VERBOSE=True
LOGFILE=$DEST/logs/stack.sh.log
LOGDAYS=1
SCREEN_LOGDIR=$DEST/logs/screen
SYSLOG=True
SYSLOG_HOST=$HOST_IP
SYSLOG_PORT=516
RECLONE=yes


While creating loadbalancer, i am getting error in octavia worker

2016-11-16 06:13:08.264 4115 INFO octavia.controller.queue.consumer [-]
Starting consumer...
2016-11-16 06:14:58.507 4115 INFO octavia.controller.queue.endpoint [-]
Creating load balancer '51082942-b348-4900-bde9-6d617dba8f99'...
2016-11-16 06:14:59.204 4115 INFO
octavia.controller.worker.tasks.database_tasks [-] Created Amphora in DB
with id 93e28edd-71ee-4448-bc70-b0424dbd64f5
2016-11-16 06:14:59.334 4115 INFO octavia.certificates.generator.local [-]
Signing a certificate request using OpenSSL locally.
2016-11-16 06:14:59.336 4115 INFO octavia.certificates.generator.local [-]
Using CA Certificate from config.
2016-11-16 06:14:59.336 4115 INFO octavia.certificates.generator.local [-]
Using CA Private Key from config.
2016-11-16 06:14:59.337 4115 INFO octavia.certificates.generator.local [-]
Using CA Private Key Passphrase from config.
2016-11-16 06:15:15.085 4115 INFO
octavia.controller.worker.tasks.database_tasks [-] Mark ALLOCATED in DB for
amphora: 93e28edd-71ee-4448-bc70-b0424dbd64f5 with compute id
f339b48d-1445-47e0-950b-ee69c2add81f for load balancer:
51082942-b348-4900-bde9-6d617dba8f99
2016-11-16 06:15:15.208 4115 INFO
octavia.network.drivers.neutron.allowed_address_pairs [-] Port
ac27cbb8-078d-47fd-824c-e95b0ebff392 already exists. Nothing to be done.
2016-11-16 06:15:39.708 4115 WARNING
octavia.amphorae.drivers.haproxy.rest_api_driver [-] Could not connect to
instance. Retrying.
2016-11-16 06:15:47.712 4115 WARNING
octavia.amphorae.drivers.haproxy.rest_api_driver [-] Could not connect to
instance. Retrying.

several 100 lines with same message

2016-11-16 06:24:29.310 4115 WARNING
octavia.amphorae.drivers.haproxy.rest_api_driver [-] Could not connect to
instance. Retrying.
^[2016-11-16 06:24:34.316 4115 WARNING
octavia.amphorae.drivers.haproxy.rest_api_driver [-] Could not connect to
instance. Retrying.
2016-11-16 06:24:39.317 4115 ERROR
octavia.amphorae.drivers.haproxy.rest_api_driver [-] Connection retries
(currently set to 100) exhausted.  The amphora is unavailable.
2016-11-16 06:24:39.327 4115 WARNING
octavia.controller.worker.controller_worker [-] Task
'octavia.controller.worker.tasks.amphora_driver_tasks.AmphoraePostVIPPlug'
(19f29ca9-3e7f-4629-b976-b4d24539d8ed) transitioned into state 'FAILURE'
from state 'RUNNING'
33 predecessors (most recent first):
  Atom
'octavia.controller.worker.tasks.network_tasks.GetAmphoraeNetworkConfigs'
{'intention': 'EXECUTE', 'state': 'SUCCESS', 'requires': {'loadbalancer':
},
'provides': {u'93e28edd-71ee-4448-bc70-b0424dbd64f5':
}}
  |__Atom 'reload-lb-after-plug-vip' {'intention': 'EXECUTE', 'state':
'SUCCESS', 'requires': {'loadbalancer_id':
u'51082942-b348-4900-bde9-6d617dba8f99'}, 'provides':
}
 |__Atom
'octavia.controller.worker.tasks.database_tasks.UpdateAmphoraVIPData'
{'intention': 'EXECUTE', 'state': 'SUCCESS', 'requires': {'amps_data':
[]},
'provides': None}
|__Atom 'octavia.controller.worker.tasks.network_tasks.PlugVIP'
{'intention': 'EXECUTE', 'state': 'SUCCESS', 'requires': {'loadbalancer':
},
'provides': []}
   |__Atom
'octavia.controller.worker.tasks.database_tasks.UpdateVIPAfterAllocation'
{'intention': 'EXECUTE', 'state': 'SUCCESS', 'requires': {'vip':
,
'loadbalancer_id': u'51082942-b348-4900-bde9-6d617dba8f99'}, 'provides':
}
  |__Atom
'octavia.controller.worker.tasks.network_tasks.AllocateVIP' {'intention':
'EXECUTE', 'state': 'SUCCESS', 'requires': {'loadbalancer':
},
'provides': }
 |__Flow 'octavia-new-loadbalancer-net-subflow'
|__Atom
'octavia-post-loadbalancer-amp_association-subflow-octavia-post-loadbalancer-amp_association-subflow-reload-lb-after-amp-assoc'
{'intention': 'EXECUTE', 'state': 'SUCCESS', 

Re: [openstack-dev] oaktree - a friendly end-user oriented API layer - anybody want to help?

[joehuang]

> Glance Image Uploads and Swift Object Uploads (and downloads). Having
> those two data operations go through an API proxy seems inefficient.
> However, having them not in the API seems like a bad user experience.
> Perhaps if we take advantage of the gRPC streaming protocol support
> doing a direct streaming passthrough actually wouldn't be awful. Or
> maybe the better approach would be for the gRPC call to return a URL and
> token for a user to POST/PUT to directly. Literally no clue.

>From bandwidth consideration, the bandwidth for the API service like Oaktree 
may not as wide as that for data storage service, for example Swift. That means
if the Oaktree will proxy the image upload, then the bandwidth for the Oaktree
sever may be exhausted soon, and not  able to provide other API service.

It's good in Glance V2 that image could be update to a store, then register the 
location
to a Glance image, but not directly upload bits to Glance API directly.

Best Regards
Chaoyi Huang (joehuang)


From: Monty Taylor [mord...@inaugust.com]
Sent: 15 November 2016 22:56
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] oaktree - a friendly end-user oriented API layer - 
anybody want to help?

Hey everybody!

At this past OpenStack Summit the results of the Interop Challenge were
shown on stage. It was pretty awesome - 17 different people from 17
different clouds ran the same workload. And it worked!

However, one of the reasons it worked is because they all used the
Ansible modules we wrote that are based on the shade library that
contains the business logic needed to hide vendor differences in clouds.
That means that there IS a fantastic OpenStack interoperability story -
but only if you program in Python. That's less awesome.

With that in mind - I'm pleased to announce a new project that aims to
address that - oaktree.

oaktree is a gRPC-based API porcelain service for OpenStack that is
based on the shade library and I'd love some help in writing it.

Basing oaktree on shade gets not only the business logic. Shade already
understands a multi-cloud world. And because we use shade in Infra for
nodepool, it already has caching, batching and thundering herd
protection sorted to be able to hand very high loads efficiently. So
while oaktree is new, the primary logic and fundamentals are all shade
and are battle-tested.

The barrier to deployers adding it to their clouds needs to be as low as
humanly possible. So as we work on it, ensuring that we keep it
dead-simple to install, update and operate must be a primary concern.

Where are we and what's next?

oaktree doesn't do a whole lot that's terribly interesting at the
moment. We have all of the development scaffolding and gate jobs set up
and a few functions implemented.

oaktree exists currently as two repos - oaktree and oaktreemodel:

  http://git.openstack.org/cgit/openstack/oaktree
  http://git.openstack.org/cgit/openstack/oaktreemodel

oaktreemodel contains the Protobuf definitions and the build scripts to
produce Python, C++ and Go code from them. The python code is published
to PyPI as a normal pure-python library. The C++ code is published as a
source tarball and the Go code is checked back in to the same repo so
that go works properly.

oaktree depends on the python oaktreemodel library, and also on shade.
It implements the server portion of the gRPC service definition.

Currently, oaktree can list and search for flavors, images and floating
ips. Exciting right? Most of the work to expose the rest of the API that
shade can provide at the moment is going to be fairly straightforward -
although in each case figuring out the best mapping will take some care.

We have a few major things that need some good community design. These
are also listed in a todo.rst file in the oaktree repo which is part of
the docs:

  http://oaktree.readthedocs.io/en/latest/

The auth story. The native/default auth for gRPC is oauth. It has the
ability for pluggable auth, but that would raise the barrier for new
languages. I'd love it if we can come up with a story that involves
making API users in keystone and authorizing them to use oaktree via an
oauth transaction. The keystone auth backends currently are all about
integrating with other auth management systems, which is great for
environments where you have a web browser, but not so much for ones
where you need to put your auth credentials into a file so that your
scripts can work. I'm waving my hands wildly here - because all I really
have are problems to solve and none of the solutions I have are great.

Glance Image Uploads and Swift Object Uploads (and downloads). Having
those two data operations go through an API proxy seems inefficient.
However, having them not in the API seems like a bad user experience.
Perhaps if we take advantage of the gRPC streaming protocol support
doing a direct streaming passthrough actually wouldn't be awful. Or

[openstack-dev] [Horizon] Meeting at 20:00 UTC this Wednesday, 16th November

[Richard Jones]

Hi folks,

The Horizon team will be having our next meeting at 20:00 UTC this
Wednesday, 16th November in #openstack-meeting-3

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

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


Cheers,

Richard

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

[openstack-dev] [neutron] neutron-lib impact

[Armando M.]

Hi neutrinos,

As mentioned during the last team meeting [1], there is a change [2] in the
works aimed at adopting the neutron plugins directory as provided in
neutron-lib 1.0.0 [3].

As shown in [2], the switch to using the directory is relatively
straightforward. I leave the rest of the affected repos as an exercise for
the reader :)

Cheers,
Armando

[1] http://eavesdrop.openstack.org/meetings/networking/2016/networking.
2016-11-14-21.00.txt
[2] https://review.openstack.org/#/q/topic:plugin-directory
[3] http://docs.openstack.org/releasenotes/neutron-lib/unreleased.html#id3
__
OpenStack Development Mailing 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] [Ironic] Baremetal Storage Service?

[Jay Pipes]

On 11/14/2016 10:22 PM, Akira Yoshiyama wrote:

2016-11-14 2:19 GMT+09:00 Jay Pipes >:

On 11/13/2016 01:52 AM, Akira Yoshiyama wrote:

No. "physical storages" means storage products like EMC VNX, NetApp
Data ONTAP, HPE Lefthand and so on.
Say there is a new service named X to manage them. A user, he/she will
be a new IaaS admin, requests many baremetal servers to Ironic and
some baremetal storages to X. After they are provided, he/she will
start to build a new OpenStack deployment with them. Nova in the new
one will provide VMs on the servers and Cinder will manage logical
volumes on the storages. X doesn't manage each logical volume but
pools, user accounts and network connections of the storages.


Yeah, I personally believe that is the domain of configuration management
systems not OpenStack HTTP API services. What you are describing is not a
multi-tenant HTTP API service, it's an IT/storage admin automation tool.

Incidentally, Ironic isn't multi-tenant either. It lives in the weird land
in OpenStack of being an HTTP API service that isn't meant for "normal
users" so in order to provider a cloud service (BareMetal-as-a-Service),
Ironic *requires* Nova to provide the multi-tenancy aspects of the
"as-a-Service" part of the software.


Hmm... so, if I built a (multi-tenant) baremetal IaaS service like SoftLayer
with OpenStack Newton release, tenant users can deploy an OpenStack
environment with cinder using SDS on it. No physical storages.


I think what you're trying to describe is that you want to build a cloud 
reseller platform where the reseller tenants would be able to provision 
raw storage for an OpenStack deployment that is then resold to end-users 
as a hosted cloud service.


Is that correct?

If so, yeah, there really isn't anything like that in the OpenStack 
ecosystem, and frankly, I think it would be a tough sell to have that in 
OpenStack because it is so very deployer and vendor-specific. 
Essentially you want to allow reseller tenants to make SAN hardware 
management calls via an API that is exposed through the normal OpenStack 
HTTP APIs. And I don't think that is something that is all that 
abstractable :(


Best,
-jay


Ironic is great, of course, but it ain't a cloud service without help from
Nova.

Best,
-jay


BR,
Akira


__
OpenStack Development Mailing 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] [kolla][kubernetes] kolla-kubernetes spec voting delay

[Swapnil Kulkarni]

On Wed, Nov 16, 2016 at 8:01 AM, Swapnil Kulkarni  wrote:
> On Wed, Nov 16, 2016 at 7:30 AM, Ryan Hallisey  wrote:
>> Hey folks,
>>
>> There has been a lot of input in the spec and tons IRC discussion
>> over the last two days.  I'm glad the discussion is very active :).
>>
>> The goal of the spec is to capture the ideas and the discussion in
>> one readable doc so no one has to read the 1 lines of IRC
>> discussion that has occurred. Right now, the spec reflects about 95%
>> of the discussion so it isn't complete. Therefore, voting will be
>> delayed at least another day from the deadline I set (today).
>>
>> Thanks,
>> -Ryan
>>
>> https://review.openstack.org/#/c/392257/
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> Thanks Ryan. I would appreciate if you could highlight some related
> information (e.g. reading material, tools) for new contributors to
> gain more insight into terminologies that one can refer to during or
> prior reading the spec and get better understanding.
>
> ~coolsvap



Jus to provide the background,  I saw on the IRC that there was some
confusion or need for more information was raised related to operator.

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

[Swapnil Kulkarni]

On Wed, Nov 16, 2016 at 7:30 AM, Ryan Hallisey  wrote:
> Hey folks,
>
> There has been a lot of input in the spec and tons IRC discussion
> over the last two days.  I'm glad the discussion is very active :).
>
> The goal of the spec is to capture the ideas and the discussion in
> one readable doc so no one has to read the 1 lines of IRC
> discussion that has occurred. Right now, the spec reflects about 95%
> of the discussion so it isn't complete. Therefore, voting will be
> delayed at least another day from the deadline I set (today).
>
> Thanks,
> -Ryan
>
> https://review.openstack.org/#/c/392257/
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Thanks Ryan. I would appreciate if you could highlight some related
information (e.g. reading material, tools) for new contributors to
gain more insight into terminologies that one can refer to during or
prior reading the spec and get better understanding.

~coolsvap

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

[openstack-dev] [neutron] [vpnaas] vpnaas no longer part of the neutron governance

[Armando M.]

Hi

As of today, the project neutron-vpnaas is no longer part of the neutron
governance. This was a decision reached after the project saw a dramatic
drop in active development over a prolonged period of time.

What does this mean in practice?

   - From a visibility point of view, release notes and documentation will
   no longer appear on openstack.org as of Ocata going forward.
   - No more releases will be published by the neutron release team.
   - The neutron team will stop proposing fixes for the upstream CI, if not
   solely on a voluntary basis (e.g. I still felt like proposing [2]).

How does it affect you, the user or the deployer?

   - You can continue to use vpnaas and its CLI via the
   python-neutronclient and expect it to work with neutron up until the newton
   release/python-neutronclient 6.0.0. After this point, if you want a release
   that works for Ocata or newer, you need to proactively request a release
   [5], and reach out to a member of the neutron release team [3] for
   approval. Assuming that the vpnaas CI is green, you can expect to have a
   working vpnaas system upon release of its package in the foreseeable future.
   - Outstanding bugs and new bug reports will be rejected on the basis of
   lack of engineering resources interested in helping out in the typical
   OpenStack review workflow.
   - Since we are freezing the development of the neutron CLI in favor of
   the openstack unified client (OSC), the lack of a plan to make the VPN
   commands available in the OSC CLI means that at some point in the future
   the neutron client CLI support for vpnaas may be dropped (though I don't
   expect this to happen any time soon).

Can this be reversed?

   - If you are interested in reversing this decision, now it is time to
   step up. That said, we won't be reversing the decision for Ocata. There is
   quite a curve to ramp up to make neutron-vpnaas worthy of being classified
   as a neutron stadium project, and that means addressing all the gaps
   identified in [6]. If you are interested, please reach out, and I will work
   with you to add your account to [4], so that you can drive the
   neutron-vpnaas agenda going forward.

Please do not hesitate to reach out to ask questions and/or clarifications.

Cheers,
Armando

[1] https://review.openstack.org/#/c/392010/
[2] https://review.openstack.org/#/c/397924/
[3] https://review.openstack.org/#/admin/groups/150,members
[4] https://review.openstack.org/#/admin/groups/502,members
[5] https://github.com/openstack/releases
[6]
http://specs.openstack.org/openstack/neutron-specs/specs/stadium/ocata/neutron-vpnaas.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-dev] [kolla][kubernetes] kolla-kubernetes spec voting delay

[Ryan Hallisey]

Hey folks,

There has been a lot of input in the spec and tons IRC discussion
over the last two days.  I'm glad the discussion is very active :).

The goal of the spec is to capture the ideas and the discussion in
one readable doc so no one has to read the 1 lines of IRC
discussion that has occurred. Right now, the spec reflects about 95%
of the discussion so it isn't complete. Therefore, voting will be
delayed at least another day from the deadline I set (today).

Thanks,
-Ryan

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

__
OpenStack Development Mailing 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] oaktree - a friendly end-user oriented API layer - anybody want to help?

[Morgan Fainberg]

On Tue, Nov 15, 2016 at 5:16 PM, Jay Pipes  wrote:

> Awesome start, Monty :) Comments inline.
>
> On 11/15/2016 09:56 AM, Monty Taylor wrote:
>
>> Hey everybody!
>>
>> At this past OpenStack Summit the results of the Interop Challenge were
>> shown on stage. It was pretty awesome - 17 different people from 17
>> different clouds ran the same workload. And it worked!
>>
>> However, one of the reasons it worked is because they all used the
>> Ansible modules we wrote that are based on the shade library that
>> contains the business logic needed to hide vendor differences in clouds.
>> That means that there IS a fantastic OpenStack interoperability story -
>> but only if you program in Python. That's less awesome.
>>
>> With that in mind - I'm pleased to announce a new project that aims to
>> address that - oaktree.
>>
>> oaktree is a gRPC-based API porcelain service for OpenStack that is
>> based on the shade library and I'd love some help in writing it.
>>
>> Basing oaktree on shade gets not only the business logic. Shade already
>> understands a multi-cloud world. And because we use shade in Infra for
>> nodepool, it already has caching, batching and thundering herd
>> protection sorted to be able to hand very high loads efficiently. So
>> while oaktree is new, the primary logic and fundamentals are all shade
>> and are battle-tested.
>>
>
> ++ muy bueno.
>
> The barrier to deployers adding it to their clouds needs to be as low as
>> humanly possible. So as we work on it, ensuring that we keep it
>> dead-simple to install, update and operate must be a primary concern.
>>
>> Where are we and what's next?
>>
>> oaktree doesn't do a whole lot that's terribly interesting at the
>> moment. We have all of the development scaffolding and gate jobs set up
>> and a few functions implemented.
>>
>> oaktree exists currently as two repos - oaktree and oaktreemodel:
>>
>>   http://git.openstack.org/cgit/openstack/oaktree
>>   http://git.openstack.org/cgit/openstack/oaktreemodel
>>
>> oaktreemodel contains the Protobuf definitions and the build scripts to
>> produce Python, C++ and Go code from them. The python code is published
>> to PyPI as a normal pure-python library. The C++ code is published as a
>> source tarball and the Go code is checked back in to the same repo so
>> that go works properly.
>>
>
> Very nice. I recently started playing around with gRPC myself for some
> ideas I had about replacing part of nova-compute with a Golang worker
> service that can tolerate lengthy disconnections with a centralized control
> plane (hello, v[E]CPE!).
>
> It's been (quite) a few years since I last used protobufs (hey, remember
> Drizzle?) but it's been a blast getting back into protobufs development.
> Now that I see you're using a similar approach for oaktree, I'm definitely
> interested in contributing.
>
> oaktree depends on the python oaktreemodel library, and also on shade.
>> It implements the server portion of the gRPC service definition.
>>
>> Currently, oaktree can list and search for flavors, images and floating
>> ips. Exciting right? Most of the work to expose the rest of the API that
>> shade can provide at the moment is going to be fairly straightforward -
>> although in each case figuring out the best mapping will take some care.
>>
>> We have a few major things that need some good community design. These
>> are also listed in a todo.rst file in the oaktree repo which is part of
>> the docs:
>>
>>   http://oaktree.readthedocs.io/en/latest/
>>
>> The auth story. The native/default auth for gRPC is oauth. It has the
>> ability for pluggable auth, but that would raise the barrier for new
>> languages. I'd love it if we can come up with a story that involves
>> making API users in keystone and authorizing them to use oaktree via an
>> oauth transaction.
>>
>
> ++
>
> > The keystone auth backends currently are all about
>
>> integrating with other auth management systems, which is great for
>> environments where you have a web browser, but not so much for ones
>> where you need to put your auth credentials into a file so that your
>> scripts can work. I'm waving my hands wildly here - because all I really
>> have are problems to solve and none of the solutions I have are great.
>>
>> Glance Image Uploads and Swift Object Uploads (and downloads). Having
>> those two data operations go through an API proxy seems inefficient.
>>
>
> Uh, yeah :)
>
> However, having them not in the API seems like a bad user experience.
>> Perhaps if we take advantage of the gRPC streaming protocol support
>> doing a direct streaming passthrough actually wouldn't be awful. Or
>> maybe the better approach would be for the gRPC call to return a URL and
>> token for a user to POST/PUT to directly. Literally no clue.
>>
>> In any case - I'd love help from anyone who thinks this sounds like a
>> good idea. In a perfect world we'll have something ready for 1.0 by
>> Atlanta.
>>
>
> I'll try my best to dig into the 

Re: [openstack-dev] oaktree - a friendly end-user oriented API layer - anybody want to help?

[Jay Pipes]

Awesome start, Monty :) Comments inline.

On 11/15/2016 09:56 AM, Monty Taylor wrote:

Hey everybody!

At this past OpenStack Summit the results of the Interop Challenge were
shown on stage. It was pretty awesome - 17 different people from 17
different clouds ran the same workload. And it worked!

However, one of the reasons it worked is because they all used the
Ansible modules we wrote that are based on the shade library that
contains the business logic needed to hide vendor differences in clouds.
That means that there IS a fantastic OpenStack interoperability story -
but only if you program in Python. That's less awesome.

With that in mind - I'm pleased to announce a new project that aims to
address that - oaktree.

oaktree is a gRPC-based API porcelain service for OpenStack that is
based on the shade library and I'd love some help in writing it.

Basing oaktree on shade gets not only the business logic. Shade already
understands a multi-cloud world. And because we use shade in Infra for
nodepool, it already has caching, batching and thundering herd
protection sorted to be able to hand very high loads efficiently. So
while oaktree is new, the primary logic and fundamentals are all shade
and are battle-tested.


++ muy bueno.


The barrier to deployers adding it to their clouds needs to be as low as
humanly possible. So as we work on it, ensuring that we keep it
dead-simple to install, update and operate must be a primary concern.

Where are we and what's next?

oaktree doesn't do a whole lot that's terribly interesting at the
moment. We have all of the development scaffolding and gate jobs set up
and a few functions implemented.

oaktree exists currently as two repos - oaktree and oaktreemodel:

  http://git.openstack.org/cgit/openstack/oaktree
  http://git.openstack.org/cgit/openstack/oaktreemodel

oaktreemodel contains the Protobuf definitions and the build scripts to
produce Python, C++ and Go code from them. The python code is published
to PyPI as a normal pure-python library. The C++ code is published as a
source tarball and the Go code is checked back in to the same repo so
that go works properly.


Very nice. I recently started playing around with gRPC myself for some 
ideas I had about replacing part of nova-compute with a Golang worker 
service that can tolerate lengthy disconnections with a centralized 
control plane (hello, v[E]CPE!).


It's been (quite) a few years since I last used protobufs (hey, remember 
Drizzle?) but it's been a blast getting back into protobufs development. 
Now that I see you're using a similar approach for oaktree, I'm 
definitely interested in contributing.



oaktree depends on the python oaktreemodel library, and also on shade.
It implements the server portion of the gRPC service definition.

Currently, oaktree can list and search for flavors, images and floating
ips. Exciting right? Most of the work to expose the rest of the API that
shade can provide at the moment is going to be fairly straightforward -
although in each case figuring out the best mapping will take some care.

We have a few major things that need some good community design. These
are also listed in a todo.rst file in the oaktree repo which is part of
the docs:

  http://oaktree.readthedocs.io/en/latest/

The auth story. The native/default auth for gRPC is oauth. It has the
ability for pluggable auth, but that would raise the barrier for new
languages. I'd love it if we can come up with a story that involves
making API users in keystone and authorizing them to use oaktree via an
oauth transaction.


++

> The keystone auth backends currently are all about

integrating with other auth management systems, which is great for
environments where you have a web browser, but not so much for ones
where you need to put your auth credentials into a file so that your
scripts can work. I'm waving my hands wildly here - because all I really
have are problems to solve and none of the solutions I have are great.

Glance Image Uploads and Swift Object Uploads (and downloads). Having
those two data operations go through an API proxy seems inefficient.


Uh, yeah :)


However, having them not in the API seems like a bad user experience.
Perhaps if we take advantage of the gRPC streaming protocol support
doing a direct streaming passthrough actually wouldn't be awful. Or
maybe the better approach would be for the gRPC call to return a URL and
token for a user to POST/PUT to directly. Literally no clue.

In any case - I'd love help from anyone who thinks this sounds like a
good idea. In a perfect world we'll have something ready for 1.0 by Atlanta.


I'll try my best to dig into the code this week/end.

Best,
-jay


Join us in #openstack-shade if you want to hack.

Thanks!
Monty


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

Re: [openstack-dev] [kolla] Kolla-ansible is available

[Fox, Kevin M]

whats the plan for genconfig? its based on ansible right now, but may fit 
better as a non ansible specific tool?

Thanks,
Kevin

From: Michał Jastrzębski [inc...@gmail.com]
Sent: Tuesday, November 15, 2016 9:53 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [kolla] Kolla-ansible is available

Hello,

I wanted to thank Steve for doing the work, but kolla-ansible is now
open for business:)

Couple of clarifications how it's going to work:

1. Currently Kolla-ansible is copy from kolla repo. We will need to
propose patches to remove docker from it. Also remove ansible bits
from kolla.
2. Any outstanding ansible change should be closed and re-posted to
kolla-ansible repo.
3. Build gates should be dropped from kolla-ansible, deploy gates
should be removed from kolla
4. Core team for kolla-ansible is copy of kolla core team, but teams
are separate and at some point might diverge from each other.
5. Kolla-ansible has it's own launchpad and we should migrate all
relevant bugs and blueprints out there.
6. Kolla-ansibe will use same version number as Kolla (so first tag
will be 4.0.0b1)

Questions?

Regards,
Michal

__
OpenStack Development Mailing 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] Gerrit downtime on Tuesday 2016-11-22 at 21:00UTC

[Ian Wienand]

Hi everyone,

On Tuesday, November 22nd from approximately 21:00 through 21:30 UTC
Gerrit will be unavailable while we complete project renames.

Currently, we plan on renaming the following projects:

 rsc -> valence

Existing reviews, project watches, etc, for these projects will all be
carried over.

This list is subject to change. If you need a rename, please be sure
to get your project-config change in soon so we can review it and add
it to 
https://wiki.openstack.org/wiki/Meetings/InfraTeamMeeting#Upcoming_Project_Renames


If you have any questions about the maintenance, please reply here or
contact us in #openstack-infra on freenode.

-i

__
OpenStack Development Mailing 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] Problem with Quota and servers spawned in groups

[melanie witt]

On Tue, 15 Nov 2016 18:10:40 -0600, Chris Friesen wrote:

I'm in favor of your change, since the existing behaviour doesn't make
sense.

But at some point I guess consistency trumps correctness, and if a new
microversion is necessary to mark the new behaviour then a spec is
required, and at that point we might want to fix the other issues with
multi-boot at the same time.  (Like
https://bugs.launchpad.net/nova/+bug/1458122 )


I think what Sławek is saying is that the quota behavior for 
multi-create already changed at some point in the past, without a spec. 
He did experiments recently that show a multi-create request succeeds as 
long as the min_count is satisfied when there isn't enough quota for 
max_count. This is different than the behavior at the time you opened 
the bug. So it seems the horse has left the barn on this one.


The patch Sławek has up right now aims to make the multi-create behavior 
for server groups consistent with the present behavior of multi-create 
for instances. I'm fine with that but I haven't spent the time to review 
the change properly yet. And I also wanted to find out when the 
multi-create behavior change and what commit changed it.


-melanie

__
OpenStack Development Mailing 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] Problem with Quota and servers spawned in groups

[Chris Friesen]

On 11/15/2016 02:02 AM, Sławek Kapłoński wrote:

Hello,

IMHO receiving multiple uuids is not related to bug which I want to
resolve somehow but if Chris wrote it I thought that it is maybe somehow
related to "spawn multiple instances" feature.
So can You maybe review my patch
https://review.openstack.org/#/c/371592/ to fix
https://bugs.launchpad.net/nova/+bug/1623809 or I really need new specs
for that?


Sorry for the confusion, I just mentioned it as something to consider if we're 
introducing a new spec for multi-boot.


I'm in favor of your change, since the existing behaviour doesn't make sense.

But at some point I guess consistency trumps correctness, and if a new 
microversion is necessary to mark the new behaviour then a spec is required, and 
at that point we might want to fix the other issues with multi-boot at the same 
time.  (Like https://bugs.launchpad.net/nova/+bug/1458122 )


Chris

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

Re: [openstack-dev] [devstack][neutron] - dropping direct route to VMs (FIXED_RANGE)

[Armando M.]

On 15 November 2016 at 15:04, Kevin Benton  wrote:

> Hi all,
>
>
> Right now, we do something in devstack that does not reflect how
> deployments are normally done. We setup a route on the parent host to the
> private tenant network that routes through the tenant's router[1]. This
> behavior originates from a very long time ago[2] and I'm not sure if it
> even works correctly right now (because the tenant router has port address
> translation enabled).
>
> I would like to stop this behavior in devstack for a couple of reasons:
>
> 1. If this works, it works by accident. Neutron doesn't have any
> guarantees of behavior when you are pointing routes to a private network
> via a router that has SNAT enabled.
> 2. This method of accessing the VMs is not how access is gained to VMs in
> normal deployments. If you want a VM to be reachable, either attach to the
> same network with a port, setup a provider network, or assign the VM a
> floating IP.
>
>
> I would like to drop the installation of this route, but I'd like to hear
> if there is anyone relying on this behavior. Reply to this email or comment
> on the patch.[3]
>

Thanks for looking into this. Let me add that this is in relation to bug
[1].

Cheers,
Armando

[1] https://bugs.launchpad.net/devstack/+bug/1629133


>
> 1. https://github.com/openstack-dev/devstack/blob/
> 29d13df1a284f8f1a5973ccc826a475156820d23/lib/neutron_
> plugins/services/l3#L378
> 2. https://review.openstack.org/#/c/13693/
> 3. https://review.openstack.org/397987
>
> __
> OpenStack Development Mailing 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] [devstack][neutron] - dropping direct route to VMs (FIXED_RANGE)

[Kevin Benton]

Hi all,


Right now, we do something in devstack that does not reflect how
deployments are normally done. We setup a route on the parent host to the
private tenant network that routes through the tenant's router[1]. This
behavior originates from a very long time ago[2] and I'm not sure if it
even works correctly right now (because the tenant router has port address
translation enabled).

I would like to stop this behavior in devstack for a couple of reasons:

1. If this works, it works by accident. Neutron doesn't have any guarantees
of behavior when you are pointing routes to a private network via a router
that has SNAT enabled.
2. This method of accessing the VMs is not how access is gained to VMs in
normal deployments. If you want a VM to be reachable, either attach to the
same network with a port, setup a provider network, or assign the VM a
floating IP.


I would like to drop the installation of this route, but I'd like to hear
if there is anyone relying on this behavior. Reply to this email or comment
on the patch.[3]


1.
https://github.com/openstack-dev/devstack/blob/29d13df1a284f8f1a5973ccc826a475156820d23/lib/neutron_plugins/services/l3#L378
2. https://review.openstack.org/#/c/13693/
3. https://review.openstack.org/397987
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Stable] Usefulness of Weekly Meeting

[Tony Breeds]

On Tue, Nov 15, 2016 at 10:25:26AM -0800, Ian Cordasco wrote:
> Hi all,
> 
> So the stable-maintenance team (and liaisons to it) have had a meeting
> scheduled for a while now. Recently, however, we've had trouble
> getting more than one person to attend meetings when we have them.

I need to apologise for letting this happen.  The current arrangement with 2
meetings US/EU and US/AU means that I can only attend the US/AU timeslot, and I
failed to set someone to run the US/EU meeting.  I'd like to propose that we
switch the arrantment to:

US/AU: #openstack-meeting-4 2100 UTC Monday (same time as now different 
room)
AU/EU: #openstack-meeting-4 1000 UTC Monday

Alternate weeks, although we *could* run both meetings on the same day every
2nd week if people wanted.

> I wonder if it would be more useful to less frequent meetings (perhaps
> every other week) and if we need to reschedule them to better serve
> those who plan to attend.

As always it's a question of less often is harder to form a habit.  I'd like to
request we try the new schedule until the PTG and then re-evaluate.

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] [keystone] meeting format poll

[Steve Martinelli]

On Tue, Nov 15, 2016 at 4:53 PM, Jeremy Stanley  wrote:

> On 2016-11-15 15:31:40 -0500 (-0500), Steve Martinelli wrote:
> > I really like the etherpad approach, its nice to see the history from
> > previous meetings
>
> Strange, I personally find it way easier to navigate the change
> history for a MediaWiki page than use the time slider in Etherpad:
>

I don't bother with the time slider, the meeting agenda is never deleted
from the etherpad, we just keep tacking on
__
OpenStack Development Mailing 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] meeting format poll

[Jeremy Stanley]

On 2016-11-15 15:31:40 -0500 (-0500), Steve Martinelli wrote:
> I really like the etherpad approach, its nice to see the history from
> previous meetings

Strange, I personally find it way easier to navigate the change
history for a MediaWiki page than use the time slider in Etherpad:

https://wiki.openstack.org/w/index.php?title=Meetings/KeystoneMeeting=history

It lets you do arbitrary side-by-side diffs between revisions too,
which is convenient for me as a meeting chair. As I don't
participate in Keystone meetings (other than to pester you when you
go over time!), don't take this as me telling you what works best.
Just wanted to make sure nobody thought the wiki option precludes
having a history/audit log.
-- 
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-Infra] [StoryBoard] Meeting Time Rearrangement

[Adam Coldrick]

Hi folks,

Last week at the StoryBoard meeting we discussed the fact that the 
meeting time
has become inconvenient for most of the people who attend. As a result, 
we took

the decision to move the meeting slot to

1900 UTC on Wednesdays in #openstack-meeting

We'll be having our first meeting at the new time tomorrow. Anyone 
interested
in seeing the state of StoryBoard or finding out more about the project 
is
welcome to attend. Our agenda can be found on the wiki[0] and anybody 
should

feel free to add topics they wish to discuss to it.

If anyone is interested in stopping by for a chat and doesn't feel like 
they

want to do so in the meeting, you can find us in #storyboard.

Hope to see some folk around!

Adam (SotK)

[0]: https://wiki.openstack.org/wiki/Meetings/StoryBoard

__
OpenStack Development Mailing 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][networking-bigswitch] tagging a branch and releasing on tarballs.openstack.org

[Doug Hellmann]

Excerpts from Aditya Vaja's message of 2016-11-16 01:50:39 +0530:
> Hi All,
> [Redirect to a more specific mailing list if applicable]
> I’m trying to tag a release on the networking-bigswitch project for 
> stable/newton branch and see if it pops up on 
> https://tarballs.openstack.org/networking-bigswitch/ 
> [https://tarballs.openstack.org/networking-bigswitch/] . Unfortunately, it 
> shows tarballs with ‘dev’ in the name i.e. not the tagged release, but 
> regular builds I guess.
> To back up a few steps, this is what I did after switching to the 
> stable/newton branch, following the steps here [1]: 
> bsn@bcf-controller-vm:~/work/networking-bigswitch$ git tag -s -m "initialize 
> newton branch" 9.40.0 -u "Big Switch Networks" 
> bsn@bcf-controller-vm:~/work/networking-bigswitch$ git push gerrit 9.40.0 
> Counting objects: 2, done. Delta compression using up to 4 threads. 
> Compressing objects: 100% (2/2), done. Writing objects: 100% (2/2), 575 bytes 
> | 0 bytes/s, done. Total 2 (delta 0), reused 0 (delta 0) remote: Processing 
> changes: refs: 1, done To 
> ssh://wolverin...@review.openstack.org:29418/openstack/networking-bigswitch.git
>  * [new tag] 9.40.0 -> 9.40.0 
> bsn@bcf-controller-vm:~/work/networking-bigswitch$
> I’m waiting for something to show up in the ‘release’ section on zuul: 
> http://status.openstack.org/zuul/ , but nothing. Any tips on debugging?
> I tried 'git os-job 9.40.0’ which opens browser with the following link [2], 
> but it returns a message ‘File not found’.
> Aditya via cloudmagic
> [1] https://wiki.openstack.org/wiki/Sahara/How_To_Release 
> [https://wiki.openstack.org/wiki/Sahara/How_To_Release] [2] 
> http://logs.openstack.org/dd/ddcd66da6a671fabd3356c006b17b187dc287164/ 
> [http://logs.openstack.org/dd/ddcd66da6a671fabd3356c006b17b187dc287164/]

Looking at the openstack/networking-bigswitch repo upstream I see
a few issues with the way the release settings are configured, but
I think we can fix them all relatively easily.

1. The tagged release isn't on the newton branch.  In fact, it's
   not on a named branch at all as far as I can tell.

$ git log --graph --oneline --decorate origin/master
origin/stable/newton 9.40.0
* c4b48fb (origin/stable/newton) initialize newton branch with correct
* version and spec file
| * 463afdc (tag: 9.40.0) initialize newton branch with correct version and 
spec file
|/
| * b244d09 (HEAD -> master, origin/master, origin/HEAD) Revert "initialize 
newton branch with correct version, spec file"
| * 0b6bdfe initialize newton branch with correct version and spec file
|/

$ git branch --contains 9.40.0
(no output)

Normally we would have wanted the stable/newton branch created from
an existing tagged release (tag master, then create the branch from
the same commit). One way to fix this would be to recreate the
existing branch, but gerrit doesn't currently know about the commit
that *has* been tagged so I'm not sure what effect recreating the
branch would have. The best guess as to why is that the commit you
tagged locally was pushed, with the tag, to gerrit, but didn't go
through the review process.

I think your best course of action will be to write off 9.40.0 as a bad
release, fix some of these issues, and then tag a new 9.40.1.

2. The way you're doing versioning is non-standard.  You should
   either use tags or hard-coding the value in setup.cfg, but not
   combine the approaches.

We've converted all of the official projects to rely only on tags
because it eliminates the opportunity for a version number to
accidentally regress on a given branch (pbr calculates the version
correctly based on the most recent tag and the number of commits
after it). To fix this, I suggest removing the "version" entry from
your setup.cfg on all branches and then we can sort out the tag
situation mentioned in item 1.

3. The actual version numbers being used are not really ideal.

We've been trying to get everyone to use semantic versioning as a
standard (http://docs.openstack.org/developer/pbr/semver.html).
That said, as an unofficial project you're not required to follow
that standard by the upstream community. Either way, at this point
I think you want to stick with 9.40 as the base version for the
newton branch.  Maybe consider moving to SemVer for ocata.

4. The name field in the setup.cfg is set to "bsnstacklib" rather
than "networking-bigswitch".

I'm curious to know what led to that choice. It will undoubtedly
cause confusion for downstream packagers who are looking for files
in http://tarballs.openstack.org/networking-bigswitch/ because I
think when the packaging jobs are set up the files will go to
http://tarballs.openstack.org/bsnstacklib/ instead -- they will at
the very least use "bsnstacklib" instead of "networking-bigswitch"
within the tarball filename, just as the name results in the PyPI
URL being https://pypi.python.org/pypi/bsnstacklib. As an alternative
example, see http://tarballs.openstack.org/networking-cisco/ and

Re: [openstack-dev] [osc][openstackclient][cliff] translation the command description in help

[Steve Martinelli]

On Tue, Nov 15, 2016 at 4:08 PM, Steve Martinelli 
wrote:

> $ find . -name '*.py' -exec sed -i .bak -e 's/""".*"""/_description=_("&")/g'
> {} \;
>
>
pep8 just burned me here, make sure you add a space between the = operator
__
OpenStack Development Mailing 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] [osc][openstackclient][cliff] translation the command description in help

[Steve Martinelli]

The following is a PSA for all OpenStackClient plugins.

Matt Edmonds filed bug 1636209 [1] against OpenStackClient because the main
help message was not getting translated. In the example below, the "Create
new user" string was not translated (some of the help text was removed for
readability):


$ openstack user create --help
  usage: openstack user create [-h]
  ... [--password ] 

Create new user  <

positional arguments:
  New user name

optional arguments:
  --password < password>   Set user password


As it turns out, this was because we were setting this help message in a
docstring, which could not be marked for translation. cliff was
automatically picking up the docstring and using that (as-designed).

Doug Hellmann fixed the issue for cliff by allowing a class attribute [2],
and I proposed a patch for OpenStackClient [3]. Look for a new cliff
release soon, and a bump to the minimum version in global-requirements.

In case you want to do this in your plugin (assuming you are setup for
translations), and not handcraft 100+ lines, you can run the following
commands (this is what I used, and I'm sure someone will come up with a
better way of doing it)

$ find . -name '*.py' -exec sed -i .bak -e
's/""".*"""/_description=_("&")/g' {} \;
$ find . -type f -name '*.py.bak' -delete
$ git checkout examples/ releasenotes/ openstackclient/tests/

Thanks for reading!
Steve

[1] https://bugs.launchpad.net/python-openstackclient/+bug/1636209
[2] https://review.openstack.org/#/c/397321/
[3] https://review.openstack.org/#/c/396939/
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [heat][tripleo] New repository for software-config elements

[Steve Baker]

On Tue, Nov 15, 2016 at 10:26 PM, Thomas Herve  wrote:

> Hi all,
>
> Historically elements to create images using software config were
> developed in the heat-templates repository, which turned out to mean
> that this had to be packaged, etc. Today we were asked if tags could
> be added to help maintaining the packages. Before we do that, I wonder
> if we should extract the elements in a different repository. We
> already have tests which are only applicable to this specific subset
> of the repo, so it shouldn't be too hard.
>
> In summary: let's create a new repository
> heat-software-config-elements, and move everything from
> hot/software-config/elements/ in the heat-templates repository to it
> (and the associated tests).
>
> Thoughts?
>
>
Yes, these have definitely outgrown their current home.

RDO already generates the following sub-packages from heat-templates:
python-heat-agent
python-heat-agent-puppet
python-heat-agent-ansible
python-heat-agent-apply-config
python-heat-agent-hiera

Therefore can I suggest we call the new repository "heat-agents"?

I do wonder about the usefulness of the diskimage-builder elements-based
directory layout, since image builders can just install the package. But I
suppose having elements will be useful for heat-agents CI jobs, and a more
appropriate layout doesn't occur to me currently.

Also we should consider if we want to retain the git history of these files
in the new repo - I'm in favour if its not too much effort and the
resulting history looks clean.
__
OpenStack Development Mailing 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][libvirt] Lets make libvirt's domain XML canonical

[Matt Riedemann]

On 9/30/2016 11:03 AM, Matthew Booth wrote:



I thought it was a counter-argument (unless I've misunderstood). If you
migrate the instance as-is without modification, you don't need to worry
about whether it's currently a rescue instance. This problem goes away.

The major complication I can think of is things which genuinely must
change during a migration, for example cpu pinning.

Matt

--
Matthew Booth
Red Hat Engineering, Virtualisation Team

Phone: +442070094448 (UK)



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



I'm glad this already came up in this thread as I was just reviewing the 
re-proposal for this spec:


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

There are other issues in the spec which is why I have a -1 on there, 
but I thought it was going directly against what Matt Booth is talking 
about doing wrt storing the guest xml so that we don't need to rely on 
the nova database when recreating a guest, like on reboot - which is 
exactly what that spec is proposing, just hard-reboot the live migrated 
guest on unrescue.


--

Thanks,

Matt Riedemann


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

Re: [openstack-dev] [keystone] meeting format poll

[Morgan Fainberg]

I agree with Steve. I just want to highlight that the wiki is viable again
if we wanted to change. The move to etherpad was a necessity, now we have
options we should be sure eveyrone is still happy with it.

On Tue, Nov 15, 2016 at 12:31 PM, Steve Martinelli 
wrote:

> I really like the etherpad approach, its nice to see the history from
> previous meetings
>
> On Tue, Nov 15, 2016 at 2:39 PM, Lance Bragstad 
> wrote:
>
>> Hey folks,
>>
>> In today's keystone meeting, Morgan mentioned that we had the ability to
>> go back to using OpenStack Wikis for meeting agendas. I created a poll to
>> get feedback [0].
>>
>> Let's keep it open for the week and look at the results as a team at our
>> next meeting.
>>
>> Thanks!
>>
>> [0] https://goo.gl/forms/Gs4lZxgktRzlwHAn2
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone] meeting format poll

[Steve Martinelli]

I really like the etherpad approach, its nice to see the history from
previous meetings

On Tue, Nov 15, 2016 at 2:39 PM, Lance Bragstad  wrote:

> Hey folks,
>
> In today's keystone meeting, Morgan mentioned that we had the ability to
> go back to using OpenStack Wikis for meeting agendas. I created a poll to
> get feedback [0].
>
> Let's keep it open for the week and look at the results as a team at our
> next meeting.
>
> Thanks!
>
> [0] https://goo.gl/forms/Gs4lZxgktRzlwHAn2
>
> __
> OpenStack Development Mailing 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] tagging a branch and releasing on tarballs.openstack.org

[Aditya Vaja]

Hi All,
[Redirect to a more specific mailing list if applicable]
I’m trying to tag a release on the networking-bigswitch project for 
stable/newton branch and see if it pops up on 
https://tarballs.openstack.org/networking-bigswitch/ 
[https://tarballs.openstack.org/networking-bigswitch/] . Unfortunately, it 
shows tarballs with ‘dev’ in the name i.e. not the tagged release, but regular 
builds I guess.
To back up a few steps, this is what I did after switching to the stable/newton 
branch, following the steps here [1]: 
bsn@bcf-controller-vm:~/work/networking-bigswitch$ git tag -s -m "initialize 
newton branch" 9.40.0 -u "Big Switch Networks" 
bsn@bcf-controller-vm:~/work/networking-bigswitch$ git push gerrit 9.40.0 
Counting objects: 2, done. Delta compression using up to 4 threads. Compressing 
objects: 100% (2/2), done. Writing objects: 100% (2/2), 575 bytes | 0 bytes/s, 
done. Total 2 (delta 0), reused 0 (delta 0) remote: Processing changes: refs: 
1, done To 
ssh://wolverin...@review.openstack.org:29418/openstack/networking-bigswitch.git 
* [new tag] 9.40.0 -> 9.40.0 bsn@bcf-controller-vm:~/work/networking-bigswitch$
I’m waiting for something to show up in the ‘release’ section on zuul: 
http://status.openstack.org/zuul/ , but nothing. Any tips on debugging?
I tried 'git os-job 9.40.0’ which opens browser with the following link [2], 
but it returns a message ‘File not found’.
Aditya via cloudmagic
[1] https://wiki.openstack.org/wiki/Sahara/How_To_Release 
[https://wiki.openstack.org/wiki/Sahara/How_To_Release] [2] 
http://logs.openstack.org/dd/ddcd66da6a671fabd3356c006b17b187dc287164/ 
[http://logs.openstack.org/dd/ddcd66da6a671fabd3356c006b17b187dc287164/]__
OpenStack Development Mailing 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][requirements] openstack_requirements 1.0.0 release

[no-reply]

We are psyched to announce the release of:

openstack_requirements 1.0.0: OpenStack python dependency management
tools

This is the first release of openstack_requirements.

Download the package from:

https://pypi.python.org/pypi/openstack_requirements

For more details, please see below.

Changes in openstack_requirements 
b788389acce5ea0dd1fcbf16bc4f402d5229491f..1.0.0
-

8b00c60 update constraint for python-swiftclient to new release 3.2.0
52b4f40 Updated from generate-constraints
e9bb451 Add pathlib2 to requirements
cc6d4e1 Add lower bound to freezegun
a8a7b4b Block ryu-4.8
224b040 Update package metadata.
13195d0 Add sphinxcontrib-fulltoc
a258688 Bump abclient to 0.2.3
74a8e15 Make pbr requirement match the setup_requires line
c7fdd97 update constraint for python-ironicclient to new release 1.8.0
7a964bf Update hacking requirements
0f38371 Adds compute-hyperv to the projects.txt
169c195 Require os-brick>=1.8.0
ab1664f Fix the minimum required oslo.db version
d7dc27a Bump os-win minimum requirement to 1.1.0
dc52a8e Subscribe mixmatch project to requirements
fa83e7e update constraint for os-brick to new release 1.8.0
deb8ea3 update constraint for python-saharaclient to new release 1.0.0
f3c2f56 update constraint for ceilometermiddleware to new release 1.0.0
2fbf1e7 Allow hacking 0.12.0 to be used
f209742 Bump os-vif minimum requirement to 1.3.0
1c27a88 update constraint for abclient to new release 0.2.1
b179656 Add xstatic-angular-ui-router
c66944f Updated from generate-constraints
510c409 Bump oslo.utils minimum version to 3.18.0
39d3ada update requirements for neutron-lib to new release 1.0.0
f76b268 Blacklist rtslib-fb 2.1.60/61
9ee1ea1 Updated from generate-constraints
d15d784 update constraint for os-brick to new release 1.7.0
088f8d2 Update ovs to 2.6.1.
428d664 update constraint for oslo.utils to new release 3.18.0
f843228 update constraint for oslo.messaging to new release 5.12.0
2390e5a update constraint for oslo.config to new release 3.19.0
0e0240a Make reno with right license name
7bc6fd0 Raise openstacksdk upper-constraint to 0.9.9
2ca4990 update constraint for XStatic-D3 to new release 3.5.17.0
64e13aa update constraint for XStatic-Angular to new release 1.5.8.0
142b3d2 update constraint for python-ceilometerclient to new release 2.7.0
2850e65 update constraint for os_vif to new release 1.3.0
48a7213 update constraint for django_openstack_auth to new release 3.0.0
eae9e03 update constraint for keystoneauth1 to new release 2.15.0
1bc06a0 Add networking-bgpvpn to projects.txt
08abd5d Bump vnware-nsxlib to 0.2.0
9c4978f Block oslo.config 3.18.0
308aa59 Bump tenacity to 3.2.1
d561ca6 Require coverage>=4.0 to use --concurrency
1ce3cae Raise minimum pyparsing to 2.0.7
96831c0 update constraint for oslotest to new release 2.11.0
78ac632 update constraint for oslo.serialization to new release 2.14.0
7de8dba update constraint for oslo.config to new release 3.18.0
70dc8ba update constraint for ironic-lib to new release 2.3.0
8717bdb update constraint for oslo.service to new release 1.17.0
da22bfa update constraint for oslosphinx to new release 4.8.0
f4f6bd4 update constraint for oslo.privsep to new release 1.14.0
1178098 update constraint for oslo.versionedobjects to new release 1.18.0
8a30f6f update constraint for oslo.rootwrap to new release 5.2.0
194ad30 update constraint for oslo.middleware to new release 3.20.0
f9b005f update constraint for oslo.db to new release 4.14.0
c297718 update constraint for oslo.concurrency to new release 3.15.0
3df256a Bump os-client-config to 1.22.0
888ce4a Bump oslo.utils minimum to 3.17.0
4006d8a update constraint for tooz to new release 1.44.0
12b0ef8 update constraint for taskflow to new release 2.7.0
12744b8 update constraint for stevedore to new release 1.18.0
2d5161d update constraint for oslo.vmware to new release 2.15.0
b1b038b update constraint for oslo.utils to new release 3.17.0
aa0c67b update constraint for oslo.reports to new release 1.15.0
73aec26 update constraint for oslo.policy to new release 1.16.0
a259dc9 update constraint for oslo.messaging to new release 5.11.0
2ec3704 update constraint for oslo.i18n to new release 3.10.0
aabf8a4 update constraint for oslo.context to new release 2.10.0
d77c934 update constraint for oslo.cache to new release 1.15.0
453aa7f update constraint for futurist to new release 0.19.0
f7f4713 update constraint for debtcollector to new release 1.9.0
5b4f323 update constraint for automaton to new release 1.5.0
0d78087 Start Ocata for rpm-packaging
9d11e01 Updating the requirement for mistral
78388f3 Add os-xenapi to projects.txt for g-r updates/checking
dd387d1 Updated from generate-constraints
af8d358 Add 'typing' for static type checking
8162d25 Updated from generate-constraints
d30606a Updated from generate-constraints
0ce1e17 Require oslo.policy>=1.15.0
2a91391 Update keystoneauth to 2.14
5f141bd bump keystoneclient minimum to latest 

[openstack-dev] [nova] Nova Bugs Team Meeting

[Augustina Ragwitz]

Hey folks! I completely mixed up the time due to recent Daylight Savings
time changes and missed the meeting. It also seems I didn't mail out the
meeting reminder. If you have anything you had wanted to bring up,
please reach out to me via email or irc. Otherwise, the next 1800 UTC
meeting will be held on Nov 29th.

-- 
Augustina Ragwitz
Señora Software Engineer
---
Ask me about contributing to OpenStack Nova!
https://wiki.openstack.org/wiki/Nova/Mentoring

Waiting for your change to get through the gate? Clean up some Nova
bugs!
http://45.55.105.55:8082/bugs-dashboard.html
---
email: aragwitz+n...@pobox.com
irc: auggy

__
OpenStack Development Mailing 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] [keystone] meeting format poll

[Lance Bragstad]

Hey folks,

In today's keystone meeting, Morgan mentioned that we had the ability to go
back to using OpenStack Wikis for meeting agendas. I created a poll to get
feedback [0].

Let's keep it open for the week and look at the results as a team at our
next meeting.

Thanks!

[0] https://goo.gl/forms/Gs4lZxgktRzlwHAn2
__
OpenStack Development Mailing 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] [oslo] rabbitmq timeout

[Ajay Kalambur (akalambu)]

Hi
We see an issue where if we boot 10 instances on 1 compute node at a time we 
see that sometimes a few instances error out on compute node with following 
Traceback
It looks like the RPC message call from compute saying set Instance to Active 
is timing out.  It seems to help to set rpc response timeout to 180 seconds. 
But what we see from TCP dump is that the message reaches the conductor and 
conductor replies almost instantly. It looks like the compute node in question 
somehow takes a long time to process it. Any pointers. Also we had to increase 
heartbeat timeout to 120 from 60 to make this scenario work better. Any inputs 
on what maybe going on here?




2016-11-14 04:44:19.518 6 INFO nova.virt.libvirt.driver [-] [instance: 
31e67591-6bd4-4df9-bba1-7a1d6f785be0] Instance spawned successfully.

2016-11-14 04:44:55.692 6 INFO nova.compute.manager 
[req-25dc826e-54bc-4c7c-b58f-c32c8e024624 - - - - -] [instance: 
31e67591-6bd4-4df9-bba1-7a1d6f785be0] During sync_power_state the instance has 
a pending task (spawning). Skip.

2016-11-14 04:44:55.693 6 INFO nova.compute.manager 
[req-25dc826e-54bc-4c7c-b58f-c32c8e024624 - - - - -] [instance: 
31e67591-6bd4-4df9-bba1-7a1d6f785be0] VM Started (Lifecycle Event)

2016-11-14 04:45:04.544 6 INFO nova.virt.libvirt.driver [-] [instance: 
5040fdad-2dbe-49a2-aa3d-ccd8e7725b5d] Instance spawned successfully.

2016-11-14 04:45:04.558 6 INFO nova.virt.libvirt.driver [-] [instance: 
ba4b3c89-0f57-4c46-91dd-44434012d289] Instance spawned successfully.

2016-11-14 04:45:04.607 6 INFO nova.compute.manager 
[req-25dc826e-54bc-4c7c-b58f-c32c8e024624 - - - - -] [instance: 
5040fdad-2dbe-49a2-aa3d-ccd8e7725b5d] VM Resumed (Lifecycle Event)

2016-11-14 04:45:16.669 6 INFO nova.virt.libvirt.driver [-] [instance: 
3794b761-f623-4fb9-a91a-f2dffca42c4c] Instance spawned successfully.

2016-11-14 04:45:16.710 6 INFO nova.compute.manager 
[req-25dc826e-54bc-4c7c-b58f-c32c8e024624 - - - - -] [instance: 
5040fdad-2dbe-49a2-aa3d-ccd8e7725b5d] VM Started (Lifecycle Event)

2016-11-14 04:46:43.765 6 ERROR nova.compute.manager 
[req-20ec8e07-d57c-4679-8122-4cfa990b6d6f 168b323822284084b1c1393faeb5b9e1 
aa39823c34e4496793250c0bc5cf7a31 - - -] [instance: 
3794b761-f623-4fb9-a91a-f2dffca42c4c] Unexpected build failure, not 
rescheduling build.

2016-11-14 04:46:43.765 6 ERROR nova.compute.manager [instance: 
3794b761-f623-4fb9-a91a-f2dffca42c4c] Traceback (most recent call last):

2016-11-14 04:46:43.765 6 ERROR nova.compute.manager [instance: 
3794b761-f623-4fb9-a91a-f2dffca42c4c]   File 
"/usr/lib/python2.7/site-packages/nova/compute/manager.py", line 1905, in 
_do_build_and_run_instance

2016-11-14 04:46:43.765 6 ERROR nova.compute.manager [instance: 
3794b761-f623-4fb9-a91a-f2dffca42c4c] filter_properties)

2016-11-14 04:46:43.765 6 ERROR nova.compute.manager [instance: 
3794b761-f623-4fb9-a91a-f2dffca42c4c]   File 
"/usr/lib/python2.7/site-packages/nova/compute/manager.py", line 2082, in 
_build_and_run_instance

2016-11-14 04:46:43.765 6 ERROR nova.compute.manager [instance: 
3794b761-f623-4fb9-a91a-f2dffca42c4c] 
instance.save(expected_task_state=task_states.SPAWNING)

2016-11-14 04:46:43.765 6 ERROR nova.compute.manager [instance: 
3794b761-f623-4fb9-a91a-f2dffca42c4c]   File 
"/usr/lib/python2.7/site-packages/oslo_versionedobjects/base.py", line 197, in 
wrapper

2016-11-14 04:46:43.765 6 ERROR nova.compute.manager [instance: 
3794b761-f623-4fb9-a91a-f2dffca42c4c] ctxt, self, fn.__name__, args, kwargs)

2016-11-14 04:46:43.765 6 ERROR nova.compute.manager [instance: 
3794b761-f623-4fb9-a91a-f2dffca42c4c]   File 
"/usr/lib/python2.7/site-packages/nova/conductor/rpcapi.py", line 242, in 
object_action

2016-11-14 04:46:43.765 6 ERROR nova.compute.manager [instance: 
3794b761-f623-4fb9-a91a-f2dffca42c4c] objmethod=objmethod, args=args, 
kwargs=kwargs)

2016-11-14 04:46:43.765 6 ERROR nova.compute.manager [instance: 
3794b761-f623-4fb9-a91a-f2dffca42c4c]   File 
"/usr/lib/python2.7/site-packages/oslo_messaging/rpc/client.py", line 158, in 
call

2016-11-14 04:46:43.765 6 ERROR nova.compute.manager [instance: 
3794b761-f623-4fb9-a91a-f2dffca42c4c] retry=self.retry)

2016-11-14 04:46:43.765 6 ERROR nova.compute.manager [instance: 
3794b761-f623-4fb9-a91a-f2dffca42c4c]   File 
"/usr/lib/python2.7/site-packages/oslo_messaging/transport.py", line 90, in 
_send

2016-11-14 04:46:43.765 6 ERROR nova.compute.manager [instance: 
3794b761-f623-4fb9-a91a-f2dffca42c4c] timeout=timeout, retry=retry)

2016-11-14 04:46:43.765 6 ERROR nova.compute.manager [instance: 
3794b761-f623-4fb9-a91a-f2dffca42c4c]   File 
"/usr/lib/python2.7/site-packages/oslo_messaging/_drivers/amqpdriver.py", line 
431, in send

2016-11-14 04:46:43.765 6 ERROR nova.compute.manager [instance: 
3794b761-f623-4fb9-a91a-f2dffca42c4c] retry=retry)

2016-11-14 04:46:43.765 6 ERROR nova.compute.manager [instance: 
3794b761-f623-4fb9-a91a-f2dffca42c4c]   File 

Re: [openstack-dev] [diskimage-builder] 01-override-yum-arch question

[dmarlin]

On 11/14/2016 11:55 AM, dmar...@redhat.com wrote:


I was looking at 01-override-yum-arch in diskimage-builder, and have a 
question.


Is the following code correct in git, or should $arch be written into 
/etc/dnf/vars/arch, similar to the yum path (for F22 and older) as 
shown below?


--- a/elements/rpm-distro/pre-install.d/01-override-yum-arch
+++ b/elements/rpm-distro/pre-install.d/01-override-yum-arch
@@ -28,7 +28,7 @@ fi
 if [[ $DISTRO_NAME == "fedora" && $DIB_RELEASE -ge 22 ]]; then
 mkdir -p /etc/dnf/vars
 echo $basearch > /etc/dnf/vars/basearch
-echo $arch > /etc/dnf/vars/basearch
+echo $arch > /etc/dnf/vars/arch
 else
 echo $basearch > /etc/yum/vars/basearch
 echo $arch > /etc/yum/vars/arch



Thank you,

d.marlin




In addition, I have created a small patch against git master (attached) 
that will permit me to run disk-image-creator native on Fedora 25 Beta 
AArch64, tested using the following command:


  DIB_RELEASE=24 disk-image-create -o test.qcow2 fedora-minimal

Please let me know if this approach is acceptable, or if you have 
suggestions for improvements.



Thank you,

d.marlin

diff --git a/elements/architecture-emulation-binaries/extra-data.d/01-copy-binary b/elements/architecture-emulation-binaries/extra-data.d/01-copy-binary
index 0140990..ee970b0 100755
--- a/elements/architecture-emulation-binaries/extra-data.d/01-copy-binary
+++ b/elements/architecture-emulation-binaries/extra-data.d/01-copy-binary
@@ -53,7 +53,7 @@ case "$ARCH" in
 qemu_binary_file="/usr/bin/qemu-arm-static"
 copy_binary $qemu_binary_file $ARCH
 ;;
-"arm64")
+"arm64" | "aarch64")
 qemu_binary_file="/usr/bin/qemu-aarch64-static"
 copy_binary $qemu_binary_file $ARCH
 ;;
diff --git a/elements/rpm-distro/pre-install.d/01-override-yum-arch b/elements/rpm-distro/pre-install.d/01-override-yum-arch
index ff84375..4cda643 100755
--- a/elements/rpm-distro/pre-install.d/01-override-yum-arch
+++ b/elements/rpm-distro/pre-install.d/01-override-yum-arch
@@ -18,6 +18,9 @@ elif [[ "$ARCH" = "ppc64" ]]; then
 elif [[ "$ARCH" = "ppc64el" ]]; then
 basearch=ppc64el
 arch=ppc64el
+elif [[ "$ARCH" = "aarch64" ]]; then
+basearch=aarch64
+arch=aarch64
 else
 echo ""
 echo "Unknown arch '$ARCH'"
diff --git a/lib/common-defaults b/lib/common-defaults
index e047185..428f58f 100644
--- a/lib/common-defaults
+++ b/lib/common-defaults
@@ -26,6 +26,8 @@ else
 "armv"*)
   _ARCH="armhf"
   ;;
+"aarch64")
+  ;;
 *)
   echo "WARNING: Unknown architecture: $_ARCH"
   ;;
__
OpenStack Development Mailing 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] [Infra] Kolla-ansible is available

[Jeremy Stanley]

On 2016-11-15 12:20:35 -0600 (-0600), Michał Jastrzębski wrote:
> I think we could use git submodule in kolla-ansible to download kolla.
> That would help us deal with gates in kolla-ansible short term.
> Thoughts?

The Infra team has _strongly_ recommended against employing Git
submodules within repos hosted on our Gerrit instance in the past,
for a number of reasons.

If your primary concern is about making sure you integration test
kolla-ansible with kolla, using zuul-cloner to retrieve
corresponding refs for them in your jobs will provide a much more
complete picture of both. Your proposed submodule would only allow
you to test proposed changes for kolla-ansible against merged
changes in kolla, making it easier to break kolla-ansible when
merging incompatible changes to kolla and also robbing you of the
ability to rely on cross-repo change dependencies between both
repos.
-- 
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] [Stable] Usefulness of Weekly Meeting

[Ian Cordasco]

Hi all,

So the stable-maintenance team (and liaisons to it) have had a meeting
scheduled for a while now. Recently, however, we've had trouble
getting more than one person to attend meetings when we have them.

I wonder if it would be more useful to less frequent meetings (perhaps
every other week) and if we need to reschedule them to better serve
those who plan to attend.

Cheers,
-- 
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] [kolla] Kolla-ansible is available

[Michał Jastrzębski]

I think we could use git submodule in kolla-ansible to download kolla.
That would help us deal with gates in kolla-ansible short term.
Thoughts?

On 15 November 2016 at 12:07, Paul Bourke  wrote:
> Seems good so far, thanks Michal / Steve. Cores don't forget to add
> openstack/kolla-ansible to your watched projects in Gerrit :)
>
> I assume we just -2 any Ansible related patches currently open against the
> openstack/kolla project with instructions on how to resubmit.
>
> Also has it been discussed yet if we have a recommended mechanism for
> integration of the two projects, e.g. git submodules, pip or something else?
>
> -Paul
>
>
> On 15/11/16 17:53, Michał Jastrzębski wrote:
>>
>> Hello,
>>
>> I wanted to thank Steve for doing the work, but kolla-ansible is now
>> open for business:)
>>
>> Couple of clarifications how it's going to work:
>>
>> 1. Currently Kolla-ansible is copy from kolla repo. We will need to
>> propose patches to remove docker from it. Also remove ansible bits
>> from kolla.
>> 2. Any outstanding ansible change should be closed and re-posted to
>> kolla-ansible repo.
>> 3. Build gates should be dropped from kolla-ansible, deploy gates
>> should be removed from kolla
>> 4. Core team for kolla-ansible is copy of kolla core team, but teams
>> are separate and at some point might diverge from each other.
>> 5. Kolla-ansible has it's own launchpad and we should migrate all
>> relevant bugs and blueprints out there.
>> 6. Kolla-ansibe will use same version number as Kolla (so first tag
>> will be 4.0.0b1)
>>
>> Questions?
>>
>> Regards,
>> Michal
>>
>> __
>> OpenStack Development Mailing 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] [kolla] Kolla-ansible is available

[Paul Bourke]

Seems good so far, thanks Michal / Steve. Cores don't forget to add 
openstack/kolla-ansible to your watched projects in Gerrit :)


I assume we just -2 any Ansible related patches currently open against 
the openstack/kolla project with instructions on how to resubmit.


Also has it been discussed yet if we have a recommended mechanism for 
integration of the two projects, e.g. git submodules, pip or something else?


-Paul

On 15/11/16 17:53, Michał Jastrzębski wrote:

Hello,

I wanted to thank Steve for doing the work, but kolla-ansible is now
open for business:)

Couple of clarifications how it's going to work:

1. Currently Kolla-ansible is copy from kolla repo. We will need to
propose patches to remove docker from it. Also remove ansible bits
from kolla.
2. Any outstanding ansible change should be closed and re-posted to
kolla-ansible repo.
3. Build gates should be dropped from kolla-ansible, deploy gates
should be removed from kolla
4. Core team for kolla-ansible is copy of kolla core team, but teams
are separate and at some point might diverge from each other.
5. Kolla-ansible has it's own launchpad and we should migrate all
relevant bugs and blueprints out there.
6. Kolla-ansibe will use same version number as Kolla (so first tag
will be 4.0.0b1)

Questions?

Regards,
Michal

__
OpenStack Development Mailing 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] [kolla] Kolla-ansible is available

[Michał Jastrzębski]

Hello,

I wanted to thank Steve for doing the work, but kolla-ansible is now
open for business:)

Couple of clarifications how it's going to work:

1. Currently Kolla-ansible is copy from kolla repo. We will need to
propose patches to remove docker from it. Also remove ansible bits
from kolla.
2. Any outstanding ansible change should be closed and re-posted to
kolla-ansible repo.
3. Build gates should be dropped from kolla-ansible, deploy gates
should be removed from kolla
4. Core team for kolla-ansible is copy of kolla core team, but teams
are separate and at some point might diverge from each other.
5. Kolla-ansible has it's own launchpad and we should migrate all
relevant bugs and blueprints out there.
6. Kolla-ansibe will use same version number as Kolla (so first tag
will be 4.0.0b1)

Questions?

Regards,
Michal

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

[openstack-dev] [ironic] ending the API meetings

[Loo, Ruby]

Hi,

We are ending the ironic API meetings that we started in July [0]. There were 
few AND mighty meetings. I thank Devananda for an awesome job of addressing 
some major API pain points in his epic "Evolving our REST API" series of 
specifications [1]! Now we need to follow his lead and get those specs 
implemented :)

--ruby

[0] http://lists.openstack.org/pipermail/openstack-dev/2016-July/098988.html
[1] http://lists.openstack.org/pipermail/openstack-dev/2016-October/105665.html
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [gnocchi] new measures backlog scheduling

[gordon chung]

On 15/11/16 04:53 AM, Julien Danjou wrote:
> Yeah in the case of the Swift driver for Gnocchi, I'm not really sure
> how much buckets we should create. Should we make the user pick a random
> number like the number of partition in Swift and then create the
> containers in Swift? Or can we have something simpler? (I like automagic
> things). WDYT Gordon?

tbh, i'm not entirely sure how many buckets we need either so i doubt 
users will know how many buckets they need.lol Ceph has that calculator 
to tell you ratio of of placement groups to OSD but i'll be honest, even 
when i use that, i'm just blindly typing numbers in.

also, if we make it configurable, then we need to add code in that 
rearranges buckets when it's changed... so... i'm hoping for something 
static if possible (although probably not?)

i imagine we want less than 1K metrics/bucket? assuming it ends up being 
maybe 5 objects/metric?... seems we need some calculator here. :(

cheers,

-- 
gord

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

Re: [openstack-dev] [Horizon] ui-cookiecutter

[Thai Q Tran]

Great! I'll be sure to bring it up on your behalf (if you are not there).
 
- Original message -From: Shuu Mutou To: "openstack-dev@lists.openstack.org" Cc: Haruhiko Katou Subject: Re: [openstack-dev] [Horizon] ui-cookiecutterDate: Mon, Nov 14, 2016 7:07 PM 
Hi Thai,I created new blueprint[1], and added the BP to next IRC meeting agenda[2]. I hope the topic will be discussed in the meeting.[1]https://blueprints.launchpad.net/horizon/+spec/ui-cookiecutter[2]https://wiki.openstack.org/wiki/Meetings/HorizonBest regards,Shu Muto> -Original Message-> From: Thai Q Tran [mailto:tqt...@us.ibm.com]> Sent: Tuesday, November 15, 2016 4:30 AM> To: openstack-dev@lists.openstack.org> Subject: Re: [openstack-dev] [Horizon] ui-cookiecutter>> Hi Shuu,>> Sorry for the delay again, I just got back from vacation. I think your> cookiecutter will be useful in a number of ways.>> 1. We can use it to easily generate plugins for beginners> 2. We can use it in Horizon's startdash command (have to look into this)> for internal use>> Ideally, the project should be under an OpenStack repo so horizon drivers> can maintain it. Lets make it a point and bring it up at the horizon weekly> meeting. We can proceed after community feedback.>>> - Original message -> From: Shuu Mutou > To: "openstack-dev@lists.openstack.org"> > Cc: Haruhiko Katou > Subject: [openstack-dev] [Horizon] ui-cookiecutter> Date: Tue, Nov 8, 2016 1:24 AM>> Hi Horizoners,>> Thanks for picking up ui-cookiecutter[1] and setting Ocata-2> milestone at summit[2].> Thai or Cindy? Thank you!!>> I'm maintaining ui-cookiecutter, but I'm ready for transferring> it as Horizon subproject.>> Can I start to create subproject for ui-cookiecutter?> Or please let me know what I should do.>> [1] https://github.com/shu-mutou/ui-cookiecutter> [2] https://etherpad.openstack.org/p/horizon-ocata-priorities>> Regards,>> Shu Muto>>> __> > OpenStack Development Mailing 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:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
 


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

Re: [openstack-dev] [Glance] [api] Community Images Impasse

[Monty Taylor]

On 11/15/2016 10:35 AM, Brian Rosmaita wrote:
> Adding '[api]' to subject to get API-WG attention.
> 
> On 11/15/16, 11:26 AM, "Ian Cordasco"  wrote:
> 
>> Hi all,
>>
>> One of our priorities for Ocata-1 (whose deadline Glance has set for
>> 17 November 2016) is the Community Images work that has been discussed
>> now for several cycles and prioritized since the end of Newton.
>>
>> Like we often do in Glance, we've reached an impasse in the 11th hour.
>> To summarize, some of us are concerned about migrating the default
>> image visibility value to "shared" although it's semantically
>> equivalent to what we already have. At first the concern was that this
>> was not part of the spec (although, in my opinion it was a natural
>> conclusion of the spec) so Brian helpfully updated that here:
>> https://review.openstack.org/396919
>>
>> Some good points have been made about the confusion this might cause
>> among users if Glance 14.0.0 is released with the code like this. As
>> it stands, we have already approved much of this as a community and
>> committed to its completion. Nothing is set in stone, however, so
>> getting as much feedback on the updates to the spec as possible will
>> be very helpful in sorting this out efficiently.
>>
>> All of that said, Timothy Symanczyk has been leading this effort and
>> is being moved onto other work by his employer. We need to decide
>> whether or not to accept Timothy's work and build upon it, or have
>> someone take over the work from him. Timothy has been incredibly
>> responsive to review comments on the work itself
>> (https://review.openstack.org/369110) and I'd appreciate it if we
>> could respect that effort by being equally responsive in the
>> discussions on the spec review.
>>
>> Thank you in advance to everyone who can pitch in,

I'm usually the extremely vocal "don't ever break backwards compat"
person. However, I would like to say that the arguments for this change
make sense to me - and will not break any of the compat code I have out
there already.

For all intents and purposes, given the continued existence of both v1
and v2, the question users wind up having to ask generally is the equiv
of "is_public". The code in shade that does this is here:

http://git.openstack.org/cgit/openstack-infra/shade/tree/shade/_normalize.py#n182

(I have additional code coming to expose the new shared/community flags)

By no means am I the only consumer of these APIs - but to me, given all
of the other things, this one seems fine - and honestly the semantic
upgrade (now I can just upload an image without thinking about it and
then add new people to it without affecting a state transition) is the
type of experience I'd like as a user.

Monty

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

Re: [openstack-dev] [Congress] Magnum_driver

[Tim Hinrichs]

Hi Ruben,

Did a little debugging for you...

1) Run your unit tests
$ tox -epy34 congress.tests.datasources.test_magnum
...
  File
"/Users/tim/opencode/congress/congress/tests/datasources/test_magnum_driver.py",
line 3, in 
from congress.datasources import magnum_driver
  File
"/Users/tim/opencode/congress/congress/datasources/magnum_driver.py", line
51
self.magnum = magnum_client.Client(session=session)
^
IndentationError: unexpected indent

The IndenetationError says you haven't lined up the code correctly.  Python
is sensitive to whitespace.  I fixed this.

2) Run unit tests again.
$ tox -epy34 congress.tests.datasources.test_magnum
..
  File
"/Users/tim/opencode/congress/congress/datasources/magnum_driver.py", line
1, in 
from magnumclient import client as magnum_client

Here the problem is that the package magnumclient doesn't exist.  You need
to add the python-magnumclient to the file requirements.txt.
I fixed this for you as well.

3) Run unit tests again
$ tox -epy34 congress.tests.datasources.test_magnum

Forgot to capture the output this time, but there was a test failure.  I
went ahead and uncommented the two translators that you wrote
because they seemed to be doing the right thing; that required combining
your two unit tests into 1.

4) Run unit tests again
$ tox -epy34 congress.tests.datasources.test_magnum

Traceback (most recent call last):
  File
"/Users/tim/opencode/congress/congress/tests/datasources/test_magnum_driver.py",
line 97, in test_cluster_template_update_from_datasource
self.assertEqual(self.driver.state, expected)
  File
"/Users/tim/opencode/congress/.tox/py34/lib/python3.4/site-packages/testtools/testcase.py",
line 411, in assertEqual
self.assertThat(observed, matcher, message)
  File
"/Users/tim/opencode/congress/.tox/py34/lib/python3.4/site-packages/testtools/testcase.py",
line 498, in assertThat
raise mismatch_error
testtools.matchers._impl.MismatchError: !=:
reference = {'cluster': {('None', 'k8s-cluster', 'None', 1, 1,
'CREATE_FAILED')},
 'cluster_template': {('None', 'k8s-cluster-template', 'None', 'None')}}
reference = {'cluster': {('f88cb9c7-1e5d-42cb-b0dc-d9c3d0872ddf',
  'k8s-cluster',
  'testkey',
  1,
  1,
  'CREATE_FAILED')},
 'cluster_template': {('3ddeaf4f-af3d-4534-9558-59bf28b1578b',
   'k8s-cluster-template',
   'kubernetes',
   'flannel')}}
actual= {'cluster': {('None', 'k8s-cluster', 'None', 1, 1,
'CREATE_FAILED')},
 'cluster_template': {('None', 'k8s-cluster-template', 'None', 'None')}}

What's happening here is that the output of the translator does not match
what the test says the output should be.  The problem is that there's a
mismatch between the keys in the data that you've mocked out (e.g.
mock_cluster_template) and the fieldnames in the translator (e.g.
cluster_template_translator).

In the translator below you say the field names are 'id', 'name', 'COE',
and 'Network_driver'.  In the data you mocked out, the closest field names
I can see are 'uuid', 'name', 'coe', and 'network_driver'.  So fieldname
'name' matches the mocked out data, but the other field names do not.
 (Field names are case sensitive.)  So if you change it so the fieldnames
and the mock-data match, your unit test should pass.

cluster_template_translator = {
'translation-type': 'HDICT',
'table-name': CLUSTER_TEMPLATE,
'selector-type': 'DICT_SELECTOR',
'field-translators':
  ({'fieldname': 'id', 'translator': value_trans},
   {'fieldname': 'name', 'translator': value_trans},
   {'fieldname': 'COE', 'translator': value_trans},
   {'fieldname': 'Network_driver', 'translator': value_trans})}

5) Of course, just because the unit tests pass doesn't mean the driver is
correct.  The translator fieldnames need to match the actual data that
magnum returns when you ask for the clusters and cluster_templates.  One
option is to read through the python-magnumclient code to see what fields
it returns; the other is to run the commands yourself from the commandline
to see what they return; another is to look at the Congress logs when the
magnum driver is running (with debug=True in /etc/congress/congress.conf).

6) I pushed all my changes as a revision on top of one of your commits.  We
always include the code and the unit tests as one commit.  So now there's 1
commit that you can download to your local machine and continue editing.
Or you can just look at the code in gerrit and make changes to your code
manually.

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

To download, the safest thing is to create a new branch and apply the
changes on top of that branch.You can also skip the 'git checkout' step
if you want to apply the changes on top of the ones you already have,
resolve conflicts, and then squash all the commits together.
$ cd /path/to/congress
$ git checkout origin/master 

Re: [openstack-dev] [tripleo][ci] jobs shuffle to add IPv6 coverage

[Gabriele Cerami]

On 18 Oct, Gabriele Cerami wrote:
> Hello,
> 
> after adding coverage in CI for HA IPv6 scenario here
> https://review.openstack.org/363674 we wanted to add IPv6 testing on the
> gates.
> To not use any more resources the first suggestion to add IPv6 to the
> gates was to make all HA jobs IPv6, move network isolation testing for
> IPv4 on non-ha job, and test non-netiso environment on multinode.

This is still up for debate, another possibility is to test IPv6 just in
the updates jobs.

> This is almost done here https://review.openstack.org/382515 with one
> exception. Liberty HA IPv6 fails during ping test with the error:
> 503 Service unavailable.

This issue was solved during the summit

> Moreover, swift memecache code in liberty is clearly not IPv6
> compatible, it gives an error on the overcloud, not being able to get
> host and port from a correctly formed IPv6 URL. To make it compatible
> with IPv6 this should be backported https://review.openstack.org/258704

This still remains.

> Before continuing the debugging I wanted to be sure that:
> - this is an acceptable shuffle for the gates jobs
> - we are really interested in testing liberty IPv6

I have another question to add to the mix. Do we care to test IPv6 with
SSL ? Our current certificate handling code is dealing only with IPv4
addresses, so if we need to test both, we'll have to add that part too.

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

[openstack-dev] [Glance] [api] Community Images Impasse

[Brian Rosmaita]

Adding '[api]' to subject to get API-WG attention.

On 11/15/16, 11:26 AM, "Ian Cordasco"  wrote:

>Hi all,
>
>One of our priorities for Ocata-1 (whose deadline Glance has set for
>17 November 2016) is the Community Images work that has been discussed
>now for several cycles and prioritized since the end of Newton.
>
>Like we often do in Glance, we've reached an impasse in the 11th hour.
>To summarize, some of us are concerned about migrating the default
>image visibility value to "shared" although it's semantically
>equivalent to what we already have. At first the concern was that this
>was not part of the spec (although, in my opinion it was a natural
>conclusion of the spec) so Brian helpfully updated that here:
>https://review.openstack.org/396919
>
>Some good points have been made about the confusion this might cause
>among users if Glance 14.0.0 is released with the code like this. As
>it stands, we have already approved much of this as a community and
>committed to its completion. Nothing is set in stone, however, so
>getting as much feedback on the updates to the spec as possible will
>be very helpful in sorting this out efficiently.
>
>All of that said, Timothy Symanczyk has been leading this effort and
>is being moved onto other work by his employer. We need to decide
>whether or not to accept Timothy's work and build upon it, or have
>someone take over the work from him. Timothy has been incredibly
>responsive to review comments on the work itself
>(https://review.openstack.org/369110) and I'd appreciate it if we
>could respect that effort by being equally responsive in the
>discussions on the spec review.
>
>Thank you in advance to everyone who can pitch in,
>--
>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] [Glance] Community Images Impasse

[Ian Cordasco]

Hi all,

One of our priorities for Ocata-1 (whose deadline Glance has set for
17 November 2016) is the Community Images work that has been discussed
now for several cycles and prioritized since the end of Newton.

Like we often do in Glance, we've reached an impasse in the 11th hour.
To summarize, some of us are concerned about migrating the default
image visibility value to "shared" although it's semantically
equivalent to what we already have. At first the concern was that this
was not part of the spec (although, in my opinion it was a natural
conclusion of the spec) so Brian helpfully updated that here:
https://review.openstack.org/396919

Some good points have been made about the confusion this might cause
among users if Glance 14.0.0 is released with the code like this. As
it stands, we have already approved much of this as a community and
committed to its completion. Nothing is set in stone, however, so
getting as much feedback on the updates to the spec as possible will
be very helpful in sorting this out efficiently.

All of that said, Timothy Symanczyk has been leading this effort and
is being moved onto other work by his employer. We need to decide
whether or not to accept Timothy's work and build upon it, or have
someone take over the work from him. Timothy has been incredibly
responsive to review comments on the work itself
(https://review.openstack.org/369110) and I'd appreciate it if we
could respect that effort by being equally responsive in the
discussions on the spec review.

Thank you in advance to everyone who can pitch in,
--
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] [glance] priorities for O-1

[Ian Cordasco]

 

-Original Message-
From: Ian Cordasco 
Reply: Ian Cordasco 
Date: November 14, 2016 at 10:58:16
To: OpenStack Development Mailing List (not for usage questions) 

Subject:  Re: [openstack-dev] [glance] priorities for O-1

> -Original Message-
> From: Brian Rosmaita  
> Reply: OpenStack Development Mailing List (not for usage questions)  
> Date: November 10, 2016 at 08:32:51
> To: OpenStack Development Mailing List (not for usage questions)  
> Subject: [openstack-dev] [glance] priorities for O-1
>  
> > Hello Glancers,
> >
> > O-1 is around the corner (i.e., next week). The priority for Glance is
> > Community Images.
> >
> > Please review the following patches:
> >
> > https://review.openstack.org/#/c/369110/

This patch has been blocked by a core reviewer. For folks trying to help with 
Glance's Ocata-1 priorities, please review and contribute to the discussion on 
https://review.openstack.org/#/c/396919 (the related spec update).

Please ignore the glanceclient change and focus on the following two reviews. 
We can merge the glanceclient work for the community image sharing work when it 
is completed.

> > https://review.openstack.org/#/c/387660/
> > https://review.openstack.org/#/c/391968/
>  
> Glance reviewers,
>  
> Please prioritize reviewing the above patches. These are the highest priority 
> items  
> for Ocata-1 and need to merge so we can stabilize them throughout the rest of 
> this very  
> short cycle.
>  
> I will be proposing a review to openstack/releases to tag Ocata-1. For now, I 
> will block  
> the workflow, but on Thursday, I will update it and encourage the Release 
> team to move  
> forward with it regardless of whether these have merged or not. While these 
> are a priority,  
> as Release Czar I cannot force you to review them but I must move forward 
> with our release  
> plans.

The review I mentioned here is: https://review.openstack.org/397793. On 
Thursday I will update the SHA and remove the workflow block. 

**Please prioritize reviewing the current priorities.**

--  
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] oaktree - a friendly end-user oriented API layer - anybody want to help?

[Dean Troyer]

On Tue, Nov 15, 2016 at 8:56 AM, Monty Taylor  wrote:
> The auth story. The native/default auth for gRPC is oauth. It has the
> ability for pluggable auth, but that would raise the barrier for new
> languages. I'd love it if we can come up with a story that involves
> making API users in keystone and authorizing them to use oaktree via an
> oauth transaction. The keystone auth backends currently are all about
> integrating with other auth management systems, which is great for
> environments where you have a web browser, but not so much for ones
> where you need to put your auth credentials into a file so that your
> scripts can work. I'm waving my hands wildly here - because all I really
> have are problems to solve and none of the solutions I have are great.

I think it is very important to not introduce new concepts to the gRPC
model here, ie, not require any out-of-band auth, such as getting a
token directly from Keystone before making any gRPC calls.

> Glance Image Uploads and Swift Object Uploads (and downloads). Having
> those two data operations go through an API proxy seems inefficient.
> However, having them not in the API seems like a bad user experience.
> Perhaps if we take advantage of the gRPC streaming protocol support
> doing a direct streaming passthrough actually wouldn't be awful. Or
> maybe the better approach would be for the gRPC call to return a URL and
> token for a user to POST/PUT to directly. Literally no clue.

Looking back at my notes from the Image v2 create talks, we have the
opportunity to finally get this right, so let's take the time to do
that.

One thing I think is worthwhile to point out is that (at this point
anyway) there is nothing here that requires 'insider' knowledge of a
cloud deployment to use oaktree, ie it does not have to be deployed by
the cloud operator.  You could run your own oaktree in front of
$PUBLIC_CLOUD and/or $PRIVATE_CLOUD.

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] [ironic] python-wsmanclient future

[Jim Rollenhagen]

On Mon, Nov 7, 2016 at 8:51 AM, Dmitry Tantsur  wrote:
> Hi folks!
>
> In view of the Ironic governance discussion [1] I'd like to talk about
> wsmanclient [2] future.
>
> This project was created to split away wsman code from python-dracclient to
> be reused in other drivers (I can only think of AMT right now). This was
> never finished: dracclient still uses its internal wsman implementation.
>
> To make it worse, the guy behind this effort (ifarkas) has left our team,
> python-dracclient is likely to leave Ironic governance per [1], and the AMT
> driver is going to leave the Ironic tree.
>
> At least the majority of the folks currently behind dracclient (Miles, Lucas
> and myself) do not have resources to continue this wsmanclient effort.
> Unless somebody is ready to take over both wsmanclient itself and the effort
> to port dracclient, I suggest we abandon wsmanclient.
>
> Any thoughts?

+1. Sounds like nobody objects, I can add retiring this to my todo list.

// jim

>
> [1] https://review.openstack.org/#/c/392685/
> [2] https://github.com/openstack/python-wsmanclient
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing 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] Fedora AArch64 (64-bit ARM) support in diskimage-builder

[dmarlin]

On 11/14/2016 09:44 PM, Gregory Haynes wrote:

On Mon, Nov 14, 2016, at 05:06 PM, dmar...@redhat.com wrote:

On 11/14/2016 04:40 PM, Ben Nemec wrote:


On 11/11/2016 10:55 AM, dmar...@redhat.com wrote:

I have been looking at using diskimage-builder on Fedora AArch64. While
there is 64-bit ARM support for Ubuntu (arm64), there appear to be a few
things missing for Fedora.  Is this the correct list to ask questions,
and propose minor changes to diskimage-builder in support of this
effort?

Yes.  I would suggest you tag your emails with [diskimage-builder] so
the relevant people are more likely to see them.

Will do.


Thank you for the feedback,

d.marlin


Additionally, if youre an IRC fan, we hang out in #openstack-dib on
freenode.

Thanks,
Greg

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


Thank you.  I'm there (dmarlin).

d.marlin


__
OpenStack Development Mailing 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][vmware] status of vmware third party CI?

[Jay Pipes]

On 11/15/2016 10:09 AM, Matt Riedemann wrote:

I've got a docs patch that failed both nova-net and neutron vmware third
party CI:

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

The nova-net one failed some aggregates response validation:

http://208.91.1.172/logs/ext-nova-dsvm/397382/2/2074/tempest_results.html.gz

That's not even related to what I'm doing, so I'm wondering how that's
happening in this job?


I've noticed similar things, and it's gotten worse it seems over the 
last month or so. :(



Also, as we're moving off of nova-network for upstream CI I'd like to
know the plans for the vmware third party CI with respect to networking
backends. The nova-net job is voting right now and the nsx neutron job
is non-voting. Is the plan to make the nova-net job non-voting once the
nsx job is running smoothly, or maybe even drop it?

As for the nsx job, it doesn't even stack successfully right now, it
looks like in this case creating an image failed:

http://208.91.1.172/logs/ext-nova-dsvm-nsx/397382/2/2074/g-api.log.gz?level=TRACE

I'm also having a hard time finding vmware people in the nova channel
that can field questions about this stuff when it fails. I tried the
openstack-vmware channel but got no response there either.


:(

-jay

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

[openstack-dev] [nova][vmware] status of vmware third party CI?

[Matt Riedemann]

I've got a docs patch that failed both nova-net and neutron vmware third 
party CI:


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

The nova-net one failed some aggregates response validation:

http://208.91.1.172/logs/ext-nova-dsvm/397382/2/2074/tempest_results.html.gz

That's not even related to what I'm doing, so I'm wondering how that's 
happening in this job?


Also, as we're moving off of nova-network for upstream CI I'd like to 
know the plans for the vmware third party CI with respect to networking 
backends. The nova-net job is voting right now and the nsx neutron job 
is non-voting. Is the plan to make the nova-net job non-voting once the 
nsx job is running smoothly, or maybe even drop it?


As for the nsx job, it doesn't even stack successfully right now, it 
looks like in this case creating an image failed:


http://208.91.1.172/logs/ext-nova-dsvm-nsx/397382/2/2074/g-api.log.gz?level=TRACE

I'm also having a hard time finding vmware people in the nova channel 
that can field questions about this stuff when it fails. I tried the 
openstack-vmware channel but got no response there either.


--

Thanks,

Matt Riedemann


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

Re: [openstack-dev] oaktree - a friendly end-user oriented API layer - anybody want to help?

[Sean M. Collins]

Great idea, I just ran into a similar issue when investigating the
following Kubernetes issue[1], and the OpenStack provider. They are running
into similar issues around networking and what a "public" network
address is, which is exactly what Shade had to deal with, in the public
clouds that we use for our testing infrastructure.

https://github.com/kubernetes/kubernetes/issues/12083

Obviously since k8s is written in Go, they can't really use Shade out of
the box - so this new project you are working on is *exactly* what the
doctor ordered.

-- 
Sean M. Collins

__
OpenStack Development Mailing 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] oaktree - a friendly end-user oriented API layer - anybody want to help?

[Monty Taylor]

Hey everybody!

At this past OpenStack Summit the results of the Interop Challenge were
shown on stage. It was pretty awesome - 17 different people from 17
different clouds ran the same workload. And it worked!

However, one of the reasons it worked is because they all used the
Ansible modules we wrote that are based on the shade library that
contains the business logic needed to hide vendor differences in clouds.
That means that there IS a fantastic OpenStack interoperability story -
but only if you program in Python. That's less awesome.

With that in mind - I'm pleased to announce a new project that aims to
address that - oaktree.

oaktree is a gRPC-based API porcelain service for OpenStack that is
based on the shade library and I'd love some help in writing it.

Basing oaktree on shade gets not only the business logic. Shade already
understands a multi-cloud world. And because we use shade in Infra for
nodepool, it already has caching, batching and thundering herd
protection sorted to be able to hand very high loads efficiently. So
while oaktree is new, the primary logic and fundamentals are all shade
and are battle-tested.

The barrier to deployers adding it to their clouds needs to be as low as
humanly possible. So as we work on it, ensuring that we keep it
dead-simple to install, update and operate must be a primary concern.

Where are we and what's next?

oaktree doesn't do a whole lot that's terribly interesting at the
moment. We have all of the development scaffolding and gate jobs set up
and a few functions implemented.

oaktree exists currently as two repos - oaktree and oaktreemodel:

  http://git.openstack.org/cgit/openstack/oaktree
  http://git.openstack.org/cgit/openstack/oaktreemodel

oaktreemodel contains the Protobuf definitions and the build scripts to
produce Python, C++ and Go code from them. The python code is published
to PyPI as a normal pure-python library. The C++ code is published as a
source tarball and the Go code is checked back in to the same repo so
that go works properly.

oaktree depends on the python oaktreemodel library, and also on shade.
It implements the server portion of the gRPC service definition.

Currently, oaktree can list and search for flavors, images and floating
ips. Exciting right? Most of the work to expose the rest of the API that
shade can provide at the moment is going to be fairly straightforward -
although in each case figuring out the best mapping will take some care.

We have a few major things that need some good community design. These
are also listed in a todo.rst file in the oaktree repo which is part of
the docs:

  http://oaktree.readthedocs.io/en/latest/

The auth story. The native/default auth for gRPC is oauth. It has the
ability for pluggable auth, but that would raise the barrier for new
languages. I'd love it if we can come up with a story that involves
making API users in keystone and authorizing them to use oaktree via an
oauth transaction. The keystone auth backends currently are all about
integrating with other auth management systems, which is great for
environments where you have a web browser, but not so much for ones
where you need to put your auth credentials into a file so that your
scripts can work. I'm waving my hands wildly here - because all I really
have are problems to solve and none of the solutions I have are great.

Glance Image Uploads and Swift Object Uploads (and downloads). Having
those two data operations go through an API proxy seems inefficient.
However, having them not in the API seems like a bad user experience.
Perhaps if we take advantage of the gRPC streaming protocol support
doing a direct streaming passthrough actually wouldn't be awful. Or
maybe the better approach would be for the gRPC call to return a URL and
token for a user to POST/PUT to directly. Literally no clue.

In any case - I'd love help from anyone who thinks this sounds like a
good idea. In a perfect world we'll have something ready for 1.0 by Atlanta.

Join us in #openstack-shade if you want to hack.

Thanks!
Monty


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

[openstack-dev] [Congress] relevant horizontal efforts at PTG

[Eric K]

Hi all!
aimeeu asked during team meeting about relevant sessions on Monday and Tuesday.
I don't have anything official. I think it's more a matter of you and your 
org's interest in contributing to those horizontal efforts. 
If you're looking to contribute to a horizontal project, horizon, the community 
app catalog (I'm thinking about the TOSCA templates), and the architecture 
working group may complement congress quite well. I'm sure here are others that 
go well too.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [vitrage]bp:static-datasource-config-formatworking items

[Afek, Ifat (Nokia - IL)]

From: Yujun Zhang
Date: Tuesday, 15 November 2016 at 16:03
On Tue, Nov 15, 2016 at 8:44 PM Weyl, Alexey (Nokia - IL) 
> wrote:
Ok, sounds good.

We need to understand what is the common way in openstack to work with 
deprecated code.

Maybe it could be discussed in next weekly meeting. Anybody who has experience 
on it please raise your hand :-)

I know that Telemetry kept Ceilometer alarms API in parallel with the new Aodh 
API for quite some time. But I don’t know if there are any general guidelines. 
In any case, I think we should keep the old format valid for now. Maybe write a 
warning to the log file about the deprecation.

__
OpenStack Development Mailing 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] [Browbeat] Nominate Justin Kilpatrick as core.

[Joe Talerico]

Alright, I have 1, +1... Any one else (I think Alex +1ed on IRC)?

Since I nominated him obviously I +1!

Joe

On Tue, Nov 8, 2016 at 9:24 AM, Sindhur Malleni  wrote:
> +1. I think Justin's done some awesome work and would be a great addition to
> the core team. Better get reviewing some patches Justin! ;)
>
> On Fri, Oct 28, 2016 at 10:28 AM, Joe Talerico  wrote:
>>
>> Justin has been doing a great deal of work on the Browbeat-CI and
>> stabilizing our code.
>>
>> I would like to nominate Justin as our first core who didn't begin as
>> a core to the project!
>>
>> Joe
>
>
>
>
> --
> Sai Sindhur Malleni
> Software Engineer
> Red Hat Inc.
> 100 East Davie Street
> Raleigh, NC, USA
> Work: (919) 754-4557 | Cell: (919) 985-1055

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

[Morales, Victor]

My two cents on this.   

OVO is going to be the new layer to access to DB model classes, therefore all 
the calls to the database(ensuring that there is an opened session) and the 
process to receive(validating fields) and/or return data(determining if a 
specific column exists) should be managed by OVO classes internally, so that’s 
also my understanding.

Regards,
Victor Morales

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

Date:  Tuesday, November 15, 2016 at 3:06 AM
To:  OpenStack List 
Subject:  [openstack-dev] [neutron] OVO support


Hi,
It seems like a lot of the object work is being done under database 
transactions. My understanding is that the objects should take care of this 
internally.
Any thoughts?
Thanks
Gary
__
OpenStack Development Mailing 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] [monasca][release] Release of openstack/monasca-grafana-datasource 1.0.0 failed

[Doug Hellmann]

It looks like the monasca-grafana-datasource repository isn't set up in
the way our release job expects for publishing nodejs projects.

>From the log:

2016-11-15 14:03:26.945891 | + npm install
2016-11-15 14:03:27.287904 | npm ERR! install Couldn't read dependencies
2016-11-15 14:03:27.289483 | npm ERR! Linux 4.4.0-47-generic
2016-11-15 14:03:27.289836 | npm ERR! argv "/usr/bin/nodejs" "/usr/bin/npm" 
"install"
2016-11-15 14:03:27.290082 | npm ERR! node v4.6.2
2016-11-15 14:03:27.290267 | npm ERR! npm  v2.15.11
2016-11-15 14:03:27.290433 | npm ERR! path 
/home/jenkins/workspace/monasca-grafana-datasource-nodejs4-npm-publish-tarball/package.json
2016-11-15 14:03:27.290483 | npm ERR! code ENOPACKAGEJSON
2016-11-15 14:03:27.290750 | npm ERR! errno -2
2016-11-15 14:03:27.290821 | npm ERR! syscall open
2016-11-15 14:03:27.291690 | 
2016-11-15 14:03:27.291865 | npm ERR! package.json ENOENT: no such file or 
directory, open 
'/home/jenkins/workspace/monasca-grafana-datasource-nodejs4-npm-publish-tarball/package.json'
2016-11-15 14:03:27.291893 | npm ERR! package.json This is most likely not a 
problem with npm itself.
2016-11-15 14:03:27.291921 | npm ERR! package.json npm can't find a 
package.json file in your current directory.
2016-11-15 14:03:27.297776 | 
2016-11-15 14:03:27.297870 | npm ERR! Please include the following file with 
any support request:
2016-11-15 14:03:27.297901 | npm ERR!  
/home/jenkins/workspace/monasca-grafana-datasource-nodejs4-npm-publish-tarball/npm-debug.log

I don't really know anything about nodejs packaging, so I'm not sure
what the issue is. I do see a plugin.json file, so perhaps this repo is
a different type of nodejs thing than the job expects and we need a
different job?

Doug

--- Begin forwarded message from jenkins ---
From: jenkins 
To: release-job-failures 
Date: Tue, 15 Nov 2016 14:03:43 +
Subject: [Release-job-failures] Release of openstack/monasca-grafana-datasource 
failed

Build failed.

- monasca-grafana-datasource-nodejs4-npm-publish-tarball 
http://logs.openstack.org/4e/4e822c25c5ce85a55d04ece0e59c7a0bb34c0dd5/release/monasca-grafana-datasource-nodejs4-npm-publish-tarball/2023b67/
 : FAILURE in 2m 02s
- monasca-grafana-datasource-npm-upload monasca-grafana-datasource-npm-upload : 
SKIPPED

--- End forwarded message ---

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

Re: [openstack-dev] [vitrage]bp:static-datasource-config-formatworking items

[Yujun Zhang]

On Tue, Nov 15, 2016 at 8:44 PM Weyl, Alexey (Nokia - IL) <
alexey.w...@nokia.com> wrote:

> Ok, sounds good.
>
> We need to understand what is the common way in openstack to work with
> deprecated code.
>

Maybe it could be discussed in next weekly meeting. Anybody who has
experience on it please raise your hand :-)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [heat][tripleo] New repository for software-config elements

[Zane Bitter]

On 15/11/16 04:26, Thomas Herve wrote:

Hi all,

Historically elements to create images using software config were
developed in the heat-templates repository, which turned out to mean
that this had to be packaged, etc. Today we were asked if tags could
be added to help maintaining the packages. Before we do that, I wonder
if we should extract the elements in a different repository. We
already have tests which are only applicable to this specific subset
of the repo, so it shouldn't be too hard.

In summary: let's create a new repository
heat-software-config-elements, and move everything from
hot/software-config/elements/ in the heat-templates repository to it
(and the associated tests).


This would definitely be the logical thing to do if we were starting 
from scratch. There is some pain involved for packagers, because they'd 
have to get rid of the old package and replace it with the new one. I'm 
OK with that though... the current arrangement is confusing.


- ZB

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

Re: [openstack-dev] [tc][kolla] Ansible module with GPLv3

[Thierry Carrez]

Jeremy Stanley wrote:
> [...]
> A quick search for http://codesearch.openstack.org/?q=gpl=1 turns
> up the openstack/murano-apps repo which has content aggregated under
> a mix of Apache License v2.0, GPLv2 (inherited from Plone), GPLv3
> (from Clearwater), and GNU AGPLv3 (SugarCRM); it calls them out with
> separate LICENSE files in different subtrees.

This licensing violates our guidelines. That said, the only files in the
repository are packaging information produced by Murano developers. They
probably don't have to mirror the upstream license the way they
currently do, so I feel like this could be (and should be) solved.

> The openstack/vmtp
> repo has an aggregation of Apache License v2.0, BSD and GPLv2 files
> with some details in their README.rst explaining the situation.

openstack/vmtp is not an "official" OpenStack project.

> The openstack/fuel-library repo has a dangerous-looking mix of Puppet
> modules under Apache License v2.0 and GPLv2 licenses, so probably
> not a shining example of how to go about this.

Yeah, probably needs to be fixed as well (if Fuel continues within the
Big Tent), looks like various leftovers from merge of internal code,
rather than intended (or necessary) licensing.

-- 
Thierry Carrez (ttx)



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

Re: [openstack-dev] [neutron][trunk-port] OVS tbr bridge wasn't be created by OVS agent

[Brian Haley]

On 11/15/16 5:12 AM, zhi wrote:

Sorry, I forgot to say my local environment is Liberty. :)


According to the blueprint and reviews this didn't land until Newton, 
maybe some in Mitaka, so I wouldn't expect it to work in Liberty.


-Brian



2016-11-15 18:07 GMT+08:00 zhi >:

Hi, all

I followed this guide[1] to create trunk ports and created a vm
by using trunk port. But I met a weird problem. OVS agent didn't
generate " tbr " bridge. All the OVS bridges shows below:
"
[root@server-64 ~]# ovs-vsctl list-br
br-int
br-physnet4
br-tun
"
Why did the OVS agent doesn't create " tbr " bridge ? I think I must
miss something but I don't know.

I enabled " trunk " in service_plugins configuration in neutron
server. And I did not add anything in OVS agent. Did I miss any
configuration in OVS agent ?


Thanks
Zhi Chang

[1]: https://wiki.openstack.org/wiki/Neutron/TrunkPort#CLI_usage_example





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

[Miles Gould]

On 14/11/16 20:52, Ian Cordasco wrote:

not_in is nice and explicit while nin and out are a bit, more clever. I think 
we should avoid trying to be clever.


Agreed - I think not_in is more intelligible and guessable than the 
other suggestions.


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

Re: [openstack-dev] [ALU] Re: [ALU] [vitrage]bp:static-datasource-config-formatworking items

[Weyl, Alexey (Nokia - IL)]

Ok, sounds good.

We need to understand what is the common way in openstack to work with 
deprecated code.

From: Yujun Zhang [mailto:zhangyujun+...@gmail.com] 
Sent: Tuesday, November 15, 2016 12:29 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [ALU] Re: [openstack-dev] [ALU] 
[vitrage]bp:static-datasource-config-formatworking items

Hi, Alexey

I plan to split the implementation to several steps, because it will take weeks 
to complete. I'm afraid it would be too big a patch to review if I submit all 
changes in one patch set.

Instead I want to get comments as earlier as possible. Each submit will be 
covered by additional unit test and keep backward compatibility.

Detail replies inline.

On Tue, Nov 15, 2016 at 5:51 PM Weyl, Alexey (Nokia - IL) 
 wrote:
Hi Yujun,

Good job! This is a very important change for Vitrage.

I have a couple of questions please:
1. Why do we want to create a new datasource ‘static’ and not rename the 
current ‘static_physical’ datasource and change it to work with the new format?
I don't want to break it during the evolution.
2. How are you planning to use the old 'static_physical' datasource  as a proxy 
if you said that you want to remove it?
Good point. Any suggestion on how we hide the deprecated modules? Move it as a 
submodule in new module.
3. What kind of merge is needed in the evaluator?
Parsing of `definition` section would be a common module for both evaluator and 
static data source 
4. I saw the implementation of the driver.py in static, and it doesn't do 
anything at the moment? (if you are still working on one of the patches then 
please market it as -1 in the code-review that we will know that you are still 
working on it.
Yes, skeleton is skeleton. Since I'm working remotely with vitrage team. I want 
to keep you updated on the progress. Still, it is complete with unit test and 
backward compatibility and will reduce further review work.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [nova] Nova API sub-team meeting

[Alex Xu]

Hi,

We have weekly Nova API meeting tomorrow. The meeting is being held
Wednesday UTC1300 and irc channel is #openstack-meeting-4.

The proposed agenda and meeting details are here:

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

Please feel free to add items to the agenda.

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

[openstack-dev] [nova] next notification subteam meeting

[Balázs Gibizer]

Hi, 

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

Cheers,
gibi

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

__
OpenStack Development Mailing 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] Proposing Kenji Ishii for core

[Akira Yoshiyama]

+1

2016年11月15日(火) 20:47 Rob Cresswell (rcresswe) :

> Big +1 from me
>
> > On 14 Nov 2016, at 00:24, Richard Jones  wrote:
> >
> > Hi Horizon core team,
> >
> > I propose Kenji Ishii as a new Horizon core reviewer. Kenji has been a
> > solid Horizon contributor for some time, with thoughtful and helpful
> > reviews showing good judgment and good knowledge of Horizion and
> > related systems. Please respond with your votes by Friday.
> >
> >
> > Thanks,
> >
> >Richard
> >
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [neutron][calico] networking-calico IRC meeting today

[Neil Jerram]

Hi all; just wanted to remind that there will be a networking-calico IRC
meeting today [1].  Please feel free to add to the agenda at [2] (or ask me
to do that if you prefer).

Thanks!
Neil

[1] http://eavesdrop.openstack.org/#Networking_Calico_Meeting
[2]
https://wiki.openstack.org/wiki/Meetings/NetworkingCalico#Agenda_for_2016-11-15
__
OpenStack Development Mailing 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] [api]

[Ian Cordasco]

On Nov 14, 2016 3:49 PM, "Edward Leafe"  wrote:
>
> On Nov 14, 2016, at 3:14 PM, Ed Leafe  wrote:
>
> > Since we already had ‘new’, I thought that ‘nin’ would be consistent.
No other reason to prefer it, though.
>
> s/new/neq
>
> Damn you autocorrect!

I forgot about neq. I suppose nin makes more sense in that context.
Hopefully, no one thinks we're making a reference to nine inch nails. ;-)
__
OpenStack Development Mailing 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] Proposing Kenji Ishii for core

[Rob Cresswell (rcresswe)]

Big +1 from me

> On 14 Nov 2016, at 00:24, Richard Jones  wrote:
> 
> Hi Horizon core team,
> 
> I propose Kenji Ishii as a new Horizon core reviewer. Kenji has been a
> solid Horizon contributor for some time, with thoughtful and helpful
> reviews showing good judgment and good knowledge of Horizion and
> related systems. Please respond with your votes by Friday.
> 
> 
> Thanks,
> 
>Richard
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

Re: [openstack-dev] [Openstack-operators] [openstack-operators][openstack-ansible]deploying mutli-node openstack on baremetal nodes

[Andy McCrae]

Hi Akshay,

If I understand correctly, you're looking to deploy the services on metal
hosts (rather than in containers) - in that case you would need to adjust
the env.d/*.yml (service files) to set the property "is_metal: True".
The second query regarding multiple VLans - if you are using pre-existing
hosts, you would pre-configure those with the appropriate network/IPs etc -
per host, and then specify them in your user_config.yml.

If you're running into problems or need more information (which I'm sure
you do!), jump into the #openstack-ansible channel on freenode IRC, it's a
lot easier to offer help there (and there are quite a few people who are
usually around and willing to help). It's difficult to understand your full
use-case and what you're trying to achieve from a single email.

Cheers,
Andy

On 15 November 2016 at 11:09, Akshay Kumar Sanghai <
akshaykumarsang...@gmail.com> wrote:

> Hi,
> I want to deploy openstack using openstack-ansilbe. I am having difficulty
> in understanding where to define baremetal host deployment and how to
> define multiple vlans that can be used to separate the networks(mgmt,
> tunnel, external). I went through  http://docs.openstack.org/
> developer/openstack-ansible/install-guide/app-custom-
> layouts.html#deploy-existing-components-on-dedicated-hosts
>
> Do i have to create service.yml for all services to specify them to
> directly run on hosts?
>
> Thanks
> AKshay
>
> ___
> OpenStack-operators mailing list
> openstack-operat...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
__
OpenStack Development Mailing 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] Proposing Kenji Ishii for core

[Akihiro Motoki]

+1

2016-11-14 9:24 GMT+09:00 Richard Jones :

> Hi Horizon core team,
>
> I propose Kenji Ishii as a new Horizon core reviewer. Kenji has been a
> solid Horizon contributor for some time, with thoughtful and helpful
> reviews showing good judgment and good knowledge of Horizion and
> related systems. Please respond with your votes by Friday.
>
>
> Thanks,
>
> Richard
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [openstack-operators][openstack-ansible]deploying mutli-node openstack on baremetal nodes

[Akshay Kumar Sanghai]

Hi,
I want to deploy openstack using openstack-ansilbe. I am having difficulty
in understanding where to define baremetal host deployment and how to
define multiple vlans that can be used to separate the networks(mgmt,
tunnel, external). I went through
http://docs.openstack.org/developer/openstack-ansible/install-guide/app-custom-layouts.html#deploy-existing-components-on-dedicated-hosts

Do i have to create service.yml for all services to specify them to
directly run on hosts?

Thanks
AKshay
__
OpenStack Development Mailing 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] Propose removal of TrivialFix requirement

[Paul Bourke]

Thanks for the reminder Andreas, patchset here: 
https://review.openstack.org/397672


On 15/11/16 10:29, Andreas Jaeger wrote:

On 2016-11-15 11:10, Paul Bourke wrote:

Given the window for this vote is now closed and I saw no minus ones
I'll assume this has passed. TrivialFix is now optional.


Is TrivialFix mentioned in the docs and do those need updating for the
changed policy?

Andreas



__
OpenStack Development Mailing 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] [ALU] [vitrage] bp:static-datasource-config-formatworking items

[Yujun Zhang]

Hi, Alexey

I plan to split the implementation to several steps, because it will take
weeks to complete. I'm afraid it would be too big a patch to review if I
submit all changes in one patch set.

Instead I want to get comments as earlier as possible. Each submit will be
covered by additional unit test and keep backward compatibility.

Detail replies inline.

On Tue, Nov 15, 2016 at 5:51 PM Weyl, Alexey (Nokia - IL) <
alexey.w...@nokia.com> wrote:

> Hi Yujun,
>
> Good job! This is a very important change for Vitrage.
>
> I have a couple of questions please:
> 1. Why do we want to create a new datasource ‘static’ and not rename the
> current ‘static_physical’ datasource and change it to work with the new
> format?
>
I don't want to break it during the evolution.

> 2. How are you planning to use the old 'static_physical' datasource  as a
> proxy if you said that you want to remove it?
>
Good point. Any suggestion on how we hide the deprecated modules? Move it
as a submodule in new module.

> 3. What kind of merge is needed in the evaluator?
>
Parsing of `definition` section would be a common module for both evaluator
and static data source

> 4. I saw the implementation of the driver.py in static, and it doesn't do
> anything at the moment? (if you are still working on one of the patches
> then please market it as -1 in the code-review that we will know that you
> are still working on it.
>
Yes, skeleton is skeleton. Since I'm working remotely with vitrage team. I
want to keep you updated on the progress. Still, it is complete with unit
test and backward compatibility and will reduce further review work.
__
OpenStack Development Mailing 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] Propose removal of TrivialFix requirement

[Andreas Jaeger]

On 2016-11-15 11:10, Paul Bourke wrote:
> Given the window for this vote is now closed and I saw no minus ones
> I'll assume this has passed. TrivialFix is now optional.

Is TrivialFix mentioned in the docs and do those need updating for the
changed policy?

Andreas
-- 
 Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
  SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GF: Felix Imendörffer, Jane Smithard, Graham Norton,
   HRB 21284 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126


__
OpenStack Development Mailing 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][trunk-port] OVS tbr bridge wasn't be created by OVS agent

[zhi]

Sorry, I forgot to say my local environment is Liberty. :)

2016-11-15 18:07 GMT+08:00 zhi :

> Hi, all
>
> I followed this guide[1] to create trunk ports and created a vm by
> using trunk port. But I met a weird problem. OVS agent didn't generate "
> tbr " bridge. All the OVS bridges shows below:
> "
> [root@server-64 ~]# ovs-vsctl list-br
> br-int
> br-physnet4
> br-tun
> "
> Why did the OVS agent doesn't create " tbr " bridge ? I think I must miss
> something but I don't know.
>
> I enabled " trunk " in service_plugins configuration in neutron
> server. And I did not add anything in OVS agent. Did I miss any
> configuration in OVS agent ?
>
>
> Thanks
> Zhi Chang
>
> [1]: https://wiki.openstack.org/wiki/Neutron/TrunkPort#CLI_usage_example
>
__
OpenStack Development Mailing 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] Propose removal of TrivialFix requirement

[Paul Bourke]

Given the window for this vote is now closed and I saw no minus ones 
I'll assume this has passed. TrivialFix is now optional.


Thanks,
-Paul

On 04/11/16 22:51, Steven Dake (stdake) wrote:

Paul,



I’ll take your request as a request for a vote of the core reviewers.



My vote is +1 in favor of removing the requirement for TrivialFix.



As per our standard policy, the voting window is open for 7 days
beginning November 3^rd , and finishing (in 7 days) on November 11^th .



Regards

-steve





*From: *Paul Bourke 
*Reply-To: *"OpenStack Development Mailing List (not for usage
questions)" 
*Date: *Thursday, November 3, 2016 at 6:21 AM
*To: *"OpenStack Development Mailing List (not for usage questions)"

*Subject: *[openstack-dev] [kolla] Propose removal of TrivialFix
requirement



Kolleagues,



How do people feel above removing the requirement of having TrivialFix

in commit messages where a bug/bp is not required?



I'm seeing a lot of valid and important commits being held up
because of

this, in my opinion, unnecessary requirement. It also causes friction

for new contributers to the project.



Are there any major benefits we're getting from the use of this tag
that

I'm missing?



Cheers,

-Paul



__

OpenStack Development Mailing List (not for usage questions)

Unsubscribe: openstack-dev-requ...@lists.openstack.org
?subject:unsubscribe

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





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



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

[openstack-dev] [neutron][trunk-port] OVS tbr bridge wasn't be created by OVS agent

[zhi]

Hi, all

I followed this guide[1] to create trunk ports and created a vm by
using trunk port. But I met a weird problem. OVS agent didn't generate "
tbr " bridge. All the OVS bridges shows below:
"
[root@server-64 ~]# ovs-vsctl list-br
br-int
br-physnet4
br-tun
"
Why did the OVS agent doesn't create " tbr " bridge ? I think I must miss
something but I don't know.

I enabled " trunk " in service_plugins configuration in neutron server.
And I did not add anything in OVS agent. Did I miss any configuration in
OVS agent ?


Thanks
Zhi Chang

[1]: https://wiki.openstack.org/wiki/Neutron/TrunkPort#CLI_usage_example
__
OpenStack Development Mailing 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] [gnocchi] new measures backlog scheduling

[Julien Danjou]

On Tue, Nov 15 2016, gordon chung wrote:

>> I'm stepping in to an area here (gnocchi) that I know very little about,
>> so please forgive me where I mess up.
>>
>> First, as a practical note, stuff in Swift will be /much/ better when
>> you spread it across the entire namespace. It's a lot better to data
>> stored in many containers instead of putting all data into just one
>> container. Spreading the data out takes advantages of Swift's scaling
>> characteristics and makes users and ops happier.
>
> thanks for the tip John! good to know the proposal might actually have 
> additional benefits.

Yup that's good to know. We do that create a container for each metric,
but not for the new measures, that we all stack into one unique
container.

> is the consistent hashing code == hashring code? we actually jacked that 
> from Ironic and used it in Ceilometer already. :) but that's a good idea 
> to leverage it in this case if we proceed. i just noticed jd adding it 
> to tooz[1].

Burned, I was going to say that!

> that's a good point. in Ceilometer, iirc we don't ever change the number 
> of buckets so we arguably didn't need it. in this case, i imagine we'd 
> need to consider overhead of creating a lot of buckets vs letting users 
> attempt to figure out what the right number of buckets is for their system.

Yeah in the case of the Swift driver for Gnocchi, I'm not really sure
how much buckets we should create. Should we make the user pick a random
number like the number of partition in Swift and then create the
containers in Swift? Or can we have something simpler? (I like automagic
things). WDYT Gordon?

And thanks John :)

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

Re: [openstack-dev] [ALU] [vitrage] bp:static-datasource-config-formatworking items

[Weyl, Alexey (Nokia - IL)]

Hi Yujun,

Good job! This is a very important change for Vitrage.

I have a couple of questions please:
1. Why do we want to create a new datasource ‘static’ and not rename the 
current ‘static_physical’ datasource and change it to work with the new format?
2. How are you planning to use the old 'static_physical' datasource  as a proxy 
if you said that you want to remove it?
3. What kind of merge is needed in the evaluator?
4. I saw the implementation of the driver.py in static, and it doesn't do 
anything at the moment? (if you are still working on one of the patches then 
please market it as -1 in the code-review that we will know that you are still 
working on it.)

BR,
Alexey

From: Yujun Zhang [mailto:zhangyujun+...@gmail.com] 
Sent: Tuesday, November 15, 2016 9:11 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [ALU] [openstack-dev] [vitrage] 
bp:static-datasource-config-formatworking items

Hi folks.

I have just started working on the blueprint about static datasource config 
format[1]. The planned working items are as following.
1. create new datasource `static` to parse new configuration format
2. parse old configuration format in `static` with a proxy to existing 
`static_physical` module
3. remove `static_physical` datasource and print deprecation warning in `static`
4. merge common logic with scenario template evaluator
Requesting for comments.

P.S. I chose the name `static` since it is actually not limited to physical 
entities. Virtual entities can also be described in `static` file if there is 
no dynamic source.

[1]: 
https://blueprints.launchpad.net/vitrage/+spec/static-datasource-config-format

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

Re: [openstack-dev] [neutron] OVO support

[Miguel Angel Ajo Pelayo]

I could be wrong, but I suspect we're doing it this way to be able to do
changes to several objects atomically, and roll back the transactions if at
some point in time what we're trying to accomplish is not possible.

Thoughts?

On Tue, Nov 15, 2016 at 10:06 AM, Gary Kotton  wrote:

> Hi,
>
> It seems like a lot of the object work is being done under database
> transactions. My understanding is that the objects should take care of this
> internally.
>
> Any thoughts?
>
> Thanks
>
> Gary
>
> __
> OpenStack Development Mailing 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] [heat][tripleo] New repository for software-config elements

[Thomas Herve]

Hi all,

Historically elements to create images using software config were
developed in the heat-templates repository, which turned out to mean
that this had to be packaged, etc. Today we were asked if tags could
be added to help maintaining the packages. Before we do that, I wonder
if we should extract the elements in a different repository. We
already have tests which are only applicable to this specific subset
of the repo, so it shouldn't be too hard.

In summary: let's create a new repository
heat-software-config-elements, and move everything from
hot/software-config/elements/ in the heat-templates repository to it
(and the associated tests).

Thoughts?

-- 
Thomas

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

[openstack-dev] [neutron] OVO support

[Gary Kotton]

Hi,
It seems like a lot of the object work is being done under database 
transactions. My understanding is that the objects should take care of this 
internally.
Any thoughts?
Thanks
Gary
__
OpenStack Development Mailing 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] [tacker] No Tacker weekly meeting today

[Sripriya Seetharam]

Hi Tackers,

There will be no weekly meeting today as there are no agenda items from the 
team. We will meet next week on Nov 22nd 2016. Please feel free to add your 
agenda items in meeting wiki link [1].

[1] https://wiki.openstack.org/wiki/Meetings/Tacker#Agenda


Thanks,
Sripriya
__
OpenStack Development Mailing 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] Problem with Quota and servers spawned in groups

[Sławek Kapłoński]

Hello,

IMHO receiving multiple uuids is not related to bug which I want to
resolve somehow but if Chris wrote it I thought that it is maybe somehow
related to "spawn multiple instances" feature.
So can You maybe review my patch
https://review.openstack.org/#/c/371592/ to fix
https://bugs.launchpad.net/nova/+bug/1623809 or I really need new specs
for that?

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

On Mon, 14 Nov 2016, melanie witt wrote:

> On Mon, 14 Nov 2016 17:34:28 -0600, Matt Riedemann wrote:
> > Why do we want to return a list of uuids for servers created? I thought
> > that's why we have the 'return_reservation_id' request parameter for the
> > server multiple-create scenario so that you can get a single reservation
> > ID back and all of the servers created are using that same
> > reservation_id and then you can query them by that later if you want to
> > list them out.
> 
> As far as I know, doing that would be a nice-to-have for people using
> multi-create, so they get the uuids in one step instead of having to do a
> second query for them using the reservation_id. It's not technically
> necessary and I don't think it's related to this multi-create quota behavior
> issue.
> 
> -melanie
> 
> 
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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