Re: [openstack-dev] [kolla] Kolla is now stable:follows-policy project

[Steven Dake (stdake)]

Folks,

The addition of this project maturity tag is a great achievement!  This is one 
of many factors used by Operators to determine maturity of OpenStack projects.  
Glad to see our project’s persistence in this area paid off for the kolla and 
kolla-ansible deliverables.

Good work all!

Regards,
-steve


-Original Message-
From: Michał Jastrzębski 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Friday, August 18, 2017 at 12:49 PM
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: [openstack-dev] [kolla] Kolla is now stable:follows-policy project

As of today Kolla got this tag. That doesn't really mean we change
anything in our model as tag is given to projects which already
follows rules of stable policy, but that makes it official:)

Keep up with good work Kolla team!

Cheers,
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] [chef] stable/ocata has been released

[Samuel Cassiba]

Ohai!

We released the stable/ocata branch of the cookbooks today. For this
release, we included updates to the following repos:

cookbook-openstack-block-storage (Cinder)
cookbook-openstack-common (shared configuration and libraries)
cookbook-openstack-compute (Nova)
cookbook-openstack-dashboard (Horizon)
cookbook-openstack-identity (Keystone)
cookbook-openstack-image (Glance)
cookbook-openstack-integration-test (Tempest)
cookbook-openstack-network (Neutron)
cookbook-openstack-ops-database (shared database (MySQL/MariaDB))
cookbook-openstack-ops-messaging (shared MQ service)
cookbook-openstack-orchestration (Heat)
cookbook-openstack-telemetry (Ceilometer and Gnocchi)
openstack-chef-repo (a functioning example monolithic repo combining
all cookbooks and deployment-specific configuration)

Regrettably, we still were not able to offer a release of the Murano
cookbook (cookbook-openstack-application-catalog) due to timing in
stabilizing the core cookbooks and our testing frameworks. We hope to
be able to carve out some time between stabilizing Pike and planning
for Queens.

A big thank you goes out to everyone who pitched in, no matter how
small. Even the tactical contributions have been beneficial.

For any issues, or just to say hi, feel free to drop by
#openstack-chef and idle. Onward to Pike!

-- 
Best,
Samuel Cassiba

__
OpenStack Development Mailing 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 is now stable:follows-policy project

[Michał Jastrzębski]

As of today Kolla got this tag. That doesn't really mean we change
anything in our model as tag is given to projects which already
follows rules of stable policy, but that makes it official:)

Keep up with good work Kolla team!

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

Re: [openstack-dev] [release] [telemetry] Ceilometer stable/pike branch outlook

[Sean McGinnis]

On Fri, Aug 18, 2017 at 07:00:08PM +, gordon chung wrote:
> apologies, I'm currently away on vacation (for a while)
> 
> we can merge the stable/pike patch as it seems there are others dependent on 
> it. I don't believe it affects us either way.
> 
> I don't see the auto patch that creates tag so I guess we need to do it via 
> releases project
> 
> --
> 
> gord

Correct, that is done via a patch proposed to the releases repo.

There's a little more instruction here:

http://lists.openstack.org/pipermail/openstack-dev/2017-August/121266.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] [release] [telemetry] Ceilometer stable/pike branch outlook

[gordon chung]

apologies, I'm currently away on vacation (for a while)

we can merge the stable/pike patch as it seems there are others dependent on 
it. I don't believe it affects us either way.

I don't see the auto patch that creates tag so I guess we need to do it via 
releases project

--

gord




From: Sean McGinnis 
Sent: Friday, August 18, 2017 4:31:44 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [release] [telemetry] Ceilometer stable/pike 
branch outlook

> > >>
> > >> Can someone on the release team clarify this for us?
> > >
> > > That's correct the bit you're missing is cycle-with-intermediary
> doesn't
> > > have pre-releases (b{1,2,3},rc{1,2}) so when the ceilometer team feels
> > > they have the code in shape for a release they'll tag that release and
> > > cut a stable/pike branch at the tag point.
> >

>
> that email explicitly says: "Deliverables following the
> cycle-with-intermediary model should also create their Pike release branch
> next week. That means potentially making a last Pike release, and in all
> cases posting the stable/pike branch creation request"
>
> And that wasn't done for ceilometer. So it needs to be done, right?
>

Yes, I just double checked, and there has not been a pike release yet for
ceilometer. That does need to be done soon.

Sean

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

Re: [openstack-dev] [TripleO][CI] FreeIPA Deployment

[Emilien Macchi]

On Fri, Aug 18, 2017 at 8:34 AM, Harry Rybacki  wrote:
> Greetings Stackers,
>
> Recently, I brought up a discussion around deploying FreeIPA via
> TripleO-Quickstart vs TripleO. This is part of a larger discussion
> around expanding security related CI coverage for OpenStack.
>
> A few months back, I added the ability to deploy FreeIPA via
> TripleO-Quickstart through three reviews:
>
> 1) Adding a role to deploy FreeIPA via OOOQ_E[1]
> 2) Providing OOOQ with the ability to deploy a supplemental node
> (alongside the undercloud)[2]
> 3) Update the quickstart-extras playbook to deploy FreeIPA[3]
>
>
> The reasoning behind this is as follows (copied from a conversation
> with jaosorior):
>
>> So the deal is that both the undercloud and the overcloud need to be 
>> registered as a FreeIPA client.
>> This is because they need to authenticate to it in order to execute actions.
>>
>> * The undercloud needs to have FreeIPA credentials because it's running 
>> novajoin, which in turn
>> executes requests to FreeIPA in order to create service principals
>>  - The service principals are ultimately the service name and the node name 
>> entries for which we'll
>> requests the certificates.
>> * The overcloud nodes need to be registered and authenticated to FreeIPA 
>> (which right now happens > through a cloud-init script provisioned by 
>> nova/nova-metadata) because that's how it requests
>> certificates.
>>
>> So the flow is as follows:
>>
>> * FreeIPA node is provisioned.
>>  - We'll appropriate credentials at this point.
>>  - We register the undercloud as a FreeIPA client and get an OTP (one time 
>> password) for it
>> - We add the OTP to the undercloud.conf and enable novajoin.
>> * We trigger the undercloud install.
>>  - after the install, we have novajoin running, which is the service that 
>> registers automatically the
>> overcloud nodes to FreeIPA.
>> * We trigger the overcloud deploy
>>  - We need to set up a flag that tells the deploy to pass appropriate nova 
>> metadata (which tells
>> novajoin that the nodes should be registered).
>>  - profit!! we can now get certificates from the CA (and do other stuff that 
>> FreeIPA allows you to do,
>> such as use kerberos auth, control sudo rights of the nodes' users, etc.)
>>
>> Since the nodes need to be registered to FreeIPA, we can't rely on FreeIPA 
>> being installed by
>> TripleO, even if that's possible by doing it through a composable service.
>> If we would use a composable service to install FreeIPA, the flow would be 
>> like this:
>>
>> * Install undercloud
>> * Install overcloud with one node (running FreeIPA)
>> * register undercloud node to FreeIPA and modify undercloud.conf
>> * Update undercloud
>> * scale overcloud and register the rest of the nodes to FreeIPA through 
>> novajoin.
>>
>> So, while we could install FreeIPA with TripleO. This really complicates the 
>> deployment to an
>> unnecessary point.
>>
>> So I suggest keeping the current behavior, which treats FreeIPA as a 
>> separate node to be
>> provisioned before the undercloud). And if folks would like to have a 
>> separate FreeIPA node for their > overcloud deployment (which could 
>> provision certs for the tenants) then we could do that as a
>> composable service, if people request it.
>
> I am now re-raising this to the group at large for discussion about
> the merits of this approach vs deploying via TripleO itself.

