Re: [openstack-dev] [ptl][release] Proposed changes for library releases

2018-10-11 Thread Trinh Nguyen 
+1 from Searchlight since we have only a small number of changes.

Thanks,

On Fri, Oct 12, 2018 at 5:07 AM Sean McGinnis  wrote:

> Libraries should be released early and often so their consumers can pick up
> merged changes, and issues with those changes can be identified close to
> when
> the change is made. To help with this, we are considering forcing at least
> one
> library release per milestone (if there are unreleased merged changes).
>
> Planned Changes
> ---
>
> The proposed change would be that for each cycle-with-intermediary library
> deliverable, if it was not released during that milestone timeframe, the
> release team would automatically generate a release request early in the
> week
> of the milestone deadline. For example, at Stein milestone 1, if the
> library
> was not released at all in the Stein cycle yet, we would trigger a release
> the
> week of the milestone. At Stein milestone 2, if the library was not
> released
> since milestone 1, we would trigger another release, etc.
>
> That autogenerated patch would be used as a base to communicate with the
> team:
> if a team knows it is not a good time to do a release for that library,
> someone
> from the team can -1 the patch to have it held, or update that patch with a
> different commit SHA where they think it would be better to release from.
> If
> there are no issues, ideally we would want a +1 from the PTL and/or release
> liaison to indicate approval, but we would also consider no negative
> feedback
> as an indicator that the automatically proposed patches without a -1 can
> all be
> approved on the Thursday milestone deadline.
>
> Frequently Asked Questions (we're guessing)
> ---
>
> Q: Our team likes to release libraries often. We don't want to wait for
> each
>milestone. Why are you ruining our lives?
> A: Teams are encouraged to request library releases regularly, and at any
> point
>in time that makes sense. The automatic release patches only serve as a
>safeguard to guarantee that library changes are released and consumed
> early
>and often, in case no release is actively requested.
>
> Q: Our library has no change, that's why we are not requesting changes.
> Why are
>you forcing meaningless releases? You need a hobby.
> A: If the library has not had any change merged since the previous tag, we
>would not generate a release patch for it.
>
> Q: My team is responsible for this library. I don't feel comfortable
> having an
>autogenerated patch grab a random commit to release. Can we opt out of
> this?
> A: The team can do their own releases when they are ready. If we generate a
>release patch and you don't think you are ready, just -1 the patch. Then
>when you are ready, you can update the patch with the new commit to use.
>
>
> Please ask questions or raise concerns here and/or in the
> #openstack-release
> channel.
>
> Thanks!
>
> The Release Management Team
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>


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

Re: [openstack-dev] [tc] assigning new liaisons to projects

2018-10-11 Thread Trinh Nguyen 
Thank Doug for coordinating this,

Is there any way for us to update the health of the Searchlight project to
reflect the current state? Right now the status is not good to attract new
contributors.

Bests,

On Fri, Oct 12, 2018 at 6:50 AM Doug Hellmann  wrote:

> Doug Hellmann  writes:
>
> > TC members,
> >
> > Since we are starting a new term, and have several new members, we need
> > to decide how we want to rotate the liaisons attached to each our
> > project teams, SIGs, and working groups [1].
> >
> > Last term we went through a period of volunteer sign-up and then I
> > randomly assigned folks to slots to fill out the roster evenly. During
> > the retrospective we talked a bit about how to ensure we had an
> > objective perspective for each team by not having PTLs sign up for their
> > own teams, but I don't think we settled on that as a hard rule.
> >
> > I think the easiest and fairest (to new members) way to manage the list
> > will be to wipe it and follow the same process we did last time. If you
> > agree, I will update the page this week and we can start collecting
> > volunteers over the next week or so.
> >
> > Doug
> >
> > [1] https://wiki.openstack.org/wiki/OpenStack_health_tracker
> >
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> I have cleared out the old assignments. Please go over and edit the wiki
> page to add yourself to the teams you want to volunteer for. Remember
> that each member needs to sign up for exactly 10 teams. If you don't
> volunteer for 10, we'll use the script to make random assignments for
> the remaining slots.
>
> 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
>


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

Re: [openstack-dev] [tc] assigning new liaisons to projects

2018-10-11 Thread Doug Hellmann 
Doug Hellmann  writes:

> TC members,
>
> Since we are starting a new term, and have several new members, we need
> to decide how we want to rotate the liaisons attached to each our
> project teams, SIGs, and working groups [1].
>
> Last term we went through a period of volunteer sign-up and then I
> randomly assigned folks to slots to fill out the roster evenly. During
> the retrospective we talked a bit about how to ensure we had an
> objective perspective for each team by not having PTLs sign up for their
> own teams, but I don't think we settled on that as a hard rule.
>
> I think the easiest and fairest (to new members) way to manage the list
> will be to wipe it and follow the same process we did last time. If you
> agree, I will update the page this week and we can start collecting
> volunteers over the next week or so.
>
> Doug
>
> [1] https://wiki.openstack.org/wiki/OpenStack_health_tracker
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

I have cleared out the old assignments. Please go over and edit the wiki
page to add yourself to the teams you want to volunteer for. Remember
that each member needs to sign up for exactly 10 teams. If you don't
volunteer for 10, we'll use the script to make random assignments for
the remaining slots.

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-dev] [ptl][release] Proposed changes for library releases

2018-10-11 Thread Sean McGinnis 
Libraries should be released early and often so their consumers can pick up
merged changes, and issues with those changes can be identified close to when
the change is made. To help with this, we are considering forcing at least one
library release per milestone (if there are unreleased merged changes).

