Re: [openstack-dev] [ python-novaclient][ python-glanceclient][ python-cinderclient][ python-neutronclient] Remove x-openstack-request-id logging code as it is logged twice

[Steve Martinelli]

On Fri, Jan 20, 2017 at 10:53 PM, Kekane, Abhishek <
abhishek.kek...@nttdata.com> wrote:

> Hi Dims,
>
> Thank you for reply. I will propose a patch soon. Just for curiosity,
> keystoneauth1 >= 2.17.0 will not install 2.18.0?
>

It will, but if we make 2.18.0 the minimum then it will for sure install
only that level.

> In the latest keystoneauth1 version 2.18.0, x-openstack-request-id is
> logged
> > for every HTTP response. This keystoneauth1 version will be used for
> ocata.
> >
> > The same request id is also logged in 'request' method of SessionClient
> > class for python-novaclient, python-glanceclient, python-cinderclient and
> > python-neutronclient. Once requirements.txt is synced with
> > global-requirements and it uses keystoneauth1 version 2.18.0 and above,
> > x-openstack-request-id will be logged twice for these clients.
>

So I approved this change (sorry it took so long to review and merge), but
I didn't realize it was going to impact python-{nova | glance | cinder |
neutron}client. I think it's slightly unrealistic to ask four teams to
remove the logging in the last week we release clients (I'm assuming we
want to remove the functionality and not log things twice).

 - Would folks prefer I revert the keystoneauth change and re-release
without it, and we can bring it back in Pike?
- Do teams have the bandwidth to remove the request id logging in the next
few days?

Sorry for the confusion this caused.
__
OpenStack Development Mailing 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] Announcing my candidacy for PTL of the Pike cycle

[gongys2017]

Hi All,
Sridhar Ramaswamy and our team have done great work during last several cycles.
Many thanks to the team and Sridhar Ramaswamy.

With this email, I'm announcing my PTL candidacy of the Tacker team for the
Pike release cycle.

First let me briefly introduce myself. I joined the OpenStack community
development in 2012, then became the core member of Neutron team and served
the project for a few cycles. Currently, I'm contributing to Tacker project
as a core member.

Following are my contribution activities:
* Review:  http://stackalytics.com/?release=all=marks_id=gongysh
* Commit:  http://stackalytics.com/?release=all=commits_id=gongysh

As a major leader of 99cloud (active Gold Member of OpenStack Foundation)
I have led 99cloud teams actively participating the upstream activities.
In addition, I introduced Tacker projects to many Chinese companies and
motivated some contributors to join Tacker and related projects.

Here are some ideas I propose the team to focus on in new cycles:
* Documentation - Tacker teams have done fairly well in this area. We should
continue this effort. Nice documentation for new users, especially developers,
will definitely help the project develop.

* Robust architecture – Tacker needs some refactoring in order to be used for
a more robust environment. For example, monitoring feature, VIM feature etc.
We can split some features into components and make them distributed. New API
framework is also one part of this architecture.

* Testing - Tacker originally derived from Neutron, the original testing
framework needs reorganization to fit the Tacker codes. After that, we need to
drive stronger principles to demand better unit and functional test coverage.

* New features - In order for Tacker to become a leading community-built
TOSCA-based Orchestrator service (Inherited from Sridhar, thanks!) in OpenStack,
Tacker need introduce more features, such as TOSCA UI tools, workflows etc.
Of course, the VNF(D), NS(D), VNFFG(D) in MANO via Tacker TOSCA Orchestrator
service will get matured in new cycles.

* Getting more stackers to join - To finish the tons of tasks, we need tons of
contributors. To involve and motivate stackers into Tacker team will be one of
my major tasks.

SDN and NFV is getting hotter and the deployments are accelerating. I would
like to make sure Tacker is getting ready to catch the rising big wave.

Many Thanks to Sridhar and all the dear developers again.

Thank you for your kind consideration of my candidacy.__
OpenStack Development Mailing 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] [ python-novaclient][ python-glanceclient][ python-cinderclient][ python-neutronclient] Remove x-openstack-request-id logging code as it is logged twice

[Kekane, Abhishek]

Hi Dims,

Thank you for reply. I will propose a patch soon. Just for curiosity, 
keystoneauth1 >= 2.17.0 will not install 2.18.0?

Abhishek

From: Davanum Srinivas 
Sent: Saturday, January 21, 2017 8:27:56 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [ python-novaclient][ python-glanceclient][ 
python-cinderclient][ python-neutronclient] Remove x-openstack-request-id 
logging code as it is logged twice

Abhishek,

1) requirements.txt for all 4 python-*client you mentioned have
"keystoneauth1>=2.17.0",
2) i do not see a review request to bump the minimum version in global
requirements for keystoneauth1 to "keystoneauth1>=2.18.0"
(https://review.openstack.org/#/q/project:openstack/requirements+is:open)

Can you please file one?

Thanks,
Dims


On Fri, Jan 20, 2017 at 12:52 AM, Kekane, Abhishek
 wrote:
> Hi Devs,
>
>
>
> In the latest keystoneauth1 version 2.18.0, x-openstack-request-id is logged
> for every HTTP response. This keystoneauth1 version will be used for ocata.
>
> The same request id is also logged in 'request' method of SessionClient
> class for python-novaclient, python-glanceclient, python-cinderclient and
> python-neutronclient. Once requirements.txt is synced with
> global-requirements and it uses keystoneauth1 version 2.18.0 and above,
> x-openstack-request-id will be logged twice for these clients.
>
>
>
> I have submitted patches for python-novaclient [1] and python-glanceclient
> [2] and created patches for python-cinderclient and python-neutronclient but
> same will not be reviewed unless and until the requirements.txt is synced
> with global-requirements and it uses keystoneauth1 version 2.18.0.
>
>
>
> As final releases for client libraries are scheduled in the next week
> (between Jan 23 - Jan 27) we want to address these issues in the above
> mentioned clients.
>
>
>
> Please let us know your opinion about the same.
>
>
>
> [1] https://review.openstack.org/422602
>
> [2] https://review.openstack.org/422591
>
>
> __
> Disclaimer: This email and any attachments are sent in strictest confidence
> for the sole use of the addressee and may contain legally privileged,
> confidential, and proprietary data. If you are not the intended recipient,
> please advise the sender by replying promptly to this email and then delete
> and destroy this email and any attachments without any further use, copying
> or forwarding.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



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

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

__
Disclaimer: This email and any attachments are sent in strictest confidence
for the sole use of the addressee and may contain legally privileged,
confidential, and proprietary data. If you are not the intended recipient,
please advise the sender by replying promptly to this email and then delete
and destroy this email and any attachments without any further use, copying
or forwarding.__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [congress] ocata client causes feature regression with pre-ocata server

[Eric K]

Hi all,

I was getting ready to request release of congress client, but I
remembered that the new client causes feature regression if used with
older versions of congress. Specifically, new client with pre-Ocata
congress cannot refer to datasource by name, something that could be done
with pre-Ocata client.

Here¹s the patch of interest: https://review.openstack.org/#/c/407329/


A few questions:

Are we okay with the regression? Seems like it could cause a fair bit of
annoyance for users.
   1. If we¹re okay with that, what¹s the best way to document that
pre-Ocata congress should be used with pre-Ocata client?
   2. If not, how we avoid the regression? Here are some candidates I can
think of.   
  a. Client detects congress version and act accordingly. I don¹t
think this is possible, nor desirable for client to be concerned with
congress version not just API version.
  b. Release backward compatible API version 1.1 that supports
getting datasource by name_or_id. Then client will take different paths
depending on API version.
  c. If datasource not found, client falls back on old method of
retrieving list of datasources to resolve name into UUID. This would work,
but causes extra API & DB call in many cases.
  d. Patch old versions of Congress to support getting datasource
by name_or_id. Essentially, it was always a bug that the API didn¹t
support name_or_id.

Thanks!



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

Re: [openstack-dev] [ python-novaclient][ python-glanceclient][ python-cinderclient][ python-neutronclient] Remove x-openstack-request-id logging code as it is logged twice

[Davanum Srinivas]

Abhishek,

1) requirements.txt for all 4 python-*client you mentioned have
"keystoneauth1>=2.17.0",
2) i do not see a review request to bump the minimum version in global
requirements for keystoneauth1 to "keystoneauth1>=2.18.0"
(https://review.openstack.org/#/q/project:openstack/requirements+is:open)

Can you please file one?

Thanks,
Dims


On Fri, Jan 20, 2017 at 12:52 AM, Kekane, Abhishek
 wrote:
> Hi Devs,
>
>
>
> In the latest keystoneauth1 version 2.18.0, x-openstack-request-id is logged
> for every HTTP response. This keystoneauth1 version will be used for ocata.
>
> The same request id is also logged in 'request' method of SessionClient
> class for python-novaclient, python-glanceclient, python-cinderclient and
> python-neutronclient. Once requirements.txt is synced with
> global-requirements and it uses keystoneauth1 version 2.18.0 and above,
> x-openstack-request-id will be logged twice for these clients.
>
>
>
> I have submitted patches for python-novaclient [1] and python-glanceclient
> [2] and created patches for python-cinderclient and python-neutronclient but
> same will not be reviewed unless and until the requirements.txt is synced
> with global-requirements and it uses keystoneauth1 version 2.18.0.
>
>
>
> As final releases for client libraries are scheduled in the next week
> (between Jan 23 - Jan 27) we want to address these issues in the above
> mentioned clients.
>
>
>
> Please let us know your opinion about the same.
>
>
>
> [1] https://review.openstack.org/422602
>
> [2] https://review.openstack.org/422591
>
>
> __
> Disclaimer: This email and any attachments are sent in strictest confidence
> for the sole use of the addressee and may contain legally privileged,
> confidential, and proprietary data. If you are not the intended recipient,
> please advise the sender by replying promptly to this email and then delete
> and destroy this email and any attachments without any further use, copying
> or forwarding.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



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

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

Re: [openstack-dev] [kolla-ansible] [kolla] Am I doing this wrong?

[Kris G. Lindgren]

Adding [kolla] tag.


___
Kris Lindgren
Senior Linux Systems Engineer
GoDaddy

From: "Kris G. Lindgren" 
Date: Friday, January 20, 2017 at 4:54 PM
To: "openstack-dev@lists.openstack.org" 
Cc: "openstack-operat...@lists.openstack.org" 

Subject: Re: [kolla-ansible] Am I doing this wrong?

Poke.  Bueller?


___
Kris Lindgren
Senior Linux Systems Engineer
GoDaddy

From: "Kris G. Lindgren" 
Date: Tuesday, January 10, 2017 at 5:34 PM
To: "openstack-dev@lists.openstack.org" 
Subject: [kolla-ansible] Am I doing this wrong?

Hello Kolla/Kolla-ansible peoples.

I have been trying to take kolla/kolla-ansible and use it to start moving our 
existing openstack deployment into containers.  At the same time also trying to 
fix some of the problems that we created with our previous deployment work 
(everything was in puppet).  Where we had puppet doing *everything* which 
eventually created a system that effectively performed actions at a distance.  
As we were never really 100% what puppet was going to do when we ran it.  Even 
with NOOP mode enabled.  So taking an example of building and deploying glance 
via kolla-ansible. I am running into some problems/concerns and wanted to reach 
out to make sure that I am not missing something.

Things that I am noticing:
 * I need to define a number of servers in my inventory outside of the specific 
servers that I want to perform actions against.  I need to define groups 
baremetal, rabbitmq, memcached, and control (IN addition to the glance specific 
groups) most of these seem to be gathering information for config? (Baremetal 
was needed soley to try to run the bootstrap play).  Running a change 
specifically against "glance" causes fact gathering on a number of other 
servers not specifically where glance is running?  My concern here is that I 
want to be able to run kola-ansible against a specific service and know that 
only those servers are being logged into.

* I want to run a dry-run only, being able to see what will happen before it 
happens, not during; during makes it really hard to see what will happen until 
it happens. Also supporting  `ansible --diff` would really help in 
understanding what will be changed (before it happens).  Ideally, this wouldn’t 
be 100% needed.  But the ability to figure out what a run would *ACTUALLY* do 
on a box is what I was hoping to see.

* Database task are ran on every deploy and status of change DB permissions 
always reports as changed? Even when nothing happens, which makes you wonder 
"what changed"?  Seems like this is because the task either reports a 0 or a 1, 
where it seems like there is 3 states, did nothing, updated something, failed 
to do what was required.  Also, Can someone tell me why the DB stuff is done on 
a deployment task?  Seems like the db checks/migration work should only be done 
on a upgrade or a bootstrap?

* Database services (that at least we have) our not managed by our team, so 
don't want kolla-ansible touching those (since it won't be able to). No way to 
mark the DB as "externally managed"?  IE we dont have permissions to create 
databases or add users.  But we got all other permissions on the databases that 
are created, so normal db-manage tooling works.

* Maintenance level operations; doesn't seem to be any built-in to say 'take a 
server out  of a production state, deploy to it, test it, put it back into 
production'  Seems like if kola-ansible is doing haproxy for API's, it should 
be managing this?  Or an extension point to allow us to run our own 
maintenance/testing scripts?

* Config must come from kolla-ansible and generated templates.  I know we have 
a patch up for externally managed service configuration.  But if we aren't 
suppose to use kolla-ansible for generating configs (see below), why cant we 
override this piece?

Hard to determine what kolla-ansible *should* be used for:

* Certain parts of it are 'reference only' (the config tasks), some are not 
recommended
  to be used at all (bootstrap?); what is the expected parts of kolla-ansible 
people are
  actually using (and not just as a reference point); if parts of kolla-ansible 
are just
  *reference only* then might as well be really upfront about it and tell 
people how to
  disable/replace those reference pieces?

* Seems like this will cause everyone who needs to make tweaks to fork or 
create an "overlay" to override playbooks/tasks with specific functions?

Other questions:

Is kolla-ansibles design philosophy that every deployment is an upgrade?  Or 
every deployment should include all the base level boostrap tests?

Because it seems to me that you have a required set of tasks that should only 
be done once (boot strap).  Another set of 

[openstack-dev] [tricircle]Pike design topics discussion

[joehuang]

Hello,

As what's discussed during the weekly meeting, let's discuss what's to do in 
Pike in etherpad next Tuesday morning UTC 1:30 am (9:30am Beijing time, 10:30 
Korea/Japan time, Monday 5:30pm PST time)

The etherpad link https://etherpad.openstack.org/p/tricircle-pike-design-topics

Please input your concerns on what to do in Pike into the etherpad, and let's 
discuss that time, the duration is around 1.5 hour.

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] [kolla-ansible] Am I doing this wrong?

[Kris G. Lindgren]