There are 3 approaches here:

- Keep using Quickstart which is of course not the viable option since
TripleO Quickstart is only used by CI and developers right now. Not by
customers neither in production.
- Deploy your own Ansible playbooks or automation tool to deploy
FreeIPA and host it wherever you like. Integrate the playbooks in
TripleO, as an external component (can be deployed manually between
some steps but will be to be documented).
- Create a composable service that will deploy FreeIPA service(s),
part of TripleO Heat Templates. The way it works *now* will require
you to have a puppet-freeipa module to deploy the bits but we're
working toward migrating to Ansible at some point.

I hope it helps, let me know if you need further details on a specific approach.
-- 
Emilien Macchi

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

[openstack-dev] [nova] [placement] [api] cache headers in placement service

[Chris Dent]

(I put [api] in the subject tags because this might be of interest
to a wider audience that cares about APIs.)

Long ago and far away I made this bug:

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

"placement api responses should not be cacehable"

Today I've pushed up a WIP that demonstrates a way to address this:

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

Before I get too far along with it, I'd like us to decide whether we
think it is worth doing and consider some of the questions it will
raise.

I think it is worth doing not just because it would be correct but
because without it, we cannot be assured that proxies or user agents
will not cache resource providers and other entities, and that would
lead to bizarre results.

At the same time, any entity you put on the web, according to the
RFCs[1], should have a last-modified header if it "can be reasonably
and consistently determined".

So my change above adds 'last-modified' and 'cache-control:
no-cache' to GET of /resource_providers and
/resource_providers/{uuid} and proposes we do it for everything
else.

Should we?

If we do, some things to think about:

* The related OVO will need the updated_at and created_at
  fields exposed. This is pretty easy to do with the
  NovaTimestampObject mixin. This doesn't need to require a object
  version bump because we don't do RPC with them.

* Adding a response header violates interop guidelines, so this
  would mean a microversion bump that impacts all GET requests. In
  systems that currently use placement (the report client in nova,
  mostly) no attention is being paid to either of the headers being
  added, so there would be no need for motion on that side.

* The current implementation of getting the last modified time for a
  collection of resources is intentionally naive and decoupled from
  other stuff. For very large result sets[3] this might be annoying,
  but since we are already doing plenty of traversing of long lists,
  it may not be a big deal. If it is we can incorporate getting the
  last modified time in the loop that serializes objects to JSON
  output.

I think we should. Generally speaking I think it is good form to
fulfil the expectations of HTTP. It helps make sure the HTTP APIs
work with the unknown client. Working with the unknown client is one
of the best reasons to have an HTTP API.k

[1] https://tools.ietf.org/html/rfc7232#section-2.2

[2] An argument could be made that this change is fixing a protocol
level bug, but I reckon that argument wouldn't fly with most people.

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

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

[Attila Darazs]

If the topics below interest you and you want to contribute to the 
discussion, feel free to join the next meeting:


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

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

Topics discussed:

We debated whether we should add an upgrades job to 
tripleo-quickstart-extra that would allow our IRC bot (hubbot) to report 
on the status of the upgrades as well using gatestatus[1]. The upgrades 
jobs are not stable enough to do that though.


We have/had two major infra issues during the week, one is not using the 
nodepool DNS in jobs (fixed by Sagi) and not using the DLRN & CentOS 
mirrors during DLRN package building in the gates. The latter has fixes 
but they are not merged yet.


Emilien and Arx is working on adding tempest tests in place of pingtests 
in most of our gate jobs where it's useful. We also have quite a few 
jobs that don't have any validation yet.


We decided on using a whitelist for the collecting log files from /etc 
on the upstream jobs. This will reduce the load on the logserver.


3/4 node multinode jobs are almost ready, we're trying to merge the 
changes, just like the ones for multinic with libvirt.


We're also working hard to get the periodic/promotion jobs work on 
rdocloud to increase the cadence of the promotions. We have daily 
standups to coordinate the work with Ronelle, Wes, John and me.


That's it for this week, have a nice weekend.

Best regards,
Attila

[1] https://github.com/adarazs/gate-status

__
OpenStack Development Mailing 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] The OpenStack Summit Sydney schedule is live!

[Allison Price]

Hi everyone,

The main conference schedule for the upcoming OpenStack Summit in Sydney 
 is now available! 

SCHEDULE: https://www.openstack.org/summit/sydney-2017/summit-schedule/ 


Log in with your OpenStackID  and start building your 
schedule now! It will automatically sync with the mobile app, which will be 
available in the coming weeks. 

Register now  at the early 
bird discounted rate on your Summit ticket before prices increase on September 
8 at 11:59pm Pacific Time (September 9 at 6:59 UTC).


IMPORTANT INFORMATION
View a list of nearby hotels on our website here 
.
Visa Information : 
All non-Australian residents will need a visa to travel to Australia.
Interested in sponsoring the Summit? Learn more here 
.


