Trying to trace this, tempest calls the POST /servers//action API
endpoint for the nova compute api.
https://github.com/openstack/tempest/blob/master/tempest/lib/services/compute/floating_ips_client.py#L82
Nova then takes the requests and tries to do this floating ip association using
the neutr
Hi, Michael,
Please ignore my last two mails. Sorry about that.
The results of the two commands are as follows.
ubuntu@amphora-a0621f0e-d27f-4f22-a4ee-05b695e2b71f:~$ sudo ip netns exec
amphora-haproxy ip route show table all
sudo: unable to resolve host amphora-a0621f0e-d27f-4f22-a4ee-05b695e2b
On Mon, Nov 13, 2017 at 5:41 PM Andreas Jaeger wrote:
> You can easily include them for any repository - add the python
> requirements to test-requirments and add the binary requirements to
> bindep.txt - as explained in
> https://docs.openstack.org/infra/manual/drivers.html#package-requirements
On 2017-11-13 22:09, Doug Hellmann wrote:
> Excerpts from zuul's message of 2017-11-13 20:37:18 +:
>> Unable to freeze job graph: Unable to modify final job > publish-openstack-releasenotes branches: None source:
>> openstack-infra/project-config/zuul.d/jobs.yaml@master#26> attribute
>> requi
On Tue, Nov 14, 2017 at 5:05 AM Antoine Musso wrote:
> Hello,
>
> I had some success with http://blockdiag.com/ which, IIRC, is pure
> python. It supports various kind of graphs (block, sequences, network ...).
>
> The few I did were for Zuul:
> https://docs.openstack.org/infra/zuul/user/gating.h
Hi All,
I am starting meteos project meeting from coming thursday.
Meteos meeting will be held every thursday 4:30 am UTC.
Please go through the meeting plan:
https://wiki.openstack.org/wiki/Meetings/meteos
Thanks,
Digambar
___
Hello,
here an example of a trivial patch that is important for people that
do operations, and they have to troubleshoot stuff.
with the old Stable Release thinking this patch would not be accepted
on old stable branches.
Let's see if this gets accepted back to stable/newton
https://review.open
Dear Neutron developers,
we are building up an OpenStack (Pike) cluster based on CentOS 7.4 and
Mellanox Ofed 4.2.
As far as we understand Neutron rely on eIPoIB in order to manage
Infiniband networks but unfortunately Mellanox dropped this feature for
the new OFED versions.
Here below the Me
This more question to mellanox then to neutron community.
I suggest that you will send me private mail regarding this issue and we can
take it with the relevant people in Mellanox.
My email is mosh...@mellanox.com.
> -Original Message-
> From: Massimo Benini [mailto:ben...@cscs.ch]
> S
Am I actually hallucinating or is it the nova API that cannot communicate with
Keystone?
Cannot substantiate this with any logs for keystone.
2017-10-29 23:12:35.521 17800 ERROR nova.api.openstack.compute.floating_ips
[req-7f810cc7-a498-4bf4-b27e-8fc80d652785 42526a28b1a14c629b83908b2d75c647
24
Hi everyone.
Reminder that the Common Classification Framework meeting is at 14:00 UTC.
The Agenda can be found here:
https://wiki.openstack.org/wiki/Neutron/CommonClassificationFramework#All_Meetings.27_Agendas
Regards.
David.
_
2017-11-14 8:24 GMT+00:00 Tobias Urdin :
> Trying to trace this, tempest calls the POST /servers//action
> API endpoint for the nova compute api.
>
> https://github.com/openstack/tempest/blob/master/tempest/lib/services/compute/floating_ips_client.py#L82
>
> Nova then takes the requests and tries t
As discussed in IRC, I have collated all the important discussions to
the etherpad (gdoc was not publicly shareable).
https://etherpad.openstack.org/p/tripleo-derive-parameters-v2
Lets continue discussion on the etherpad to finalize.
Regards,
Saravanan KR
On Thu, Nov 9, 2017 at 11:05 AM, Sarava
Yea, I've been scavenging the logs for any kind of indicator on what
might have gone wrong but I can't see anything
related to a deadlock even though I'm very certain that's the issue but
don't know what's causing it.
Perhaps we will need to manually recreate this issue and then
troubleshoot it ma
Saverio,
This is still under the stable team reviews... NOT LTS.
Your contacts for the Nova Stable team is ...
https://review.openstack.org/#/admin/groups/540,members
Let's please be clear, we need new people to help with LTS plans.
Current teams can't scale, they should not have to and it's tot
Hi,
We just started with Openstack Swift which we intend to use as a
replacement for an API which was written to work with AWS S3.
We know that Swift is S3 compatible and our API should work out of the box
with it.
We have not been able to get Swift running with S3 plugins.
I was wondering if the
On 2017-11-13 14:26:38 -0500 (-0500), Mohammed Naser wrote:
[...]
> Given that Puppet OpenStack has a large number of modules, in addition
> to Infra's puppet modules, it would be good to have a project-template
> specific for build and release of Puppet modules.
[...]
Coming up with something con
Hi folks!
This was raised several times, now I want to bring it to the wider audience.
We're planning [1] to deprecate classic drivers in Queens and remove them in
Rocky. It was pointed at the Forum that we'd better provide an automatic migration.
I'd like to hear your opinion on the options:
On 14/11/17 22:33 +1100, Davanum Srinivas wrote:
Saverio,
This is still under the stable team reviews... NOT LTS.
Your contacts for the Nova Stable team is ...
https://review.openstack.org/#/admin/groups/540,members
Let's please be clear, we need new people to help with LTS plans.
Current team
Team,
Just a reminder that we will now return to our regularly scheduled
weekly Cinder meetings starting 11/15/2017.
I hope you all enjoyed a little break and thank you to whoever updated
the etherpad for 11/8. :-)
An important reminder to everyone in the US (and possibly elsewhere)
that
Is it a known limitation that the ML2 plugin and associated drivers do not
properly handle cases where there are multiple agents running on the same host?
That is, two or more agents that reside on the same host and both report
device/interface mappings for physical networks?One such setu
Excerpts from Andreas Jaeger's message of 2017-11-14 09:31:48 +0100:
> On 2017-11-13 22:09, Doug Hellmann wrote:
> > Excerpts from zuul's message of 2017-11-13 20:37:18 +:
> >> Unable to freeze job graph: Unable to modify final job >> publish-openstack-releasenotes branches: None source:
> >>
Flavio, Saverio,
Agree, that review may be a good example of what could be done. More info below.
Saverio said - "with the old Stable Release thinking this patch would
not be accepted on old stable branches."
My response - "Those branches are still under stable policy. That has
not changed just b
On 2017-11-14 17:03, Doug Hellmann wrote:
> Excerpts from Andreas Jaeger's message of 2017-11-14 09:31:48 +0100:
>> On 2017-11-13 22:09, Doug Hellmann wrote:
>>> Excerpts from zuul's message of 2017-11-13 20:37:18 +:
Unable to freeze job graph: Unable to modify final job >>> publish-openst
Excerpts from Gilles Dubreuil's message of 2017-11-14 10:15:02 +1100:
> Hi,
>
> Follow-up conversation from our last "API SIG feedback and discussion
> session" at Sydney Summit [1], about APIs schema consumption.
>
> Let's summarize the current situation.
>
> Each OpenStack project has an "API
The concept, in general, is to create a new set of cores from these
groups, and use 3rd party CI to validate patches. There are lots of
details to be worked out yet, but our amazing UC (User Committee) will
be begin working out the details.
What is the most worrying is the exact "take over" proc
Excerpts from zuul's message of 2017-11-14 16:01:20 +:
> Unable to freeze job graph: Unable to modify final job publish-openstack-releasenotes branches: None source:
> openstack-infra/project-config/zuul.d/jobs.yaml@master#26> attribute
> required_projects={'openstack/horizon': 0x7ff8f8b0a7
Hi all,
as this topic it was recently brought up in ironic IRC meeting, I'd like to
start a discussion on the subject.
A quick recap - networking-generic-switch project (n-g-s) was born out of
necessity to do two things:
- test the "network isolation for baremetal nodes" (a.k.a. multi-tenancy)
Greetings ironic folk!
Like many other teams, we had very few ironic contributors make it to
Sydney. As such, I wanted to go ahead and write up a summary that
covers takeaways, questions, and obvious action items for the
community that were raised by operators and users present during the
sessions
Excerpts from Davanum Srinivas (dims)'s message of 2017-11-15 03:04:38 +1100:
> Flavio, Saverio,
>
> Agree, that review may be a good example of what could be done. More info
> below.
>
> Saverio said - "with the old Stable Release thinking this patch would
> not be accepted on old stable branch
Bogdan, Team,
So i got this etherpad started. Please add policy ideas at the top and
volunteer for the team too.,
https://etherpad.openstack.org/p/LTS-proposal
Thanks,
Dims
On Wed, Nov 15, 2017 at 3:08 AM, Bogdan Dobrelya wrote:
>>> The concept, in general, is to create a new set of cores from
Excerpts from Bogdan Dobrelya's message of 2017-11-14 17:08:31 +0100:
> >> The concept, in general, is to create a new set of cores from these
> >> groups, and use 3rd party CI to validate patches. There are lots of
> >> details to be worked out yet, but our amazing UC (User Committee) will
> >> be
Hi everyone,
Thank you so much for the work on this, I'm sure we can progress with
this together. I have noticed that this only occurs in master and
never in the stable branches. Also, it only occurs under Ubuntu (so
maybe something related to mod_wsgi version?)
Given that we don't have any "ma
Hi all - please note this conversation has been split variously across
-dev and -operators.
One small observation from the discussion so far is that it seems as
though there are two issues being discussed under the one banner:
1) maintain old releases for longer
2) do stable releases less frequent
On Tue, Nov 14, 2017, at 08:09 AM, Doug Hellmann wrote:
> Excerpts from zuul's message of 2017-11-14 16:01:20 +:
> > Unable to freeze job graph: Unable to modify final job > publish-openstack-releasenotes branches: None source:
> > openstack-infra/project-config/zuul.d/jobs.yaml@master#26> at
> Which stable policy does that patch violate? It's clearly a bug
> because the wrong information is being logged. I suppose it goes
> against the string freeze rule? Except that we've stopped translating
> log messages so maybe we don't need to worry about that in this case,
> since it isn't an
To do this you want to use the `swift3` middleware, available at
https://github.com/openstack/swift3. Its `README.md` file has installation
instructions.
Also note that the Swift community is currently integrating the `swift3`
middleware into Swift's code repo. In the future, you will not need
Saverio,
Please see this :
https://docs.openstack.org/project-team-guide/stable-branches.html for
current policies.
On Wed, Nov 15, 2017 at 3:33 AM, Saverio Proto wrote:
>> Which stable policy does that patch violate? It's clearly a bug
>> because the wrong information is being logged. I suppo
On Tue, Nov 14, 2017 at 9:16 AM, Pavlo Shchelokovskyy
wrote:
> As a core in n-g-s myself I'm happy with either 1) or 2), but not really
> fond of 3) as it kind of stretches the networking-baremetal scope too much
> IMHO.
Personally, I'm happy with 1 or 2. I personally think we might as well
lean
Excerpts from Clark Boylan's message of 2017-11-14 08:31:15 -0800:
> On Tue, Nov 14, 2017, at 08:09 AM, Doug Hellmann wrote:
> > Excerpts from zuul's message of 2017-11-14 16:01:20 +:
> > > Unable to freeze job graph: Unable to modify final job > > publish-openstack-releasenotes branches: None
Yipei,
Yeah, we have clearly identified the problem. Those two default route
lines should not be different. See my devstack:
sudo: unable to resolve host amphora-20a717b4-eb97-4b5c-a11a-0633fe61f135
default via 10.0.0.1 dev eth1 table 1 onlink
default via 10.0.0.1 dev eth1 onlink
So the issue
Let's focus our energy on the etherpad please
https://etherpad.openstack.org/p/LTS-proposal
On Wed, Nov 15, 2017 at 3:35 AM, Davanum Srinivas wrote:
> Saverio,
>
> Please see this :
> https://docs.openstack.org/project-team-guide/stable-branches.html for
> current policies.
>
> On Wed, Nov 15, 2
Blair,
Please add #2 as a line proposal in:
https://etherpad.openstack.org/p/LTS-proposal
So far it's focused on #1
Thanks,
Dims
On Wed, Nov 15, 2017 at 3:30 AM, Blair Bethwaite
wrote:
> Hi all - please note this conversation has been split variously across
> -dev and -operators.
>
> One small
Excerpts from zuul's message of 2017-11-14 16:24:33 +:
> Build failed.
>
> - release-openstack-python-without-pypi
> http://logs.openstack.org/17/175bd53e7b18a9dc4d42e60fe9225a5748eded34/pre-release/release-openstack-python-without-pypi/7a9474c/
> : POST_FAILURE in 14m 47s
> - announce-relea
On Tue, Nov 14, 2017, at 09:01 AM, Doug Hellmann wrote:
> Excerpts from zuul's message of 2017-11-14 16:24:33 +:
> > Build failed.
> >
> > - release-openstack-python-without-pypi
> > http://logs.openstack.org/17/175bd53e7b18a9dc4d42e60fe9225a5748eded34/pre-release/release-openstack-python-w
On Tue, Nov 14, 2017 at 11:30 AM, Blair Bethwaite
wrote:
> Hi all - please note this conversation has been split variously across
> -dev and -operators.
>
> One small observation from the discussion so far is that it seems as
> though there are two issues being discussed under the one banner:
> 1)
Folks,
I'd like to share the progress of the HA Inspector effort with you.
TL;DR I'm able to run 2 instances of ironic inspector in an active-active
fashion in a modified devstack deployment.
I've uploaded a Github repo containing my config&steps[1] to take to
reproduce as well as a video[2] of m
Hi!
Thanks for raising this.
On 11/14/2017 05:16 PM, Pavlo Shchelokovskyy wrote:
Hi all,
as this topic it was recently brought up in ironic IRC meeting, I'd like to
start a discussion on the subject.
A quick recap - networking-generic-switch project (n-g-s) was born out of
necessity to do
2017-11-14 16:29 GMT+00:00 Mohammed Naser :
> Hi everyone,
>
> Thank you so much for the work on this, I'm sure we can progress with
> this together. I have noticed that this only occurs in master and
> never in the stable branches. Also, it only occurs under Ubuntu (so
> maybe something related
Jens,
That's quite an interesting catch. I'm reaching out to the author of
this change to get some more information.
Thanks,
Mohammed
On Tue, Nov 14, 2017 at 2:02 PM, Jens Harbott wrote:
> 2017-11-14 16:29 GMT+00:00 Mohammed Naser :
>> Hi everyone,
>>
>> Thank you so much for the work on this,
On 11/14/2017 10:25 AM, Doug Hellmann wrote:
Why
would we have third-party jobs on an old branch that we don't have on
master, for instance?
One possible reason is to test the stable version of OpenStack against a stable
version of the underlying OS distro. (Where that distro may not meet th
On 11/14/2017 05:08 PM, Bogdan Dobrelya wrote:
The concept, in general, is to create a new set of cores from these
groups, and use 3rd party CI to validate patches. There are lots of
details to be worked out yet, but our amazing UC (User Committee) will
be begin working out the details.
What is
On 11/14/2017 06:21 PM, Erik McCormick wrote:
On Tue, Nov 14, 2017 at 11:30 AM, Blair Bethwaite
wrote:
Hi all - please note this conversation has been split variously across
-dev and -operators.
One small observation from the discussion so far is that it seems as
though there are two issues be
Thanks for sending this out.
I would vote for Option 1.
Thanks,
John
From: Pavlo Shchelokovskyy [mailto:pshchelokovs...@mirantis.com]
Sent: Tuesday, November 14, 2017 8:16 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [ironic] inclusion of
openst
On Tue, Nov 14, 2017 at 11:28 AM, Dmitry Tantsur wrote:
> On 11/14/2017 05:08 PM, Bogdan Dobrelya wrote:
The concept, in general, is to create a new set of cores from these
groups, and use 3rd party CI to validate patches. There are lots of
details to be worked out yet, but our
On 11/14/2017 01:28 PM, Dmitry Tantsur wrote:
The quality of backported fixes is expected to be a direct (and only?)
interest of those new teams of new cores, coming from users and operators and
vendors.
I'm not assuming bad intentions, not at all. But there is a lot of involved in a
decision
On Tue, Nov 14, 2017 at 11:25:03AM -0500, Doug Hellmann wrote:
> Excerpts from Bogdan Dobrelya's message of 2017-11-14 17:08:31 +0100:
> > >> The concept, in general, is to create a new set of cores from these
> > >> groups, and use 3rd party CI to validate patches. There are lots of
> > >> details
On Wed, Nov 15, 2017 at 7:01 AM, Chris Friesen
wrote:
> On 11/14/2017 01:28 PM, Dmitry Tantsur wrote:
>
>>> The quality of backported fixes is expected to be a direct (and only?)
>>> interest of those new teams of new cores, coming from users and operators
>>> and
>>> vendors.
>>
>>
>> I'm not ass
Excerpts from Chris Friesen's message of 2017-11-14 14:01:58 -0600:
> On 11/14/2017 01:28 PM, Dmitry Tantsur wrote:
>
> >> The quality of backported fixes is expected to be a direct (and only?)
> >> interest of those new teams of new cores, coming from users and operators
> >> and
> >> vendors.
>
Excerpts from Clark Boylan's message of 2017-11-14 09:04:07 -0800:
>
> On Tue, Nov 14, 2017, at 09:01 AM, Doug Hellmann wrote:
> > Excerpts from zuul's message of 2017-11-14 16:24:33 +:
> > > Build failed.
> > >
> > > - release-openstack-python-without-pypi
> > > http://logs.openstack.org/17
Excerpts from zuul's message of 2017-11-14 20:13:45 +:
> Unable to freeze job graph: Unable to modify final job publish-openstack-releasenotes branches: None source:
> openstack-infra/project-config/zuul.d/jobs.yaml@master#26> attribute
> required_projects={'openstack/neutron': 0x7ff89c7ab5
Folks,
This discussion and the people interested in it seem like a perfect application
of the SIG process. By turning LTS into a SIG, everyone can discuss the issues
on the SIG mailing list and the discussion shouldn't end up split. If it turns
into a project, great. If a solution is found t
On Tue, Nov 14, 2017, at 12:15 PM, Doug Hellmann wrote:
> Excerpts from Clark Boylan's message of 2017-11-14 09:04:07 -0800:
> >
> > On Tue, Nov 14, 2017, at 09:01 AM, Doug Hellmann wrote:
> > > Excerpts from zuul's message of 2017-11-14 16:24:33 +:
> > > > Build failed.
> > > >
> > > > - r
In general, you should be able to run both regular l2 agent (ovs) and
sriov agent. If you have problems with it, we should probably assume
it's a bug. Please report.
On Tue, Nov 14, 2017 at 8:02 AM, Legacy, Allain
wrote:
> Is it a known limitation that the ML2 plugin and associated drivers do not
Hey all,
I just finished dumping everything from the summit into a blog post [0].
If you have a summary or feedback - we can use this thread to advertise
it and discuss.
Thanks,
Lance
[0] https://www.lbragstad.com/blog/openstack-summit-sydney-recap
signature.asc
Description: OpenPGP digita
On 11/14/2017 02:10 PM, Doug Hellmann wrote:
Excerpts from Chris Friesen's message of 2017-11-14 14:01:58 -0600:
On 11/14/2017 01:28 PM, Dmitry Tantsur wrote:
The quality of backported fixes is expected to be a direct (and only?)
interest of those new teams of new cores, coming from users and
On Tue, Nov 14, 2017 at 8:10 AM, Dmitry Tantsur wrote:
> Hi folks!
>
> This was raised several times, now I want to bring it to the wider audience.
> We're planning [1] to deprecate classic drivers in Queens and remove them in
> Rocky. It was pointed at the Forum that we'd better provide an automa
Excerpts from Chris Friesen's message of 2017-11-14 15:50:08 -0600:
> On 11/14/2017 02:10 PM, Doug Hellmann wrote:
> > Excerpts from Chris Friesen's message of 2017-11-14 14:01:58 -0600:
> >> On 11/14/2017 01:28 PM, Dmitry Tantsur wrote:
> >>
> The quality of backported fixes is expected to be
The pressure for #2 comes from the inability to skip upgrades and the fact that
upgrades are hugely time consuming still.
If you want to reduce the push for number #2 and help developers get their wish
of getting features into users hands sooner, the path to upgrade really needs
to be much less
On Tue, Nov 14, 2017 at 6:00 PM, Fox, Kevin M wrote:
> The pressure for #2 comes from the inability to skip upgrades and the fact
> that upgrades are hugely time consuming still.
>
> If you want to reduce the push for number #2 and help developers get their
> wish of getting features into users
On 14 Nov 2017, at 15:18, Mathieu Gagné wrote:
> On Tue, Nov 14, 2017 at 6:00 PM, Fox, Kevin M wrote:
>> The pressure for #2 comes from the inability to skip upgrades and the fact
>> that upgrades are hugely time consuming still.
>>
>> If you want to reduce the push for number #2 and help deve
For those wondering why operators can’t always upgrade sooner, I can add a
little bit of color: In our clouds, we have a couple vendors (one network
plugin, one cinder driver) and those vendors typically are 1-3 releases behind
‘cutting edge’. By the time they support the version we want to go
On Tue, Nov 14, 2017 at 6:44 PM, John Dickinson wrote:
>
>
> On 14 Nov 2017, at 15:18, Mathieu Gagné wrote:
>
>> On Tue, Nov 14, 2017 at 6:00 PM, Fox, Kevin M wrote:
>>> The pressure for #2 comes from the inability to skip upgrades and the fact
>>> that upgrades are hugely time consuming still.
On Wed, Nov 15, 2017 at 10:44 AM, John Dickinson wrote:
>
>
> On 14 Nov 2017, at 15:18, Mathieu Gagné wrote:
>
>> On Tue, Nov 14, 2017 at 6:00 PM, Fox, Kevin M wrote:
>>> The pressure for #2 comes from the inability to skip upgrades and the fact
>>> that upgrades are hugely time consuming still.
On Tue, Nov 14, 2017 at 6:44 PM, John Dickinson wrote:
>
>
> On 14 Nov 2017, at 15:18, Mathieu Gagné wrote:
>
>> On Tue, Nov 14, 2017 at 6:00 PM, Fox, Kevin M wrote:
>>> The pressure for #2 comes from the inability to skip upgrades and the fact
>>> that upgrades are hugely time consuming still.
Hi,
I'm working on migrating all TripleO CI jobs to be in-tree, I'm also
refactoring the layout and do some cleanup.
It's a bit of work, that can be followed here:
https://review.openstack.org/#/q/topic:tripleo/migrate-to-zuulv3
The only thing I ask from our team is to let me know any change in
p
On Tue, Nov 14, 2017 at 4:10 PM, Rochelle Grober
wrote:
> Folks,
>
> This discussion and the people interested in it seem like a perfect
> application of the SIG process. By turning LTS into a SIG, everyone can
> discuss the issues on the SIG mailing list and the discussion shouldn't end
> up
I can think of a few ideas, though some sound painful on paper Not really
recommending anything, just thinking out loud...
One idea is that at the root of chaos monkey. If something is hard, do it
frequently. If upgrading is hard, we need to be doing it constantly so the pain
gets largely e
All,
Please consider today's meeting canceled.
Thanks,
pk
> From: "Petr Kovar"
> To: openstack-dev@lists.openstack.org
> Cc: "enstack.org"
> Sent: Tuesday, November 14, 2017 11:37:39 AM
> Subject: [OpenStack-docs] [docs] Next documentation meeting
>
> Hi docs people,
>
> Our next documenta
On 14 Nov 2017, at 16:08, Davanum Srinivas wrote:
> On Wed, Nov 15, 2017 at 10:44 AM, John Dickinson wrote:
>>
>>
>> On 14 Nov 2017, at 15:18, Mathieu Gagné wrote:
>>
>>> On Tue, Nov 14, 2017 at 6:00 PM, Fox, Kevin M wrote:
The pressure for #2 comes from the inability to skip upgrades and
Well, moving this discussion is easy. All that takes is everyone posting
responses to the openstack-...@lists.openstack.org mailing list instead of dev
and ops lists. I've cc'ed all here. I've also added [LTS] to the subject
(sorry to break all the threaders). So that the sig list knows what
On 11/14/2017 10:58 AM, Davanum Srinivas wrote:
Let's focus our energy on the etherpad please
https://etherpad.openstack.org/p/LTS-proposal
On Wed, Nov 15, 2017 at 3:35 AM, Davanum Srinivas wrote:
Saverio,
Please see this :
https://docs.openstack.org/project-team-guide/stable-branches.html f
On 2017-11-15 01:18, Emilien Macchi wrote:
> Hi,
>
> I'm working on migrating all TripleO CI jobs to be in-tree, I'm also
> refactoring the layout and do some cleanup.
Please don't move *all* in tree - only the legacy ones. There's a
specific set of jobs we (infra, release team) like to keep in
p
On 11/14/2017 11:17 PM, Doug Hellmann wrote:
Excerpts from Chris Friesen's message of 2017-11-14 15:50:08 -0600:
On 11/14/2017 02:10 PM, Doug Hellmann wrote:
Excerpts from Chris Friesen's message of 2017-11-14 14:01:58 -0600:
On 11/14/2017 01:28 PM, Dmitry Tantsur wrote:
The quality of backp
On 11/14/2017 09:01 PM, Chris Friesen wrote:
On 11/14/2017 01:28 PM, Dmitry Tantsur wrote:
The quality of backported fixes is expected to be a direct (and only?)
interest of those new teams of new cores, coming from users and operators and
vendors.
I'm not assuming bad intentions, not at all.
85 matches
Mail list logo