Hi everyone!
So I’ve been thinking of dropping the Xenial jobs to reduce our overall impact
in terms of gate usage in master because we don’t support it.
However, I was a bit torn on this because i realize that it’s possible for us
to write things and backport them only to find out that
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
BU + North Eastern - https://massopen.cloud/blog/moc-production-kaizen/
On Tue, Oct 9, 2018 at 9:41 PM Jeremy Stanley wrote:
> On 2018-10-10 02:54:52 +0200 (+0200), Jay See wrote:
> > May be a different question , not completely related to issues
> > associated with openstack.
> >
> > Does
On 2018-10-10 02:54:52 +0200 (+0200), Jay See wrote:
> May be a different question , not completely related to issues
> associated with openstack.
>
> Does anyone know any university or universities using opnstack for
> cloud deployment and resource sharing.
There are many, but the first which
On 10/9/2018 1:20 PM, Jay Pipes wrote:
On 10/09/2018 11:04 AM, Balázs Gibizer wrote:
If you do the force flag removal in a nw microversion that also means
(at least to me) that you should not change the behavior of the force
flag in the old microversions.
Agreed.
Keep the old, buggy and
On 10/09/2018 02:20 PM, Jay Pipes wrote:
> On 10/09/2018 11:04 AM, Balázs Gibizer wrote:
>> If you do the force flag removal in a nw microversion that also means
>> (at least to me) that you should not change the behavior of the force
>> flag in the old microversions.
>
> Agreed.
>
> Keep the
Thank you Tom for nominating me and thank you all for your votes :)
- Amit
On Tue, Oct 9, 2018 at 11:24 PM Erlon Cruz wrote:
> Hey Amit,
>
> Welcome!
>
> Em ter, 9 de out de 2018 às 16:52, Tom Barron escreveu:
>
>> On 02/10/18 13:58 -0400, Tom Barron wrote:
>> >Amit Oren has contributed high
Hey Amit,
Welcome!
Em ter, 9 de out de 2018 às 16:52, Tom Barron escreveu:
> On 02/10/18 13:58 -0400, Tom Barron wrote:
> >Amit Oren has contributed high quality reviews in the last
> >couple of cycles so I would like to nominated him for manila
> >core.
> >
> >Please respond with your +1 or
Hi Ghanshyam,
Though I have concern over running those tests by default(making config
> options True by default), because it is not confirmed all cinder backends
> implements this functionality and it only works for nova libvirt driver. We
> need to keep config options default as False and
On 02/10/18 13:58 -0400, Tom Barron wrote:
Amit Oren has contributed high quality reviews in the last
couple of cycles so I would like to nominated him for manila
core.
Please respond with your +1 or -1 votes. We'll hold voting
open for 7 days.
Thanks,
-- Tom Barron (tbarron)
We've
On Tue, Oct 9, 2018 at 10:56 AM Doug Hellmann wrote:
> Matthew Thode writes:
>
> > On 18-10-09 11:12:30, Doug Hellmann wrote:
> >> Matthew Thode writes:
> >>
> >> > several projects have had problems with the new release, some have
> ways
> >> > of working around it, and some do not. I'm
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
On 10/5/2018 6:59 PM, melanie witt wrote:
5) when live migration fails due to a internal error rollback is not
handled correctly https://bugs.launchpad.net/nova/+bug/1788014
- Bug was reported on 2018-08-20
- The change that caused the regression landed on 2018-07-26, FF day
On 10/09/2018 11:04 AM, Balázs Gibizer wrote:
If you do the force flag removal in a nw microversion that also means
(at least to me) that you should not change the behavior of the force
flag in the old microversions.
Agreed.
Keep the old, buggy and unsafe behaviour for the old microversion
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.
Is this a TC question?
Hi Cyborg Team,
I want to nominate Xinran Wang as a new core reviewer for Cyborg project.
Xiran has been working hard and kept contributing to the project[1][2].
Keep Claim and Carry on :)
[1]
https://review.openstack.org/#/q/owner:xin-ran.wang%2540intel.com+status:open
[2]
Hi Team,
This week's Cyborg meeting will be held in ZOOM. Sundar will give a
presentation.
LI LIU is inviting you to a scheduled Zoom meeting.
Topic: Cyborg Meeting
Time: Oct 10, 2018 10:00 AM Eastern Time (US and Canada)
Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/6637468814
On 10/9/2018 11:08 AM, Miguel Lavalle wrote:
Since it has been more than a week since this nomination was posted and
we have received only positive feedback, can we move ahead and add
Bernard Cafarelli to Neutron Stable core team?
Done:
https://review.openstack.org/#/admin/groups/539,members
On Tue, 9 Oct 2018 10:35:23 -0700, Melanie Witt wrote:
On Tue, 9 Oct 2018 07:23:03 -0400, Jay Pipes wrote:
That explains where the source of the problem comes from (it's the use
of SELECT FOR UPDATE, which has been removed from Nova's quota-handling
code in the Rocky release).
Small
Got it thanks very much, Sampath!
From: Sam P
Reply-To: "OpenStack Development Mailing List (not for usage questions)"
Date: Saturday, October 6, 2018 at 8:29 PM
To: "OpenStack Development Mailing List (not for usage questions)"
Subject: Re: [openstack-dev] [masakari][congress] what is a
On Tue, Oct 9, 2018 at 12:30 PM Doug Hellmann wrote:
> Ken Giusti writes:
>
> > On Tue, Oct 9, 2018 at 11:56 AM Doug Hellmann
> wrote:
> >
> >> Matthew Thode writes:
> >>
> >> > On 18-10-09 11:12:30, Doug Hellmann wrote:
> >> >> Matthew Thode writes:
> >> >>
> >> >> > several projects have
On Tue, 9 Oct 2018 07:23:03 -0400, Jay Pipes wrote:
That explains where the source of the problem comes from (it's the use
of SELECT FOR UPDATE, which has been removed from Nova's quota-handling
code in the Rocky release).
Small correction, the SELECT FOR UPDATE was removed from Nova's
Ken Giusti writes:
> On Tue, Oct 9, 2018 at 11:56 AM Doug Hellmann wrote:
>
>> Matthew Thode writes:
>>
>> > On 18-10-09 11:12:30, Doug Hellmann wrote:
>> >> Matthew Thode writes:
>> >>
>> >> > several projects have had problems with the new release, some have
>> ways
>> >> > of working
On Tue, Oct 9, 2018 at 11:56 AM Doug Hellmann wrote:
> Matthew Thode writes:
>
> > On 18-10-09 11:12:30, Doug Hellmann wrote:
> >> Matthew Thode writes:
> >>
> >> > several projects have had problems with the new release, some have
> ways
> >> > of working around it, and some do not. I'm
etcd is an already approved openstack dependency. Could that be used instead of
consul so as to not add yet another storage system? coredns with the
https://coredns.io/plugins/etcd/ plugin would maybe do what you need?
Thanks,
Kevin
From: Florian
There are specific cases where it expects the client to retry and not all code
tests for that case. Its safe funneling all traffic to one server. It can be
unsafe to do so otherwise.
Thanks,
Kevin
From: Jay Pipes [jaypi...@gmail.com]
Sent: Monday,
Hi Stable Team,
Since it has been more than a week since this nomination was posted and we
have received only positive feedback, can we move ahead and add Bernard
Cafarelli to Neutron Stable core team?
Thanks and regards
Miguel
On Wed, Oct 3, 2018 at 8:32 AM Nate Johnston
wrote:
> On Tue,
Matthew Thode writes:
> On 18-10-09 11:12:30, Doug Hellmann wrote:
>> Matthew Thode writes:
>>
>> > several projects have had problems with the new release, some have ways
>> > of working around it, and some do not. I'm sending this just to raise
>> > the issue and allow a place to discuss
On Tue, Oct 9, 2018 at 10:31 AM Ben Nemec wrote:
>
>
> On 10/9/18 9:06 AM, Lance Bragstad wrote:
> > Keystone is failing because it's missing a fix from oslo.messaging [0].
> > That said, keystone is also relying on an internal implementation detail
> > in oslo.messaging by mocking it in tests
Ben Nemec writes:
> On 10/9/18 10:19 AM, Doug Hellmann wrote:
>> Brian Rosmaita writes:
>>
>>> On 10/8/18 11:59 PM, Matthew Thode wrote:
several projects have had problems with the new release, some have ways
of working around it, and some do not. I'm sending this just to raise
On Tue, Oct 9, 2018 at 5:32 PM, Sylvain Bauza
wrote:
>
>
> Le mar. 9 oct. 2018 à 17:09, Balázs Gibizer
> a écrit :
>>
>>
>> On Tue, Oct 9, 2018 at 4:56 PM, Sylvain Bauza
>>
>> wrote:
>> >
>> >
>> > Le mar. 9 oct. 2018 à 16:39, Eric Fried a
>> > écrit :
>> >> IIUC, the primary thing
On 10/9/18 10:19 AM, Doug Hellmann wrote:
Brian Rosmaita writes:
On 10/8/18 11:59 PM, Matthew Thode wrote:
several projects have had problems with the new release, some have ways
of working around it, and some do not. I'm sending this just to raise
the issue and allow a place to discuss
> Shit, I forgot to add openstack-operators@...
> Operators, see my question for you here :
>
>
>> Le mar. 9 oct. 2018 à 16:39, Eric Fried a écrit :
>>
>>> IIUC, the primary thing the force flag was intended to do - allow an
>>> instance to land on the requested destination even if that means
>>>
> Shit, I forgot to add openstack-operators@...
> Operators, see my question for you here :
>
>
>> Le mar. 9 oct. 2018 à 16:39, Eric Fried a écrit :
>>
>>> IIUC, the primary thing the force flag was intended to do - allow an
>>> instance to land on the requested destination even if that means
>>>
Shit, I forgot to add openstack-operators@...
Operators, see my question for you here :
> Le mar. 9 oct. 2018 à 16:39, Eric Fried a écrit :
>
>> IIUC, the primary thing the force flag was intended to do - allow an
>> instance to land on the requested destination even if that means
>>
Le mar. 9 oct. 2018 à 17:09, Balázs Gibizer a
écrit :
>
>
> On Tue, Oct 9, 2018 at 4:56 PM, Sylvain Bauza
> wrote:
> >
> >
> > Le mar. 9 oct. 2018 à 16:39, Eric Fried a
> > écrit :
> >> IIUC, the primary thing the force flag was intended to do - allow an
> >> instance to land on the requested
Am 10/9/18 um 1:23 PM schrieb Jay Pipes:
On 10/09/2018 06:34 AM, Florian Engelmann wrote:
Am 10/9/18 um 11:41 AM schrieb Jay Pipes:
On 10/09/2018 04:34 AM, Christian Berendt wrote:
On 8. Oct 2018, at 19:48, Jay Pipes wrote:
Why not send all read and all write traffic to a single haproxy
On 10/9/18 9:06 AM, Lance Bragstad wrote:
Keystone is failing because it's missing a fix from oslo.messaging [0].
That said, keystone is also relying on an internal implementation detail
in oslo.messaging by mocking it in tests [1]. The notification work has
been around in keystone for a
On 18-10-09 11:12:30, Doug Hellmann wrote:
> Matthew Thode writes:
>
> > several projects have had problems with the new release, some have ways
> > of working around it, and some do not. I'm sending this just to raise
> > the issue and allow a place to discuss solutions.
> >
> > Currently
Lance Bragstad writes:
> Keystone is failing because it's missing a fix from oslo.messaging [0].
> That said, keystone is also relying on an internal implementation detail in
> oslo.messaging by mocking it in tests [1]. The notification work has been
> around in keystone for a *long* time, but
Brian Rosmaita writes:
> On 10/8/18 11:59 PM, Matthew Thode wrote:
>> several projects have had problems with the new release, some have ways
>> of working around it, and some do not. I'm sending this just to raise
>> the issue and allow a place to discuss solutions.
>>
>> Currently there is a
Matthew Thode writes:
> several projects have had problems with the new release, some have ways
> of working around it, and some do not. I'm sending this just to raise
> the issue and allow a place to discuss solutions.
>
> Currently there is a review proposed to blacklist 9.0.0, but if this is
On 10/9/18 8:22 AM, Brian Rosmaita wrote:
On 10/8/18 11:59 PM, Matthew Thode wrote:
several projects have had problems with the new release, some have ways
of working around it, and some do not. I'm sending this just to raise
the issue and allow a place to discuss solutions.
Currently there
On Tue, Oct 9, 2018 at 4:56 PM, Sylvain Bauza
wrote:
>
>
> Le mar. 9 oct. 2018 à 16:39, Eric Fried a
> écrit :
>> IIUC, the primary thing the force flag was intended to do - allow an
>> instance to land on the requested destination even if that means
>> oversubscription of the host's
On Tue, Oct 9, 2018 at 4:39 PM, Eric Fried wrote:
> IIUC, the primary thing the force flag was intended to do - allow an
> instance to land on the requested destination even if that means
> oversubscription of the host's resources - doesn't happen anymore
> since
> we started making the
Hi,
I'm trying to setup Cinder as a standalone service with Docker using the
blockbox system (contrib/blockbox in the Cinder source distribution). I
was inspired by this manual:
https://thenewstack.io/deploying-cinder-stand-alone-storage-service/.
This works quite well with Cinder’s noauth
Le mar. 9 oct. 2018 à 16:39, Eric Fried a écrit :
> IIUC, the primary thing the force flag was intended to do - allow an
> instance to land on the requested destination even if that means
> oversubscription of the host's resources - doesn't happen anymore since
> we started making the
On 10/8/2018 8:54 AM, Sean McGinnis wrote:
On Mon, Oct 08, 2018 at 03:09:36PM +0800, Yikun Jiang wrote:
In Denver, we agree to add a new "re-image" API in cinder to support upport
volume-backed server rebuild with a new image.
An initial blueprint has been drafted in [3], welcome to review
IIUC, the primary thing the force flag was intended to do - allow an
instance to land on the requested destination even if that means
oversubscription of the host's resources - doesn't happen anymore since
we started making the destination claim in placement.
IOW, since pike, you don't actually
On 10/9/2018 8:04 AM, Erlon Cruz wrote:
If you are planning to re-image an image on a bootable volume then yes
you should use a force parameter. I have lost the discussion about this
on PTG. What is the main use cases? This seems to me something that
could be leveraged with the current
Keystone is failing because it's missing a fix from oslo.messaging [0].
That said, keystone is also relying on an internal implementation detail in
oslo.messaging by mocking it in tests [1]. The notification work has been
around in keystone for a *long* time, but it's apparent that we should
On 10/8/18 11:59 PM, Matthew Thode wrote:
> several projects have had problems with the new release, some have ways
> of working around it, and some do not. I'm sending this just to raise
> the issue and allow a place to discuss solutions.
>
> Currently there is a review proposed to blacklist
On Sun, Sep 30, 2018 at 3:43 AM Miguel Lavalle wrote:
> The next step is for each project to propose the jobs that they want to
> run against Neutron patches.
>
This is fantastic. Do you plan to have all patches under a single topic for
easier tracking? I'll be handling the proposal of these
If you are planning to re-image an image on a bootable volume then yes you
should use a force parameter. I have lost the discussion about this on PTG.
What is the main use cases? This seems to me something that could be
leveraged with the current revert-to-snapshot API, which would be even
better.
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.
>
On Mon, Oct 8, 2018 at 5:58 AM Gilles Dubreuil wrote:
>
> On 05/10/18 21:54, Jim Rollenhagen wrote:
>
> GraphQL has introspection features that allow clients to pull the schema
> (types, queries, mutations, etc): https://graphql.org/learn/introspection/
>
> That said, it seems like using this in
On Tue, 9 Oct 2018 at 12:03, Florian Engelmann <
florian.engelm...@everyware.ch> wrote:
> Am 10/9/18 um 11:04 AM schrieb Mark Goddard:
> > Thanks for these suggestions Florian, there are some interesting ideas
> > in here. I'm a little concerned about the maintenance overhead of adding
> >
On 10/09/2018 06:34 AM, Florian Engelmann wrote:
Am 10/9/18 um 11:41 AM schrieb Jay Pipes:
On 10/09/2018 04:34 AM, Christian Berendt wrote:
On 8. Oct 2018, at 19:48, Jay Pipes wrote:
Why not send all read and all write traffic to a single haproxy
endpoint and just have haproxy spread all
I won't be able to chair the edge squad meeting this week. Can anyone
take it over? If not, we'll pick it back up next week.
--
-- James Slagle
--
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
Am 10/9/18 um 11:04 AM schrieb Mark Goddard:
Thanks for these suggestions Florian, there are some interesting ideas
in here. I'm a little concerned about the maintenance overhead of adding
support for all of these things, and wonder if some of them could be
done without explicit support in
Am 10/9/18 um 11:41 AM schrieb Jay Pipes:
On 10/09/2018 04:34 AM, Christian Berendt wrote:
On 8. Oct 2018, at 19:48, Jay Pipes wrote:
Why not send all read and all write traffic to a single haproxy
endpoint and just have haproxy spread all traffic across each Galera
node?
Galera, after
On Mon, Oct 8, 2018 at 11:57 PM Ghanshyam Mann
wrote:
>
>
>
> On Mon, 08 Oct 2018 23:27:06 +0900 Doug Hellmann <
> d...@doughellmann.com> wrote
> > TC members,
> >
> > Since we are starting a new term, and have several new members, we need
> > to decide how we want to rotate the
Hi,
Setup
-
nested allocation: an allocation that contains resources from one or
more nested RPs. (if you have better term for this then please suggest).
If an instance has nested allocation it means that the compute, it
allocates from, has a nested RP tree. BUT if a compute has a nested
On 10/09/2018 04:34 AM, Christian Berendt wrote:
On 8. Oct 2018, at 19:48, Jay Pipes wrote:
Why not send all read and all write traffic to a single haproxy endpoint and
just have haproxy spread all traffic across each Galera node?
Galera, after all, is multi-master synchronous
Thanks for these suggestions Florian, there are some interesting ideas in
here. I'm a little concerned about the maintenance overhead of adding
support for all of these things, and wonder if some of them could be done
without explicit support in kolla and kolla-ansible. The kolla projects
have
> On 8. Oct 2018, at 19:48, Jay Pipes wrote:
>
> Why not send all read and all write traffic to a single haproxy endpoint and
> just have haproxy spread all traffic across each Galera node?
>
> Galera, after all, is multi-master synchronous replication... so it shouldn't
> matter which node
Hi Hongbin,
I'll add this to our meeting agenda for tomorrow, but I see no reason why
we should not make another queens series release.
Cheers,
Mark
On Sun, 7 Oct 2018 at 18:50, Hongbin Lu wrote:
> Hi Kolla team,
>
> I have a fixup on the configuration of Zun service:
>
Hi,
I just wanted to follow up on this for documentation purpose. Although
I still don't have all answers there's something I can explain.
When I upload a new image (iso) to create a new base image for glance,
and I use "--disk-format iso", this will lead to the described
behavior, nova
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
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
a reminder for all, please put your ideas/thoughts/suggest actions in our
etherpad [1],
which we gonna use for further discussion in Forum, or in PTG if we got no
forum for it.
So we won't be missing anything.
[1] https://etherpad.openstack.org/p/autoscaling-integration-and-feedback
On Tue,
> >One approach would be to switch the underlying Heat AutoScalingGroup
> >implementation to use Senlin and then deprecate the AutoScalingGroup
> >resource type in favor of the Senlin resource type over several
> >cycles.
>
> The hard part (or one hard part, at least) of that is migrating the
72 matches
Mail list logo