Planned Changes
---

The proposed change would be that for each cycle-with-intermediary library
deliverable, if it was not released during that milestone timeframe, the
release team would automatically generate a release request early in the week
of the milestone deadline. For example, at Stein milestone 1, if the library
was not released at all in the Stein cycle yet, we would trigger a release the
week of the milestone. At Stein milestone 2, if the library was not released
since milestone 1, we would trigger another release, etc.

That autogenerated patch would be used as a base to communicate with the team:
if a team knows it is not a good time to do a release for that library, someone
from the team can -1 the patch to have it held, or update that patch with a
different commit SHA where they think it would be better to release from. If
there are no issues, ideally we would want a +1 from the PTL and/or release
liaison to indicate approval, but we would also consider no negative feedback
as an indicator that the automatically proposed patches without a -1 can all be
approved on the Thursday milestone deadline.

Frequently Asked Questions (we're guessing)
---

Q: Our team likes to release libraries often. We don't want to wait for each
   milestone. Why are you ruining our lives?
A: Teams are encouraged to request library releases regularly, and at any point
   in time that makes sense. The automatic release patches only serve as a
   safeguard to guarantee that library changes are released and consumed early
   and often, in case no release is actively requested.

Q: Our library has no change, that's why we are not requesting changes. Why are
   you forcing meaningless releases? You need a hobby.
A: If the library has not had any change merged since the previous tag, we
   would not generate a release patch for it.

Q: My team is responsible for this library. I don't feel comfortable having an
   autogenerated patch grab a random commit to release. Can we opt out of this?
A: The team can do their own releases when they are ready. If we generate a
   release patch and you don't think you are ready, just -1 the patch. Then
   when you are ready, you can update the patch with the new commit to use.


Please ask questions or raise concerns here and/or in the #openstack-release
channel.

Thanks!

The Release Management Team

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

[openstack-dev] [oslo] Config Validator

2018-10-11 Thread Ben Nemec 

Hi,

We recently merged a new feature to oslo.config and it was suggested 
that I publicize it since it addresses a longstanding pain point. It's a 
validator tool[1] that will warn or error on any entries in a config 
file that aren't defined in the service or are deprecated.


Previously this was difficult to do accurately because config opts are 
registered at runtime and you don't know for sure when all of the opts 
are present. This tool makes use of the less recently added 
machine-readable sample config[2], which should contain all of the 
available opts for a service. If any are missing, that is a bug and 
should be addressed in the service anyway. This is the same data used to 
generate sample config files and those should have all of the possible 
opts listed.


The one limitation I'm aware of at this point is that dynamic groups 
aren't handled, so options in a dynamic group will be reported as 
missing even though they are recognized by the service. This should be 
solvable, but for the moment it is a limitation to keep in mind.


So if this is something you were interested in, please try it out and 
let us know how it works for you. The latest release of oslo.config on 
pypi should have this tool, and since it doesn't necessarily have to be 
run on the live system you can install the bleeding edge oslo.config 
somewhere else and just generate the machine readable sample config from 
the production system. That functionality has been in oslo.config for a 
few cycles now so it's more likely to be available.


Thanks.

-Ben

1: https://docs.openstack.org/oslo.config/latest/cli/validator.html
2: 
https://docs.openstack.org/oslo.config/latest/cli/generator.html#machine-readable-configs


__
OpenStack Development Mailing 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][tc] add service discovery, proxysql, vault, fabio and FQDN endpoints

2018-10-11 Thread Fox, Kevin M 
My understanding is it is still safeish to use when you deal with it right. it 
causes a transaction abort if the race condition ever hits, and you can keep 
retrying until your commit makes it. So, there are two issues here:
1. its a more rare kind of abort, so unless you are testing and retrying, it 
can cause operations to fail in a way the user might notice needlessly. This is 
bad. It should be tested for in the gate.
2. in highly contended systems, it can be a performance issue. This is less bad 
then #1. For certain codes, it may never be a problem.

Thanks,
Kevin

From: Zane Bitter [zbit...@redhat.com]
Sent: Thursday, October 11, 2018 10:08 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [kolla][tc] add service discovery, proxysql, 
vault, fabio and FQDN endpoints

On 10/10/18 1:35 PM, Jay Pipes wrote:
> +tc topic
>
> On 10/10/2018 11:49 AM, Fox, Kevin M wrote:
>> Sorry. Couldn't quite think of the name. I was meaning, openstack
>> project tags.
>
> I think having a tag that indicates the project is no longer using
> SELECT FOR UPDATE (and thus is safe to use multi-writer Galera) is an
> excellent idea, Kevin. ++

I would support such a tag, especially if it came with detailed
instructions on how to audit your code to make sure you are not doing
this with sqlalchemy. (Bonus points for a flake8 plugin that can be
enabled in the gate.)

(One question for clarification: is this actually _required_ to use
multi-writer Galera? My previous recollection was that it was possible,
but inefficient, to use SELECT FOR UPDATE safely as long as you wrote a
lot of boilerplate to restart the transaction if it failed.)