SPEAKER NOTIFICATIONS
If you submitted a talk - check your email. Everyone who submitted a speaking 
proposal for the Summit will receive an email notification to let them know 
whether or not their talk has been accepted. The email sent to selected 
speakers was sent from speakersupp...@openstack.org 
 and contains important next steps and 
speaker registration codes. Each speaker is responsible for registering 
themselves to attend the Summit; please make sure your colleagues read the 
email and complete this step.

Contact sum...@openstack.org  with any questions.

See you in Sydney!

Cheers,
Allison 

Allison Price
OpenStack Foundation
alli...@openstack.org


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

Re: [openstack-dev] [tripleo] Adding new roles after upgrade is broken.

[Jiří Stránský]

On 18.8.2017 17:25, Marios Andreou wrote:

On Fri, Aug 18, 2017 at 4:22 PM, Jiří Stránský  wrote:


On 18.8.2017 13:18, Sofer Athlan-Guyot wrote:


Hi,

We may have missing packages when the user is adding a new role to its
roles_data file and the base image is coming from previous version.

The workflow would be this one:
   - install newton
   - upgrade to ocata
   - add collectd to roles_data and redeploy the stack

For instance if one is adding
OS::TripleO::Services::Collectdservices::collectd in an ocata env coming
from an upgraded newton env, he/she won't have the necessary packages
(for instance collectd-disk).  The puppet manifest will fail has the
package is missing and puppet doesn't install package.  The upgrade
task[1] is useless as the new role wasn't added during the upgrade but
after.



Right, but the package could be added during the upgrade. The
upgrade_tasks could/should make the set of installed overcloud RPMs on par
with the overcloud-full image of the respective release, ideally. So you'd
have collectd RPMs installed always, both on freshly deployed and upgraded
envs, regardless if you actually use collectd or not. We already did some
package installs/uninstalls as part of upgrades and updates, but probably
didn't have 100% coverage.



yeah +1 to this except where would those upgrade_tasks go? Taking the given
example, upgrade_tasks in collectd-disk.yaml wont be executed because
during the upgrade, the operator didn't have that enabled as a service (it
is default off, and new so they couldn't deploy it before).

So we may have to use some 'central place' (this is what Sofer was
advocating earlier on irc) like in the tripleo-packages.yaml and have tasks
there.


Yes exactly, tripleo-packages.yaml is the right place IMO.


The problem then becomes however that we don't _know_ which services
we need to download packages for? Oh.. no you're saying we can use the
current release package list (e.g. do you mean from something in
https://github.com/openstack/tripleo-puppet-elements pkg-maps? ).


Yea i meant diff between e.g. Newton and Ocata t-p-e:

https://github.com/openstack/tripleo-puppet-elements/compare/stable/newton...stable/ocata

Or we could download overcloud-full.qcow2 for both Newton and Ocata, and 
inspect them using libguestfs-tools for the list of installed RPMs, 
which could give us the exact diff. That might be the easiest way how to 
do this perhaps?



Have a good day folks,

Jirka







I don't see any easy way to solve this.  Basically we need a way to keep
in sync base image between release without using the upgrade_tasks,
maybe in the tripleo-package one ?



Given that released code is affected, we may treat it as a bug that
requires a minor update, and in addition to upgrade_tasks, we can add all
the necessary package installs into minor update code (yum_update.sh) too.
Again this shouldn't depend on what services are actually enabled, just
unconditionally sync with latest content of overcloud-full image of the
respective release.

I guess the time consuming part will be preparing the envs that will allow
comparing a fresh deploy vs. an upgraded one to get the `rpm -qa | sort`
difference. Or we could try a shortcut and see what changes went into
tripleo-puppet-elements in each release.



yeah based on what you said, am thinking
https://github.com/openstack/tripleo-puppet-elements/blob/master/elements/overcloud-controller/pkg-map
for example , or some parsing of the combined element pkg maps... :/ still
likely need some tooling to do that though

thanks, marios





This shouldn't be a problem with container, but everything before pike
is affected.



Indeed. There will still be some basic baremetal host content management
as long as we're not using Atomic, but the room for potential problems will
be much smaller.

Jirka



Originially seen there[2]

[1] https://github.com/openstack/tripleo-heat-templates/blob/sta
ble/ocata/puppet/services/metrics/collectd.yaml#L130..L134
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1455065




__
OpenStack Development Mailing 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] [Octavia]Questions about octavia flavors spec

[Michael Johnson]

Hi,

Flavors are intended to be setup by the operator/admin only.  They
capture details of the load balancer offering and any local specific
configuration.  The intent here is the flavor options and descriptions
will be visible to end users, but creation/modification would require
an admin role.  End users will be able to specify the flavor they
would like to use for the load balancer at load balancer creation time
via the load balancer create API.

We are just now starting to work on providers.  The providers
implementation needs a spec and review process. I hope we can create
this spec and create the providers interface during the Queens series.

Michael


On Tue, Aug 15, 2017 at 7:09 PM, 何庆  wrote:
> Hi, I'm trying to figure out how the flavor will be implemented and have few
> questions about the flavor spec[1]
>
> 1. What does "RO" mean in API /flavors? Is it short for ReadOnly?
> In my understanding, user need create flavor by himself, so the flavor API
> should not be readonly.
>
> FLAVOR(/flavors)
>
> +-+---+-+-++-+
> |Attribute|Type   |Access   |Default  |Validation/ |Description
> |
> |Name |   | |Value|Conversion  |
> |
> +=+===+=+=++=+
> |id   |string |RO, admin|generated|N/A |identity
> |
> | |(UUID) | | ||
> |
> +-+---+-+-++-+
> |name |string |RO, admin|''   |string  |human-readable
> |
> | |   | | ||name
> |
> +-+---+-+-++-+
> |description  |string |RO, admin|''   |string  |human-readable
> |
> | |   | | ||description
> |
> +-+---+-+-++-+
> |enabled  |bool   |RO, admin|true |bool|toggle
> |
> | |   | | ||
> |
> +-+---+-+-++-+
> |flavor_profile_id|string |RO, admin| |string  |human-readable
> |
> | |   | | |
> |flavor_profile_id|
> +-+---+-+-++-+
>
> 2. Do we also need an API like /providers to query providers and metadata
> available？
>
>
>
> [1] https://review.openstack.org/#/c/392485/
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

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

[openstack-dev] [TripleO][CI] FreeIPA Deployment