Poke.  Bueller?


___
Kris Lindgren
Senior Linux Systems Engineer
GoDaddy

From: "Kris G. Lindgren" 
Date: Tuesday, January 10, 2017 at 5:34 PM
To: "openstack-dev@lists.openstack.org" 
Subject: [kolla-ansible] Am I doing this wrong?

Hello Kolla/Kolla-ansible peoples.

I have been trying to take kolla/kolla-ansible and use it to start moving our 
existing openstack deployment into containers.  At the same time also trying to 
fix some of the problems that we created with our previous deployment work 
(everything was in puppet).  Where we had puppet doing *everything* which 
eventually created a system that effectively performed actions at a distance.  
As we were never really 100% what puppet was going to do when we ran it.  Even 
with NOOP mode enabled.  So taking an example of building and deploying glance 
via kolla-ansible. I am running into some problems/concerns and wanted to reach 
out to make sure that I am not missing something.

Things that I am noticing:
 * I need to define a number of servers in my inventory outside of the specific 
servers that I want to perform actions against.  I need to define groups 
baremetal, rabbitmq, memcached, and control (IN addition to the glance specific 
groups) most of these seem to be gathering information for config? (Baremetal 
was needed soley to try to run the bootstrap play).  Running a change 
specifically against "glance" causes fact gathering on a number of other 
servers not specifically where glance is running?  My concern here is that I 
want to be able to run kola-ansible against a specific service and know that 
only those servers are being logged into.

* I want to run a dry-run only, being able to see what will happen before it 
happens, not during; during makes it really hard to see what will happen until 
it happens. Also supporting  `ansible --diff` would really help in 
understanding what will be changed (before it happens).  Ideally, this wouldn’t 
be 100% needed.  But the ability to figure out what a run would *ACTUALLY* do 
on a box is what I was hoping to see.

* Database task are ran on every deploy and status of change DB permissions 
always reports as changed? Even when nothing happens, which makes you wonder 
"what changed"?  Seems like this is because the task either reports a 0 or a 1, 
where it seems like there is 3 states, did nothing, updated something, failed 
to do what was required.  Also, Can someone tell me why the DB stuff is done on 
a deployment task?  Seems like the db checks/migration work should only be done 
on a upgrade or a bootstrap?

* Database services (that at least we have) our not managed by our team, so 
don't want kolla-ansible touching those (since it won't be able to). No way to 
mark the DB as "externally managed"?  IE we dont have permissions to create 
databases or add users.  But we got all other permissions on the databases that 
are created, so normal db-manage tooling works.

* Maintenance level operations; doesn't seem to be any built-in to say 'take a 
server out  of a production state, deploy to it, test it, put it back into 
production'  Seems like if kola-ansible is doing haproxy for API's, it should 
be managing this?  Or an extension point to allow us to run our own 
maintenance/testing scripts?

* Config must come from kolla-ansible and generated templates.  I know we have 
a patch up for externally managed service configuration.  But if we aren't 
suppose to use kolla-ansible for generating configs (see below), why cant we 
override this piece?

Hard to determine what kolla-ansible *should* be used for:

* Certain parts of it are 'reference only' (the config tasks), some are not 
recommended
  to be used at all (bootstrap?); what is the expected parts of kolla-ansible 
people are
  actually using (and not just as a reference point); if parts of kolla-ansible 
are just
  *reference only* then might as well be really upfront about it and tell 
people how to
  disable/replace those reference pieces?

* Seems like this will cause everyone who needs to make tweaks to fork or 
create an "overlay" to override playbooks/tasks with specific functions?

Other questions:

Is kolla-ansibles design philosophy that every deployment is an upgrade?  Or 
every deployment should include all the base level boostrap tests?

Because it seems to me that you have a required set of tasks that should only 
be done once (boot strap).  Another set of tasks that should be done for day to 
day care/feeding: service restarts, config changes, updates to code (new 
container deployments), package updates (new docker container deployment).  And 
a final set of tasks for upgrades where you will need to do things like db 
migrations and other special upgrade things.  It also seems like the day to day 
care and feeding tasks should be incredibly targeted/explicit. For example, 
deploying a new glance 

[openstack-dev] [puppet] CI status for Ubuntu

[Alex Schultz]

Just FYI,

We switched the Ubuntu scenario jobs to non-voting this week due to
the large amount of breakage caused by the ocata-proposed update to m2
based packages.  The Ubuntu beaker jobs are still voting on the
modules themselves.

Here's where we're keeping track of issues:

https://etherpad.openstack.org/p/puppet-ubuntu-ocata-m2

So if anyone wants to jump in and help that would be great.  We
addressed the libvirt, ceilometer and aodh issues. Still outstanding
as of now are items related to the webob 1.7, designate mdns failure
and python-gabbi missing for tempest.  There might be more issues, but
this is what we're aware of at the moment.

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

Re: [openstack-dev] [puppet] Nominating zhongshengping for core of the Puppet OpenStack modules

[Emilien Macchi]

plus one

On Fri, Jan 20, 2017 at 12:19 PM, Alex Schultz  wrote:
> Hey Puppet Cores,
>
> I would like to nominate Zhong Shengping as a Core reviewer for the
> Puppet OpenStack modules.  He is an excellent contributor to our
> modules over the last several cycles. His stats for the last 90 days
> can be viewed here[0].
>
> Please response with your +1 or any objections. If there are no
> objections by Jan 27 I will add him to the core list.
>
> Thanks,
> -Alex
>
> [0] http://stackalytics.com/report/contribution/puppet%20openstack-group/90
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
Emilien Macchi

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

[openstack-dev] [ironic][ptl] PTL Candidacy for Pike

[Jay Faulkner]

Hi all,

I am thrilled to nominate myself as a candidate for ironic PTL for Pike cycle.
Most of you should know me by now — I’m Jay Faulkner, aka “JayF” on freenode
IRC. I have been in the tech industry for 10 years, starting as a systems
administrator and working my way up the ladder. Since 2014, my primary focus
has been working on bare metal clouds, culminating in my position today as a
full-time ironic developer.

Many PTL nominees post an agenda with their nomination email — I won’t do that
here. The project has been run very well, as evidenced by us achieving almost
75% of our stated goals by the end of the last two cycles (newton and ocata).
If elected PTL, I would try to maintain the productive environment we've
built, and work as a facilitator, organizer, and servant, working towards the
goals the community will set for Pike.

My experience with ironic has been varied, starting with my work on Rackspace
OnMetal, the first public cloud offering including ironic, a short stint as
manager of that development team, and now as full-time upstream developer.
These perspectives have provided me with the communication skills and
technical context needed to be PTL. Ironic lives on the border between
software and hardware, which allows me to use my operational experience toward
designing new features. Some tangible examples of this include the introduction
of both cleaning and the initial agent deploy driver were introduced.
Furthermore, I learned how to empathize with businesses trying to integrate
with OpenStack during my tenure as a manager.

One of the reasons I wanted to run for PTL is to keep as many ironic
contributors doing what they do best: writing code. In my time on the project,
I've found I can contribute best by taking care of issues that can get in the
way of progress such as fixing gate breakages, working to help and mentor new
contributors, triaging bugs, and reviewing code. Another example of my
initiative on these types of issues is my work on cross-project items, such as
my work as documentation liason, and working on our CI jobs. By taking on these
items and more as PTL, I hope to act as a force multiplier for my
ironic colleagues.

Working full time on OpenStack Ironic, and open source in general, has been
one of the most rewarding times of my career. The community around ironic has
always been friendly, and I view my fellow contributors as co-workers and
friends. I cherish the time I’ve had collaborating with you all, and hope to
be given the opportunity to continue to work with everyone as PTL during Pike.
Thank you for your consideration.

Sincerely,
Jay Faulkner

__
OpenStack Development Mailing 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] Features ready for final +W (1/20)

[Matt Riedemann]

We've got two more single-patch reviews to complete a couple of 
blueprints that are ready for a 2nd core:


1. 
https://blueprints.launchpad.net/nova/+spec/libvirt-os-vif-fastpath-vhostuser


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

2. https://blueprints.launchpad.net/nova/+spec/soft-reboot-poweroff

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

--

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] [all] new os-api-ref warning, changes may be needed

[Jay Faulkner]

> On Jan 20, 2017, at 12:55 PM, Sean Dague  wrote:
> 
> On 01/20/2017 03:21 PM, Jay Faulkner wrote:
>> On Jan 20, 2017, at 9:41 AM, Sean Dague  wrote:
>>> 
>>> We released a new os-api-ref yesterday which includes a few
>>> enhancements, including the anchor links on the website working as
>>> expected now.
>>> 
>>> One of the things in there is a new warning when a parameter is used,
>>> and is not defined.
>>> 
>>> https://github.com/openstack/keystone/blob/bc8a145de14e455a2a73824e8a84d92ac27aae1c/api-ref/source/v2-ext/ksec2-admin.inc#L31
>>> - as an example
>>> 
>>> Which will generate an issue such as:
>>> 
>>> Warning, treated as error:
>>> /home/sdague/code/openstack/keystone/api-ref/source/api-ref/source/v2-ext/ksec2-admin.inc:112
>>> .rst:: WARNING: No path parameter ``userId`` found in rest_parameter stanza.
>>> 
>>> 
>> 
>> While I understand these are not desirable, is there a better way to 
>> communicate up-front that a potential gate breaking change is coming down 
>> the pipe? This change has impacted the ironic gate 
>> (https://bugs.launchpad.net/ironic/+bug/1658187), and we’re working now to 
>> resolve it, but simply a heads up a few days in advance could’ve prevented 
>> having a bunch of patches fail our api-ref jobs.
> 
> This is my bad. When I looked at the change list and saw this new thing,
> it honestly didn't occur to me that there would be much breakage because
> of the way we did the audit on the nova side.
> 
> I made a note of giving 2 days warning on items like this here -
> https://review.openstack.org/#/c/423517/
> 

Perfect, that’s what I was hoping for. It wasn’t very disruptive because of 
your email + it being caught early, but it’s not fun to waste resources, 
especially with Ironic jobs being so heavy. Thanks for the update, I appreciate 
it.

-Jay


>   -Sean
> 
> -- 
> Sean Dague
> http://dague.net
> 
> __
> OpenStack Development Mailing 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] [Performance][Shaker]

[Sai Sindhur Malleni]

Hey,

When using the "iperf3" class in shaker for looking at UDP small packet
performance, we see that as we scale up the concurrency the average PPS
goes up and also the loss % increases. Is the loss % a percentage of the
PPS or does the PPS only represent successful transmissions? Thanks!

-- 
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] [Heat][TripleO] How to run mistral workflows via templates

[Zane Bitter]

Better late than never...

On 16/12/16 08:57, Steven Hardy wrote:


I know we've previously tried to steer execute/run type actions to signal
driven interfaces (and I myself have opposed these kinds of resources in
the past, to be honest).  However, I can't currently see a better way to
handle this requirement, and given it may be pretty easy to fix (refactor
handle_signal and add a boolean to each handle_foo function), I think this
discussion warrants revisiting.


I think we need to get away from thinking of this as "I just need to run 
a script in the middle of Heat's workflow, let me do it!". That's verb 
thinking and that's the reason I -1'd 
https://review.openstack.org/267770 originally.


We need to think of it as "I have some external thing that I need to 
manage, but I can't teach Heat about it because it means nothing to my 
cloud operator". That's noun thinking and something we can actually work 
with.


For that reason I started talking to a few folks a while back about 
implementing an equivalent of CloudFormation's "CustomResource"[1]. 
Basically, it sends a message to an SNS topic (c.f. Zaqar notification) 
and waits for a success/failure response. We have the technology now to 
trigger Mistral workflows from Zaqar messages.[2] It's clear that this 
is both conceptually sound and solves a number of problems with the best 
available solution, which is triggering workflows via Zaqar 
notifications from user hooks:

 - There's no way to fail a particular resource.
 - The Zaqar queue has to be passed in to the environment when creating 
the stack. This means that the queue has to be created outside of the stack.

 - All stacks in the tree share the same queue for hook notifications.

One reason that CloudFormation implements CustomResource as a message to 
a topic is that it allows integration with third-party service 
providers. That's a valid use case, but I think there's an equally or 
more valid use case for integrating with stuff in your own tenant that 
is just under the end user's control rather than the operators. For that 
case, it makes sense to cut out the Zaqar middleman and just trigger the 
Mistral execution directly.


So I am on board with a Mistral execution resource, BUT:

 * I don't think we should call it a Mistral Execution. I think we 
should give it a name that indicates it's managing some external thing 
by executing Mistral workflows.
 * We need to learn the lesson of SoftwareComponent and include _all_ 
the different phases of the lifecycle in the _same resource_. The user 
should not have to assemble the different phases (Create/Update/Delete) 
of their external resource using discrete workflows, like they do with 
SoftwareConfigs. It's too much to ask them to understand how to build 
the dependency graphs correctly - it took me over a year to work it 
out[3] and that was my whole job.
 * We should also learn the lesson of 
https://launchpad.net/bugs/1595040 and implement a mechanism to allow 
the template author to select (in advance) between update-in-place and 
update-replace for any given update from the get-go.


I also left similar comments on https://review.openstack.org/#/c/420664/ 
but I wanted to go into the background in more depth here.


We may _also_ want to implement something like CustomResource in the 
future, but I agree that this is the higher priority.


cheers,
Zane.

[1] 
http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/template-custom-resources.html
[2] 
http://docs.openstack.org/developer/heat/template_guide/openstack.html#OS::Zaqar::MistralTrigger
[3] 
https://review.openstack.org/gitweb?p=openstack/heat.git;a=commitdiff;h=8b732241df6007c3005b14413ee1fe047eb4d108


__
OpenStack Development Mailing 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] new os-api-ref warning, changes may be needed

[Sean Dague]

On 01/20/2017 03:21 PM, Jay Faulkner wrote:
> On Jan 20, 2017, at 9:41 AM, Sean Dague  wrote:
>>
>> We released a new os-api-ref yesterday which includes a few
>> enhancements, including the anchor links on the website working as
>> expected now.
>>
>> One of the things in there is a new warning when a parameter is used,
>> and is not defined.
>>
>> https://github.com/openstack/keystone/blob/bc8a145de14e455a2a73824e8a84d92ac27aae1c/api-ref/source/v2-ext/ksec2-admin.inc#L31
>> - as an example
>>
>> Which will generate an issue such as:
>>
>> Warning, treated as error:
>> /home/sdague/code/openstack/keystone/api-ref/source/api-ref/source/v2-ext/ksec2-admin.inc:112
>> .rst:: WARNING: No path parameter ``userId`` found in rest_parameter stanza.
>>
>>
> 
> While I understand these are not desirable, is there a better way to 
> communicate up-front that a potential gate breaking change is coming down the 
> pipe? This change has impacted the ironic gate 
> (https://bugs.launchpad.net/ironic/+bug/1658187), and we’re working now to 
> resolve it, but simply a heads up a few days in advance could’ve prevented 
> having a bunch of patches fail our api-ref jobs.

This is my bad. When I looked at the change list and saw this new thing,
it honestly didn't occur to me that there would be much breakage because
of the way we did the audit on the nova side.

I made a note of giving 2 days warning on items like this here -
https://review.openstack.org/#/c/423517/

-Sean

-- 
Sean Dague
http://dague.net

__
OpenStack Development Mailing 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] [puppet] PTL candidacy