> -jay
>
>> 
>> From: Jay Pipes [jaypi...@gmail.com]
>> Sent: Tuesday, October 09, 2018 12:22 PM
>> To: openstack-dev@lists.openstack.org
>> Subject: Re: [openstack-dev] [kolla] add service discovery, proxysql,
>> vault, fabio and FQDN endpoints
>>
>> On 10/09/2018 03:10 PM, Fox, Kevin M wrote:
>>> Oh, this does raise an interesting question... Should such
>>> information be reported by the projects up to users through labels?
>>> Something like, "percona_multimaster=safe" Its really difficult for
>>> folks to know which projects can and can not be used that way currently.
>>
>> Are you referring to k8s labels/selectors? or are you referring to
>> project tags (you know, part of that whole Big Tent thing...)?
>>
>> -jay
>>
>> __
>>
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>> __
>>
>> OpenStack Development Mailing 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 Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tripleo][ci] Having more that one queue for gate pipeline at tripleo

2018-10-11 Thread Clark Boylan 
On Thu, Oct 11, 2018, at 7:17 AM, Ben Nemec wrote:
> 
> 
> On 10/11/18 8:53 AM, Felix Enrique Llorente Pastora wrote:
> > So for example, I don't see why changes at tripleo-quickstart can be 
> > reset if tripleo-ui fails, this is the kind of thing that maybe can be 
> > optimize.
> 
> Because if two incompatible changes are proposed to tripleo-quickstart 
> and tripleo-ui and both end up in parallel gate queues at the same time, 
> it's possible both queues could get wedged. Quickstart and the UI are 
> not completely independent projects. Quickstart has roles for deploying 
> the UI, which means there is a connection there.
> 
> I think the only way you could have independent gate queues is if you 
> had two disjoint sets of projects that could be gated without any use of 
> projects from the other set. I don't think it's possible to divide 
> TripleO in that way, but if I'm wrong then maybe you could do multiple 
> queues.

To follow up on this the Gate pipeline queue that your projects belong to are 
how you indicate to Zuul that there is coupling between these projects. Having 
things set up in this way allows you to ensure (through the Gate and Zuul's 
speculative future states) that a change to one project in the queue can't 
break another because they are tested together.

If your concern is "time to merge" splitting queues won't help all that much 
unless you put all of the unreliable broken code with broken tests in one queue 
and have the reliable code in another queue. Zuul tests everything in parallel 
within a queue. This means that if your code base and its tests are reliable 
you can merge 20 changes all at once and the time to merge for all 20 changes 
is the same as a single change. Problems arise when tests fail and these future 
states have to be updated and retested. This will affect one or many queues.

The fix here is to work on making reliable test jobs so that you can merge all 
20 changes in the span of time it takes to merge a single change.  This isn't 
necessarily easy, but helps you merge more code and be confident it works too.

Clark

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

Re: [openstack-dev] [kolla][tc] add service discovery, proxysql, vault, fabio and FQDN endpoints

2018-10-11 Thread Zane Bitter 

On 10/10/18 1:35 PM, Jay Pipes wrote:

+tc topic

On 10/10/2018 11:49 AM, Fox, Kevin M wrote:
Sorry. Couldn't quite think of the name. I was meaning, openstack 
project tags.


I think having a tag that indicates the project is no longer using 
SELECT FOR UPDATE (and thus is safe to use multi-writer Galera) is an 
excellent idea, Kevin. ++


I would support such a tag, especially if it came with detailed 
instructions on how to audit your code to make sure you are not doing 
this with sqlalchemy. (Bonus points for a flake8 plugin that can be 
enabled in the gate.)


(One question for clarification: is this actually _required_ to use 
multi-writer Galera? My previous recollection was that it was possible, 
but inefficient, to use SELECT FOR UPDATE safely as long as you wrote a 
lot of boilerplate to restart the transaction if it failed.)



-jay



From: Jay Pipes [jaypi...@gmail.com]
Sent: Tuesday, October 09, 2018 12:22 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [kolla] add service discovery, proxysql, 
vault, fabio and FQDN endpoints


On 10/09/2018 03:10 PM, Fox, Kevin M wrote:
Oh, this does raise an interesting question... Should such 
information be reported by the projects up to users through labels? 
Something like, "percona_multimaster=safe" Its really difficult for 
folks to know which projects can and can not be used that way currently.


Are you referring to k8s labels/selectors? or are you referring to
project tags (you know, part of that whole Big Tent thing...)?

-jay

__ 


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

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

__ 


OpenStack Development Mailing 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] [goals][python3][telemetry][barbican][monasca][neutron] having a gerrit admin approve the remaining zuul job settings import patches

2018-10-11 Thread Doug Hellmann 
Doug Hellmann  writes:

> We have about 17 remaining patches to import zuul job settings into a
> few repositories. Those are mostly in stable branches and the jobs are
> failing in ways that may take us a long time to fix.
>
> Rather than waiting for those, Andreas and I are proposing that we have
> someone from the infra team approve them, bypassing the test jobs. That
> will allow us to complete the cleanup work in the project-config
> repository, and will not leave the affected repositories in a state that
> is any more (or less) broken than they are today.
>
> If you have any objections to the plan, please speak up quickly. I
> would like to try to proceed before the end of the week.
>
> Doug
>
> +--+-+---++--+-+---+---+
> | Subject  | Repo 
>| Team  | Tests  | Workflow | URL | 
> Branch| Owner |
> +--+-+---++--+-+---+---+
> | import zuul job settings from project-config | openstack/aodh   
>| Telemetry | FAILED | NEW  | https://review.openstack.org/598648 | 
> stable/ocata  | Doug Hellmann |
> | import zuul job settings from project-config | openstack/barbican   
>| barbican  | FAILED | REVIEWED | https://review.openstack.org/599659 | 
> stable/queens | Doug Hellmann |
> | import zuul job settings from project-config | openstack/barbican   
>| barbican  | FAILED | REVIEWED | https://review.openstack.org/599661 | 
> stable/rocky  | Doug Hellmann |
> | import zuul job settings from project-config | openstack/castellan-ui   
>| barbican  | FAILED | NEW  | https://review.openstack.org/599649 | 
> master| Doug Hellmann |
> | import zuul job settings from project-config | 
> openstack/ceilometermiddleware  | Telemetry | FAILED | APPROVED | 
> https://review.openstack.org/598634 | master| Doug Hellmann |
> | import zuul job settings from project-config | 
> openstack/ceilometermiddleware  | Telemetry | FAILED | APPROVED | 
> https://review.openstack.org/598655 | stable/pike   | Doug Hellmann |
> | import zuul job settings from project-config | 
> openstack/ceilometermiddleware  | Telemetry | PASS   | NEW  | 
> https://review.openstack.org/598661 | stable/queens | Doug Hellmann |
> | import zuul job settings from project-config | 
> openstack/ceilometermiddleware  | Telemetry | FAILED | NEW  | 
> https://review.openstack.org/598667 | stable/rocky  | Doug Hellmann |
> | import zuul job settings from project-config | openstack/monasca-analytics  
>| monasca   | FAILED | REVIEWED | https://review.openstack.org/595658 | 
> master| Doug Hellmann |
> | import zuul job settings from project-config | openstack/networking-midonet 
>| neutron   | PASS   | REVIEWED | https://review.openstack.org/597937 | 
> stable/queens | Doug Hellmann |
> | import zuul job settings from project-config | openstack/networking-sfc 
>| neutron   | FAILED | NEW  | https://review.openstack.org/597913 | 
> stable/ocata  | Doug Hellmann |
> | import zuul job settings from project-config | openstack/networking-sfc 
>| neutron   | FAILED | NEW  | https://review.openstack.org/597925 | 
> stable/pike   | Doug Hellmann |
> | import zuul job settings from project-config | openstack/python-aodhclient  
>| Telemetry | FAILED | NEW  | https://review.openstack.org/598652 | 
> stable/ocata  | Doug Hellmann |
> | import zuul job settings from project-config | openstack/python-aodhclient  
>| Telemetry | FAILED | NEW  | https://review.openstack.org/598657 | 
> stable/pike   | Doug Hellmann |
> | import zuul job settings from project-config | openstack/python-aodhclient  
>| Telemetry | FAILED | APPROVED | https://review.openstack.org/598669 | 
> stable/rocky  | Doug Hellmann |
> | import zuul job settings from project-config | 
> openstack/python-barbicanclient | barbican  | FAILED | NEW  | 
> https://review.openstack.org/599656 | stable/ocata  | Doug Hellmann |
> | import zuul job settings from project-config | 
> openstack/python-barbicanclient | barbican  | FAILED | NEW  | 
> https://review.openstack.org/599658 | stable/pike   | Doug Hellmann |
> +--+-+---++--+-+---+---+

Clark went ahead and merged all of these today. We have 3 clean-up
patches in project-config to approve now, and then the zuul migration
phase of the goal is completed.

Thank you, Clark, Andreas, and everyone who worked on these patches!

Doug

[openstack-dev] [tripleo] PTL out of office

2018-10-11 Thread Juan Antonio Osorio Robles 
Hi all!

I'll be out starting from Oct 15th, coming back on Oct 19th.]
The upstream meeting will be led by Alex Schultz (mwhahaha).

Best Regards


__
OpenStack Development Mailing 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] [kuryr-kubernetes] Kuryr vPTG

2018-10-11 Thread Daniel Mellado 
Hi Kuryrs!

As I promised in my earlier email, I'd like to organize a virtual team
gathering to gather around and sync for the upcoming and next release.

I've put up an etherpad [1] for gathering topics for the sessions, which
will be open until October 22nd, where I'll put up a tentative schedule
for this.

Thanks and looking forward to see you!

[1] https://etherpad.openstack.org/p/kuryr-vtg-stein


0x13DDF774E05F5B85.asc
Description: application/pgp-keys


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

[openstack-dev] [kuryr-kubernetes] PTL out for two weeks

2018-10-11 Thread Daniel Mellado 
Hi all!

I'll be out for two weeks, coming back on Oct 30th. I won't cancel the
upstream meeting, which will be led by apuimedo in the meanwhile.

I also do plan to organize a vPTG, around my return date, so stay tuned
for an email with a document for topics.

See you in some days!

Best!

Daniel



0x13DDF774E05F5B85.asc
Description: application/pgp-keys


0x13DDF774E05F5B85.asc
Description: application/pgp-keys


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

Re: [openstack-dev] [python3] Enabling py37 unit tests

2018-10-11 Thread Andreas Jaeger 
On 10/10/2018 23.10, Jeremy Stanley wrote:
> I might have only pointed this out on IRC so far, but the
> expectation is that testing 3.5 and 3.6 at the same time was merely
> transitional since official OpenStack projects should be moving
> their testing from Ubuntu Xenial (which provides 3.5) to Ubuntu
> Bionic (which provides 3.6 and, now, 3.7 as well) during the Stein
> cycle and so will drop 3.5 testing on master in the process.

Agreed, this needs some larger communication and explanation on what to do,

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] [Openstack-operators] [SIGS] Ops Tools SIG

2018-10-11 Thread Miguel Angel Ajo Pelayo 
Adding the mailing lists back to your reply, thank you :)