[Harry Rybacki]

Greetings Stackers,

Recently, I brought up a discussion around deploying FreeIPA via
TripleO-Quickstart vs TripleO. This is part of a larger discussion
around expanding security related CI coverage for OpenStack.

A few months back, I added the ability to deploy FreeIPA via
TripleO-Quickstart through three reviews:

1) Adding a role to deploy FreeIPA via OOOQ_E[1]
2) Providing OOOQ with the ability to deploy a supplemental node
(alongside the undercloud)[2]
3) Update the quickstart-extras playbook to deploy FreeIPA[3]


The reasoning behind this is as follows (copied from a conversation
with jaosorior):

> So the deal is that both the undercloud and the overcloud need to be 
> registered as a FreeIPA client.
> This is because they need to authenticate to it in order to execute actions.
>
> * The undercloud needs to have FreeIPA credentials because it's running 
> novajoin, which in turn
> executes requests to FreeIPA in order to create service principals
>  - The service principals are ultimately the service name and the node name 
> entries for which we'll
> requests the certificates.
> * The overcloud nodes need to be registered and authenticated to FreeIPA 
> (which right now happens > through a cloud-init script provisioned by 
> nova/nova-metadata) because that's how it requests
> certificates.
>
> So the flow is as follows:
>
> * FreeIPA node is provisioned.
>  - We'll appropriate credentials at this point.
>  - We register the undercloud as a FreeIPA client and get an OTP (one time 
> password) for it
> - We add the OTP to the undercloud.conf and enable novajoin.
> * We trigger the undercloud install.
>  - after the install, we have novajoin running, which is the service that 
> registers automatically the
> overcloud nodes to FreeIPA.
> * We trigger the overcloud deploy
>  - We need to set up a flag that tells the deploy to pass appropriate nova 
> metadata (which tells
> novajoin that the nodes should be registered).
>  - profit!! we can now get certificates from the CA (and do other stuff that 
> FreeIPA allows you to do,
> such as use kerberos auth, control sudo rights of the nodes' users, etc.)
>
> Since the nodes need to be registered to FreeIPA, we can't rely on FreeIPA 
> being installed by
> TripleO, even if that's possible by doing it through a composable service.
> If we would use a composable service to install FreeIPA, the flow would be 
> like this:
>
> * Install undercloud
> * Install overcloud with one node (running FreeIPA)
> * register undercloud node to FreeIPA and modify undercloud.conf
> * Update undercloud
> * scale overcloud and register the rest of the nodes to FreeIPA through 
> novajoin.
>
> So, while we could install FreeIPA with TripleO. This really complicates the 
> deployment to an
> unnecessary point.
>
> So I suggest keeping the current behavior, which treats FreeIPA as a separate 
> node to be
> provisioned before the undercloud). And if folks would like to have a 
> separate FreeIPA node for their > overcloud deployment (which could provision 
> certs for the tenants) then we could do that as a
> composable service, if people request it.

I am now re-raising this to the group at large for discussion about
the merits of this approach vs deploying via TripleO itself.


[1] - https://review.openstack.org/#/c/436198/
[2] - https://review.openstack.org/#/c/451523/
[3] - https://review.openstack.org/#/c/453223/

/R

Harry Rybacki

__
OpenStack Development Mailing 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] [tricircle-Service Function Chaining]

[meher.hihi]

Hi Zhiyuan,

Thank you very much, I'll join the next meeting! 

Meher




Message: 3
Date: Thu, 17 Aug 2017 12:26:06 +
From: Vega Cai 
To: "OpenStack Development Mailing List (not for usage questions)"

Subject: Re: [openstack-dev] [tricircle-Service Function Chaining]
Message-ID:

[openstack-dev] [tricircle-North South Networking via Direct Provider Networks]

[meher.hihi]

Hello everyone,

Still in the test phase of the scenarios proposed by the Tricircle 
documentation, I try to do "North South Networking via Direct Provider 
Networks" but I failed to start an instance with 2 NICs, apparently the Cirros 
image does not support this option by default.

So I will add a new image and so I need the horizon service which is disabled 
when installing Tricircle. Thanks in advance for giving me an idea on how to 
add the dashboard without re-deploying!

Best regards,

Meher

[Logo Orange]

Meher Hihi
Intern
ORANGE/IMT/OLN/WTC/CMA/MAX
Fixe : +33 2 96 07 03 
71
Mobile : +33 7 58 38 68 
87
meher.h...@orange.com



_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

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

Re: [openstack-dev] [tripleo] Adding new roles after upgrade is broken.

[Marios Andreou]

On Fri, Aug 18, 2017 at 4:22 PM, Jiří Stránský  wrote:

> On 18.8.2017 13:18, Sofer Athlan-Guyot wrote:
>
>> Hi,
>>
>> We may have missing packages when the user is adding a new role to its
>> roles_data file and the base image is coming from previous version.
>>
>> The workflow would be this one:
>>   - install newton
>>   - upgrade to ocata
>>   - add collectd to roles_data and redeploy the stack
>>
>> For instance if one is adding
>> OS::TripleO::Services::Collectdservices::collectd in an ocata env coming
>> from an upgraded newton env, he/she won't have the necessary packages
>> (for instance collectd-disk).  The puppet manifest will fail has the
>> package is missing and puppet doesn't install package.  The upgrade
>> task[1] is useless as the new role wasn't added during the upgrade but
>> after.
>>
>
> Right, but the package could be added during the upgrade. The
> upgrade_tasks could/should make the set of installed overcloud RPMs on par
> with the overcloud-full image of the respective release, ideally. So you'd
> have collectd RPMs installed always, both on freshly deployed and upgraded
> envs, regardless if you actually use collectd or not. We already did some
> package installs/uninstalls as part of upgrades and updates, but probably
> didn't have 100% coverage.
>
>
yeah +1 to this except where would those upgrade_tasks go? Taking the given
example, upgrade_tasks in collectd-disk.yaml wont be executed because
during the upgrade, the operator didn't have that enabled as a service (it
is default off, and new so they couldn't deploy it before).