[Alex Schultz]

Hey folks,

I would like to nominate myself for the PTL role in the Puppet Openstack Team
for the Pike release cycle.

I served as the PTL during the Ocata cycle and would like to continue to serve
for the Pike release cycle. As part of the Ocata cycle we have made some
excellent progress around ensuring a consistent experience when using the
modules. Additionally we have made continued progress around test coverage.

For the Pike cycle, I believe we have a few places to continue to focus.
- Ensuring the modules are updated for Pike changes.
- Continuing to focus on CI integration both upstream and downstream.
- Improving documentation around established patterns and best practices.
- Working on the feedback loop between the puppet modules and upstream services.
- Improving the deprecation cycle to ensure we are catching deprecations in the
  current cycle rather than after configurations have already been removed.

I look forward to working with all of you. As always, I'm open to any
suggestions or ideas for additional places to improve our processes and modules.

Thanks,
Alex Schultz
irc: mwhahaha

https://review.openstack.org/423514

__
OpenStack Development Mailing 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 Developer Mailing List Digest January 14-20

[Mike Perez]

HTML version: 
https://www.openstack.org/blog/2017/01/openstack-developer-mailing-list-digest-20170120/

SuccessBot Says
===
* stevemar [1] : number of open keystone bugs < 100!
* morgan [2] : Good policy meeting, provided history and background that
  cleared up a lot of confusion
*  Tell us yours via OpenStack IRC channels with message “#success ”
* All: https://wiki.openstack.org/wiki/Successes

FIPS Compliance
===
* Previous threads [3] have been discussing enabling Federal Information
  Processing Standards (FIPS).
* Various OpenStack projects make md5 calls. Not for security purposes, just
  hash generation, but even that blocks enabling FIPS.
* A patch has been proposed for newest versions of Python for users to set if
  these are used for security or not [4].
  - Won’t land until next versions of Python, but in place for current RHEL and
CentOS versions.
  - We will create a wrapper around md5 with a useforsecurity=False parameter
to check the signature of hashlib.md5.
* Steps forward:
  - Create the wrapper
  - Replace all md5 calls in OpenStack projects with the wrapper.
* Unfortunately the patch 4 has stopped having progress since 2013. We should
  get that merged first.
  - Even if this did land, it would be a while before it was adopted, since it
would land in Python 3.7.
* Full thread: 
http://lists.openstack.org/pipermail/openstack-dev/2017-January/thread.html#110278

Refreshing and Revalidating API Compatibility Guidelines

* In the last TC meeting [5] , a tag was in review for supporting API
  compatibility [6] .
* The tag evaluates projects by using the API guideline which is out of date
  [7].
  - A review has been posted to refresh these guidelines [8].
  - API compatibility of overtime is a fundamental aspect of OpenStack
interoperability. Not only do we need to get it it right, we need to make
sure we understand it.
* Full thread: 
http://lists.openstack.org/pipermail/openstack-dev/2017-January/110384.html

Base Services
=
* in open stack all components can assume that a number of external services 
won't be present and available (e.g. A message queue, database).
* The Architecture working group has started this effort [9].
* This proposal [10] is a prerequisite in order for us to have more strategic 
discussions with adding base services.
* Review the proposal and/or join the Architecture working group meeting [11].
* Once solidified the technical committee will have a final discussion and 
approval.
* Full thread: 
http://lists.openstack.org/pipermail/openstack-dev/2017-January/110391.html

Improving Vendor Discoverability

* In previous Technical Committee meetings, it was agreed that vendor
  discoverability needs to be improved.
* This is done today with the OpenStack Foundation marketplace [12] .
  - This is powered by the community driven project call driver log which is
a big JSON file [13].
* Various people in the community did not know how the marketplace worked and
  we're unhappy that the projects themselves weren't owning it.
* The goal of this discussion is to have this process be more community driven
  than it is today.
* Suggestion: Split driver log into smaller JSON files that are inside each
  project to maintain.
  - Projects will set how they validate vendors into this list.
  - There’s a trend today for third party CI’s being a choice of validation
[14].
* Full thread: 
http://lists.openstack.org/pipermail/openstack-dev/2017-January/110151.html

Nominations for OpenStack PTLs Are Now Open!

* Will remain open until January 29, 2017 23:45 UTC.
* Candidates must submit a text file openstack/election repository [15]
  - Filename convention is $cyclename/$projectname/$ircname.txt.
  - To be eligible, you need to have contributed an accepted patch to one of
the corresponding program’s projects [16] during the Neutron-Ocata
timeframe (April 11, 2016 00:00 UTC to January 23, 2017 23:59 UTC).
* Additional information about the nomination process [17]
* Approved candidates will be listed [18].
* Electorate should confirm their email address in Gerrit [19] in Settings ->
  Contact Information -> Preferred Email prior to Jan 25, 2017 23:59 UTC.
* Full thread: 
http://lists.openstack.org/pipermail/openstack-dev/2017-January/110441.html

The Process of Creating stable/ocata branches
=
* As previously mentioned [20], it’s possible for teams to setup stable
  branches when ready.
* The release team will not be automatically setting up branches this cycle.
  - The release liaison within teams will need to inform when ready.
  - The PTL or release liaison may request a new branch by submitting a patch
to the openstack/releases repository specifying the tagged version to be
used as the base of the branch.
* Guidelines

Re: [openstack-dev] [osc][openstackclient][glance] broken image functional test

[Brian Rosmaita]

Top-posting a quick follow-up.

While the reversion was in the gate queue, Ian discovered the fix so
we're going to merge that [0] instead.  So anyone who was planning to
use/test community images this weekend, please go ahead!

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

cheers,
brian


On 1/20/17 11:46 AM, Dean Troyer wrote:
> On Fri, Jan 20, 2017 at 10:00 AM, Brian Rosmaita
>  wrote:
>> We've approved the revert to get the OSC unblocked, though it may be a
>> while before jenkins gets around to processing it, as (of course) the
>> gate is pretty busy now.
> 
> Thanks Brian.  This is our last week before the freeze and we're
> trying to fix our own upstream-breakage before then.
> 
>> Even with sufficient caffeine, it's not obvious.  We didn't change the
>> v1 API for this (translation for v1 is being handled in the registry),
>> and the v1 test coverage is pretty good, so it looked like nothing was
>> broken.  On a closer look, the relevant v1 tests for this particular
>> problem check the response code, not the actual response content, so we
>> will beef those up a bit.
> 
> I've proposed a couple of unit tests that appear to me to illustrate
> what OSC's functional test found.  [0] runs on top of the revert, so
> this is the 'before' check, and [1] runs with the community image
> change and should show the v1 breakage.  As is often heard, "it's
> working for me that way in DevStack" :)
> 
> dt
> 
> [0] https://review.openstack.org/423344
> [1] https://review.openstack.org/423345
> 


__
OpenStack Development Mailing 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] [osc][openstackclient][glance] broken image functional test

[Dean Troyer]

On Fri, Jan 20, 2017 at 10:46 AM, Dean Troyer  wrote:
> I've proposed a couple of unit tests that appear to me to illustrate
> what OSC's functional test found.  [0] runs on top of the revert, so
> this is the 'before' check, and [1] runs with the community image
> change and should show the v1 breakage.  As is often heard, "it's
> working for me that way in DevStack" :)

For completeness, Ian fixed the problem and added a functional test
[0] that also passes my little canary unit tests [1].  The revert has
been abandoned.

Ian & Brian, thanks for jumping on this quickly.

dt

[0] https://review.openstack.org/#/c/423499/
[1] https://review.openstack.org/423345


-- 

Dean Troyer
dtro...@gmail.com

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

Re: [openstack-dev] [all] new os-api-ref warning, changes may be needed

[Jay Faulkner]

On Jan 20, 2017, at 9:41 AM, Sean Dague  wrote:
> 
> We released a new os-api-ref yesterday which includes a few
> enhancements, including the anchor links on the website working as
> expected now.
> 
> One of the things in there is a new warning when a parameter is used,
> and is not defined.
> 
> https://github.com/openstack/keystone/blob/bc8a145de14e455a2a73824e8a84d92ac27aae1c/api-ref/source/v2-ext/ksec2-admin.inc#L31
> - as an example
> 
> Which will generate an issue such as:
> 
> Warning, treated as error:
> /home/sdague/code/openstack/keystone/api-ref/source/api-ref/source/v2-ext/ksec2-admin.inc:112
> .rst:: WARNING: No path parameter ``userId`` found in rest_parameter stanza.
> 
> 

While I understand these are not desirable, is there a better way to 
communicate up-front that a potential gate breaking change is coming down the 
pipe? This change has impacted the ironic gate 
(https://bugs.launchpad.net/ironic/+bug/1658187), and we’re working now to 
resolve it, but simply a heads up a few days in advance could’ve prevented 
having a bunch of patches fail our api-ref jobs.

Thanks,
Jay Faulkner

> Long term, these really all need to be fixed, because this is specifying
> a parameter and giving the user no expectation about what it is and how
> it is used.
> 
> In the short term, if this is too hard for teams to address, remove the
> '-W' from the sphinx_build line in your api-ref section, then work
> through the warnings, and make warnings enforcing when done.
> 
> I've seen fails on keystone. But there may be fails other places as well.
> 
> Keystone fix is here - https://review.openstack.org/#/c/423387 as an
> example of what might be needed to move forward for projects.
> 
>   -Sean
> 
> -- 
> Sean Dague
> http://dague.net
> 
> __
> OpenStack Development Mailing 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] [glance] priorities for the coming week (01/20-01/26)

[Brian Rosmaita]

As discussed in the weekly meeting yesterday, here are our priorities
for the week:

(1) final release for client libraries is next week, so glanceclient
patches need attention.  This list is in priority order (first one is
the highest):
- https://review.openstack.org/#/c/352892/
- https://review.openstack.org/#/c/391968/
- https://review.openstack.org/#/c/421868/

(2) patches associated with the rolling upgrades effort
- https://review.openstack.org/#/c/382958/
- https://review.openstack.org/#/c/392993/
- https://review.openstack.org/#/c/397409/

(3) changes in WebOb 1.7 breaking glance
- https://review.openstack.org/423366

(4) community images merged yesterday afternoon, and madcap hijinks may
ensue.  Please keep a lookout for reports of problems.  For example, Ian
fixed a problem today that was detected by an OpenStack Client test of
the Images v1 API.  Here's the patch FYI:
- https://review.openstack.org/#/c/423499/
Even though we have good test coverage for this, it may be worth adding
some more.  For example,
- https://review.openstack.org/423345

thanks,
brian

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

Re: [openstack-dev] [octavia] Nominating German Eichberger for Octavia core reviewer

[Miguel Lavalle]

Well, I don't vote here but it's nice to see German back in the community.
Welcome!

On Fri, Jan 20, 2017 at 1:26 PM, Brandon Logan 
wrote:

> +1, yes welcome back German.
> On Fri, 2017-01-20 at 09:41 -0800, Michael Johnson wrote:
> > Hello Octavia Cores,
> >
> > I would like to nominate German Eichberger (xgerman) for
> > reinstatement as an
> > Octavia core reviewer.
> >
> > German was previously a core reviewer for Octavia and neutron-lbaas
> > as well
> > as a former co-PTL for Octavia.  Work dynamics required him to step
> > away
> > from the project for a period of time, but now he has moved back into
> > a
> > position that allows him to contribute to Octavia.  His review
> > numbers are
> > back in line with other core reviewers [1] and I feel he would be a
> > solid
> > asset to the core reviewing team.
> >
> > Current Octavia cores, please respond with your +1 vote or an
> > objections.
> >
> > Michael
> >
> > [1] http://stackalytics.com/report/contribution/octavia-group/90
> >
> >
> > _
> > _
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubs
> > cribe
> > 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] Nominating German Eichberger for Octavia core reviewer

[Brandon Logan]

+1, yes welcome back German.
On Fri, 2017-01-20 at 09:41 -0800, Michael Johnson wrote:
> Hello Octavia Cores,
> 
> I would like to nominate German Eichberger (xgerman) for
> reinstatement as an
> Octavia core reviewer.
> 
> German was previously a core reviewer for Octavia and neutron-lbaas
> as well
> as a former co-PTL for Octavia.  Work dynamics required him to step
> away
> from the project for a period of time, but now he has moved back into
> a
> position that allows him to contribute to Octavia.  His review
> numbers are
> back in line with other core reviewers [1] and I feel he would be a
> solid
> asset to the core reviewing team.
> 
> Current Octavia cores, please respond with your +1 vote or an
> objections.
> 
> Michael
> 
> [1] http://stackalytics.com/report/contribution/octavia-group/90
> 
> 
> _
> _
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubs
> cribe
> 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] [puppet] Nominating mkarpin for core for the Puppet OpenStack modules

[Iury Gregory]

+1, well deserved!


2017-01-20 8:59 GMT-03:00 Tobias Urdin :

> Even though I dont have a vote I would like to extend a lot of gratitude
> to Mykyta Karpin for
> always helping out!
>
> Congratulations and well deserved!
>
>
> On 01/19/2017 11:28 PM, Alex Schultz wrote:
> > Hey Puppet Cores,
> >
> > I would like to nominate Mykyta Karpin as a Core reviewer for the
> > Puppet OpenStack modules.  He has been providing quality patches and
> > reviews for some time now and I believe he would be a good addition to
> > the team.  His stats for the last 90 days can be viewed here[0]
> >
> > Please response with your +1 or any objections. If there are no
> > objections by Jan 26, I will add him to the core list.
> >
> > Thanks,
> > -Alex
> >
> > [0] http://stackalytics.com/report/contribution/puppet%
> 20openstack-group/90
> >
> > 
> __
> > OpenStack Development Mailing 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
>



-- 

~


*Att[]'sIury Gregory Melo Ferreira *
*Master student in Computer Science at UFCG*

*Part of the puppet-manager-core team in OpenStack*
*E-mail:  iurygreg...@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