I guess that +melvin.hills...@huawei.com  can
help us a little bit organizing the SIG,
but I guess the first thing would be collecting a list of tools which could
be published
under the umbrella of the SIG, starting by the ones already in Osops.

Publishing documentation for those tools, and the catalog under
docs.openstack.org
is possibly the next step (or a parallel step).


On Wed, Oct 10, 2018 at 4:43 PM Rob McAllister  wrote:

> Hi Miguel,
>
> I would love to join this. What do I need to do?
>
> Sent from my iPhone
>
> On Oct 9, 2018, at 03:17, Miguel Angel Ajo Pelayo 
> wrote:
>
> Hello
>
> Yesterday, during the Oslo meeting we discussed [6] the possibility of
> creating a new Special Interest Group [1][2] to provide home and release
> means for operator related tools [3] [4] [5]
>
> I continued the discussion with M.Hillsman later, and he made me aware
> of the operator working group and mailing list, which existed even before
> the SIGs.
>
> I believe it could be a very good idea, to give life and more
> visibility to all those very useful tools (for example, I didn't know some
> of them existed ...).
>
>Give this, I have two questions:
>
>1) Do you know or more tools which could find home under an Ops Tools
> SIG umbrella?
>
>2) Do you want to join us?
>
>
> Best regards and have a great day.
>
>
> [1] https://governance.openstack.org/sigs/
> [2] http://git.openstack.org/cgit/openstack/governance-sigs/tree/sigs.yaml
> [3] https://wiki.openstack.org/wiki/Osops
> [4] http://git.openstack.org/cgit/openstack/ospurge/tree/
> [5] http://git.openstack.org/cgit/openstack/os-log-merger/tree/
> [6]
> http://eavesdrop.openstack.org/meetings/oslo/2018/oslo.2018-10-08-15.00.log.html#l-130
>
>
>
> --
> Miguel Ángel Ajo
> OSP / Networking DFG, OVN Squad Engineering
>
> ___
> OpenStack-operators mailing list
> openstack-operat...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>

-- 
Miguel Ángel Ajo
OSP / Networking DFG, OVN Squad Engineering
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tripleo][ci] Having more that one queue for gate pipeline at tripleo

2018-10-11 Thread Ben Nemec 



On 10/11/18 8:53 AM, Felix Enrique Llorente Pastora wrote:
So for example, I don't see why changes at tripleo-quickstart can be 
reset if tripleo-ui fails, this is the kind of thing that maybe can be 
optimize.


Because if two incompatible changes are proposed to tripleo-quickstart 
and tripleo-ui and both end up in parallel gate queues at the same time, 
it's possible both queues could get wedged. Quickstart and the UI are 
not completely independent projects. Quickstart has roles for deploying 
the UI, which means there is a connection there.


I think the only way you could have independent gate queues is if you 
had two disjoint sets of projects that could be gated without any use of 
projects from the other set. I don't think it's possible to divide 
TripleO in that way, but if I'm wrong then maybe you could do multiple 
queues.




On Thu, Oct 11, 2018 at 1:17 PM Emilien Macchi > wrote:




On Thu, Oct 11, 2018 at 10:01 AM Felix Enrique Llorente Pastora
mailto:ellor...@redhat.com>> wrote:

Hello there,

    After suffering a lot from zuul's tripleo gate piepeline
queue reseting after failures on patches I have ask myself what
would happend if we have more than one queue for gating tripleo.

    After a quick read here
https://zuul-ci.org/docs/zuul/user/gating.html, I have found the
following:

"If changes with cross-project dependencies do not share a
change queue then Zuul is unable to enqueue them together, and
the first will be required to merge before the second is enqueued."

    So it make sense to share zuul queue, but maybe only one
queue for all tripleo projects is too  much, for example sharing
queue between tripleo-ui and tripleo-quickstart, maybe we need
for example to queues for product stuff and one for CI, so
product does not get resetted if CI fails in a patch.

    What do you think ?

Probably a wrong example, as TripleO UI gate is using CI jobs
running tripleo-quickstart scenarios.
We could create more queues for projects which are really
independent from each other but we need to be very careful about it.
-- 
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



--
Quique Llorente

Openstack TripleO CI

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



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

Re: [openstack-dev] [tripleo][ci] Having more that one queue for gate pipeline at tripleo

2018-10-11 Thread Felix Enrique Llorente Pastora 
So for example, I don't see why changes at tripleo-quickstart can be reset
if tripleo-ui fails, this is the kind of thing that maybe can be optimize.

On Thu, Oct 11, 2018 at 1:17 PM Emilien Macchi  wrote:

>
>
> On Thu, Oct 11, 2018 at 10:01 AM Felix Enrique Llorente Pastora <
> ellor...@redhat.com> wrote:
>
>> Hello there,
>>
>>After suffering a lot from zuul's tripleo gate piepeline queue
>> reseting after failures on patches I have ask myself what would happend if
>> we have more than one queue for gating tripleo.
>>
>>After a quick read here https://zuul-ci.org/docs/zuul/user/gating.html,
>> I have found the following:
>>
>> "If changes with cross-project dependencies do not share a change queue
>> then Zuul is unable to enqueue them together, and the first will be
>> required to merge before the second is enqueued."
>>
>>So it make sense to share zuul queue, but maybe only one queue for all
>> tripleo projects is too  much, for example sharing queue between tripleo-ui
>> and tripleo-quickstart, maybe we need for example to queues for product
>> stuff and one for CI, so product does not get resetted if CI fails in a
>> patch.
>>
>>What do you think ?
>>
>
> Probably a wrong example, as TripleO UI gate is using CI jobs running
> tripleo-quickstart scenarios.
> We could create more queues for projects which are really independent from
> each other but we need to be very careful about it.
> --
> 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
>