So we may have to use some 'central place' (this is what Sofer was
advocating earlier on irc) like in the tripleo-packages.yaml and have tasks
there. The problem then becomes however that we don't _know_ which services
we need to download packages for? Oh.. no you're saying we can use the
current release package list (e.g. do you mean from something in
https://github.com/openstack/tripleo-puppet-elements pkg-maps? ).


>
>> I don't see any easy way to solve this.  Basically we need a way to keep
>> in sync base image between release without using the upgrade_tasks,
>> maybe in the tripleo-package one ?
>>
>
> Given that released code is affected, we may treat it as a bug that
> requires a minor update, and in addition to upgrade_tasks, we can add all
> the necessary package installs into minor update code (yum_update.sh) too.
> Again this shouldn't depend on what services are actually enabled, just
> unconditionally sync with latest content of overcloud-full image of the
> respective release.
>
> I guess the time consuming part will be preparing the envs that will allow
> comparing a fresh deploy vs. an upgraded one to get the `rpm -qa | sort`
> difference. Or we could try a shortcut and see what changes went into
> tripleo-puppet-elements in each release.
>
>
yeah based on what you said, am thinking
https://github.com/openstack/tripleo-puppet-elements/blob/master/elements/overcloud-controller/pkg-map
for example , or some parsing of the combined element pkg maps... :/ still
likely need some tooling to do that though

thanks, marios


>
>> This shouldn't be a problem with container, but everything before pike
>> is affected.
>>
>
> Indeed. There will still be some basic baremetal host content management
> as long as we're not using Atomic, but the room for potential problems will
> be much smaller.
>
> Jirka
>
>
>> Originially seen there[2]
>>
>> [1] https://github.com/openstack/tripleo-heat-templates/blob/sta
>> ble/ocata/puppet/services/metrics/collectd.yaml#L130..L134
>> [2] https://bugzilla.redhat.com/show_bug.cgi?id=1455065
>>
>>
>
> __
> OpenStack Development Mailing 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] [release] [telemetry] Ceilometer stable/pike branch outlook

[Sean McGinnis]

> > >>
> > >> Can someone on the release team clarify this for us?
> > >
> > > That's correct the bit you're missing is cycle-with-intermediary
> doesn't
> > > have pre-releases (b{1,2,3},rc{1,2}) so when the ceilometer team feels
> > > they have the code in shape for a release they'll tag that release and
> > > cut a stable/pike branch at the tag point.
> >

> 
> that email explicitly says: "Deliverables following the
> cycle-with-intermediary model should also create their Pike release branch
> next week. That means potentially making a last Pike release, and in all
> cases posting the stable/pike branch creation request"
> 
> And that wasn't done for ceilometer. So it needs to be done, right?
> 

Yes, I just double checked, and there has not been a pike release yet for
ceilometer. That does need to be done soon.

Sean

__
OpenStack Development Mailing 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] [telemetry] Ceilometer stable/pike branch outlook

[William M Edmonds]

Thierry Carrez  wrote on 08/17/2017 03:35:20 AM:
> From: Thierry Carrez 
> To: openstack-dev@lists.openstack.org
> Date: 08/17/2017 03:37 AM
> Subject: Re: [openstack-dev] [release] [telemetry] Ceilometer
> stable/pike branch outlook
>
> Tony Breeds wrote:
> > On Wed, Aug 16, 2017 at 02:37:50PM -0400, William M Edmonds wrote:
> >>
> >> Julien Danjou  wrote on 08/16/2017 02:13:10 PM:
> >>> AFAIU it's impossible to cut a branch for our projects and release a
rc1
> >>> because of the release model we use. The release team does not allow
us
> >>> to do that. We need to release directly a stable version and cut a
> >>> branch.
> >>>
> >>> I guess we'll do that in a couple of week, at release time.
> >>
> >> That doesn't fit my understanding of cycle-with-intermediary, which is
the
> >> the ceilometer release model per [0]. As I read the release model
> >> definitions [1], cycle-with-intermediary means that you can have
> >> intermediate releases *as well*, but you still have to have a
cycle-ending
> >> release in line with the projects using the cycle-with-milestones
model.
> >>
> >> Can someone on the release team clarify this for us?
> >
> > That's correct the bit you're missing is cycle-with-intermediary
doesn't
> > have pre-releases (b{1,2,3},rc{1,2}) so when the ceilometer team feels
> > they have the code in shape for a release they'll tag that release and
> > cut a stable/pike branch at the tag point.
>
> Exactly. As explained a couple weeks ago in the release countdown email
[1]:
>

that email explicitly says: "Deliverables following the
cycle-with-intermediary model should also create their Pike release branch
next week. That means potentially making a last Pike release, and in all
cases posting the stable/pike branch creation request"

And that wasn't done for ceilometer. So it needs to be done, right?

> > Deliverables following the cycle-with-intermediary model should also
> > create their Pike release branch next week. That means potentially
> > making a last Pike release, and in all cases posting the stable/pike
> > branch creation request:
> >
> > ...
> > branches:
> >   - location: YOUR.PIKE.VERSION
> > name: stable/pike
>
> [1]
>
http://lists.openstack.org/pipermail/openstack-dev/2017-August/120574.html
>
> --
> Thierry Carrez (ttx)
>
> [attachment "signature.asc" deleted by William M Edmonds/Raleigh/
> IBM]
>
__
> OpenStack Development Mailing 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] [barbican] [security] custodia @ PTG

[Raildo Mascena de Sousa Filho]

Sure, I'll be there, see you guys on Thursday.

On Thu, Aug 17, 2017 at 1:53 PM Luke Hinds  wrote:

> Hi Raildo,
>
> That's great news. Are you around next Thursday to jump on
> #openstack-meeting-alt at 17:00 UTC? we can then go over some topics.
>
> @Dave, unless you prefer to use the Barbican meeting that is (possible
> synergies to barbican)?
>
> Regards,
>
> Luke
>
> On Thu, Aug 17, 2017 at 1:10 PM, Raildo Mascena de Sousa Filho <
> rmasc...@redhat.com> wrote:
>
>> Hi Luke,
>>
>> I'll definitely be there, sounds like a great idea, so we can clarify a
>> lot of topics and make progress in the community together.
>>
>> Cheers,
>>
>>
>> On Thu, Aug 17, 2017 at 5:52 AM Luke Hinds  wrote:
>>
>>> Hi Raildo,
>>>
>>> Both Barbican and Security have an interest in custodia and we have it
>>> marked down as a topic / discussion point for the PTG [1]
>>>
>>> Would you be interested / willing to join the Barbican room on Thurs /
>>> Fri and propose a walk through / overview etc?
>>>
>>> [1] https://etherpad.openstack.org/p/barbican-ptg-queens
>>>
>>>
>>> Regards,
>>>
>>> Luke
>>>
>> --
>>
>> Raildo mascena
>>
>> Software Engineer, Identity Managment
>>
>> Red Hat
>>
>> 
>> 
>> TRIED. TESTED. TRUSTED. 
>>
>
>
>
> --
> Luke Hinds | NFV Partner Engineering | Office of Technology | Red Hat
> e: lhi...@redhat.com | irc: lhinds @freenode | m: +44 77 45 63 98 84 | t: +44
> 12 52 36 2483
>
-- 