[openstack-dev] [kolla] PTL candidacy

[Michał Jastrzębski]

My dear community,

I humbly ask you all to accept my candidacy as PTL of best cloud project there
is, Kolla. I serve as PTL during current Ocata cycle, and I would like to
continue serving during Pike.

During Ocata cycle, even thou it was very short one with holiday season in the
middle, we did some amazing things, which includes:

* Performed clean repo split, kolla-ansible is now separate deliverable
* Kolla-kubernetes development skyrocketed, including helm as package
  manager. Community grows very fast.
* First voting gates
* Docker registry functionality in gates

My goals stays largely the same, we still have work to do in most of them. You
can see them here [1].

I thank you for your confidence during Ocata cycle and consideration for Pike.

Woot for Kolla!

Michal "inc0" Jastrzebski

[1] 
https://github.com/openstack/election/blob/master/candidates/ocata/Kolla/inc0.txt
[2] https://review.openstack.org/#/c/423403/

__
OpenStack Development Mailing 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] [networking-sfc] Does SFC support chaining of Layer 2 devices?

[Henry Fourie]

Vikash,
   Unclear what you mean by SFC spinning an L2 IDS?
What is the behavior of L2 IDS devices?

-Louis

From: Vikash Kumar [mailto:vikash.ku...@oneconvergence.com]
Sent: Wednesday, January 18, 2017 10:49 PM
To: openstack-dev
Subject: [openstack-dev] [networking-sfc] Does SFC support chaining of Layer 2 
devices?

All,
   I am exploring SFC for chaining an IDS device (strictly in L2 mode). As of 
now, it looks SFC default supports only L3 devices. SFC APIs doesn't have any 
way to specify the nature of device and without that, it seems there is no way 
an operator can spin any device/VNF except L3 mode VNFs. Is anything I am 
missing here ? Can one still spin a L2 IDS with SFC ?


--
Regards,
Vikash
__
OpenStack Development Mailing 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] new os-api-ref warning, changes may be needed

[Steve Martinelli]

Thanks for addressing this in the keystone project Sean!

On Fri, Jan 20, 2017 at 12:41 PM, Sean Dague  wrote:

> We released a new os-api-ref yesterday which includes a few
> enhancements, including the anchor links on the website working as
> expected now.
>
> One of the things in there is a new warning when a parameter is used,
> and is not defined.
>
> https://github.com/openstack/keystone/blob/bc8a145de14e455a2a73824e8a84d9
> 2ac27aae1c/api-ref/source/v2-ext/ksec2-admin.inc#L31
> - as an example
>
> Which will generate an issue such as:
>
> Warning, treated as error:
> /home/sdague/code/openstack/keystone/api-ref/source/api-
> ref/source/v2-ext/ksec2-admin.inc:112
> .rst:: WARNING: No path parameter ``userId`` found in rest_parameter
> stanza.
>
>
> Long term, these really all need to be fixed, because this is specifying
> a parameter and giving the user no expectation about what it is and how
> it is used.
>
> In the short term, if this is too hard for teams to address, remove the
> '-W' from the sphinx_build line in your api-ref section, then work
> through the warnings, and make warnings enforcing when done.
>
> I've seen fails on keystone. But there may be fails other places as well.
>
> Keystone fix is here - https://review.openstack.org/#/c/423387 as an
> example of what might be needed to move forward for projects.
>
> -Sean
>
> --
> Sean Dague
> http://dague.net
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [horizon] feature freeze exception request -- nova simple tenant usages api pagination

[Rob Cresswell]

Just a thought: With the way we currently do microversions, wouldnt this 
request 2.40 for every request ? There's a pretty good chance that would break 
things.

Rob

On 20 January 2017 at 00:02, Richard Jones 
> wrote:
FFE granted for the three patches. We need to support that nova API change.

On 20 January 2017 at 01:28, Radomir Dopieralski 
> wrote:
> I would like to request a feature freeze exception for the following patch:
>
> https://review.openstack.org/#/c/410337
>
> This patch adds support for retrieving the simple tenant usages from Nova in
> chunks, and it is necessary for correct data given that related patches have
> been already merged in Nova. Without
> it, the data received will be truncated.
>
> In order to actually use that patch, however, it is necessary to set the
> Nova API version to at least
> version 3.40. For this, it's necessary to also add this patch:
>
> https://review.openstack.org/422642
>
> However, that patch will not work, because of a bug in the VersionManager,
> which for some reason
> uses floating point numbers for specifying versions, and thus understands
> 2.40 as 2.4. To fix that, it
> is also necessary to merge this patch:
>
> https://review.openstack.org/#/c/410688
>
> I would like to request an exception for all those three patches.
>
> An alternative to this would be to finish and merge the microversion
> support, and modify the first patch to make use of it. Then we would need
> exceptions for those two patches.
>
> __
> OpenStack Development Mailing 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] [release][stable] nominating Alan Pevec (apevec) for stable release core

[Alan Pevec]

> Welcome to the team, Alan!

Thanks all!

Alan

__
OpenStack Development Mailing 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] Nominating German Eichberger for Octavia core reviewer

[Adam Harwell]

+1

Welcome back German!

On Fri, Jan 20, 2017, 11:43 Michael Johnson  wrote:

>
> Hello Octavia Cores,
>
> I would like to nominate German Eichberger (xgerman) for reinstatement as
> an
> Octavia core reviewer.
>
> German was previously a core reviewer for Octavia and neutron-lbaas as well
> as a former co-PTL for Octavia.  Work dynamics required him to step away
> from the project for a period of time, but now he has moved back into a
> position that allows him to contribute to Octavia.  His review numbers are
> back in line with other core reviewers [1] and I feel he would be a solid
> asset to the core reviewing team.
>
> Current Octavia cores, please respond with your +1 vote or an objections.
>
> Michael
>
> [1] http://stackalytics.com/report/contribution/octavia-group/90
>
>
> __
> OpenStack Development Mailing 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] [octavia] Nominating German Eichberger for Octavia core reviewer

[Michael Johnson]

Hello Octavia Cores,

I would like to nominate German Eichberger (xgerman) for reinstatement as an
Octavia core reviewer.

German was previously a core reviewer for Octavia and neutron-lbaas as well
as a former co-PTL for Octavia.  Work dynamics required him to step away
from the project for a period of time, but now he has moved back into a
position that allows him to contribute to Octavia.  His review numbers are
back in line with other core reviewers [1] and I feel he would be a solid
asset to the core reviewing team.

Current Octavia cores, please respond with your +1 vote or an objections.

Michael

[1] http://stackalytics.com/report/contribution/octavia-group/90


__
OpenStack Development Mailing 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] new os-api-ref warning, changes may be needed

[Sean Dague]

We released a new os-api-ref yesterday which includes a few
enhancements, including the anchor links on the website working as
expected now.

One of the things in there is a new warning when a parameter is used,
and is not defined.

https://github.com/openstack/keystone/blob/bc8a145de14e455a2a73824e8a84d92ac27aae1c/api-ref/source/v2-ext/ksec2-admin.inc#L31
- as an example

Which will generate an issue such as:

Warning, treated as error:
/home/sdague/code/openstack/keystone/api-ref/source/api-ref/source/v2-ext/ksec2-admin.inc:112
.rst:: WARNING: No path parameter ``userId`` found in rest_parameter stanza.


Long term, these really all need to be fixed, because this is specifying
a parameter and giving the user no expectation about what it is and how
it is used.

In the short term, if this is too hard for teams to address, remove the
'-W' from the sphinx_build line in your api-ref section, then work
through the warnings, and make warnings enforcing when done.

I've seen fails on keystone. But there may be fails other places as well.

Keystone fix is here - https://review.openstack.org/#/c/423387 as an
example of what might be needed to move forward for projects.

-Sean

-- 
Sean Dague
http://dague.net

__
OpenStack Development Mailing 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][puppet] Preparations for Ocata release in RDO

[Ben Nemec]

On 01/20/2017 08:06 AM, Alfredo Moralejo Alonso wrote:

On Fri, Jan 20, 2017 at 1:50 PM, Emilien Macchi  wrote:

On Fri, Jan 20, 2017 at 7:30 AM, Alfredo Moralejo Alonso
 wrote:

Hi,

In RDO we are preparing for the incoming Ocata release. This means
we'll create a new RDO Trunk builder "centos-ocata" in the next few
days (It will be ready for next week). This builder will get content
from stable/ocata branches of projects as they become available and
fallback to master for those not branched yet. The repos created by
this worker will be published under
https://trunk.rdoproject.org/centos7-ocata/ (which will not longer be
a link to https://trunk.rdoproject.org/centos7-master/).

According to the feedback received during the last release cycle, we
are changing the way we do the transition this time so that
repositories content will be more accurate to what is expected at any
point in the cycle. Repos under centos-master will allways follow
master branch and centos-ocata will get stable/ocata as soon as repos
get the branch created.

This has some implications from the upstream projects point of view:

- Projects using repositories under
https://trunk.rdoproject.org/centos7-ocata/ will start getting
packages for content delivered in stable/ocata branches instead of
master. Repos in https://trunk.rdoproject.org/centos7-master/ will
keep getting packages for content in master branch.


Excellent news.


- Anyone currently pinning to a specific hash repo under
https://trunk.rdoproject.org/centos7-ocata/ should move it to use
https://trunk.rdoproject.org/centos7-master/ as soon as possible. Note
that pinning to a specific hash is not recommended practice.


ack


- With current job definitions, link current-tripleo promoted by
upstream TripleoCI will promote repos with content from master
branches and not stable/ocata after creating the ocata builder. We
think this is not the desired situation during RC period and we must
keep promotion of current-tripleo link for stable/ocata until
cycle-trailing projects are tagged. This will require some changes in
both Tripleo-CI and RDO-CI, please let us know your thoughs so that we
can agree on the best way to implement this and start working on it.


I agree we need to move promotion job to stable/ocata until TripleO
release and then come back to master.
I'm wondering if it would be useful to create a new periodic job that
would run TripleO on master.
Tell me if I'm wrong, but the reason is during our trailing period,
things can (and probably will) break upstream and we might want to
keep aware of it. If we're not, I'm afraid we'll have to deal with a
huge list of blocker after our release when we'll come back on master.



I think the optimal situation would be to keep promotions in both
master an ocata during RC period. If we don't do that, I'm afraid it
will take us some time and effort to get a clean master again.


My understanding is that in the past we've played a bit fast and loose 
with the end of the cycle.  For example, at the end of the Newton cycle 
after the other OpenStack projects cut their Newton branches, we 
continued to run against their master for a period of time before we cut 
our Newton branches.  So essentially we were running our Newton against 
their early Ocata.  Since the overlap is short, we've gotten away with this.


Obviously that's not ideal, but there's another reason I think it would 
be beneficial to start running promotion jobs against stable branches. 
Right now, every stable job has to build images because without 
promotion jobs there are no cached images.  Since we keep making our 
jobs longer and longer with each release, that's only going to get more 
painful.  If we had promotion jobs for stable branches we could cache 
the images and speed things up considerably.  There's also the benefit 
that it would insulate us from broken backports, which has happened in 
the past.


As far as what to do with master during that time, I think we'd at least 
still keep running master jobs against tripleo-ci patches since that 
already has multi-release jobs in project-config.  Plus it will need to 
have both master and stable/ocata jobs anyway.  The other projects 
should probably pin to ocata until their stable branches are cut.


However, I suspect this might involve some kind of ugly project-config 
patches, so we may want to talk to infra about it as well.  They might 
have something in place for this situation already since all projects 
don't cut their stable branches at the same time.  Or maybe they can 
tell us that it generally hasn't been a problem to run mixed releases 
for a couple of weeks and it would be easier to fix any issues that 
creep in after we cut our stable branches instead of trying to do this 
dance.  Although I still think stable promotion jobs would be beneficial 
for the other reasons I noted above.






Thanks,


Best regards,

Alfredo

Re: [openstack-dev] [cinder] Can I use lvm thin provisioning in mitaka?

[Duncan Thomas]

There's also cinder functionality called the 'generic image cache' that
does this for you; see the (per-backend) config options:
image_volume_cache_enabled, image_volume_cache_max_size_gb and
image_volume_cache_max_count

On 20 January 2017 at 16:54, Chris Friesen 
wrote:

> On 01/20/2017 04:07 AM, Marco Marino wrote:
>
>> Hi, I'm trying to use cinder with lvm thin provisioning. It works well
>> and I'd
>> like to know if there is some reason lvm thin should be avoided in mitaka
>> release. I'm trying to use with
>> max_over_subscription_ratio = 1.0
>> so I don't have problems with over subscription.
>> I using thin provisioning because it is fast (I think). More precisely,
>> my use
>> case is:
>>
>> - create one bootable volume. This is a long operation because cinder
>> download
>> the image from glance, qemu-img convert in raw format and then "dd" copy
>> the
>> image in the volume.
>> - Create a snapshot of the bootable volume. Really fast and reliable
>> because the
>> original volume is not used by any vm.
>> - Create a new volume from the snapshot. This is faster than create a new
>> bootable volume.
>>
>> Is this use correct? Can I deploy in the production environment (mitaka -
>> centos 7)
>> Thank you
>>
>
> For what it's worth we're using cinder with LVM thin provisioning in
> production with no overprovisioning.
>
> What you're proposing should work, you're basically caching the vanilla
> image as a cinder snapshot.
>
> If you wish to speed up volume deletion, you can set "volume_clear=none"
> in the cinder.conf file.
>
> Be aware that LVM thin provisioning will see a performance penalty the
> first time you write to a given disk block in a volume, because it needs to
> allocate a new block, zero it out, then write the new data to it.
>
> 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
>



-- 
-- 
Duncan 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] [puppet] Nominating zhongshengping for core of the Puppet OpenStack modules

[Alex Schultz]

Hey Puppet Cores,

I would like to nominate Zhong Shengping as a Core reviewer for the
Puppet OpenStack modules.  He is an excellent contributor to our
modules over the last several cycles. His stats for the last 90 days
can be viewed here[0].

Please response with your +1 or any objections. If there are no
objections by Jan 27 I will add him to the core list.

Thanks,
-Alex

[0] http://stackalytics.com/report/contribution/puppet%20openstack-group/90

__
OpenStack Development Mailing 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] Improving Vendor Driver Discoverability

[Anita Kuno]

On 2017-01-17 02:08 AM, Isaac Beckman wrote:

I think that it would also be a good idea to have the option to let the CI
maintainers add some useful information on the current status.
It is very helpful to know that the CI system is under maintenance which
is the reason why it hasn't been reporting for the last week or so...

Isaac Beckman

Office: +972-3-6897874
Fax: +972-3-6897755
Mobile: +972-50-2680180
Email: isa...@il.ibm.com