-- 
Quique Llorente

Openstack TripleO CI
__
OpenStack Development Mailing 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][cinder][glance][osc][sdk] Image Encryption for OpenStack (proposal)

2018-10-11 Thread Josephine Seifert 
Am 08.10.2018 um 17:16 schrieb Markus Hentsch:
> Dear OpenStack developers,
>
> as you suggested, we have written individual specs for Nova [1] and
> Cinder [2] so far and will write another spec for Glance soon. We'd
> appreciate any feedback and reviews on the specs :)
>
> Thank you in advance,
> Markus Hentsch
>
> [1] https://review.openstack.org/#/c/608696/
> [2] https://review.openstack.org/#/c/608663/
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

The spec for Glance is also on gerrit now:

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

__
OpenStack Development Mailing 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] [python3] Enabling py37 unit tests

2018-10-11 Thread Corey Bryant 
On Wed, Oct 10, 2018 at 7:36 PM Goutham Pacha Ravi 
wrote:

> On Wed, Oct 10, 2018 at 2:10 PM Jeremy Stanley  wrote:
> >
> > On 2018-10-10 16:00:40 -0500 (-0500), Sean McGinnis wrote:
> > [...]
> > > I would rather see us testing 3.5 and 3.7 versus 3.5, 3.6, and
> > > 3.7.
> > [...]
> >
> > I might have only pointed this out on IRC so far, but the
> > expectation is that testing 3.5 and 3.6 at the same time was merely
> > transitional since official OpenStack projects should be moving
> > their testing from Ubuntu Xenial (which provides 3.5) to Ubuntu
> > Bionic (which provides 3.6 and, now, 3.7 as well) during the Stein
> > cycle and so will drop 3.5 testing on master in the process.
>
> ++ on switching python3.5 jobs to testing with python3.7 on Bionic.
> python3.5 wasn't supported on all distros [1][2][3][4][5]. Xenial had it,
> so it was nice to test with it when developing Queens and Rocky.
>
>
> Thanks Corey for starting this effort. I proposed changes to
> manila repos to use your template [1] [2], but the interpreter's not
> being installed,
> do you need to make any bindep changes to enable the "universe" ppa and
> install
> python3.7 and python3.7-dev?
>
>
Great, thanks for doing that! I'll look into what's needed to get python3.7
installed by the CI job.

Corey


> [1] OpenSuse https://software.opensuse.org/package/python3
> [2] Ubuntu https://packages.ubuntu.com/search?keywords=python3
> [3] Fedora https://apps.fedoraproject.org/packages/python3
> [4] Arch https://www.archlinux.org/packages/extra/x86_64/python/
> [5] Gentoo https://wiki.gentoo.org/wiki/Project:Python/Implementations
> [6] manila https://review.openstack.org/#/c/609558
> [7] python-manilaclient https://review.openstack.org/609557
>
> --
> Goutham
>
> > --
> > Jeremy Stanley
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [tc] biweekly vs monthly meetings

2018-10-11 Thread Mohammed Naser 
Hi everyone:

We've discussed bringing back meetings back to the TC and there's
different opinions on having biweekly vs monthly meetings.  Therefore,
I have added a patch similar to Doug's that instead lists biweekly
meetings instead of monthly meetings.

I would really appreciate if other community members could step vote
on what they feel would be best.  The agenda of those meetings would
be published in advance, topics could be requested from
chair/vice-chairs in advance and the notes would be available for the
community to consume, which should be easier to parse.

Besides the community, I'd invite TC members to vote on the change
that they prefer! :)

- Weekly: https://review.openstack.org/#/c/609562/
- Monthly: https://review.openstack.org/#/c/608751/

Thank you!
Mohammed

-- 
Mohammed Naser — vexxhost
-
D. 514-316-8872
D. 800-910-1726 ext. 200
E. mna...@vexxhost.com
W. http://vexxhost.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] [nova] API updates week 18-41

2018-10-11 Thread Ghanshyam Mann 
Hi All, 

Please find the Nova API highlights of this week. 

Weekly Office Hour: 
=== 

What we discussed this week: 
- Discussed on api cleanup spec. 

- Discussed api extensions work and pending things on this work. Proposed all 
the pending item for this BP. 

- Discussed on 2 new bugs which needs more log for further debugging. added bug 
comments. 

Planned Features : 
== 
Below are the API related features for Stein. Ref - 
https://etherpad.openstack.org/p/stein-nova-subteam-tracking (feel free to add 
API item there if you are working or found any). NOTE: sequence order are not 
the priority, they are listed as per their start date.  

1. API Extensions merge work 
- https://blueprints.launchpad.net/nova/+spec/api-extensions-merge-stein 
- 
https://review.openstack.org/#/q/project:openstack/nova+branch:master+topic:bp/api-extensions-merge-stein+status:open
- Weekly Progress: Pushed all the remaining patches. This is in runway also.

2. Handling a down cell 
- https://blueprints.launchpad.net/nova/+spec/handling-down-cell 
- 
https://review.openstack.org/#/q/topic:bp/handling-down-cell+(status:open+OR+status:merged)
 
- Weekly Progress: No progress. Need to open for stein 

3. Servers Ips non-unique network names : 
- 
https://blueprints.launchpad.net/nova/+spec/servers-ips-non-unique-network-names
 