Raildo mascena

Software Engineer, Identity Managment

Red Hat



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

Re: [openstack-dev] [tripleo] Adding new roles after upgrade is broken.

[Jiří Stránský]

On 18.8.2017 13:18, Sofer Athlan-Guyot wrote:

Hi,

We may have missing packages when the user is adding a new role to its
roles_data file and the base image is coming from previous version.

The workflow would be this one:
  - install newton
  - upgrade to ocata
  - add collectd to roles_data and redeploy the stack

For instance if one is adding
OS::TripleO::Services::Collectdservices::collectd in an ocata env coming
from an upgraded newton env, he/she won't have the necessary packages
(for instance collectd-disk).  The puppet manifest will fail has the
package is missing and puppet doesn't install package.  The upgrade
task[1] is useless as the new role wasn't added during the upgrade but
after.


Right, but the package could be added during the upgrade. The 
upgrade_tasks could/should make the set of installed overcloud RPMs on 
par with the overcloud-full image of the respective release, ideally. So 
you'd have collectd RPMs installed always, both on freshly deployed and 
upgraded envs, regardless if you actually use collectd or not. We 
already did some package installs/uninstalls as part of upgrades and 
updates, but probably didn't have 100% coverage.




I don't see any easy way to solve this.  Basically we need a way to keep
in sync base image between release without using the upgrade_tasks,
maybe in the tripleo-package one ?


Given that released code is affected, we may treat it as a bug that 
requires a minor update, and in addition to upgrade_tasks, we can add 
all the necessary package installs into minor update code 
(yum_update.sh) too. Again this shouldn't depend on what services are 
actually enabled, just unconditionally sync with latest content of 
overcloud-full image of the respective release.


I guess the time consuming part will be preparing the envs that will 
allow comparing a fresh deploy vs. an upgraded one to get the `rpm -qa | 
sort` difference. Or we could try a shortcut and see what changes went 
into tripleo-puppet-elements in each release.




This shouldn't be a problem with container, but everything before pike
is affected.


Indeed. There will still be some basic baremetal host content management 
as long as we're not using Atomic, but the room for potential problems 
will be much smaller.


Jirka



Originially seen there[2]

[1] 
https://github.com/openstack/tripleo-heat-templates/blob/stable/ocata/puppet/services/metrics/collectd.yaml#L130..L134
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1455065




__
OpenStack Development Mailing 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] Technical Committee Status update, August 18th

[Thierry Carrez]

Flavio Percoco wrote:
> On 18/08/17 11:17 +0200, Thierry Carrez wrote:
>> == Need for a TC meeting next Tuesday ==
>>
>> I'll be off next week (therefore skipping this update next Friday). I
>> don't think we have anything thoroughly blocked at this point requiring
>> a meeting. However if something comes up and requires a meeting next
>> week while I'm off, please feel free to self-organize :)
> 
> I'd happy to send the Friday update email until you're back.

Awesome! Feel free to update the wiki page in parallel:
https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee

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

[openstack-dev] [ptg] Room schedule posted for Denver PTG

[Thierry Carrez]

Hi everyone,

The list of available rooms for the Project Teams Gathering in Denver is
now finalized, with thematic inter-project rooms on Monday/Tuesday and
team-specific meetings on Wednesday/Thursday/Friday. You can find the
list (and explanation of what will be covered in each) on the event
website at:

https://www.openstack.org/ptg#tab_schedule

Each of those rooms will self-organize what's being discussed, and
expose what's currently being discussed (and what's coming up next) to a
common schedule page (driven by the ptgbot on the #openstack-ptg
channel). Most room leads have started an etherpad to gather input. You
can find them all and add your own topics to discuss at:

https://wiki.openstack.org/wiki/PTG/Queens/Etherpads

At this point it is still possible to register to join the event at
https://www.openstack.org/ptg . The discounted rooms block at the event
hotel is now sold out, but Erin outlined options in hotels close to the
event venue that you can consider:

http://lists.openstack.org/pipermail/openstack-dev/2017-August/121192.html

I hope to see you there !

-- 
Thierry Carrez (ttx)

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

[openstack-dev] [nova] placement/resource providers update 32

[Chris Dent]

Placement Update 32

# Meta

To avoid noise that nobody seems to care about, I've taken the liberty
of not making reference here to reviews that have received no
attention for more than a month. As we all have understandably limited
attention, that seems to be the best. I do keep track of new bugs and
new fixes, so this shouldn't lead to too much stuff getting lost in the
wilderness.

# What Matters Most

rc2 is in progress. There continue to be bugs found here and there,
mostly with handling of allocations in corner cases. A new one is with
forced live migration, found just this morning. A bug is coming, but
in the meantime there's code that demonstrates it:

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

So at this point important things to be doing are the same as last
week:

* watching for new bugs tagged placement, scheduler or resource-tracker
* inspecting the logs of tempest runs (even those that have passed)
   for unexpected log messages related to managing inventory or
   allocations
* using the code, especially to do things like resize, migrate,
   evacuate, etc
* reviewing code

Plus preparing for the PTG. See the link to the etherpad in help
wanted below.

# What's Changed

This week has been finding and fixing bugs. Bugs have been found and
fixed.

The api-ref is published!
https://developer.openstack.org/api-ref/placement/

# Help Wanted

See the beginning of this message.

Also, there's a swathe of placement related stuff on the PTG planning
etherpad. Please add to that or make some adjustments if you think
something is missing or incomplete:

https://etherpad.openstack.org/p/nova-ptg-queens

An important aspect of this is determining what kind of dependency
tree is involved with the work.

# Main Themes

## Custom Resource Classes for Ironic