IBM XIV, Cloud Storage Solutions (previously HSG)
www.ibm.com/storage/disk/xiv
  




From:   "Jay S. Bryant" 
To: "OpenStack Development Mailing List (not for usage questions)"

Date:   16/01/2017 21:56
Subject:Re: [openstack-dev] [all] Improving Vendor Driver
Discoverability





On 01/16/2017 12:19 PM, Jonathan Bryce wrote:

On Jan 16, 2017, at 11:58 AM, Jay S. Bryant

 wrote:

On 01/13/2017 10:29 PM, Mike Perez wrote:

The way validation works is completely up to the project team. In my

research

as shown in the Summit etherpad [5] there's a clear trend in projects

doing

continuous integration for validation. If we wanted to we could also

have the

marketplace give the current CI results, which was also requested in

the

feedback from driver maintainers.

Having the CI results reported would be an interesting experiment. I

wonder if having the results even more publicly reported would result in
more stable CI's.  It is a dual edged sword however. Given the instability
of many CI's it could make OpenStack look bad to customers who don't
understand what they are looking at.  Just my thoughts on that idea.

That?s very useful feedback. Having that kind of background upfront is

really helpful. As we make updates on the display side, we can take into
account if certain attributes are potentially unreliable or at a higher
risk of showing instability and have the interface better support that
without it looking like everything is failing and a river of red X?s. Are
there other things that might be similar?

Jonathan


Jonathan,

Glad to be of assistance.

I think reporting some percentage of success might be the most accurate
way to report the CI results.  Not necessarily flagging it good or bed
but leave it for the consumers to see and compare.  Also combine that
with Anita's idea of when the CI last successfully reported and I think
it could give a good barometer for consumers. Our systems all have their
rough times so we need to avoid a 'snapshot in time' view and provide
more of a 'activity over time' view.  Third party CI is a good barometer
of community activity and attention, but not always 100% accurate.

Obviously there will need to be some information included with the
results explaining what they are and helping guide interpretations.

Jay




Since the information about system details (contact information, current 
status - with the option to fill in as many details as you like on your 
individual wikipage) already exists here: 
https://wiki.openstack.org/wiki/ThirdPartySystems I think it would be 
easy to add a link to this wikipage.


Thanks,
Anita.


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

Re: [openstack-dev] [cinder] Can I use lvm thin provisioning in mitaka?

[Chris Friesen]

On 01/20/2017 04:07 AM, Marco Marino wrote:

Hi, I'm trying to use cinder with lvm thin provisioning. It works well and I'd
like to know if there is some reason lvm thin should be avoided in mitaka
release. I'm trying to use with
max_over_subscription_ratio = 1.0
so I don't have problems with over subscription.
I using thin provisioning because it is fast (I think). More precisely, my use
case is:

- create one bootable volume. This is a long operation because cinder download
the image from glance, qemu-img convert in raw format and then "dd" copy the
image in the volume.
- Create a snapshot of the bootable volume. Really fast and reliable because the
original volume is not used by any vm.
- Create a new volume from the snapshot. This is faster than create a new
bootable volume.

Is this use correct? Can I deploy in the production environment (mitaka - 
centos 7)
Thank you


For what it's worth we're using cinder with LVM thin provisioning in production 
with no overprovisioning.


What you're proposing should work, you're basically caching the vanilla image as 
a cinder snapshot.


If you wish to speed up volume deletion, you can set "volume_clear=none" in the 
cinder.conf file.


Be aware that LVM thin provisioning will see a performance penalty the first 
time you write to a given disk block in a volume, because it needs to allocate a 
new block, zero it out, then write the new data to it.


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] [osc][openstackclient][glance] broken image functional test

[Dean Troyer]

On Fri, Jan 20, 2017 at 10:00 AM, Brian Rosmaita
 wrote:
> We've approved the revert to get the OSC unblocked, though it may be a
> while before jenkins gets around to processing it, as (of course) the
> gate is pretty busy now.

Thanks Brian.  This is our last week before the freeze and we're
trying to fix our own upstream-breakage before then.

> Even with sufficient caffeine, it's not obvious.  We didn't change the
> v1 API for this (translation for v1 is being handled in the registry),
> and the v1 test coverage is pretty good, so it looked like nothing was
> broken.  On a closer look, the relevant v1 tests for this particular
> problem check the response code, not the actual response content, so we
> will beef those up a bit.

I've proposed a couple of unit tests that appear to me to illustrate
what OSC's functional test found.  [0] runs on top of the revert, so
this is the 'before' check, and [1] runs with the community image
change and should show the v1 breakage.  As is often heard, "it's
working for me that way in DevStack" :)

dt

[0] https://review.openstack.org/423344
[1] https://review.openstack.org/423345

-- 

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] [tripleo] Mistral Workflow for deriving THT parameters

[John Fulton]

On 01/11/2017 11:34 PM, Saravanan KR wrote:

Thanks John, I would really appreciate if you could tag me on the
reviews. I will do the same for mine too.


Hi Saravanan,

Following up on this, have a look at the OS::Mistral::WorflowExecution
Heat spec [1] to trigger Mistral workflows. I'm hoping to use it for
deriving THT parameters for optimal resource isolation in HCI
deployments as I mentioned below. I have a spec [2] which describes
the derivation of the values, but this is provided as an example for
the more general problem of capturing the rules used to derive the
values so that deployers may easily apply them.

Thanks,
  John

[1] OS::Mistral::WorflowExecution https://review.openstack.org/#/c/267770/
[2] TripleO Performance Profiles https://review.openstack.org/#/c/423304/


On Wed, Jan 11, 2017 at 8:03 PM, John Fulton  wrote:

On 01/11/2017 12:56 AM, Saravanan KR wrote:


Thanks Emilien and Giulio for your valuable feedback. I will start
working towards finalizing the workbook and the actions required.



Saravanan,

If you can add me to the review for your workbook, I'd appreciate it. I'm
trying to solve a similar problem, of computing THT params for HCI
deployments in order to isolate resources between CephOSDs and NovaComputes,
and I was also looking to use a Mistral workflow. I'll add you to the review
of any related work, if you don't mind. Your proposal to get NUMA info into
Ironic [1] helps me there too. Hope to see you at the PTG.

Thanks,
  John

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



would you be able to join the PTG to help us with the session on the
overcloud settings optimization?


I will come back on this, as I have not planned for it yet. If it
works out, I will update the etherpad.

Regards,
Saravanan KR


On Wed, Jan 11, 2017 at 5:10 AM, Giulio Fidente 
wrote:


On 01/04/2017 09:13 AM, Saravanan KR wrote:



Hello,

The aim of this mail is to ease the DPDK deployment with TripleO. I
would like to see if the approach of deriving THT parameter based on
introspection data, with a high level input would be feasible.

Let me brief on the complexity of certain parameters, which are
related to DPDK. Following parameters should be configured for a good
performing DPDK cluster:
* NeutronDpdkCoreList (puppet-vswitch)
* ComputeHostCpusList (PreNetworkConfig [4], puppet-vswitch) (under
review)
* NovaVcpuPinset (puppet-nova)

* NeutronDpdkSocketMemory (puppet-vswitch)
* NeutronDpdkMemoryChannels (puppet-vswitch)
* ComputeKernelArgs (PreNetworkConfig [4]) (under review)
* Interface to bind DPDK driver (network config templates)

The complexity of deciding some of these parameters is explained in
the blog [1], where the CPUs has to be chosen in accordance with the
NUMA node associated with the interface. We are working a spec [2], to
collect the required details from the baremetal via the introspection.
The proposal is to create mistral workbook and actions
(tripleo-common), which will take minimal inputs and decide the actual
value of parameters based on the introspection data. I have created
simple workbook [3] with what I have in mind (not final, only
wireframe). The expected output of this workflow is to return the list
of inputs for "parameter_defaults",  which will be used for the
deployment. I would like to hear from the experts, if there is any
drawbacks with this approach or any other better approach.




hi, I am not an expert, I think John (on CC) knows more but this looks
like
a good initial step to me.

once we have the workbook in good shape, we could probably integrate it
in
the tripleo client/common to (optionally) trigger it before every
deployment

would you be able to join the PTG to help us with the session on the
overcloud settings optimization?

https://etherpad.openstack.org/p/tripleo-ptg-pike
--
Giulio Fidente
GPG KEY: 08D733BA


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




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

Re: [openstack-dev] [nova] Do not recheck changes until 422709 is merged

[Matt Riedemann]

On 1/20/2017 9:20 AM, Jeremy Stanley wrote:


Do you have example logs for those failures so we can compare them
to the timeline for the fix landing? When a change enters a Zuul
pipeline, it and its open parent changes are unconditionally merged
to the current branch tip and then jobs are run against that state
(and if the changes are unable to be merged to the branch tip
without conflict, Zuul immediately reports back with a merge failure
rather than running any jobs).



Yeah, this is the failure in the gate before I rebased it [1].

This is the change that was needed for the rebase [2].

Looking at when [1] failed and [2] merged, it looks like it [2] merged 
an hour later, so yeah, I guess I thought the other was already merged 
when I rebased [1].


So the world isn't ruined.

[1] 
http://logs.openstack.org/37/410737/5/gate/gate-nova-python35-db/1a828b8/console.html#_2017-01-19_23_23_36_271935

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

--

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] [qa] PTL non-candidacy

[Cazares, Luz]

Thank you Kenichi for the great work and leadership.

Glad that you will continue working on the QA program, so… see you around ☺

Luz Cazares


On 1/19/17, 2:30 PM, "Masayuki Igawa"  wrote:

Thank you for your great effort! I'm very proud of you as a colleague :)

-- Masayuki Igawa

On Fri, Jan 20, 2017 at 6:16 AM, Ken'ichi Ohmichi  
wrote:
> Hi,
>
> I will step down as PTL after this Ocata cycle.
> I was happy to see new ideas and folks who try making ideas true in
> this 2 cycles.
> Now QA project has a lot of components with many people's effort and
> we help each other as a community.
> This experience is very exciting for me, I am proud to being a member
> in this community.
>
> Today, I'd like to concentrate on coding and reviewing again as a 
developer.
> I think we have good candidates for a next PTL, and I will keep active
> under the next PTL's leadership.
>
> Thanks for choosing me anyways, let's make OpenStack quality better 
together :-)
>
> Thanks
> Ken Ohmichi
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing 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] [osc][openstackclient][glance] broken image functional test

[Brian Rosmaita]

On 1/20/17 9:05 AM, Dean Troyer wrote:
> On Fri, Jan 20, 2017 at 6:46 AM, Steve Martinelli
>  wrote:
>> it seems the OSC gate is broken, several patches are failing the same way:
> 
> [...]
> 
>> did something break? at first glance (hehe), it seems this patch may be to
>> blame?
>> https://github.com/openstack/glance/commit/265659e8c34865331568b069fdb27ea272df4eaa
> 
> I've posted a revert of 265659e8c34865331568b069fdb27ea272df4eaa due
> to the breakage of API v1 this late in the cycle.

We've approved the revert to get the OSC unblocked, though it may be a
while before jenkins gets around to processing it, as (of course) the
gate is pretty busy now.

> 
> A couple of attempts on my part to see why the Glance unit tests did
> not catch this have fallen short due to ENO_CAFFIENE.

Even with sufficient caffeine, it's not obvious.  We didn't change the
v1 API for this (translation for v1 is being handled in the registry),
and the v1 test coverage is pretty good, so it looked like nothing was
broken.  On a closer look, the relevant v1 tests for this particular
problem check the response code, not the actual response content, so we
will beef those up a bit.

> 
> dt
> 


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

Re: [openstack-dev] [qa] PTL non-candidacy

[Daniel Mellado]

El 19/01/17 a las 20:16, Ken'ichi Ohmichi escribió:
> Hi,
> 
> I will step down as PTL after this Ocata cycle.
> I was happy to see new ideas and folks who try making ideas true in
> this 2 cycles.
> Now QA project has a lot of components with many people's effort and
> we help each other as a community.
> This experience is very exciting for me, I am proud to being a member
> in this community.
> 
> Today, I'd like to concentrate on coding and reviewing again as a developer.
> I think we have good candidates for a next PTL, and I will keep active
> under the next PTL's leadership.
> 
> Thanks for choosing me anyways, let's make OpenStack quality better together 
> :-)
> 
> Thanks
> Ken Ohmichi
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
Thanks for all your hard 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] [release][stable] nominating Alan Pevec (apevec) for stable release core

[Doug Hellmann]

Excerpts from Doug Hellmann's message of 2017-01-18 09:16:53 -0500:
> Based on Tony's recommendation, and Alan's recent review work, I
> am nominating Alan Pevec (apevec) to have core reviewer rights on
> stable releases in the openstack/releases repository.
> 
> Release team, please either +1 or raise any concerns you have.
> 
> Doug
> 

Seeing only positive responses from the release team, I have added Alan
to the releases-core group.

Welcome to the team, Alan!

Doug

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

Re: [openstack-dev] [all] Improving Vendor Driver Discoverability

[Jay S. Bryant]

Mike,

Similar the evil driver support matrix that Cinder has had forever [1].

So, there is a precedent and this looks like it would be better than 
something that has to be manually updated.


No initial objections.  :-)

Jay

[1] https://wiki.openstack.org/wiki/CinderSupportMatrix


On 01/19/2017 07:37 PM, Mike Perez wrote:

On 17:38 Jan 18, Morales, Victor wrote:

Just a FYI, Ankur have been working on have a Feature Classification Matrix
in Neutron[1] which collects some of this information

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

I actually didn't know Nova also generated this with a script and ini file.
Perhaps this would be a better approach than a giant JSON file like driver log
is today. I could then have the marketplace parse these ini files using the
common script. What do others think?



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


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

Re: [openstack-dev] [nova] Do not recheck changes until 422709 is merged

[Jeremy Stanley]

On 2017-01-20 08:53:19 -0600 (-0600), Matt Riedemann wrote:
[...]
> Yeah idk, but that wasn't working, I had already rechecked once
> and those changes were failing on the thing noted above, and only
> fixed once I rebased them.

Do you have example logs for those failures so we can compare them
to the timeline for the fix landing? When a change enters a Zuul
pipeline, it and its open parent changes are unconditionally merged
to the current branch tip and then jobs are run against that state
(and if the changes are unable to be merged to the branch tip
without conflict, Zuul immediately reports back with a merge failure
rather than running any jobs).
-- 
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

Re: [openstack-dev] [cinder] drbdmanage is no more GPL2

[Philipp Reisner]

Hi Sean,