- Spec Merged 
- 
https://review.openstack.org/#/q/topic:bp/servers-ips-non-unique-network-names+(status:open+OR+status:merged)
 
- Weekly Progress: No progress. I will push code after API extensions work is 
merged. 

4. Volume multiattach enhancements: 
- https://blueprints.launchpad.net/nova/+spec/volume-multiattach-enhancements 
- 
https://review.openstack.org/#/q/topic:bp/volume-multiattach-enhancements+(status:open+OR+status:merged)
 
- Weekly Progress: No progress. 

5. Boot instance specific storage backend
- 
https://blueprints.launchpad.net/nova/+spec/boot-instance-specific-storage-backend
 - 
https://review.openstack.org/#/q/topic:bp/boot-instance-specific-storage-backend+(status:open+OR+status:merged)
- Weekly Progress: Code is up and it is in runway. I am adding this in my 
tomorrow review list. 

6. Add API ref guideline for body text (takashin)
 - https://review.openstack.org/#/c/605628/
- Weekly Progress: patch is up for review. I have reviewed it to map it in more 
structural way.

Specs: 
7. Detach and attach boot volumes
 - 
https://review.openstack.org/#/q/topic:bp/detach-boot-volume+(status:open+OR+status:merged)
- Weekly Progress:  under review. Kevin has updated the spec with review 
comment fix. 

8. Nova API policy updates
https://blueprints.launchpad.net/nova/+spec/granular-api-policy 
Spec: https://review.openstack.org/#/c/547850/
- Weekly Progress: No progress in this. first concentrating on its dependency 
on 'consistent policy name' - https://review.openstack.org/#/c/606214/

9. Nova API cleanup
https://blueprints.launchpad.net/nova/+spec/api-consistency-cleanup 
Spec: https://review.openstack.org/#/c/603969/ 
- Weekly Progress: No progress on this. I am thinking to keep it open till T 
cycle and we keep adding more and more API cleanup in this and then discuss 
that what all we can fix or not. This way we can avoid the re-iterate of API 
cleanup fixes. Obviously we cannot find all API cleanup till T but it is good 
to cover most of them together. Thoughts ? 

10. Support deleting data volume when destroy instance(Brin Zhang)
- https://review.openstack.org/#/c/580336/
- Weekly Progress: No Progress. 

Bugs: 
 
This week Bug Progress: 
https://etherpad.openstack.org/p/nova-api-weekly-bug-report 

Critical: 0->0 
High importance: 1->2 
By Status: 
New: 1->4
Confirmed/Triage: 30-> 32 
In-progress: 31->35 
Incomplete: 3->3
= 
Total: 65->74 

NOTE- There might be some bug which are not tagged as 'api' or 'api-ref', those 
are not in above list. Tag such bugs so that we can keep our eyes. 

-gmann






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

Re: [openstack-dev] [api] Open API 3.0 for OpenStack API

2018-10-11 Thread Gilles Dubreuil 



On 11/10/18 00:18, Jeremy Stanley wrote:

On 2018-10-10 13:24:28 +1100 (+1100), Gilles Dubreuil wrote:

On 09/10/18 23:58, Jeremy Stanley wrote:

On 2018-10-09 08:52:52 -0400 (-0400), Jim Rollenhagen wrote:
[...]

It seems to me that a major goal of openstacksdk is to hide
differences between clouds from the user. If the user is meant
to use a GraphQL library themselves, we lose this and the user
needs to figure it out themselves. Did I understand that
correctly?

This is especially useful where the SDK implements business
logic for common operations like "if the user requested A and
the cloud supports features B+C+D then use those to fulfil the
request, otherwise fall back to using features E+F".

The features offered to the user don't have to change, it's just a
different architecture.

The user doesn't have to deal with a GraphQL library, only the
client applications (consuming OpenStack APIs). And there are also
UI tools such as GraphiQL which allow to interact directly with
GraphQL servers.

My point was simply that SDKs provide more than a simple translation
of network API calls and feature discovery. There can also be rather
a lot of "business logic" orchestrating multiple primitive API calls
to reach some more complex outcome. The services don't want to embed
this orchestrated business logic themselves, and it makes little
sense to replicate the same algorithms in every single application
which wants to make use of such composite functionality. There are
common actions an application might wish to take which involve
speaking to multiple APIs for different services to make specific
calls in a particular order, perhaps feeding the results of one into
the next.

Can you explain how GraphQL eliminates the above reasons for an SDK?


What I meant is the communication part of any SDK interfacing between 
clients and API services can be handled by GraphQL client librairies.
So instead of having to rely on modules (imported or native) to carry 
the REST communications, we're dealing with data provided by GraphQL 
libraries (which are also modules but standardized as GraphQL is a 
specification).
So as you mentioned there is still need to provide the data wrap in 
objects or any adequate struct to present to the consumers.


Having a Schema helps both API and clients developers because the data 
is clearly typed and graphed. Backend devs can focus on resolving the 
data for each node/leaf while the clients can focus on what they need 
and not how to get it.


To relate to $subject, by building the data model (graph) we obtain a 
schema and introspection. That's a big saver in term of resources.







__
OpenStack Development Mailing 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] [ironic] Stepping down as core

2018-10-11 Thread Sam Betts (sambetts) 
As many of you will have seen on IRC, I've mostly been appearing AFK for the 
last couple of development cycles. Due to other tasks downstream most of my 
attention has been drawn away from upstream Ironic development. Going forward 
I'm unlikely to be as heavily involved with the Ironic project as I have been 
in the past, so I am stepping down as a core contributor to make way for those 
more involved and with more time to contribute.