It took a lot of fiddling but ironic's handling of custom resource
classes is now merged, with some caveats that had to be mentioned in
the reno.

   
https://docs.openstack.org/releasenotes/nova/unreleased.html#deprecation-notes

## Traits

Work continues apace on getting filtering by traits working:

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

This has some overlap with shared provider handling (below).

## Shared Resource Providers

There's some support for shared resource providers on the placement
side of the scheduling equation, but the resource tracker is not yet
ready to support it. There is some work in progress, starting with
functional tests:

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

## Nested Resource Providers

This will start back up after we clean off the windscreen. The stack
begins at https://review.openstack.org/#/c/470575/5

## Docs

Henceforth if you add a new URL+method combination to placement (by
adding to ROUTE_DECLARATIONS) the docs job will fail unless you add
documentation. You _must_ document the new functionality to continue.

# Other Code

Some of the stuff below is bug fixes, created in pike, that never got
much attention, so potentially will not make it into pike now that
we're effectively in queens. It would be great if we could clear these
off the board before we get started on other major stuff, so they
aren't lingering, unloved and lonely in the corner.

* Reset client when placement endpoint not found
  https://review.openstack.org/#/c/493536/
  (This may be a backport candidate)

* Update allocation spec for alternates
  https://review.openstack.org/#/c/471927/

* functional tests for live migrate
  https://review.openstack.org/#/c/493865/

* Allow shuffling of best weighted hosts
  https://review.openstack.org/#/c/494136/

* tests for resource allocation during soft delete
  https://review.openstack.org/#/c/495159/

* WIP: resize with custom resource
  https://review.openstack.org/#/c/490461/

* replace chance with filter scheduler in func tests
  https://review.openstack.org/#/c/491529/

* https://review.openstack.org/#/c/427200/
  Add a status check for legacy filters in nova-status.

* https://review.openstack.org/#/c/469048/
  Provide more information about installing placement

* https://review.openstack.org/#/c/468928/
  Disambiguate resource provider conflict message

* https://review.openstack.org/#/c/485209/
  gabbi tests for shared custom resource class

* https://review.openstack.org/#/c/489633/
  Update RT aggregates less often

* https://review.openstack.org/#/c/492247/
  Use ksa adapter for placement in the new way

* https://review.openstack.org/#/c/483506/
  Call _update fewer times in the resource tracker
  I'm relatively certain we can't do this one because of the way the
  code is structured.

* https://review.openstack.org/#/c/468797/
  Spec for requesting traits in flavors

--
Chris Dent  (⊙＿⊙') https://anticdent.org/
freenode: cdent tw: @anticdent__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 

Re: [openstack-dev] [kolla] [tripleo] [openstack-ansible] [deployment] Collaboration at PTG

[Flavio Percoco]

On 17/08/17 10:24 -0500, Major Hayden wrote:

On 08/17/2017 09:30 AM, Emilien Macchi wrote:

If you're working on Kolla / OpenStack-Ansible - please let us know if
you have specific constraints on the schedule, so we can maybe block a
timeslot in the agenda from now.
We'll have a "Packaging" room which is reserved for all topics related
to OpenStack deployments, so we can use this one.


I don't have any constraints (that I'm aware of), but I'd be interested in 
participating!  Performance in the gate jobs has been one of my tasks lately 
and I'd like to see if we can collaborate there to make improvements without 
ruining infra's day. ;)

As long as you can put up with a few Dad jokes, I'll be there.


++ I'm interested in this topic too!
Flavio

--
@flaper87
Flavio Percoco


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

[openstack-dev] [tripleo] Adding new roles after upgrade is broken.

[Sofer Athlan-Guyot]

Hi,

We may have missing packages when the user is adding a new role to its
roles_data file and the base image is coming from previous version.

The workflow would be this one:
 - install newton
 - upgrade to ocata
 - add collectd to roles_data and redeploy the stack

For instance if one is adding
OS::TripleO::Services::Collectdservices::collectd in an ocata env coming
from an upgraded newton env, he/she won't have the necessary packages
(for instance collectd-disk).  The puppet manifest will fail has the
package is missing and puppet doesn't install package.  The upgrade
task[1] is useless as the new role wasn't added during the upgrade but
after.

I don't see any easy way to solve this.  Basically we need a way to keep
in sync base image between release without using the upgrade_tasks,
maybe in the tripleo-package one ?

This shouldn't be a problem with container, but everything before pike
is affected.

Originially seen there[2]

[1] 
https://github.com/openstack/tripleo-heat-templates/blob/stable/ocata/puppet/services/metrics/collectd.yaml#L130..L134
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1455065

-- 
Sofer Athlan-Guyot.

__
OpenStack Development Mailing 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] Technical Committee Status update, August 18th

[Flavio Percoco]

On 18/08/17 11:17 +0200, Thierry Carrez wrote:

== Need for a TC meeting next Tuesday ==

I'll be off next week (therefore skipping this update next Friday). I
don't think we have anything thoroughly blocked at this point requiring
a meeting. However if something comes up and requires a meeting next
week while I'm off, please feel free to self-organize :)


I'd happy to send the Friday update email until you're back.
Flavio

--
@flaper87
Flavio Percoco


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

[openstack-dev] [tc] Technical Committee Status update, August 18th

[Thierry Carrez]

Hi!

This is the weekly update on Technical Committee initiatives. You can
find the full list of all open topics at:

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


== Recently-approved changes ==

* Resolution to "Describe what upstream support means" [1][2]
* Add stable:follows-policy tag for Kolla and oslo.messaging
* Pike goals updates: zun
* Queens goals updates: murano
* New repositories: monasca-events-api, watcher-tempest-plugin

[1] https://review.openstack.org/#/c/440601/
[2] https://review.openstack.org/#/c/486964/

John Garbutt's resolution on clarifying what "upstream support" means
was finally approved this week. You can read it at:

https://governance.openstack.org/tc/resolutions/20170620-volunteer-support.html


== PTG prep ==

We'll have a TC / StewardshipWG room on Monday-Tuesday at the PTG. You
can chime in on topics we should cover there on the planning etherpad:

https://etherpad.openstack.org/p/queens-PTG-TC-SWG


== Election results ==

We'll have to update the projects.yaml file to reflect the newly-elected
PTLs, and are expecting a proposed change from the election officials.