please review these commits in drbdmanage upstream:
http://git.drbd.org/drbdmanage.git/commit/2312d7e7657f98728b6ae1601d8c77010f6adca2
http://git.drbd.org/drbdmanage.git/commit/24ff36ec21f5b7cfdfe38b1888b64eb01f463240

Basically everything behind the dbus API GPL-v3. All files included by the
cinder driver are LGPL-v3.

To the best of my understanding this make the drbd cinder driver now
compliant with all OpenStack licensing rules and OpenStack infra rules.

Is there action required from my side to get the attention from
openstack-infra about this move?

best regards,
 Phil

> It has been pointed out that this change of license no longer qualifies
> this driver to have CI run by openstack-infra. It is a requirement that
> all Cinder backend drivers have a running third party CI to validate all
> patches.
> 
> A new CI will need to be set up for this driver ASAP. If that is not
> possible, the driver will be marked as not supported in this release and
> removed in Pike.



__
OpenStack Development Mailing 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][ptl][telemetry][barbican][cloudkitty][congress][glance][ironic][magnum][manila][murano][neutron][searchlight][vitrage] last chance to release a client next week

[Dmitry Tantsur]

On 01/20/2017 02:57 PM, Doug Hellmann wrote:

We have quite a few client libraries for which there are no Ocata releases at 
all:

python-aodhclient
python-barbicanclient
python-brick-cinderclient-ext
python-cloudkittyclient
python-congressclient
python-glanceclient
python-ironic-inspector-client


We're nearly done, one small patch still on review: 
https://review.openstack.org/409789. If the deadline comes, though, we can 
release even without it.



python-magnumclient
python-manilaclient
python-muranoclient
python-neutronclient
python-searchlightclient
python-vitrageclient

Please keep in mind that next week’s deadline is the last chance to prepare a 
release for client libraries for this cycle. Review the list of changes in 
master since the last release and propose a new release if you need one.

Doug


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




__
OpenStack Development Mailing 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] Order of n-api (placement) and n-sch upgrades for Ocata

[Matt Riedemann]

On 1/20/2017 9:00 AM, Matt Riedemann wrote:

On 1/20/2017 4:53 AM, Eoghan Glynn wrote:


Do we also need to be concerned about the placement API "warm-up" time?

i.e. if a placement-less newton deployment is upgraded to placement-ful
ocata, then would there surely be a short period during which placement
is able to respond to the incoming queries from the scheduler, but only
with incomplete information since all the computes haven't yet triggered
their first reporting cycle?

In that case, it wouldn't necessarily lead to a NoValidHost failure on a
instance boot request, but rather a potentially faulty placement
decision,
being based on incomplete information. I mean "faulty" there in the sense
of not strictly following the configured scheduling strategy.

Is that a concern, or an acceptable short degradation of service?

Cheers,
Eoghan



That's discussed a bit in this older thread [1]. If placement is up and
running but there are no computes checking in yet, then it's going to be
a NoValidHost from the filter scheduler because it's not going to
fallback to the compute_nodes table.

The nova-status command was written as an upgrade readiness check for
this situation [2]. If there are compute nodes in the database (from
Newton) but no resource providers in the placement service, then that
upgrade check is going to fail.

If it's a fresh install and there are 0 resource providers in the
placement service and 0 compute nodes, then the upgrade check passes but
provides a reminder about needing to make sure you get the computes
configured and registered for placement as you bring them online.

[1]
http://lists.openstack.org/pipermail/openstack-dev/2016-December/109060.html

[2]
https://github.com/openstack/nova/blob/ae753d96281709397dcfe5dd4ff7d6db57f3683e/nova/cmd/status.py#L301




Also, before anyone mentions this:

"Well what if I've upgraded my controller services to Ocata, including 
placement and nova-scheduler, but my computes are all still Newton?!"


The answer is Newton computes can be configured to register with the 
placement service already, and we backported a fix from Dan Smith [1] to 
make sure the Newton computes keep trying to connect to placement.


So this means you can still configure your Newton computes to talk to 
the Ocata placement service, even before rolling out placement, and once 
it's up the computes will check in and you shouldn't have NoValidHost 
issues, or at least the window should be small.


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

--

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] [nova] Order of n-api (placement) and n-sch upgrades for Ocata

[Matt Riedemann]

On 1/20/2017 4:53 AM, Eoghan Glynn wrote:


Do we also need to be concerned about the placement API "warm-up" time?

i.e. if a placement-less newton deployment is upgraded to placement-ful
ocata, then would there surely be a short period during which placement
is able to respond to the incoming queries from the scheduler, but only
with incomplete information since all the computes haven't yet triggered
their first reporting cycle?

In that case, it wouldn't necessarily lead to a NoValidHost failure on a
instance boot request, but rather a potentially faulty placement decision,
being based on incomplete information. I mean "faulty" there in the sense
of not strictly following the configured scheduling strategy.

Is that a concern, or an acceptable short degradation of service?

Cheers,
Eoghan



That's discussed a bit in this older thread [1]. If placement is up and 
running but there are no computes checking in yet, then it's going to be 
a NoValidHost from the filter scheduler because it's not going to 
fallback to the compute_nodes table.


The nova-status command was written as an upgrade readiness check for 
this situation [2]. If there are compute nodes in the database (from 
Newton) but no resource providers in the placement service, then that 
upgrade check is going to fail.


If it's a fresh install and there are 0 resource providers in the 
placement service and 0 compute nodes, then the upgrade check passes but 
provides a reminder about needing to make sure you get the computes 
configured and registered for placement as you bring them online.


[1] 
http://lists.openstack.org/pipermail/openstack-dev/2016-December/109060.html
[2] 
https://github.com/openstack/nova/blob/ae753d96281709397dcfe5dd4ff7d6db57f3683e/nova/cmd/status.py#L301


--

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] [release][ptl][telemetry][barbican][cloudkitty][congress][glance][ironic][magnum][manila][murano][neutron][searchlight][vitrage] last chance to release a client next week

[Julien Danjou]

On Fri, Jan 20 2017, Doug Hellmann wrote:

> We have quite a few client libraries for which there are no Ocata releases at 
> all:
>
> python-aodhclient

The gate is broken for this one, we're working on fixing it. :)

-- 
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] [nova] Do not recheck changes until 422709 is merged

[Matt Riedemann]

On 1/20/2017 7:46 AM, Andreas Jaeger wrote:


You shouldn't need to rebase changes - we always rebase in check and
gate queue before running tests. So, a simple "recheck" should be enough.

Andreas



Yeah idk, but that wasn't working, I had already rechecked once and 
those changes were failing on the thing noted above, and only fixed once 
I rebased them.


--

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] [all] Improving Vendor Driver Discoverability

[Jeremy Stanley]

On 2017-01-19 17:37:13 -0800 (-0800), Mike Perez wrote:
> I actually didn't know Nova also generated this with a script and
> ini file. Perhaps this would be a better approach than a giant
> JSON file like driver log is today. I could then have the
> marketplace parse these ini files using the common script. What do
> others think?

With at least two existing instances, we can assert this is an
emerging common practice. That seems far more palatable than having
some new solution pushed at various projects from scratch and
insisting that those who have already solved it give up what they're
using successfully.
-- 
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

Re: [openstack-dev] [tripleo][puppet] Preparations for Ocata release in RDO

[Alfredo Moralejo Alonso]

On Fri, Jan 20, 2017 at 1:50 PM, Emilien Macchi  wrote:
> On Fri, Jan 20, 2017 at 7:30 AM, Alfredo Moralejo Alonso
>  wrote:
>> Hi,
>>
>> In RDO we are preparing for the incoming Ocata release. This means
>> we'll create a new RDO Trunk builder "centos-ocata" in the next few
>> days (It will be ready for next week). This builder will get content
>> from stable/ocata branches of projects as they become available and
>> fallback to master for those not branched yet. The repos created by
>> this worker will be published under
>> https://trunk.rdoproject.org/centos7-ocata/ (which will not longer be
>> a link to https://trunk.rdoproject.org/centos7-master/).
>>
>> According to the feedback received during the last release cycle, we
>> are changing the way we do the transition this time so that
>> repositories content will be more accurate to what is expected at any
>> point in the cycle. Repos under centos-master will allways follow
>> master branch and centos-ocata will get stable/ocata as soon as repos
>> get the branch created.
>>
>> This has some implications from the upstream projects point of view:
>>
>> - Projects using repositories under
>> https://trunk.rdoproject.org/centos7-ocata/ will start getting
>> packages for content delivered in stable/ocata branches instead of
>> master. Repos in https://trunk.rdoproject.org/centos7-master/ will
>> keep getting packages for content in master branch.
>
> Excellent news.
>
>> - Anyone currently pinning to a specific hash repo under
>> https://trunk.rdoproject.org/centos7-ocata/ should move it to use
>> https://trunk.rdoproject.org/centos7-master/ as soon as possible. Note
>> that pinning to a specific hash is not recommended practice.
>
> ack
>
>> - With current job definitions, link current-tripleo promoted by
>> upstream TripleoCI will promote repos with content from master
>> branches and not stable/ocata after creating the ocata builder. We
>> think this is not the desired situation during RC period and we must
>> keep promotion of current-tripleo link for stable/ocata until
>> cycle-trailing projects are tagged. This will require some changes in
>> both Tripleo-CI and RDO-CI, please let us know your thoughs so that we
>> can agree on the best way to implement this and start working on it.
>
> I agree we need to move promotion job to stable/ocata until TripleO
> release and then come back to master.
> I'm wondering if it would be useful to create a new periodic job that
> would run TripleO on master.
> Tell me if I'm wrong, but the reason is during our trailing period,
> things can (and probably will) break upstream and we might want to
> keep aware of it. If we're not, I'm afraid we'll have to deal with a
> huge list of blocker after our release when we'll come back on master.
>

I think the optimal situation would be to keep promotions in both
master an ocata during RC period. If we don't do that, I'm afraid it
will take us some time and effort to get a clean master again.

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

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

Re: [openstack-dev] [osc][openstackclient][glance] broken image functional test

[Dean Troyer]

On Fri, Jan 20, 2017 at 6:46 AM, Steve Martinelli
 wrote:
> it seems the OSC gate is broken, several patches are failing the same way:

[...]

> did something break? at first glance (hehe), it seems this patch may be to
> blame?
> https://github.com/openstack/glance/commit/265659e8c34865331568b069fdb27ea272df4eaa

I've posted a revert of 265659e8c34865331568b069fdb27ea272df4eaa due
to the breakage of API v1 this late in the cycle.

A couple of attempts on my part to see why the Glance unit tests did
not catch this have fallen short due to ENO_CAFFIENE.

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

[openstack-dev] [release][ptl][telemetry][barbican][cloudkitty][congress][glance][ironic][magnum][manila][murano][neutron][searchlight][vitrage] last chance to release a client next week

[Doug Hellmann]

We have quite a few client libraries for which there are no Ocata releases at 
all:

python-aodhclient
python-barbicanclient
python-brick-cinderclient-ext
python-cloudkittyclient
python-congressclient
python-glanceclient
python-ironic-inspector-client
python-magnumclient
python-manilaclient
python-muranoclient
python-neutronclient
python-searchlightclient
python-vitrageclient

Please keep in mind that next week’s deadline is the last chance to prepare a 
release for client libraries for this cycle. Review the list of changes in 
master since the last release and propose a new release if you need one.

Doug


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

Re: [openstack-dev] [qa] PTL non-candidacy

[Tomoyuki KATO]

大道さん、PTL本当におつかれさまでした。QAのような複雑なプロジェクトで2サイクル継続して素晴らしいと思います。PTLかどうかに関係なく、何かとお世話になると思いますが、OpenStackを発展させるためにこれからもがんばりましょう。加藤
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] Do not recheck changes until 422709 is merged

[Andreas Jaeger]

On 2017-01-20 14:36, Matt Riedemann  wrote:
> On 1/20/2017 2:22 AM, Sylvain Bauza wrote:
>>
>>
>> Le 20/01/2017 04:16, Matt Riedemann a écrit :
>>> On 1/19/2017 5:09 PM, Matt Riedemann wrote:
 On 1/19/2017 10:56 AM, Matt Riedemann wrote:
> The py35 unit test job is broken for Nova until this patch is merged:
>
> https://review.openstack.org/#/c/422709/
>
> So please hold off on the rechecks until that happens.
>

 We're good to go again for rechecks.

>>>
>>> Just a heads up that if you still see py35 unit test failures with a
>>> TypeError like this [1] then you need to rebase you patch.
>>>
>>> [1]
>>> http://logs.openstack.org/37/410737/5/check/gate-nova-python35-db/4fec66c/console.html#_2017-01-20_01_56_21_021702
>>>
>>>
>>>
>>
>> Just for understanding correctly the context, which merged change fixes
>> that, needing a rebase ?
>>
>>
>> __
>>
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
> 
> Not merged changes, changes in the check queue. I had noticed a couple
> of approved changes yesterday were failing on oslo.serialization 2.16.0
> in upper-constraints so those needed to be rebased to pick this up:
> 
> https://github.com/openstack/nova/commit/161799edaab21ea7b4f577766764768fa6c39e5d


You shouldn't need to rebase changes - we always rebase in check and
gate queue before running tests. So, a simple "recheck" should be enough.

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] [nova] Do not recheck changes until 422709 is merged

[Matt Riedemann]

On 1/20/2017 2:22 AM, Sylvain Bauza wrote:



Le 20/01/2017 04:16, Matt Riedemann a écrit :

On 1/19/2017 5:09 PM, Matt Riedemann wrote:

On 1/19/2017 10:56 AM, Matt Riedemann wrote:

The py35 unit test job is broken for Nova until this patch is merged:

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

So please hold off on the rechecks until that happens.



We're good to go again for rechecks.



Just a heads up that if you still see py35 unit test failures with a
TypeError like this [1] then you need to rebase you patch.

[1]
http://logs.openstack.org/37/410737/5/check/gate-nova-python35-db/4fec66c/console.html#_2017-01-20_01_56_21_021702




Just for understanding correctly the context, which merged change fixes
that, needing a rebase ?


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



Not merged changes, changes in the check queue. I had noticed a couple 
of approved changes yesterday were failing on oslo.serialization 2.16.0 
in upper-constraints so those needed to be rebased to pick this up:


https://github.com/openstack/nova/commit/161799edaab21ea7b4f577766764768fa6c39e5d

--

Thanks,

Matt Riedemann


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

[openstack-dev] [sahara] PTL Candidacy for Pike

[Telles Nobrega]

Hello everyone!



I'd like to announce my candidacy for PTL of the Data

Processing project (Sahara), and to describe what I hope to do to help
Sahara  move forward.



First of all I would like to introduce myself. I've been working on the
Sahara project since the Icehouse release, and since the Newton release I
have been a member of the Sahara core reviewer team.