That said I do not intend to disappear, Myself and my colleagues plan to 
continue to support the Cisco Ironic drivers, we just won't be so heavily 
involved in core ironic development and its worth noting that although I might 
appear AFK on IRC because my main focus is on other things, I always have an 
ear to the ground and direct pings will generally reach me.

I will be in Berlin for the OpenStack summit, so to those that are attending I 
hope to see you there.

The Ironic project has been (and I hope continues to be) an awesome place to 
contribute too, thank you

Sam Betts
sambetts

__
OpenStack Development Mailing 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] [sahara] PTL out for a week

2018-10-11 Thread Luigi Toscano 
On Wednesday, 10 October 2018 22:42:03 CEST Telles Nobrega wrote:
> Hi all,
> 
> I'm taking PTO from tomorrow until Monday Oct 22nd. I won't cancel the
> meeting yet but let me know if you want me to.


No strong opinions about it.

I will be around; if there are people asking for it, I can start it, or just 
(most likely) discuss on the channel :)

> 
> See you all in a couple weeks.

See you, enjoy the vacation!

Ciao
-- 
Luigi




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

Re: [openstack-dev] [tripleo][ci] Having more that one queue for gate pipeline at tripleo

2018-10-11 Thread Emilien Macchi 
On Thu, Oct 11, 2018 at 10:01 AM Felix Enrique Llorente Pastora <
ellor...@redhat.com> wrote:

> Hello there,
>
>After suffering a lot from zuul's tripleo gate piepeline queue reseting
> after failures on patches I have ask myself what would happend if we have
> more than one queue for gating tripleo.
>
>After a quick read here https://zuul-ci.org/docs/zuul/user/gating.html,
> I have found the following:
>
> "If changes with cross-project dependencies do not share a change queue
> then Zuul is unable to enqueue them together, and the first will be
> required to merge before the second is enqueued."
>
>So it make sense to share zuul queue, but maybe only one queue for all
> tripleo projects is too  much, for example sharing queue between tripleo-ui
> and tripleo-quickstart, maybe we need for example to queues for product
> stuff and one for CI, so product does not get resetted if CI fails in a
> patch.
>
>What do you think ?
>

Probably a wrong example, as TripleO UI gate is using CI jobs running
tripleo-quickstart scenarios.
We could create more queues for projects which are really independent from
each other but we need to be very careful about it.
-- 
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] [sahara] PTL out for a week

2018-10-11 Thread Telles Nobrega 
Thanks Jeremy.
On Thu, 11 Oct 2018 at 02:09 Jeremy Freudberg 
wrote:

> Enjoy the PTO, Telles!
>
> I don't really have much to share at a meeting. My vote is for no meeting.
> Our other active core and other active community members can agree to
> cancel or not, and I'll heed that decision.
>
> On Wed, Oct 10, 2018 at 4:42 PM Telles Nobrega 
> wrote:
>
>> Hi all,
>>
>> I'm taking PTO from tomorrow until Monday Oct 22nd. I won't cancel the
>> meeting yet but let me know if you want me to.
>>
>> See you all in a couple weeks.
>>
>> Thanks,
>> --
>>
>> TELLES NOBREGA
>>
>> SOFTWARE ENGINEER
>>
>> Red Hat Brasil  
>>
>> Av. Brg. Faria Lima, 3900 - 8º andar - Itaim Bibi, São Paulo
>>
>> tenob...@redhat.com
>> 
>> TRIED. TESTED. TRUSTED. 
>>  Red Hat é reconhecida entre as melhores empresas para trabalhar no
>> Brasil pelo Great Place to Work.
>>
> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-- 

TELLES NOBREGA

SOFTWARE ENGINEER

Red Hat Brasil  

Av. Brg. Faria Lima, 3900 - 8º andar - Itaim Bibi, São Paulo

tenob...@redhat.com

TRIED. TESTED. TRUSTED. 
 Red Hat é reconhecida entre as melhores empresas para trabalhar no Brasil
pelo Great Place to Work.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [publiccloud-wg] Todays meeting for Public Cloud WG CANCELLED

2018-10-11 Thread Tobias Rydberg 

Hi folks,

Unfortunate we need to cancel todays meeting! Talk to you next Wednesday 
at 0700 UTC.


Cheers,
Tobias

--
Tobias Rydberg
Senior Developer
Twitter & IRC: tobberydberg

www.citynetwork.eu | www.citycloud.com

INNOVATION THROUGH OPEN IT INFRASTRUCTURE
ISO 9001, 14001, 27001, 27015 & 27018 CERTIFIED


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

[openstack-dev] [tripleo][ci] Having more that one queue for gate pipeline at tripleo

2018-10-11 Thread Felix Enrique Llorente Pastora 
Hello there,

   After suffering a lot from zuul's tripleo gate piepeline queue reseting
after failures on patches I have ask myself what would happend if we have
more than one queue for gating tripleo.

   After a quick read here https://zuul-ci.org/docs/zuul/user/gating.html,
I have found the following:

"If changes with cross-project dependencies do not share a change queue
then Zuul is unable to enqueue them together, and the first will be
required to merge before the second is enqueued."

   So it make sense to share zuul queue, but maybe only one queue for all
tripleo projects is too  much, for example sharing queue between tripleo-ui
and tripleo-quickstart, maybe we need for example to queues for product
stuff and one for CI, so product does not get resetted if CI fails in a
patch.

   What do you think ?

-- 
Quique Llorente

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