For leaderless teams, the TC is proposing to appoint Kota TSUYUZAKI as
Storlets PTL for Queens:

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

Packaging-Deb being in the middle of a transition to Debian project
infrastructure, we won't be appointing a PTL for Queens, where that team
will be retired.


== New project teams ==

As we open Queens cycle development, it's time to reconsider our current
backlog of project additions:

* Stackube: https://review.openstack.org/462460
The project was set up on OpenStack infrastructure, so it's time to
review the proposal again.

* Glare: https://review.openstack.org/479285
* Blazar: https://review.openstack.org/482860
* Gluon: https://review.openstack.org/463069
Also ready for review, those teams will be at the PTG and available to
spend some time in the TC room on Monday-Tuesday


== Open discussions ==

Monty submitted a new proposal to be explicit about supported database
versions. Please review at:

https://review.openstack.org/493932

It looks more and more like John's resolution on how decisions should be
globally inclusive should be morphed into project-team-guide material.
Please review it if you haven't yet, and bring your input before we work
on project team guide editions:

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


== Voting in progress ==

Emmet's rewording of the leaderless project resolution reached majority
yesterday and will be approved early next week unless new objections are
brought:

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

Flavio's resolutions on dropping Technical Committee meetings[3] and
allowing teams to use their channel for meetings[4] are both ready for
your voting consideration:

[3] https://review.openstack.org/459848
[4] https://review.openstack.org/485117


== Need for a TC meeting next Tuesday ==

I'll be off next week (therefore skipping this update next Friday). I
don't think we have anything thoroughly blocked at this point requiring
a meeting. However if something comes up and requires a meeting next
week while I'm off, please feel free to self-organize :)

Cheers,

-- 
Thierry Carrez (ttx)

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

[openstack-dev] [docs][ptg] Doc team attendance

[Alexandra Settle]

Hi everyone,

I’ve updated the docs PTG etherpad with a few details: 
https://etherpad.openstack.org/p/denver-doc-PTG

All those attending, could you please put your names/availability on the 
etherpad.

Also – to those interested who cannot attend on the Mon-Tues for Queens 
planning sessions, please note that I have booked Wednesday morning in Colorado 
Ballroom C for migration-specific discussions. See: 
https://ethercalc.openstack.org/Queens-PTG-Discussion-Rooms

If you wish to attend *these* sessions, please put your name in the Wednesday 
slot in the etherpad.

Cheers,

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

[openstack-dev] [release] Release countdown for week R-1, August 18-25

[Thierry Carrez]

Welcome to our regular release countdown email!

Development Focus
-

We are entering the last week before release week. Focus should be on
producing the last Pike release candidates and intermediary releases,
including updated translations and requirements updates.

If your team attends the PTG in Denver, you should also be actively
preparing the topics for discussion at the event.


Actions
--

For *cycle-with-intermediary* deliverables, the Pike release will be the
last-released version. If you need to release a newer version, you need
to do it before August 24. After that date we can't guarantee inclusion
in the Pike release, and will fall back to the last-released version.

The following deliverables still did not have /any/ release during the
Pike cycle and urgently need to make one (and ask for the stable/pike
branch to be cut from it). If we don't have anything by the deadline,
the release team will have to either force a release, or remove the
deliverable from Pike:

- ceilometer, panko
- magnum, magnum-ui
- senlin-dashboard
- tacker

As a reminder, asking for a release and corresponding stable/pike branch
is done by modifying the deliverable Pike release file in the
openstack/releases repository and adding:
...
  - projects:
  - hash: YOURHASH
repo: openstack/YOURPROJECT
version: YOUR.NEW.VERSION
branches:
  - location: YOUR.NEW.VERSION
name: stable/pike

The following deliverables do have an intermediary release in Pike but
still haven't asked for a stable/pike branch to be cut. If we don't have
a stable/pike branch by the deadline, the release team will branch from
the last-available intermediary release:

- aodh
- instack-undercloud
- kuryr-kubernetes
- manila-ui
- neutron-fwaas-dashboard
- swift
- tacker-horizon

As a reminder, asking for the stable/pike branch to be cut from an
already-released Pike version is done by modifying the deliverable Pike
release file in the openstack/releases repository and adding:

...
branches:
  - location: YOUR.LAST.PIKEVERSION
name: stable/pike

For *cycle-with-milestones* deliverables, early next week you should
make sure to merge the latest translations patches[1] and latest
requirements patches[2], and ask for a last release candidate before the
Pike release. As a reminder, asking for a new RC is done by modifying
the deliverable Pike release file in the openstack/releases repository
and adding:

...
  - projects:
  - hash: YOURHASH
repo: openstack/YOURPROJECT
version: YOURVERSION.0.0.0rc2

[1]
https://review.openstack.org/#/q/status:open+branch:stable/pike+topic:zanata/translations

[2]
https://review.openstack.org/#/q/status:open+branch:stable/pike+topic:openstack/requirements


Upcoming Deadlines & Dates
--

Deadline for last release candidates / intermediary releases: August 24
Final Pike release: August 30
Queens PTG in Denver: Sept 11-15

As usual come find us on #openstack-release IRC channel if you have any
questions or concerns.

-- 
Thierry Carrez (ttx)

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

[openstack-dev] [octavia] octavia 1.0.0.0rc2 (pike)

[no-reply]

Hello everyone,

A new release candidate for octavia for the end of the Pike
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/octavia/

Unless release-critical issues are found that warrant a release
candidate respin, this candidate will be formally released as the
final Pike release. You are therefore strongly
encouraged to test and validate this tarball!

Alternatively, you can directly test the stable/pike release
branch at:

http://git.openstack.org/cgit/openstack/octavia/log/?h=stable/pike

Release notes for octavia can be found at:

http://docs.openstack.org/releasenotes/octavia/




__
OpenStack Development Mailing 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] keystone 12.0.0.0rc2 (pike)

[no-reply]

Hello everyone,

A new release candidate for keystone for the end of the Pike
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/keystone/

Unless release-critical issues are found that warrant a release
candidate respin, this candidate will be formally released as the
final Pike release. You are therefore strongly
encouraged to test and validate this tarball!

Alternatively, you can directly test the stable/pike release
branch at:

http://git.openstack.org/cgit/openstack/keystone/log/?h=stable/pike

Release notes for keystone can be found at:

http://docs.openstack.org/releasenotes/keystone/




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