I was responsible for introducing the Storm plugin to Sahara and have
maintained it since its creation. Other than that, I've been working on
many different features and small fixes to Sahara.


Here are a summary of my contributions to Sahara:

Reviews:

* All-time:
http://stackalytics.com/?module=sahara-group_id=tellesmvn=all
* Ocata:
http://stackalytics.com/?module=sahara-group_id=tellesmvn=ocata
Commits:
* All-time:
http://stackalytics.com/?module=sahara-group_id=tellesmvn=all=commits
* Ocata:
http://stackalytics.com/?module=sahara-group_id=tellesmvn=ocata=commits


As PTL I will coordinate the team to reach community goals, manage
Sahara releases, and track all activities related to new features
in Sahara. Also I plan to minimize the open bug list by organizing some bug
triage days and bug fix weeks. Improving documentation is also a priority
to
allow Sahara to grow.



My main focus for this coming release is finding ways to grow the Sahara
team.
Currently we have mentees and I would like to improve that kind of
integration to bring new people to the team.


As for Sahara features, I plan to establish a team and set deadlines to
deliver API v2. I will also focus on preparing Sahara for Python 3.5


I hope that Sahara will continue to grow in the Pike release.


Best regards, Telles Nobrega

e-mail: tel...@redhat.com

IRC: tellesnobrega, Launchpad: tellesmvn.


-- 
[image: Red Hat] 
Telles Nobrega | Software Engineer
Red Hat Brasil
T: +55 11 3529-6000 <+55%2011%203529-6000> | M: +55 11 9 9910-1689
Av. Brigadeiro Faria Lima 3900, 8° Andar. São Paulo, Brasil.
RED HAT | TRIED. TESTED. TRUSTED. Saiba porque em redhat.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] [tripleo][puppet] Preparations for Ocata release in RDO

[Emilien Macchi]

On Fri, Jan 20, 2017 at 7:30 AM, Alfredo Moralejo Alonso
 wrote:
> Hi,
>
> In RDO we are preparing for the incoming Ocata release. This means
> we'll create a new RDO Trunk builder "centos-ocata" in the next few
> days (It will be ready for next week). This builder will get content
> from stable/ocata branches of projects as they become available and
> fallback to master for those not branched yet. The repos created by
> this worker will be published under
> https://trunk.rdoproject.org/centos7-ocata/ (which will not longer be
> a link to https://trunk.rdoproject.org/centos7-master/).
>
> According to the feedback received during the last release cycle, we
> are changing the way we do the transition this time so that
> repositories content will be more accurate to what is expected at any
> point in the cycle. Repos under centos-master will allways follow
> master branch and centos-ocata will get stable/ocata as soon as repos
> get the branch created.
>
> This has some implications from the upstream projects point of view:
>
> - Projects using repositories under
> https://trunk.rdoproject.org/centos7-ocata/ will start getting
> packages for content delivered in stable/ocata branches instead of
> master. Repos in https://trunk.rdoproject.org/centos7-master/ will
> keep getting packages for content in master branch.

Excellent news.

> - Anyone currently pinning to a specific hash repo under
> https://trunk.rdoproject.org/centos7-ocata/ should move it to use
> https://trunk.rdoproject.org/centos7-master/ as soon as possible. Note
> that pinning to a specific hash is not recommended practice.

ack

> - With current job definitions, link current-tripleo promoted by
> upstream TripleoCI will promote repos with content from master
> branches and not stable/ocata after creating the ocata builder. We
> think this is not the desired situation during RC period and we must
> keep promotion of current-tripleo link for stable/ocata until
> cycle-trailing projects are tagged. This will require some changes in
> both Tripleo-CI and RDO-CI, please let us know your thoughs so that we
> can agree on the best way to implement this and start working on it.

I agree we need to move promotion job to stable/ocata until TripleO
release and then come back to master.
I'm wondering if it would be useful to create a new periodic job that
would run TripleO on master.
Tell me if I'm wrong, but the reason is during our trailing period,
things can (and probably will) break upstream and we might want to
keep aware of it. If we're not, I'm afraid we'll have to deal with a
huge list of blocker after our release when we'll come back on master.


Thanks,

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



-- 
Emilien Macchi

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

Re: [openstack-dev] [keystone] [nova] [glance] [oslo] webob 1.7

[Corey Bryant]

On Thu, Jan 19, 2017 at 9:50 PM, Corey Bryant 
wrote:

>
>
> On Thu, Jan 19, 2017 at 8:29 PM, Joshua Harlow 
> wrote:
>
>> Corey Bryant wrote:
>>
>>>
>>> Added [nova] and [oslo] to the subject.  This is also affecting nova and
>>> oslo.middleware.  I know Sean's initial response on the thread was that
>>> this shouldn't be a priority for ocata but we're completely blocked by
>>> it.  Would those teams be able to prioritize a fix for this?
>>>
>>>
>> Is this the issue for that https://github.com/Pylons/webob/issues/307 ?
>>
>>
> Yes, at least for glance that is part of the issue, the dropping of the
> http_method_probably_has_body check.
>
>
>> If so, then perhaps we need to comment and work together on that and
>> introduce a fix into webob? Would that be the correct path here? What
>> otherwise would be needed to 'prioritize a fix' for it?
>>
>>
> That doesn't appear to be a bug in webob from what I can see in the issue
> 307 discussion, just a change of behavior that various projects need to
> adapt to if they're going to support webob 1.7.x.
>
>
>
Debian just uploaded python-webob 1:1.6.2-2 to replace 1.7.0-1.  I didn't
know this was an option, so I apologize for the noise.  Thanks to those who
already started on patches.  I imagine they'll be needed in Pike.  We'll
get 1:1.6.2-2 synced over to zesty and that should solve our webob problems
in Ocata.

-- 
Regards,
Corey
__
OpenStack Development Mailing 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][glance] broken image functional test

[Steve Martinelli]

hey glancerinos,

it seems the OSC gate is broken, several patches are failing the same way:

testtools.matchers._impl.MismatchError: !=:
reference = '''\
qcow2
True
4
5
d35ba06a07654721bb730ea154b9c6e7
'''
actual= u'''\
qcow2
False
4
5
d35ba06a07654721bb730ea154b9c6e7
'''


In short, the test used to use python-glanceclient's image update method to
set the "is_public" attribute of an image to True, but now it's returning
False, here's the actual OSC test:
https://github.com/openstack/python-openstackclient/blob/master/openstackclient/tests/functional/image/v1/test_image.py#L55-L61

here's an example test result:
http://logs.openstack.org/54/423154/1/check/gate-osc-dsvm-functional-ubuntu-xenial/f23fbfa/testr_results.html.gz

did something break? at first glance (hehe), it seems this patch may be to
blame?
https://github.com/openstack/glance/commit/265659e8c34865331568b069fdb27ea272df4eaa

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

[openstack-dev] [tripleo][puppet] Preparations for Ocata release in RDO

[Alfredo Moralejo Alonso]

Hi,

In RDO we are preparing for the incoming Ocata release. This means
we'll create a new RDO Trunk builder "centos-ocata" in the next few
days (It will be ready for next week). This builder will get content
from stable/ocata branches of projects as they become available and
fallback to master for those not branched yet. The repos created by
this worker will be published under
https://trunk.rdoproject.org/centos7-ocata/ (which will not longer be
a link to https://trunk.rdoproject.org/centos7-master/).

According to the feedback received during the last release cycle, we
are changing the way we do the transition this time so that
repositories content will be more accurate to what is expected at any
point in the cycle. Repos under centos-master will allways follow
master branch and centos-ocata will get stable/ocata as soon as repos
get the branch created.

This has some implications from the upstream projects point of view:

- Projects using repositories under
https://trunk.rdoproject.org/centos7-ocata/ will start getting
packages for content delivered in stable/ocata branches instead of
master. Repos in https://trunk.rdoproject.org/centos7-master/ will
keep getting packages for content in master branch.
- Anyone currently pinning to a specific hash repo under
https://trunk.rdoproject.org/centos7-ocata/ should move it to use
https://trunk.rdoproject.org/centos7-master/ as soon as possible. Note
that pinning to a specific hash is not recommended practice.
- With current job definitions, link current-tripleo promoted by
upstream TripleoCI will promote repos with content from master
branches and not stable/ocata after creating the ocata builder. We
think this is not the desired situation during RC period and we must
keep promotion of current-tripleo link for stable/ocata until
cycle-trailing projects are tagged. This will require some changes in
both Tripleo-CI and RDO-CI, please let us know your thoughs so that we
can agree on the best way to implement this and start working on it.

Best regards,

Alfredo

__
OpenStack Development Mailing 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] [puppet] Nominating mkarpin for core for the Puppet OpenStack modules

[Tobias Urdin]

Even though I dont have a vote I would like to extend a lot of gratitude
to Mykyta Karpin for
always helping out!

Congratulations and well deserved!


On 01/19/2017 11:28 PM, Alex Schultz wrote:
> Hey Puppet Cores,
>
> I would like to nominate Mykyta Karpin as a Core reviewer for the
> Puppet OpenStack modules.  He has been providing quality patches and
> reviews for some time now and I believe he would be a good addition to
> the team.  His stats for the last 90 days can be viewed here[0]
>
> Please response with your +1 or any objections. If there are no
> objections by Jan 26, I will add him to the core list.
>
> Thanks,
> -Alex
>
> [0] http://stackalytics.com/report/contribution/puppet%20openstack-group/90
>
> __
> OpenStack Development Mailing 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-docs] [Docs] PTL Candidacy for Pike

[Alexandra Settle]

Hi everyone,

I am announcing my candidacy for the OpenStack manuals PTL position. 

Some of you may know me from the 2014 Paris summit where I cooed like a pigeon 
[1] in a panel discussion, but I hope that most of you will know me from my 
documentation work across OpenStack, specifically the OpenStack manuals project 
and OpenStack-Ansible contributions.

I have been an active contributor to OpenStack manuals since the beginning of 
2014, and have been a core member since early 2015. Over these last 3 years, I 
was privileged to be a part of the sprint team that authored the first edition 
of the OpenStack Architecture Design Guide [2] (and the subsequent swarm team 
that fixed it up), the team that converted the manuals from XML to RST, the 
specialty team that worked on the creation and curation of the Contributor 
Guide, and the release management team for Ocata. I also worked with the 
OpenStack Infra team to create the new Deployment Guides section [3] at 
docs.openstack.org.

I regularly work in different OpenStack projects. For example, I assisted the 
Swift team to curate the Swift Ops Runbook [4], and have been helping the 
OpenStack-Ansible team rework their documentation [5]. 

I am passionate about our documentation, our community, and our team’s 
involvement across OpenStack. OpenStack manuals was never organised and 
facilitated by a single person. Behind the scenes there are a great number of 
individuals who work hard to ensure our ship stays afloat. As PTL, I would like 
to continue this trend by:

1. Improving cross-project documentation liaison relationships
a. Over the course of the Pike release, I plan to focus on developing better 
relationships with the cross-project liaisons and PTL’s of individual projects. 
I would like to promote and encourage developers and operators to get more 
involved in the development of OpenStack manuals content. OpenStack manuals 
takes on the responsibility of documenting and maintaining guides that 
represent the projects and tools developers and operators are working so hard 
to build and maintain. This written representation of their work is equally as 
important as the output. 
2. Continuing with Lana’s bug-depletion legacy
a. I plan to achieve this by reporting on completed bugs on a weekly basis and 
encouraging other contributors to report and fix one bug per week. When Lana 
first became PTL, she vowed to attack our enormous (and continuously growing) 
bug list. I'd like to continue this work, and will strive to find innovative 
ways to reduce our technical debt.

If you would like to know more about how I will work to improve our community 
and the manuals, I’d love to chat with you more on IRC or via email.

Coo coo,

Alexandra Settle

IRC: asettle
Twitter: dewsday
Email: a.set...@outlook.com

[1] https://youtu.be/PtomtKeJ0tc?t=1783 
[2] 
http://docs.openstack.org/arch-design/introduction-how-this-book-was-written.html
 
[3] http://docs.openstack.org/project-deploy-guide/newton/
[4] http://docs.openstack.org/developer/swift/ops_runbook/index.html 
[5] 
https://blueprints.launchpad.net/openstack-ansible/+spec/osa-install-guide-overhaul
 

 

__
OpenStack Development Mailing 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] [cinder] dog command in Sheepdog is executable, not library

[Takashi Menjo]

Hi,

I've confirmed the commit "Mark the sheepdog driver as unsupported" [1].
Sorry for CI failure. The problem will be fixed by Sheepdog team soon.

I have an opinion about license.

AFAIU, except CI failure, the reason why the Sheepdog driver was marked
is that "dog", Sheepdog admin command line, is considered an external
*library* licensed under GPLv2.

However, "dog" is *executable*, not library.
The Sheepdog driver communicates with "dog" in inter-process manner.

So I think the driver does not violate the licensing requirements [2].
The paragraph including "external libraries" does not seem to be applied.

[1] https://review.openstack.org/419079
[2] https://governance.openstack.org/tc/reference/licensing.html

Best regards,
-- 
Takashi Menjo 





__
OpenStack Development Mailing 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] Order of n-api (placement) and n-sch upgrades for Ocata

[Eoghan Glynn]

> >> What are these issues? My original message was to highlight one
> >> particular deployment type which is completely independent of
> >> how things get packaged in the traditional sense of the word
> >> (rpms/deb/tar.gz).  Perhaps it's getting lost in terminology,
> >> but packaging the software in one way and how it's run can be two
> >> separate issues.  So what I'd like to know is how is that
> >> impacted by whatever ordering is necessary, and if there's anyway
> >> way not to explicitly have special cases that need to be handled
> >> by the end user when applying updates.  It seems like we all want
> >> similar things. I would like not to have to do anything different
> >> from the install for upgrade. Why can't apply configs, restart
> >> all services?  Or can I?  I seem to be getting mixed messages...
> >> 
> >> 
> > 
> > Sorry for being unclear on the issue. As Jay pointed out, if
> > nova-scheduler is upgraded before the placement service, the
> > nova-scheduler service will continue to start and take requests.
> > The problem is if the filter scheduler code is requesting a
> > microversion in the placement API which isn't available yet, in
> > particular this 1.4 microversion, then scheduling requests will
> > fail which to the end user means NoValidHost (the same as if we
> > don't have any compute nodes yet, or available).
> > 
> > So as Jay also pointed out, if placement and n-sch are upgraded
> > and restarted at the same time, the window for hitting this is
> > minimal. If deployment tooling is written to make sure to restart
> > the placement service *before* nova-scheduler, then there should be
> > no window for issues.
> > 
> 
> 
> Thanks all for providing insights. I'm trying to see a consensus here,
> and while I understand the concerns from Alex about the upgrade, I
> think it's okay for a deployer having a "controller" node (disclaimer:
> Nova doesn't have this concept, rather a list of components that are
> not compute nodes) to have a very quick downtime (I mean getting
> NoValidHosts if an user asks for an instance while the "controller" is
> upgraded).

