I'm trying so hard to catch up the discussion since I lost few.., it is
really hard...
In my mind , I'm always thinking the request group is only about binding
the trait and the resource class together. Also thinking about whether we
need a explicit tree structure to describe the request. So sound
Hi Hamdy,
Thanks for quick action.
Regards
Maciej
From: Hamdy Khader [mailto:ham...@mellanox.com]
Sent: Tuesday, April 17, 2018 12:51 PM
To: OpenStack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Os-brick][Cinder] NVMe-oF NQN string
Hi,
I think you're right, will drop the split and pu
On Thu, Apr 19, 2018 at 12:45 AM, Eric Fried wrote:
I have a feeling we're just going to go back and forth on this, as
we
have for weeks now, and not reach any conclusion that is
satisfactory to
everyone. And we'll delay, yet again, getting functionality into
this
release that serves 90%
On Wed, 18 Apr 2018, Eric Fried wrote:
I have a feeling we're just going to go back and forth on this, as we
have for weeks now, and not reach any conclusion that is satisfactory to
everyone. And we'll delay, yet again, getting functionality into this
release that serves 90% of use cases because
2018-04-19 10:38 GMT+02:00 Balázs Gibizer :
>
>
> On Thu, Apr 19, 2018 at 12:45 AM, Eric Fried wrote:
>
>> I have a feeling we're just going to go back and forth on this, as we
>>> have for weeks now, and not reach any conclusion that is satisfactory to
>>> everyone. And we'll delay, yet again
Dear all,
a quick update on the current status.
Zuul has been fixed to use the correct branch for roles coming from
different repositories [1].
The backport of the devstack patches to support multinode jobs is almost
complete. All stable/queens patches are merged, stable/pike patches are
almost a
gibi-
> Can the proximity param specify relationship between the un-numbered and
> the numbered groups as well or only between numbered groups?
> Besides that I'm +1 about proxyimity={isolate|any}
Remembering that the resources in the un-numbered group can be spread
around the tree and sharing pr
Chris-
Thanks for this perspective. I totally agree.
> * the common behavior should require the least syntax.
To that point, I had been assuming "any fit" was going to be more common
than "explicit anti-affinity". But I think this is where we are having
trouble agreeing. So since, as you poin
Sylvain-
> What's the default behaviour if we aren't providing the proximity qparam
> ? Isolate or any ?
What we've been talking about, per mriedem's suggestion, is that the
qparam is required when you specify any numbered request groups. There
is no default. If you don't provide the qparam, 40
On Thu, Apr 19, 2018 at 2:27 PM, Eric Fried wrote:
gibi-
Can the proximity param specify relationship between the
un-numbered and
the numbered groups as well or only between numbered groups?
Besides that I'm +1 about proxyimity={isolate|any}
Remembering that the resources in the un-num
Excerpts from Mark Kirkwood's message of 2018-04-19 16:47:58 +1200:
> Swift has had storage policies for a while now. These are enabled by
> setting the 'X-Storage-Policy' header on a container.
>
> It looks to me like this is not possible using openstack-client (even in
> master branch) - while
===
#openstack-doc: docteam
===
Meeting started by pkovar at 16:02:48 UTC. The full logs are available
at
http://eavesdrop.openstack.org/meetings/docteam/2018/docteam.2018-04-18-16.02.log.html
.
Meeting summary
---
* Open discussion (pkova
Hi,
When configuring TripleO deployments with nodes on routed ctlplane
networks we need to pass some per-network properties to the
NetworkConfig resource[1] in THT. We get the ``ControlPlaneIp``
property using get_attr, but the NIC configs need a couple of more
parameters[2], for example: ``Contro
We've had inconsistent naming of recreate/evacuate in Nova for a long
time, and it will persist in a couple of places for a while more.
However, I've proposed the following to rename 'recreate' to
'evacuate' everywhere with no rpc/api impact here:
https://review.openstack.org/560900
One of the th
Today is the deadline for proposing a release for the Rocky-1 milestone.
Please don't forget to include your libraries (client or otherwise) as
well.
Doug
__
OpenStack Development Mailing List (not for usage questions)
Unsubs
Two different setups, very basic.
AggregateInstanceExtraSpecsFilter
RetryFilter
AvailabilityZoneFilter
ComputeFilter
ComputeCapabilitiesFilter
ImagePropertiesFilter
ServerGroupAntiAffinityFilter
ServerGroupAffinityFilter
RetryFilter
AvailabilityZoneFilter
RamFilter
ComputeFilter
ComputeCapabiliti
Hello fellow packagers,
During today's meeting [1], we discussed the schedule conflicts some of us have
with the current meeting slot. As a result, I would like to propose a new
meeting time:
- Wednesdays, 1 PM UTC (3 PM CEST)
So far, dirk and jruzicka agreed with the change. If you have an is
Excerpts from Doug Hellmann's message of 2018-04-19 09:38:31 -0400:
> Excerpts from zuul's message of 2018-04-19 13:22:40 +:
> > Build failed.
> >
> > - release-openstack-python
> > http://logs.openstack.org/c9/c9263cde360d37654c4298c496cd9af251f23ce7/pre-release/release-openstack-python/541a
Excerpts from zuul's message of 2018-04-19 13:22:40 +:
> Build failed.
>
> - release-openstack-python
> http://logs.openstack.org/c9/c9263cde360d37654c4298c496cd9af251f23ce7/pre-release/release-openstack-python/541ad7d/
> : FAILURE in 3m 48s
> - announce-release announce-release : SKIPPED
>
Hello,
>From my understanding, we have a race between the scheduling
process and host weight update.
I made a simple experiment. On the 50 fake host environment
it was asked to boot 40 VMs those should be placed 1 on each host.
The hosts are equal to each other in terms of inventory.
img=6fedf6a
On 04/19/2018 09:15 AM, Matthew Booth wrote:
We've had inconsistent naming of recreate/evacuate in Nova for a long
time, and it will persist in a couple of places for a while more.
However, I've proposed the following to rename 'recreate' to
'evacuate' everywhere with no rpc/api impact here:
htt
All,
Please note that Bandits code and issues / docs will be migrated from
OpenStack to PyCQA.
This is expected to happen next week.
No changes are required in any projects or CI, as Bandit will still be
available via pypi and projects / CI are set up to use Bandit in that way
via tox.
READMEs
Andrea Frittoli writes:
> Dear all,
>
> a quick update on the current status.
>
> Zuul has been fixed to use the correct branch for roles coming from
> different repositories [1].
> The backport of the devstack patches to support multinode jobs is almost
> complete. All stable/queens patches are
Thanks to everyone who contributed to this discussion. With just a
teeny bit more bikeshedding on the exact syntax [1], we landed on:
group_policy={none|isolate}
I have proposed this delta to the granular spec [2].
-efried
[1]
http://p.anticdent.org/logs/openstack-placement?dated=2018-04-19%20
On 04/19/2018 08:33 AM, Jay Pipes wrote:
On 04/19/2018 09:15 AM, Matthew Booth wrote:
We've had inconsistent naming of recreate/evacuate in Nova for a long
time, and it will persist in a couple of places for a while more.
However, I've proposed the following to rename 'recreate' to
'evacuate' ev
Привет, Андрей! Comments inline...
On 04/19/2018 10:27 AM, Andrey Volkov wrote:
Hello,
From my understanding, we have a race between the scheduling
process and host weight update.
I made a simple experiment. On the 50 fake host environment
it was asked to boot 40 VMs those should be placed 1
Hello from Infra.
This is our weekly reminder of the upcoming gerrit replacement. We'll continue
to send these announcements out up until the day of the migration. We are now 2
weeks away from replacement date.
If you have any questions, please contact us in #openstack-infra.
---
It's that tim
On 19 April 2018 at 15:33, Jay Pipes wrote:
> On 04/19/2018 09:15 AM, Matthew Booth wrote:
>>
>> We've had inconsistent naming of recreate/evacuate in Nova for a long
>> time, and it will persist in a couple of places for a while more.
>> However, I've proposed the following to rename 'recreate' t
On 19 April 2018 at 16:46, Chris Friesen wrote:
> On 04/19/2018 08:33 AM, Jay Pipes wrote:
>>
>> On 04/19/2018 09:15 AM, Matthew Booth wrote:
>>>
>>> We've had inconsistent naming of recreate/evacuate in Nova for a long
>>> time, and it will persist in a couple of places for a while more.
>>> Howe
Greetings OpenStack community,
As it was just edleafe and I today, we had a quick meeting and went back to
other things. The main actions were to select one guideline to publish and one
guideline to freeze. These are listed below. We also briefly discussed that
though we have not planned any
On 4/19/2018 11:06 AM, Matthew Booth wrote:
I'm ambivalent, tbh, but I think it's better to pick one. I thought
we'd picked 'evacuate' based on the TODOs from Matt R:
http://git.openstack.org/cgit/openstack/nova/tree/nova/compute/manager.py#n2985
http://git.openstack.org/cgit/openstack/nova/tree
On 4/19/2018 10:46 AM, Chris Friesen wrote:
From the CLI perspective, it makes no sense that "nova evacuate"
operates after a host is already down, but "nova evacuate-live" operates
on a running host.
http://www.danplanet.com/blog/2016/03/03/evacuate-in-nova-one-command-to-confuse-us-all/
If
On 04/19/2018 12:27 PM, Matt Riedemann wrote:
On 4/19/2018 11:06 AM, Matthew Booth wrote:
I'm ambivalent, tbh, but I think it's better to pick one. I thought
we'd picked 'evacuate' based on the TODOs from Matt R:
http://git.openstack.org/cgit/openstack/nova/tree/nova/compute/manager.py#n2985
On Thu, Apr 19, 2018 at 7:51 AM, Doug Hellmann wrote:
> Excerpts from Mark Kirkwood's message of 2018-04-19 16:47:58 +1200:
>> Swift has had storage policies for a while now. These are enabled by
>> setting the 'X-Storage-Policy' header on a container.
>>
>> It looks to me like this is not possibl
Greetings,
As you probably know mcornea on IRC, Marius Cornea has been contributing on
TripleO for a while, specially on the upgrade bits.
Part of the quality team, he's always testing real customer scenarios and
brings a lot of good feedback in his reviews, and quite often takes care of
fixing co
+1
On Thu, Apr 19, 2018 at 1:01 PM, Emilien Macchi wrote:
> Greetings,
>
> As you probably know mcornea on IRC, Marius Cornea has been contributing on
> TripleO for a while, specially on the upgrade bits.
> Part of the quality team, he's always testing real customer scenarios and
> brings a lot o
All aboard! Next stop Denver!
The fourth Project Teams Gathering [1] will be held September 10-14th back at
the Renaissance Stapleton Hotel [2] in Denver, Colorado (3801 Quebec Street,
Denver, Colorado 80207). The Project Teams Gathering (PTG) is an event
organized by the OpenStack Foundation.
Thank you, Doug. Question: do we need to do a client library release prior
to R-3? The practice seems to change from cycle to cycle.
On 4/19/18, 6:15 AM, "Doug Hellmann" wrote:
>Today is the deadline for proposing a release for the Rocky-1 milestone.
>Please don't forget to include your librarie
Specifically, for client library using the cycle-with-intermediary release
model.
On 4/19/18, 10:52 AM, "Eric K" wrote:
>Thank you, Doug. Question: do we need to do a client library release prior
>to R-3? The practice seems to change from cycle to cycle.
>
>On 4/19/18, 6:15 AM, "Doug Hellmann"
+1 :D hell yeah!
On Thu, 19 Apr 2018, 20:05 John Fulton, wrote:
> +1
>
> On Thu, Apr 19, 2018 at 1:01 PM, Emilien Macchi
> wrote:
> > Greetings,
> >
> > As you probably know mcornea on IRC, Marius Cornea has been contributing
> on
> > TripleO for a while, specially on the upgrade bits.
> > Part
Libraries do need to release by R-3 so that we have something to use as
a branch point for the stable branches.
We encourage releases earlier than that, for a couple of reasons.
First, because of the way the CI system works, libraries are generally
not used in test jobs unless they are released.
On 4/19/2018 1:15 PM, Doug Hellmann wrote:
Second, releasing early and often gives us more time to fix issues,
so we aren't rushing around at deadline trying to solve a problem
while the gate is full of other last minute patches for other
projects.
Yup, case in point: I waited too long to relea
Got it thanks a lot, Doug and Matt!
On 4/19/18, 11:34 AM, "Matt Riedemann" wrote:
>On 4/19/2018 1:15 PM, Doug Hellmann wrote:
>> Second, releasing early and often gives us more time to fix issues,
>> so we aren't rushing around at deadline trying to solve a problem
>> while the gate is full of o
Excerpts from Jim Rollenhagen's message of 2018-04-18 13:44:08 -0400:
> Hi all,
>
> We have a number of stable branch jobs failing[0] with an error about pep8
> not being importable[1], when it's clearly installed[2]. We first saw this
> when installing networking-generic-switch on queens in our m
Excerpts from Matt Riedemann's message of 2018-04-19 13:34:44 -0500:
> On 4/19/2018 1:15 PM, Doug Hellmann wrote:
> > Second, releasing early and often gives us more time to fix issues,
> > so we aren't rushing around at deadline trying to solve a problem
> > while the gate is full of other last mi
Greetings,
I'd like to propose now that we have debian-stable (stretch) nodesets online for
nodepool, that we start the process to remove debian-jessie. As I can see,
there really is only 2 projects using debian-jessie:
* ARA
* ansible-hardening
I've already proposed patches to update their
How loose are we with saying things like, "you should run this as root"
in the docs?
I was triaging this nova bug [1] which is saying that the docs should
tell you to run nova-status (which implies also nova-manage) as root,
but isn't running admin-level CLIs implied that you need root, or
so
Matt Riedemann wrote on 04/19/2018 06:11:58 PM:
> How loose are we with saying things like, "you should run this as root"
> in the docs?
>
> I was triaging this nova bug [1] which is saying that the docs should
> tell you to run nova-status (which implies also nova-manage) as root,
> but isn't r
Greetings,
With ubuntu-bionic release around the corner we'll be starting discussions about
migrating jobs from ubuntu-xenial to ubuntu-bionic.
On topic I'd like to raise, is round job migrations from legacy to native
zuulv3. Specifically, I'd like to propose we do not add legacy-ubuntu-bionic
n
Dear Neutron-Release team,
I wonder if any of you can add me to the network-onos-release member.
It seems that Vikram is busy. :-)
Thank you,
Sangho
> On 19 Apr 2018, at 9:18 AM, Sangho Shin wrote:
>
> Ian,
>
> Thank you so much for your help.
> I have requested Vikram to add me to the re
Hi SDK team,
Few weeks back we have moved "instance_ha" service code from
python-masakariclient into openstacksdk project in patch [1] and it got merged.
Currently, masakari-monitors is totally broken and it requires newer version of
openstacksdk. We have proposed a patch [2] in masakari-monito
I’m also seeing this issue, but with Routers and networks as well.
The apache server running horizon logs the following
ERROR horizon.tables.base Error while checking action permissions.
Traceback (most recent call last):
File "/usr/share/openstack-dashboard/horizon/tables/base.py", line 1389, i
52 matches
Mail list logo