Do we also need to be concerned about the placement API "warm-up" time?

i.e. if a placement-less newton deployment is upgraded to placement-ful
ocata, then would there surely be a short period during which placement
is able to respond to the incoming queries from the scheduler, but only
with incomplete information since all the computes haven't yet triggered
their first reporting cycle?

In that case, it wouldn't necessarily lead to a NoValidHost failure on a
instance boot request, but rather a potentially faulty placement decision,
being based on incomplete information. I mean "faulty" there in the sense
of not strictly following the configured scheduling strategy.

Is that a concern, or an acceptable short degradation of service?

Cheers,
Eoghan

> To be honest, Nova has never supported (yet) having rolling upgrades
> for services that are not computes. If you look at the upgrade devref,
> we ask for a maintenance window [1]. During that maintenance window,
> we say it's safer to upgrade "nova-conductor first and nova-api last"
> for coherence reasons but since that's during the maintenance window,
> we're not supposed to have user requests coming in.
> 
> So, to circle back with the original problem, I think having the
> nova-scheduler upgraded *before* placement is not a problem. If
> deployers don't want to implement an upgrade scenario where placement
> is upgraded before scheduler, that's fine. No need of extra work for
> deployers. That's just that *if* you implement that path, the
> scheduler could still get requests.
> 
> -Sylvain
> 
> [1]
> http://docs.openstack.org/developer/nova/upgrade.html#rolling-upgrade-process
> 
> 
> > --
> > 
> > Thanks,
> > 
> > Matt
> > 
> > __
> >
> > 
> OpenStack Development Mailing 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] [cinder] Can I use lvm thin provisioning in mitaka?

[Marco Marino]

Hi, I'm trying to use cinder with lvm thin provisioning. It works well and
I'd like to know if there is some reason lvm thin should be avoided in
mitaka release. I'm trying to use with
max_over_subscription_ratio = 1.0
so I don't have problems with over subscription.
I using thin provisioning because it is fast (I think). More precisely, my
use case is:

- create one bootable volume. This is a long operation because cinder
download the image from glance, qemu-img convert in raw format and then
"dd" copy the image in the volume.
- Create a snapshot of the bootable volume. Really fast and reliable
because the original volume is not used by any vm.
- Create a new volume from the snapshot. This is faster than create a new
bootable volume.

Is this use correct? Can I deploy in the production environment (mitaka -
centos 7)
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] [nova] Order of n-api (placement) and n-sch upgrades for Ocata

[Alex Xu]

2017-01-19 23:43 GMT+08:00 Sylvain Bauza :

>
>
> Le 19/01/2017 16:27, Matt Riedemann a écrit :
> > Sylvain and I were talking about how he's going to work placement
> > microversion requests into his filter scheduler patch [1]. He needs to
> > make requests to the placement API with microversion 1.4 [2] or later
> > for resource provider filtering on specific resource classes like VCPU
> > and MEMORY_MB.
> >
> > The question was what happens if microversion 1.4 isn't available in the
> > placement API, i.e. the nova-scheduler is running Ocata code now but the
> > placement service is running Newton still.
> >
> > Our rolling upgrades doc [3] says:
> >
> > "It is safest to start nova-conductor first and nova-api last."
> >
> > But since placement is bundled with n-api that would cause issues since
> > n-sch now depends on the n-api code.
> >
> > If you package the placement service separately from the nova-api
> > service then this is probably not an issue. You can still roll out n-api
> > last and restart it last (for control services), and just make sure that
> > placement is upgraded before nova-scheduler (we need to be clear about
> > that in [3]).
> >
> > But do we have any other issues if they are not packaged separately? Is
> > it possible to install the new code, but still only restart the
> > placement service before nova-api? I believe it is, but want to ask this
> > out loud.
> >
> > I think we're probably OK here but I wanted to ask this out loud and
> > make sure everyone is aware and can think about this as we're a week
> > from feature freeze. We also need to look into devstack/grenade because
> > I'm fairly certain that we upgrade n-sch *before* placement in a grenade
> > run which will make any issues here very obvious in [1].
> >
> > [1] https://review.openstack.org/#/c/417961/
> > [2]
> > http://docs.openstack.org/developer/nova/placement.html#
> filter-resource-providers-having-requested-resource-capacity
> >
> > [3]
> > http://docs.openstack.org/developer/nova/upgrade.html#
> rolling-upgrade-process
> >
> >
>
> I thought out loud in the nova channel at the following possibility :
> since we always ask to upgrade n-cpus *AFTER* upgrading our other
> services, we could imagine to allow the nova-scheduler gently accept to
> have a placement service be Newton *UNLESS* you have Ocata computes.
>
> On other technical words, the scheduler getting a response from the
> placement service is an hard requirement for Ocata. That said, if the
> response code is a 400 with a message saying that the schema is
> incorrect, it would be checking the max version of all the computes and
> then :
>  - either the max version is Newton and then call back the
> ComputeNodeList.get_all() for getting the list of nodes
>  - or, the max version is Ocata (at least one node is upgraded), and
> then we would throw a NoValidHosts
>

Emm...when you request a Microversion which didn't support by the service,
you will get 406 response. Then you will know the placement is old. Then
you needn't check the version of computes?


>
> That way, the upgrade path would be :
>  1/ upgrade your conductor
>  2/ upgrade all your other services but n-cpus (we could upgrade and
> restart n-sch before n-api, that would still work, or the contrary would
> be fine too)
>  3/ rolling upgrade your n-cpus
>
> I think we would keep then the existing upgrade path and we would still
> have the placement service be mandatory for Ocata.
>
> Thoughts ?
> -Sylvain
>
> __
> OpenStack Development Mailing 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] [charms] monitoring interface

[Brad Marshall]

On Thu, Jan 19, 2017 at 12:44:22PM +, Liam Young wrote:
> Thanks for looking into it. I think things should actually work out of the
> box as they are now. So,
> 
> Should add nagios checks for glance and cinder to the juju deployed nagios.
> (Taken from
> https://wiki.ubuntu.com/OpenStack/OpenStackCharms/ReleaseNotes1504#Monitoring
> ).
> 
> Ideally we would rename the nrpe-external-master interface to local-monitor
> (or add it as an additional interface) but that is not needed to get it up
> and running.

The problem we were seeing was the nrpe charm wasn't passing the default
checks across, there's been a bug floating around for a while - LP#1605733.

There is a fix in that bug report which we've tried out and it seems to
fix the issue, but I'm not sure if there's any other side effects.

Thanks,
Brad
-- 
Brad Marshall
Cloud Reliability Engineer
Bootstack Squad, Canonical

__
OpenStack Development Mailing 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] [puppet] Nominating mkarpin for core for the Puppet OpenStack modules

[Ivan Berezovskiy]

+1, well done!

2017-01-20 12:20 GMT+04:00 Denis Egorenko :

> +1
>
> 2017-01-20 4:10 GMT+04:00 Emilien Macchi :
>
>> On Thu, Jan 19, 2017 at 5:25 PM, Alex Schultz 
>> wrote:
>> > Hey Puppet Cores,
>> >
>> > I would like to nominate Mykyta Karpin as a Core reviewer for the
>> > Puppet OpenStack modules.  He has been providing quality patches and
>> > reviews for some time now and I believe he would be a good addition to
>> > the team.  His stats for the last 90 days can be viewed here[0]
>> >
>> > Please response with your +1 or any objections. If there are no
>> > objections by Jan 26, I will add him to the core list.
>>
>> +1, that's well deserved.
>> Thanks Mykyta for your contributions! Keep rocking :-)
>>
>> > Thanks,
>> > -Alex
>> >
>> > [0] http://stackalytics.com/report/contribution/puppet%20opensta
>> ck-group/90
>> >
>> > 
>> __
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe: openstack-dev-requ...@lists.op
>> enstack.org?subject:unsubscribe
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>> --
>> Emilien Macchi
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
>
> --
> Best Regards,
> Egorenko Denis,
> Senior Deployment Engineer
> Mirantis
>
> __
> OpenStack Development Mailing 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, Ivan Berezovskiy
MOS Puppet Team Lead
at Mirantis 

slack: iberezovskiy
skype: bouhforever
phone: + 7-960-343-42-46
__
OpenStack Development Mailing 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] Order of n-api (placement) and n-sch upgrades for Ocata

[Sylvain Bauza]

Le 19/01/2017 21:39, Matt Riedemann a écrit :
> On Thu, Jan 19, 2017 at 2:29 PM, Alex Schultz 
> wrote:
>> 
>> What are these issues? My original message was to highlight one 
>> particular deployment type which is completely independent of
>> how things get packaged in the traditional sense of the word 
>> (rpms/deb/tar.gz).  Perhaps it's getting lost in terminology,
>> but packaging the software in one way and how it's run can be two
>> separate issues.  So what I'd like to know is how is that
>> impacted by whatever ordering is necessary, and if there's anyway
>> way not to explicitly have special cases that need to be handled
>> by the end user when applying updates.  It seems like we all want
>> similar things. I would like not to have to do anything different
>> from the install for upgrade. Why can't apply configs, restart
>> all services?  Or can I?  I seem to be getting mixed messages...
>> 
>> 
> 
> Sorry for being unclear on the issue. As Jay pointed out, if 
> nova-scheduler is upgraded before the placement service, the 
> nova-scheduler service will continue to start and take requests.
> The problem is if the filter scheduler code is requesting a
> microversion in the placement API which isn't available yet, in
> particular this 1.4 microversion, then scheduling requests will
> fail which to the end user means NoValidHost (the same as if we
> don't have any compute nodes yet, or available).
> 
> So as Jay also pointed out, if placement and n-sch are upgraded
> and restarted at the same time, the window for hitting this is
> minimal. If deployment tooling is written to make sure to restart
> the placement service *before* nova-scheduler, then there should be
> no window for issues.
> 


Thanks all for providing insights. I'm trying to see a consensus here,
and while I understand the concerns from Alex about the upgrade, I
think it's okay for a deployer having a "controller" node (disclaimer:
Nova doesn't have this concept, rather a list of components that are
not compute nodes) to have a very quick downtime (I mean getting
NoValidHosts if an user asks for an instance while the "controller" is
upgraded).
To be honest, Nova has never supported (yet) having rolling upgrades
for services that are not computes. If you look at the upgrade devref,
we ask for a maintenance window [1]. During that maintenance window,
we say it's safer to upgrade "nova-conductor first and nova-api last"
for coherence reasons but since that's during the maintenance window,
we're not supposed to have user requests coming in.

So, to circle back with the original problem, I think having the
nova-scheduler upgraded *before* placement is not a problem. If
deployers don't want to implement an upgrade scenario where placement
is upgraded before scheduler, that's fine. No need of extra work for
deployers. That's just that *if* you implement that path, the
scheduler could still get requests.

-Sylvain

[1]
http://docs.openstack.org/developer/nova/upgrade.html#rolling-upgrade-process


> --
> 
> Thanks,
> 
> Matt
> 
> __
>
> 
OpenStack Development Mailing 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] [cinder]Can we run cinder-volume and cinder-backup on a same host?

[Dulko, Michal]

On Fri, 2017-01-20 at 14:15 +0900, Rikimaru Honjo wrote:
> Hi Cinder devs,
> 
> I have a question about cinder.
> Can I run cinder-volume and cinder-backup on a same host when I using
> iscsi backend?
> 
> I afraid that iscsi operations will be conflicted between cinder-
> volume and cinder-backup.
> In my understanding, iscsi operations are serialized for each
> individual process.
> But these could be raced between processes.
> 
> e.g.(Caution: This is just a forecast.)
> If cinder-backup execute "multipath -r" while cinder-volume is
> terminating connection,
> a multipath garbage will remain unexpectedly.

Hi,

Before Mitaka it was *required* to place cinder-volume and cinder-
backup on the same node. As both services shared same file lock
directory, it was safe. In fact cinder-backup simply imported cinder-
volume code.

Since Mitaka cinder-backup doesn't do any iSCSI operations directly and
attaches volumes by calling cinder-volume over RPC. This means that
it's possible to place cinder-backup on other node than cinder-volume,
but it's still totally safe to place them together.

If you're able to reproduce a scenario that fails these assumptions,
please file a bug report and we'll be happy to investigate and provide
a fix.

Thanks,
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] [nova] Do not recheck changes until 422709 is merged

[Sylvain Bauza]

Le 20/01/2017 04:16, Matt Riedemann a écrit :
> On 1/19/2017 5:09 PM, Matt Riedemann wrote:
>> On 1/19/2017 10:56 AM, Matt Riedemann wrote:
>>> The py35 unit test job is broken for Nova until this patch is merged:
>>>
>>> https://review.openstack.org/#/c/422709/
>>>
>>> So please hold off on the rechecks until that happens.
>>>
>>
>> We're good to go again for rechecks.
>>
> 
> Just a heads up that if you still see py35 unit test failures with a
> TypeError like this [1] then you need to rebase you patch.
> 
> [1]
> http://logs.openstack.org/37/410737/5/check/gate-nova-python35-db/4fec66c/console.html#_2017-01-20_01_56_21_021702
> 
> 

Just for understanding correctly the context, which merged change fixes
that, needing a rebase ?


__
OpenStack Development Mailing 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] [puppet] Nominating mkarpin for core for the Puppet OpenStack modules

[Denis Egorenko]

+1

2017-01-20 4:10 GMT+04:00 Emilien Macchi :

> On Thu, Jan 19, 2017 at 5:25 PM, Alex Schultz  wrote:
> > Hey Puppet Cores,
> >
> > I would like to nominate Mykyta Karpin as a Core reviewer for the
> > Puppet OpenStack modules.  He has been providing quality patches and
> > reviews for some time now and I believe he would be a good addition to
> > the team.  His stats for the last 90 days can be viewed here[0]
> >
> > Please response with your +1 or any objections. If there are no
> > objections by Jan 26, I will add him to the core list.
>
> +1, that's well deserved.
> Thanks Mykyta for your contributions! Keep rocking :-)
>
> > Thanks,
> > -Alex
> >
> > [0] http://stackalytics.com/report/contribution/puppet%
> 20openstack-group/90
> >
> > 
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
> unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> --
> Emilien Macchi
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Best Regards,
Egorenko Denis,
Senior Deployment Engineer
Mirantis
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev