Re: [openstack-dev] [Openstack-operators] [nova][neutron] How do you use the instance IP filter?

[Joshua Harlow]

Further things that someone may want to read/try (if the below is true),

https://en.wikipedia.org/wiki/ReDoS

Joshua Harlow wrote:

Just the paranoid person in me, but is it safe to say that the filter
that you are showing here does not come from user text?

Ie these two lines don't come from a user input directly (without going
through some filter) do they?

https://github.com/openstack/nova/blob/16.0.0/nova/compute/api.py#L2458-L2459


 From reading it seems like perhaps they do come at least partially from
a user, so I am hoping that its not possible for a user to present a
'ip' that is really a complicated regex that takes a long time to
compile (and therefore can DOS the nova-api component); but I don't know
the surrounding code so I might be wrong...

Just wondering :-/

-Josh

Matt Riedemann wrote:

Nova has had this long-standing known performance issue if you're
filtering a large number of instances by IP. The instance IPs are stored
in a JSON blob in the database so we don't do filtering in SQL. We pull
the instances out of the database, deserialize the JSON and then apply a
regex filter match in the nova-api python code.

At the Queens PTG we talked about possible ways to fix this and came up
with this nova spec:

https://specs.openstack.org/openstack/nova-specs/specs/queens/approved/improve-filter-instances-by-ip-performance.html



The idea is to have nova get ports from neutron and apply the IP filter
in neutron to whittle down the ports, then from that list of ports get
the instances to pull out of the nova database.

One issue that has come up with this is neutron does not currently
support regex filters when listing ports. There is an RFE for adding
that:

https://bugs.launchpad.net/neutron/+bug/1718605

The proposed neutron implementation is to just do SQL LIKE substring
matching in the database.

However, one issue that has come up is that the compute API accepts a
python regex filter and uses re.match():

https://github.com/openstack/nova/blob/16.0.0/nova/compute/api.py#L2469

At least one good thing about that is match() only matches from the
beginning of the string unlike search().

So for example I can filter on "192.16.*[1-5]$" if I wanted to, but
that's not going to work with just a LIKE substring filter in SQL.

The question is, does anyone actually do more than basic substring
matching with the IP filter today? Because if we started using neutron,
that behavior would be broken. We've never actually documented the match
restrictions on the IP filter, but that's not a good reason to break it.

One option is to make this configurable such that deployments which rely
on the complicated pattern matching can just use the existing nova code
despite performance issues. However, that's not interoperable, I hate
config-driven API behavior, and it would mean maintaining two code paths
in nova, which is also terrible.

I was trying to think of a way to determine if the IP filter passed to
nova is basic or a complicated pattern match and let us decide that way,
but I'm not sure if there are good ways to detect that - maybe by simply
looking for special characters like (, ), - and $? But then there is []
and we have an IPv6 filter, so that gets messy too...

For now I'd just like to know if people rely on the regex match or not.
Other ideas on how to handle this are appreciated.




___
OpenStack-operators mailing list
openstack-operat...@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators



__
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][neutron] How do you use the instance IP filter?

[Joshua Harlow]

Just the paranoid person in me, but is it safe to say that the filter 
that you are showing here does not come from user text?


Ie these two lines don't come from a user input directly (without going 
through some filter) do they?


https://github.com/openstack/nova/blob/16.0.0/nova/compute/api.py#L2458-L2459

From reading it seems like perhaps they do come at least partially from 
a user, so I am hoping that its not possible for a user to present a 
'ip' that is really a complicated regex that takes a long time to 
compile (and therefore can DOS the nova-api component); but I don't know 
the surrounding code so I might be wrong...


Just wondering :-/

-Josh

Matt Riedemann wrote:

Nova has had this long-standing known performance issue if you're
filtering a large number of instances by IP. The instance IPs are stored
in a JSON blob in the database so we don't do filtering in SQL. We pull
the instances out of the database, deserialize the JSON and then apply a
regex filter match in the nova-api python code.

At the Queens PTG we talked about possible ways to fix this and came up
with this nova spec:

https://specs.openstack.org/openstack/nova-specs/specs/queens/approved/improve-filter-instances-by-ip-performance.html


The idea is to have nova get ports from neutron and apply the IP filter
in neutron to whittle down the ports, then from that list of ports get
the instances to pull out of the nova database.

One issue that has come up with this is neutron does not currently
support regex filters when listing ports. There is an RFE for adding that:

https://bugs.launchpad.net/neutron/+bug/1718605

The proposed neutron implementation is to just do SQL LIKE substring
matching in the database.

However, one issue that has come up is that the compute API accepts a
python regex filter and uses re.match():

https://github.com/openstack/nova/blob/16.0.0/nova/compute/api.py#L2469

At least one good thing about that is match() only matches from the
beginning of the string unlike search().

So for example I can filter on "192.16.*[1-5]$" if I wanted to, but
that's not going to work with just a LIKE substring filter in SQL.

The question is, does anyone actually do more than basic substring
matching with the IP filter today? Because if we started using neutron,
that behavior would be broken. We've never actually documented the match
restrictions on the IP filter, but that's not a good reason to break it.

One option is to make this configurable such that deployments which rely
on the complicated pattern matching can just use the existing nova code
despite performance issues. However, that's not interoperable, I hate
config-driven API behavior, and it would mean maintaining two code paths
in nova, which is also terrible.

I was trying to think of a way to determine if the IP filter passed to
nova is basic or a complicated pattern match and let us decide that way,
but I'm not sure if there are good ways to detect that - maybe by simply
looking for special characters like (, ), - and $? But then there is []
and we have an IPv6 filter, so that gets messy too...

For now I'd just like to know if people rely on the regex match or not.
Other ideas on how to handle this are appreciated.




__
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][neutron] How do you use the instance IP filter?

[Tony Breeds]

On Thu, Oct 26, 2017 at 10:35:47PM -0500, Matt Riedemann wrote:
> On 10/26/2017 9:54 PM, Tony Breeds wrote:
> > Can you use RLIKE/REGEX? or is that too MySQL specific ?
> 
> I thought about that, and my gut response is 'no' because even if it does
> work for mysql, I'm assuming regex pattern matching for postgresql is
> different. And then you have different API behavior between clouds based on
> the backend database they are using, and now we've opened that whole can of
> worms again.

Yeah:
column.op('rlike')() # Mysql
column.op('~')() # Pgsql

I have no idea if the regexs themselves would be compatible and of
course there are other RDBMSs

Yours Tony.


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

Re: [openstack-dev] [nova][neutron] How do you use the instance IP filter?

[Matt Riedemann]

On 10/26/2017 9:54 PM, Tony Breeds wrote:

Can you use RLIKE/REGEX? or is that too MySQL specific ?


I thought about that, and my gut response is 'no' because even if it 
does work for mysql, I'm assuming regex pattern matching for postgresql 
is different. And then you have different API behavior between clouds 
based on the backend database they are using, and now we've opened that 
whole can of worms again.


--

Thanks,

Matt

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

Re: [openstack-dev] [nova][ironic] Concerns over rigid resource class-only ironic scheduling

[Nisha Agarwal]

Hi John,

>@Nisha I think that should largely allow you to construct the same
behavior you have today, or am I totally missing what you are wanting to do?

Yes, i agree that qualitative capabilities are covered by your spec and
will give us the behaviour as its today with your spec implemented.


Regards
Nisha

On Fri, Oct 27, 2017 at 8:12 AM, Ed Leafe  wrote:

> On Oct 26, 2017, at 6:57 PM, Wan-yen Hsu  wrote:
>
> > In Nisha's message, "capabilities" refers to
> "ComputeCapabilitiesFilter".   "capabilities" provides a lot of flexibility
> for scheduling.  It supports qualitative as well as quantitative
> attributes.  It supports a variety of operators such as ">=", "<", "=",
> etc.   For instance, with "capabilities", one can create a flavor for
> "GPU_Count >=2".  Quantity matters for workloads.  A workload may require
> at least 2GPUs or at least certain amount of SSD capacity to meet the
> performance requirements.   Trait will help but it only supports
> qualitative attributes.  Therefore, we still need "capabilities".
>
> In your example, you would create a resource class that specifies the
> number of GPUs. If there is a machine with no GPU, it would be a different
> resource class than a machine with a GPU. Likewise, a machine with 2 GPUs
> would be a different class. This gives you the ability to match the request
> to the need. Saying you need a machine with at least 2 GPUs means that you
> could end up with a machine with 100 GPUs - ok, I know that's not
> realistic, but it illustrates my point. Each hardware combination is a
> separate resource class. If your workload requires 2 GPUs and SSD, there
> are a finite number of hardware combinations available. You pick the flavor
> (i.e., resource class) that matches your need.
>
>
> -- Ed Leafe
>
>
>
>
>
>
> __
> 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 Secret Of Success is learning how to use pain and pleasure, instead
of having pain and pleasure use you. If You do that you are in control
of your life. If you don't life controls you.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [heat][horizon] Migration to heat-dashboard: how can we move this forward?

[Kaz Shinohara]

Hi Akihiro,

Much appreciated for giving us the right direction.
We are totally on same page as you & will let you know when
heat-dashboard is ready.

> AFAIK, the only patch which landed after the heat-dashboard repo was created 
> is
> https://review.openstack.org/#/c/498838/
Thanks!  will pick up this later :)

Regards,
Kaz Shinohara

2017-10-27 0:27 GMT+09:00 Akihiro Motoki :
> Hi Kaz,
>
> Thanks for sharing the current status of heat-dashboard.
> Queens-2 sounds a reasonable milestone.
>
> I summarize the near-future below. Right?
>
> - heat-dashboard team is preparing for heat dashboard split-out.
>   The horizon parity (including stability) is the current focus.
> - Heat related bugs filed to horizon can be hold until the
> heat-dashboard is ready (around Q-2)
>   After it is ready, they will be forwarded to heat-dashboard from
> horizon launchpad
>   and we can fix them in the heat-dashboard repository.
> - Horizon team tries not to approve heat-related patches without strong 
> reasons.
>
>> Of course we will keep looking at what's going on in Horizon side &
>> will cherry-pick the leftovers if needed in the end.
>
> AFAIK, the only patch which landed after the heat-dashboard repo was created 
> is
> https://review.openstack.org/#/c/498838/
>
> Thanks,
> Akihiro
>
> 2017-10-25 13:11 GMT+09:00 Kaz Shinohara :
>>  Hi Akihiro,
>>
>>
>> Thanks for your kind following up :)
>>
>>> (1) Patch reviews and approvals in horizon
>> Could you please stop to accept heat-dashboard related patches without
>> critical ones ?
>> According to our discussion in the last PTG, we made heat-dashboard
>> repo taking horizon repo as upstream & now trying to land it in
>> queens-2.
>> Of course we will keep looking at what's going on in Horizon side &
>> will cherry-pick the leftovers if needed in the end.
>>
>>> (2) Bug Management
>> Yes we can take over those bugs, but now we are focusing to stabilize
>> heat-dashboard-self.
>> We would like to fix them after we will safely land heat-dashboard in 
>> queens-2.
>>
>> Regards,
>> Kaz Shinohara
>>
>> 2017-10-25 11:47 GMT+09:00 Akihiro Motoki :
>>> Hi Heat dashboard team,
>>>
>>> I noticed heat-dashboard repository was created.
>>> I have several questions from horizon side.
>>>
>>> A big question is "When does the switch happen?"
>>>
>>> This mainly affects two things:
>>>
>>> (1) Patch reviews and approvals in horizon
>>>
>>> Should the horizon team stop to accept heat-dashboard related patches
>>> into the horizon repo now?
>>> If you want to migrate in parallel, you need to take care of what
>>> happens in the horizon repo continuously.
>>> The simplest way is to stop any activities in horizon side.
>>>
>>> Note that one patch landed yesterday into the horizon repo.
>>> Perhaps the heat-dashboard team will cherry-pick it into your repository.
>>>
>>> (2) Bug Management
>>>
>>> Is it okay to forward heat-related bugs into heat-dashboard launchpad?
>>> When do we start?
>>> There are several number of existing bugs related to the heat dashboard.
>>> The horizon team now just adds 'heat' tag and is waiting for heat-dashboard.
>>> https://bugs.launchpad.net/horizon/+bugs?field.tag=heat
>>>
>>> Thanks,
>>> Akihiro
>>>
>>> __
>>> 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] [nova][neutron] How do you use the instance IP filter?

[Tony Breeds]

On Thu, Oct 26, 2017 at 09:23:50PM -0500, Matt Riedemann wrote:
> Nova has had this long-standing known performance issue if you're filtering
> a large number of instances by IP. The instance IPs are stored in a JSON
> blob in the database so we don't do filtering in SQL. We pull the instances
> out of the database, deserialize the JSON and then apply a regex filter
> match in the nova-api python code.
> 
> At the Queens PTG we talked about possible ways to fix this and came up with
> this nova spec:
> 
> https://specs.openstack.org/openstack/nova-specs/specs/queens/approved/improve-filter-instances-by-ip-performance.html
> 
> The idea is to have nova get ports from neutron and apply the IP filter in
> neutron to whittle down the ports, then from that list of ports get the
> instances to pull out of the nova database.
> 
> One issue that has come up with this is neutron does not currently support
> regex filters when listing ports. There is an RFE for adding that:
> 
> https://bugs.launchpad.net/neutron/+bug/1718605
> 
> The proposed neutron implementation is to just do SQL LIKE substring
> matching in the database.

Can you use RLIKE/REGEX? or is that too MySQL specific ?

Yours Tony.


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

Re: [openstack-dev] [nova][ironic] Concerns over rigid resource class-only ironic scheduling

[Ed Leafe]

On Oct 26, 2017, at 6:57 PM, Wan-yen Hsu  wrote:

> In Nisha's message, "capabilities" refers to "ComputeCapabilitiesFilter".   
> "capabilities" provides a lot of flexibility for scheduling.  It supports 
> qualitative as well as quantitative attributes.  It supports a variety of 
> operators such as ">=", "<", "=", etc.   For instance, with "capabilities", 
> one can create a flavor for "GPU_Count >=2".  Quantity matters for workloads. 
>  A workload may require at least 2GPUs or at least certain amount of SSD 
> capacity to meet the performance requirements.   Trait will help but it only 
> supports qualitative attributes.  Therefore, we still need "capabilities".

In your example, you would create a resource class that specifies the number of 
GPUs. If there is a machine with no GPU, it would be a different resource class 
than a machine with a GPU. Likewise, a machine with 2 GPUs would be a different 
class. This gives you the ability to match the request to the need. Saying you 
need a machine with at least 2 GPUs means that you could end up with a machine 
with 100 GPUs - ok, I know that's not realistic, but it illustrates my point. 
Each hardware combination is a separate resource class. If your workload 
requires 2 GPUs and SSD, there are a finite number of hardware combinations 
available. You pick the flavor (i.e., resource class) that matches your need.


-- Ed Leafe







signature.asc
Description: Message signed with OpenPGP
__
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][neutron] How do you use the instance IP filter?

[Mohammed Naser]

On Thu, Oct 26, 2017 at 10:23 PM, Matt Riedemann 
wrote:

> Nova has had this long-standing known performance issue if you're
> filtering a large number of instances by IP. The instance IPs are stored in
> a JSON blob in the database so we don't do filtering in SQL. We pull the
> instances out of the database, deserialize the JSON and then apply a regex
> filter match in the nova-api python code.
>
> At the Queens PTG we talked about possible ways to fix this and came up
> with this nova spec:
>
> https://specs.openstack.org/openstack/nova-specs/specs/queen
> s/approved/improve-filter-instances-by-ip-performance.html
>
> The idea is to have nova get ports from neutron and apply the IP filter in
> neutron to whittle down the ports, then from that list of ports get the
> instances to pull out of the nova database.
>
> One issue that has come up with this is neutron does not currently support
> regex filters when listing ports. There is an RFE for adding that:
>
> https://bugs.launchpad.net/neutron/+bug/1718605
>
> The proposed neutron implementation is to just do SQL LIKE substring
> matching in the database.
>
> However, one issue that has come up is that the compute API accepts a
> python regex filter and uses re.match():
>
> https://github.com/openstack/nova/blob/16.0.0/nova/compute/api.py#L2469
>
> At least one good thing about that is match() only matches from the
> beginning of the string unlike search().
>
> So for example I can filter on "192.16.*[1-5]$" if I wanted to, but that's
> not going to work with just a LIKE substring filter in SQL.
>
> The question is, does anyone actually do more than basic substring
> matching with the IP filter today? Because if we started using neutron,
> that behavior would be broken. We've never actually documented the match
> restrictions on the IP filter, but that's not a good reason to break it.
>

The use-case for us is that it helps us easily identify or find VMs which
we get any abuse reports for (or anything we see malicious traffic going
to/from).  We usually search for an *exact* match of the IP address as we
are simply trying to perform a lookup of instance ID based on the IP
address.  Regex matching isn't important in our case.


> One option is to make this configurable such that deployments which rely
> on the complicated pattern matching can just use the existing nova code
> despite performance issues. However, that's not interoperable, I hate
> config-driven API behavior, and it would mean maintaining two code paths in
> nova, which is also terrible.
>
> I was trying to think of a way to determine if the IP filter passed to
> nova is basic or a complicated pattern match and let us decide that way,
> but I'm not sure if there are good ways to detect that - maybe by simply
> looking for special characters like (, ), - and $? But then there is [] and
> we have an IPv6 filter, so that gets messy too...
>
> For now I'd just like to know if people rely on the regex match or not.
> Other ideas on how to handle this are appreciated.
>
> --
>
> Thanks,
>
> Matt
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [nova][neutron] How do you use the instance IP filter?

[Matt Riedemann]

Nova has had this long-standing known performance issue if you're 
filtering a large number of instances by IP. The instance IPs are stored 
in a JSON blob in the database so we don't do filtering in SQL. We pull 
the instances out of the database, deserialize the JSON and then apply a 
regex filter match in the nova-api python code.


At the Queens PTG we talked about possible ways to fix this and came up 
with this nova spec:


https://specs.openstack.org/openstack/nova-specs/specs/queens/approved/improve-filter-instances-by-ip-performance.html

The idea is to have nova get ports from neutron and apply the IP filter 
in neutron to whittle down the ports, then from that list of ports get 
the instances to pull out of the nova database.


One issue that has come up with this is neutron does not currently 
support regex filters when listing ports. There is an RFE for adding that:


https://bugs.launchpad.net/neutron/+bug/1718605

The proposed neutron implementation is to just do SQL LIKE substring 
matching in the database.


However, one issue that has come up is that the compute API accepts a 
python regex filter and uses re.match():


https://github.com/openstack/nova/blob/16.0.0/nova/compute/api.py#L2469

At least one good thing about that is match() only matches from the 
beginning of the string unlike search().


So for example I can filter on "192.16.*[1-5]$" if I wanted to, but 
that's not going to work with just a LIKE substring filter in SQL.


The question is, does anyone actually do more than basic substring 
matching with the IP filter today? Because if we started using neutron, 
that behavior would be broken. We've never actually documented the match 
restrictions on the IP filter, but that's not a good reason to break it.


One option is to make this configurable such that deployments which rely 
on the complicated pattern matching can just use the existing nova code 
despite performance issues. However, that's not interoperable, I hate 
config-driven API behavior, and it would mean maintaining two code paths 
in nova, which is also terrible.


I was trying to think of a way to determine if the IP filter passed to 
nova is basic or a complicated pattern match and let us decide that way, 
but I'm not sure if there are good ways to detect that - maybe by simply 
looking for special characters like (, ), - and $? But then there is [] 
and we have an IPv6 filter, so that gets messy too...


For now I'd just like to know if people rely on the regex match or not. 
Other ideas on how to handle this are appreciated.


--

Thanks,

Matt

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

Re: [openstack-dev] [nova][ironic] Concerns over rigid resource class-only ironic scheduling

[Wan-yen Hsu]

In Nisha's message, "capabilities" refers to "ComputeCapabilitiesFilter".
 "capabilities" provides a lot of flexibility for scheduling.  It supports
qualitative as well as quantitative attributes.  It supports a variety of
operators such as ">=", "<", "=", etc.   For instance, with "capabilities",
one can create a flavor for "GPU_Count >=2".  Quantity matters for
workloads.  A workload may require at least 2GPUs or at least certain
amount of SSD capacity to meet the performance requirements.   Trait will
help but it only supports qualitative attributes.  Therefore, we still need
"capabilities".

Standard Resource Class represents quantitative things but it 's not
available for Ironic.   Ironic currently can only use one single
CUSTOM_Resource_class with exact match.  Prior to Pike, Ironic customers
can use  non-exact match filter to support the use case of "at least this
amount of quantitative things on a bare metal node" but it's not supported
by Ironic Custom_resource_class.  Therefore it is a regression and will
cause issues for those who are depending on it.

On 19 October 2017 at 15:38, Jay Pipes  wrote:

> On 10/16/2017 05:31 AM, Nisha Agarwal wrote:
>
>> Hi Matt,
>>
>> As i understand John's spec https://review.openstack.org/#/c/507052/ <
>> https://review.openstack.org/#/c/507052/>, it is actually a replacement
>> for capabilities(qualitative only) for ironic. It doesnt cover the
>> quantitative capabilities as 'traits' are meant only for qualitative
>> capabilities. Quantitative capabilities are covered by resource classes in
>> Nova. We have few (one or two) quantitative capabilities already supported
>> in ironic.
>>
>
> Hi Nisha,
>
> This may be a case of mixed terminology. We do not refer to anything
> quantitative as a "capability". Rather, we use the term "resource class"
> (or sometimes just "resource") to represent quantitative things that may be
> consumed by the instance.
>
> Traits, on the other hand, are qualitative. They represent a binary on/off
> capability that the compute host (or baremetal node in the case of Ironic)
> exposes.
>
> There's no limit on the number of traits that may be associated with a
> particular Ironic baremetal node. However, for Ironic baremetal nodes, if
> the node.resource_class attribute is set, the Nova Ironic virt driver will
> create a single inventory record for the node containing a quantity of 1
> and a resource class equal to whatever is in the node.resource_class
> attribute. This resource class is auto-created by Nova as a custom resource
> class.
>

Just to follow up on this one...

I hope my traits spec will replace the need for the non-exact filters.

Consider two flavors Gold and Gold_Plus. Lets say Gold_plus gives you a
slightly newer CPU, or something.

Consider this setup:

* both GOLD and GOLD_PLUS ironic nodes have Resource Class: CUSTOM_GOLD
* but you can have some have trait: GOLD_REGULAR and some with GOLD_PLUS

Now you can have the flavors:

* GOLD flavor requests resources:CUSTOM_GOLD=1
* GOLD_PLUS flavor also has resources:CUSTOM_GOLD=1 but also
trait:GOLD_PLUS:requires

Now eventually we could modify the GOLD flavor to say:

* resources:CUSTOM_GOLD=1 and trait:GOLD_REGULAR:prefer

@Nisha I think that should largely allow you to construct the same behavior
you have today, or am I totally missing what you are wanting to do?

On Thu, Oct 19, 2017 at 8:37 AM, John Garbutt  wrote:

> On 19 October 2017 at 15:38, Jay Pipes  wrote:
>
>> On 10/16/2017 05:31 AM, Nisha Agarwal wrote:
>>
>>> Hi Matt,
>>>
>>> As i understand John's spec https://review.openstack.org/#/c/507052/ <
>>> https://review.openstack.org/#/c/507052/>, it is actually a replacement
>>> for capabilities(qualitative only) for ironic. It doesnt cover the
>>> quantitative capabilities as 'traits' are meant only for qualitative
>>> capabilities. Quantitative capabilities are covered by resource classes in
>>> Nova. We have few (one or two) quantitative capabilities already supported
>>> in ironic.
>>>
>>
>> Hi Nisha,
>>
>> This may be a case of mixed terminology. We do not refer to anything
>> quantitative as a "capability". Rather, we use the term "resource class"
>> (or sometimes just "resource") to represent quantitative things that may be
>> consumed by the instance.
>>
>> Traits, on the other hand, are qualitative. They represent a binary
>> on/off capability that the compute host (or baremetal node in the case of
>> Ironic) exposes.
>>
>> There's no limit on the number of traits that may be associated with a
>> particular Ironic baremetal node. However, for Ironic baremetal nodes, if
>> the node.resource_class attribute is set, the Nova Ironic virt driver will
>> create a single inventory record for the node containing a quantity of 1
>> and a resource class equal to whatever is in the node.resource_class
>> attribute. This resource class is auto-created by Nova as a custom resource
>> class.
>>
>
> Just to 

Re: [openstack-dev] [openstack-infra][stable][urgent][rally] Someone deleted Rally stable branch, we need to restore

[Tony Breeds]

On Thu, Oct 26, 2017 at 01:36:01PM -0700, Boris Pavlovic wrote:
> Hi,
> 
> Someone somehow deleted 0.9.* branches from GitHub repo
> https://github.com/openstack/rally
> A lot of end users are using these branches and are affected by this
> change.
> 
> Can someone help to restore them?

So sorry this happened.

It's corrected now see [1]  I've modified my tools to call out *all*
affected projects in the subject line to increase visibility.

Yours Tony.

[1]
http://eavesdrop.openstack.org/irclogs/%23openstack-infra/%23openstack-infra.2017-10-26.log.html#t2017-10-26T21:03:17


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

Re: [openstack-dev] [ironic] [Openstack-operators] replace node "tags" with node "traits"

[Jay Pipes]

On 10/25/2017 12:55 PM, Mathieu Gagné wrote:

Hi,

On Wed, Oct 25, 2017 at 10:17 AM, Loo, Ruby  wrote:

Hello ironic'ers,

A while ago, we approved a spec to add node tag support to ironic [1]. The
feature itself did not land yet (although some of the code has). Now that
the (nova) community has come up with traits, ironic wants to support node
traits, and there is a spec proposing that [2]. At the ironic node level,
this is VERY similar to the node tag support, so the thought is to drop (not
implement) the node tagging feature, since the node traits feature could be
used instead. There are a few differences between the tags and traits.
"Traits" means something in OpenStack, and there are some restrictions about
it:

- max 50 per node

- names must be one of those in os-traits library OR prefixed with 'CUSTOM_'

For folks that wanted the node tagging feature, will this new node traits
feature work for your use case? Should we support both tags and traits? I
was wondering about e.g. using ironic standalone.

Please feel free to comment in [2].

Thanks in advance,

--ruby

[1]
http://specs.openstack.org/openstack/ironic-specs/specs/approved/nodes-tagging.html

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



Are tags/traits serving a different purpose? One serves the purpose of
helping the scheduling/placement while the other is more or less aims
at grouping for the "end users"?
I understand that the code will be *very* similar but who/what will be
the consumers/users?
I fell they won't be the same and could artificially limit its use due
to technical/design "limitations". (must be in os-traits or be
prefixed by CUSTOM)

For example which I personally foresee:
* I might want to populate Ironic inventory from an external system
which would also injects the appropriate traits.
* I might also want some technical people to use/query Ironic and
allow them to tag nodes based on their own needs while not messing
with the traits part (as it's managed by an external system and will
influence the scheduling later)

Lets not assume traits/tags have the same purpose and same user.


I agree with Matthieu 100% here.

Traits are structured, formalized, and set by the system or the operator 
against resource providers.


Tags are for end-users to, well, tag their instances with whatever 
strings they want.


Best,
-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-dev] [openstack-infra][stable][urgent][rally] Someone deleted Rally stable branch, we need to restore

[Boris Pavlovic]

Hi,

Someone somehow deleted 0.9.* branches from GitHub repo
https://github.com/openstack/rally
A lot of end users are using these branches and are affected by this
change.

Can someone help to restore them?


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

Re: [openstack-dev] [release] Release countdown for week R-17, October 28 - November 3

[Doug Hellmann]

Excerpts from Sean McGinnis's message of 2017-10-26 13:46:23 -0500:
> With much anticipation, our regular release countdown email.
> 
> Development Focus
> -
> 
> Now that the Queens-1 milestone is passed*, teams should now be focused on
> feature development and completion of release goals [0].
> 
> [1] https://governance.openstack.org/tc/goals/queens/index.html
> 
> * Not all Q-1 releases have been processed at the time of this email. We are
>   continuing to work through issues and have been able to start processing a
>   few releases. We will continue to slowly work through these until we are
>   confident that everything is working as expected. If your project's Q-1
>   release does go through but you notice anything out of the ordinary, please
>   let me or anyone in the #openstack-release channel know so we can
>   investigate.

In the course of fixing some of the release issues, we noticed that
some deliverables are configured with what appear to be the wrong
release jobs. It's not clear if this is the result of the zuulv3
migration, other changes, or if we just haven't noticed it before.
We have added some additional validation to the releases repository
to catch these cases.

If you see release patches fail with new errors about the release
jobs we can help you decide whether to fix the job or to set the
release type for the deliverable to allow the existing job to be
used. Ask in #openstack-release or via an email to openstack-dev tagged
"[release]".

Doug

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

Re: [openstack-dev] [all] [elections] Technical Committee Election Results

[Ed Leafe]

On Oct 26, 2017, at 9:52 AM, Doug Hellmann  wrote:
> 
> It would also be good to see some discussion of those issues outside
> of campaign periods. Some of the questions, like the one about user
> perspectives held by the candidates, were clearly meant to elicit
> more info to help make a choice in the election. The discussion of
> inclusiveness shouldn't be reserved for the campaign period, though.

Very true, but it’s nice to see the candidates’ answers collected in a single 
place. I know that I don’t have the time to search through meeting and IRC 
archives to find the answers for the people I am considering voting for.

-- Ed Leafe






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

Re: [openstack-dev] [all] [elections] Technical Committee Election Results

[Ed Leafe]

On Oct 25, 2017, at 10:36 PM, Tony Breeds  wrote:

> The whole election takes close to 3 weeks of officials time so I'd like
> to ask we be mindful of that before we extend things too much

There isn’t really a need for the self-nomination period to be very long. 
Announce it, say, a week before nominations open, and give candidates a few 
days to post their nominations. History has shown that the majority of 
candidates announce near the end of the period, and as a former nominee, I can 
say that a lot of that was due to procrastination.

I was glad to see a good response to the questions this time, and the answers 
(and non-answers) strongly influenced my vote. So I would rather see a shorter 
nomination period and a longer “campaign” period in the future.


-- Ed Leafe






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

[openstack-dev] [release] Release countdown for week R-17, October 28 - November 3

[Sean McGinnis]

With much anticipation, our regular release countdown email.

Development Focus
-

Now that the Queens-1 milestone is passed*, teams should now be focused on
feature development and completion of release goals [0].

[1] https://governance.openstack.org/tc/goals/queens/index.html

* Not all Q-1 releases have been processed at the time of this email. We are
  continuing to work through issues and have been able to start processing a
  few releases. We will continue to slowly work through these until we are
  confident that everything is working as expected. If your project's Q-1
  release does go through but you notice anything out of the ordinary, please
  let me or anyone in the #openstack-release channel know so we can
  investigate.

General Information
---

If you have not yet requested a Queens-1 release for your cycle-following
project, please do so immediately. Even if we can't process the release right
away, all requests should be in and ready by this point. Once things catch up
we will do a check and see if there are any missing that either need to do the
release, or need to be switched to an independent release.

This would also be a good time to check whether to do a release for any
independent, library, or stable releases.

The Technical Committee election ended last week. Congratulations to our new
and returning members:

Colleen Murphy (cmurphy)
Doug Hellmann (dhellmann)
Emilien Macchi (emilienm)
Jeremy Stanley (fungi)
Julia Kreger (TheJulia)
Paul Belanger (pabelanger)

As always, if you have any questions or concerns, feel free to swing by the
#openstack-release channel.

Upcoming Deadlines & Dates
--

Forum at OpenStack Summit in Sydney: November 6-8
Queens-2 Milestone: December 7

-- 
Sean McGinnis (smcginnis)

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

[openstack-dev] [Congress] time change for IRC meeting

[Eric K]

Hi all,

As previously discussed over, we'll move the weekly Congress team meeting
to the new time of Fridays 02:30 UTC, with the first new meeting on
November 3rd. Same channel #openstack-meeting.
Just to reiterate, there will be no meeting on November 2nd 00:00 (old
meeting time).

As always, collaborative list of meeting topics is kept here:
https://etherpad.openstack.org/p/congress-meeting-topics

See you all!

-Eric Kao


On 10/19/17, 11:13 AM, "Eric K"  wrote:

>Hi all,
>
>Here is a proposal (no actual change until further notice) to move the
>weekly Congress team meeting from Thursdays 00:00 UTC to Fridays 02:30 UTC
>in order to make the meeting time more bearable for India while still
>being workable for East Asia and the Americas. The time remains very bad
>for Europe and Africa (if there is interest, we can also set up for some
>weeks a meeting time that works better for Europe and Africa; please let
>us know!).
>
>Please express your comments and suggestions here. Thanks!
>
>-Eric Kao
>
>



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

Re: [openstack-dev] [all] [elections] Technical Committee Election Results

[Flavio Percoco]

On 26/10/17 10:52 -0400, Doug Hellmann wrote:

Excerpts from Jeremy Stanley's message of 2017-10-26 13:30:53 +:

On 2017-10-26 14:42:35 +0200 (+0200), Flavio Percoco wrote:
[...]
> I personally don't think the campaing period was too short. I saw
> enough interactions between candidates and the rest of the
> community, which was useful for me to make up my mind and vote.
> This is, of course, my own view and I don't mean to imply David's
> view is not valid.
[...]

Indeed, by my quick count we had 84 E-mails to the list for
questions to and answers from the candidates (not including
candidacy/platform statements, announcements from election
officials, et cetera). Also, it's entirely legitimate for these
discussions to continue into the voting week as some voters may wait
until toward the end of the period to make up their minds on how to
rank various candidates (I know I did, at least).


It would also be good to see some discussion of those issues outside
of campaign periods. Some of the questions, like the one about user
perspectives held by the candidates, were clearly meant to elicit
more info to help make a choice in the election. The discussion of
inclusiveness shouldn't be reserved for the campaign period, though.


+1K

What trigger the question is that many candidates mentioned inclusiveness and
diversity in their candidacies. Since it's a topic that I believe is sensitive
and vibrant in our industry, I felt it was fair to dive into it further before
the voting period. It definitely influenced the way I voted.

This said, I agree we should have this kind of discussions more often than not
and I intend to pursue this topic further.

Flavio

--
@flaper87
Flavio Percoco


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

[openstack-dev] [all][api] POST /api-sig/news

[Chris Dent]

Greetings OpenStack community,

Another short meeting this week. Participants have very busy radar; can't see for the 
trees, nor the mixed metaphors. The main topic of discussion is the work required to 
prepare for summit, where there will be an API-SIG forum session [5]. Also a bug has been 
created to remind us of the need to create a "changes-since" guideline [6].

# Newly Published Guidelines

None this week.

# API Guidelines Proposed for Freeze

Guidelines that are ready for wider review by the whole community.

None this week

# Guidelines Currently Under Review [3]

* A (shrinking) suite of several documents about doing version and service 
discovery
  Start at https://review.openstack.org/#/c/459405/

* WIP: microversion architecture archival doc (very early; not yet ready for 
review)
  https://review.openstack.org/444892

# Highlighting your API impacting issues

If you seek further review and insight from the API SIG about APIs that you are 
developing or changing, please address your concerns in an email to the OpenStack 
developer mailing list[1] with the tag "[api]" in the subject. In your email, 
you should include any relevant reviews, links, and comments to help guide the discussion 
of the specific challenge you are facing.

To learn more about the API SIG mission and the work we do, see our wiki page 
[4] and guidelines [2].

Thanks for reading and see you next week!

# References

[1] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[2] http://specs.openstack.org/openstack/api-wg/
[3] https://review.openstack.org/#/q/status:open+project:openstack/api-wg,n,z
[4] https://wiki.openstack.org/wiki/API_SIG
[5] 
https://www.openstack.org/summit/sydney-2017/summit-schedule/events/20442/api-sig-feedback-and-discussion-session
[6] https://bugs.launchpad.net/openstack-api-wg/+bug/1727725

Meeting Agenda
https://wiki.openstack.org/wiki/Meetings/API-SIG#Agenda
Past Meeting Records
http://eavesdrop.openstack.org/meetings/api_sig/
Open Bugs
https://bugs.launchpad.net/openstack-api-wg

--
Chris Dent  (⊙＿⊙') https://anticdent.org/
freenode: cdent tw: @anticdent__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [heat][horizon] Migration to heat-dashboard: how can we move this forward?

[Akihiro Motoki]

Hi Kaz,

Thanks for sharing the current status of heat-dashboard.
Queens-2 sounds a reasonable milestone.

I summarize the near-future below. Right?

- heat-dashboard team is preparing for heat dashboard split-out.
  The horizon parity (including stability) is the current focus.
- Heat related bugs filed to horizon can be hold until the
heat-dashboard is ready (around Q-2)
  After it is ready, they will be forwarded to heat-dashboard from
horizon launchpad
  and we can fix them in the heat-dashboard repository.
- Horizon team tries not to approve heat-related patches without strong reasons.

> Of course we will keep looking at what's going on in Horizon side &
> will cherry-pick the leftovers if needed in the end.

AFAIK, the only patch which landed after the heat-dashboard repo was created is
https://review.openstack.org/#/c/498838/

Thanks,
Akihiro

2017-10-25 13:11 GMT+09:00 Kaz Shinohara :
>  Hi Akihiro,
>
>
> Thanks for your kind following up :)
>
>> (1) Patch reviews and approvals in horizon
> Could you please stop to accept heat-dashboard related patches without
> critical ones ?
> According to our discussion in the last PTG, we made heat-dashboard
> repo taking horizon repo as upstream & now trying to land it in
> queens-2.
> Of course we will keep looking at what's going on in Horizon side &
> will cherry-pick the leftovers if needed in the end.
>
>> (2) Bug Management
> Yes we can take over those bugs, but now we are focusing to stabilize
> heat-dashboard-self.
> We would like to fix them after we will safely land heat-dashboard in 
> queens-2.
>
> Regards,
> Kaz Shinohara
>
> 2017-10-25 11:47 GMT+09:00 Akihiro Motoki :
>> Hi Heat dashboard team,
>>
>> I noticed heat-dashboard repository was created.
>> I have several questions from horizon side.
>>
>> A big question is "When does the switch happen?"
>>
>> This mainly affects two things:
>>
>> (1) Patch reviews and approvals in horizon
>>
>> Should the horizon team stop to accept heat-dashboard related patches
>> into the horizon repo now?
>> If you want to migrate in parallel, you need to take care of what
>> happens in the horizon repo continuously.
>> The simplest way is to stop any activities in horizon side.
>>
>> Note that one patch landed yesterday into the horizon repo.
>> Perhaps the heat-dashboard team will cherry-pick it into your repository.
>>
>> (2) Bug Management
>>
>> Is it okay to forward heat-related bugs into heat-dashboard launchpad?
>> When do we start?
>> There are several number of existing bugs related to the heat dashboard.
>> The horizon team now just adds 'heat' tag and is waiting for heat-dashboard.
>> https://bugs.launchpad.net/horizon/+bugs?field.tag=heat
>>
>> Thanks,
>> Akihiro
>>
>> __
>> 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] [all] Book the date: next PTG will be in Dublin, week of Feb 26, 2018

[Thierry Carrez]

Hi everyone,

In case you missed the news last week, it's now confirmed: the next PTG
will happen in Dublin (Ireland), the week of February 26, 2018.

We are still working on locking down the exact location, so please stay
tuned for more details. But you can already mark this date and location
in your calendars.

-- 
Thierry Carrez (ttx)

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

Re: [openstack-dev] [all] [elections] Technical Committee Election Results

[Doug Hellmann]

Excerpts from Jeremy Stanley's message of 2017-10-26 13:30:53 +:
> On 2017-10-26 14:42:35 +0200 (+0200), Flavio Percoco wrote:
> [...]
> > I personally don't think the campaing period was too short. I saw
> > enough interactions between candidates and the rest of the
> > community, which was useful for me to make up my mind and vote.
> > This is, of course, my own view and I don't mean to imply David's
> > view is not valid.
> [...]
> 
> Indeed, by my quick count we had 84 E-mails to the list for
> questions to and answers from the candidates (not including
> candidacy/platform statements, announcements from election
> officials, et cetera). Also, it's entirely legitimate for these
> discussions to continue into the voting week as some voters may wait
> until toward the end of the period to make up their minds on how to
> rank various candidates (I know I did, at least).

It would also be good to see some discussion of those issues outside
of campaign periods. Some of the questions, like the one about user
perspectives held by the candidates, were clearly meant to elicit
more info to help make a choice in the election. The discussion of
inclusiveness shouldn't be reserved for the campaign period, though.

Doug

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

Re: [openstack-dev] [all] [elections] Technical Committee Election Results

[Jeremy Stanley]

On 2017-10-26 14:42:35 +0200 (+0200), Flavio Percoco wrote:
[...]
> I personally don't think the campaing period was too short. I saw
> enough interactions between candidates and the rest of the
> community, which was useful for me to make up my mind and vote.
> This is, of course, my own view and I don't mean to imply David's
> view is not valid.
[...]

Indeed, by my quick count we had 84 E-mails to the list for
questions to and answers from the candidates (not including
candidacy/platform statements, announcements from election
officials, et cetera). Also, it's entirely legitimate for these
discussions to continue into the voting week as some voters may wait
until toward the end of the period to make up their minds on how to
rank various candidates (I know I did, at least).
-- 
Jeremy Stanley


signature.asc
Description: 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] [all] [elections] Technical Committee Election Results

[Flavio Percoco]

On 26/10/17 11:27 +0200, Thierry Carrez wrote:

Tony Breeds wrote:

On Wed, Oct 25, 2017 at 10:06:46PM -0400, David Moreau Simard wrote:

Was it just me or did the "official" period for campaigning/questions was
awfully short ?

The schedule [1] went:
​TC Campaigning: (Start) Oct 11, 2017 23:59 UTC (End) Oct 14, 2017 23:45
UTC


The original was:
  - name: 'TC Campaigning'
start: '2017-10-09T23:59'
end:   '2017-10-12T23:45'

but that needed to be adjusted (https://review.openstack.org/509654/)

While that was still the same duration it was mid-week.


​That's three days, one of which was a saturday.
Was it always this short ? It seems to me that this is not a lot of time to
the community to ask (read, and answer) thoughful ​questions.


There used to be no campaigning period at all, so it had been shorter :)


I realize this doesn't mean you can't keep asking questions once the actual
election voting start but I wonder if we should cut a few days from the
nomination and give it to the campaigning.


I can't find anything that documents how long the nomination period
needed to be, perhaps I missed it?  So we could do this but it's already
quite short.  So more likely we could just extend the Campaigning period
if that's the consensus.


Duration of campaigning period is not mandated by the TC charter, so
left at the appreciation of election officials.


The whole election takes close to 3 weeks of officials time so I'd like
to ask we be mindful of that before we extend things too much


It's clearly a balance between having interesting discussions and
triggering election fatigue. I'd say we need to have /some/ campaigning
time but not too much :)

Ideally discussions would start once people self-nominate, and we could
keep the period between nomination close and election start relatively
short (3/4 business days max).


As an observation, participating in the elections (not only as an election
official but also as a candidate) can be stressful.

I personally don't think the campaing period was too short. I saw enough
interactions between candidates and the rest of the community, which was useful
for me to make up my mind and vote. This is, of course, my own view and I don't
mean to imply David's view is not valid.

I would be a bit hesitant to make the total election period too long but I'm
sure we cand adjust a few things here and there. I would also prefer waiting
until the nomination period is closed to start discussion. It might not feel
fair if the discussions start early and then some candidacies use the data from
the discussions as promotion. Again, personal preference.

Flavio

--
@flaper87
Flavio Percoco


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

[openstack-dev] [QA] Office Hours report 2017-10-26

[Andrea Frittoli]

Dear all,

today we had our QA office hours.
We will have the next office hours in two weeks from now.

The IRC report [0] and full log [1] are available through meetbot.

Below a details of the bugs we triaged today.

Kind regards,

Andrea Frittoli (andreaf)


Bug #1715859 in tempest: "After upgrade to stestr cannot access
.testrepository"
https://bugs.launchpad.net/tempest/+bug/1715859
Discussed, invalid/incomplete

Bug #1724543 in devstack: "devstack fails while installing with monasca-api
in queens "
https://bugs.launchpad.net/devstack/+bug/1724543
Triaged, not a devstack bug

Bug #1724746 in devstack: "devstack fail at monasca-api plugin installation
in pike"
https://bugs.launchpad.net/devstack/+bug/1724746
Triaged, not a devstack bug

Bug #1724747 in devstack: "cleaning of devstack using ./clean.sh is not
preoperly done for monasca schema"
https://bugs.launchpad.net/devstack/+bug/1724747
Triaged, not a devstack bug


[0]
http://eavesdrop.openstack.org/meetings/office_hours/2017/office_hours.2017-10-26-09.00.html

[1]
http://eavesdrop.openstack.org/meetings/office_hours/2017/office_hours.2017-10-26-09.00.log.html
__
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] Blocking gate - do not recheck / rebase / approve any patch now (please)

[Attila Darazs]

On 10/26/2017 06:14 AM, Emilien Macchi wrote:

On Wed, Oct 25, 2017 at 1:59 PM, Emilien Macchi  wrote:

Quick update before being afk for some hours:

- Still trying to land https://review.openstack.org/#/c/513701 (thanks
Paul for promoting it in gate).


Landed.


- Disabling voting on scenario001 and scenario004 container jobs:
https://review.openstack.org/#/c/515188/


Done, please be very careful while these jobs are not voting.
If any doubt, please ping me or fultonj or gfidente on #tripleo.


- overcloudrc/keystone v2 workaround:
https://review.openstack.org/#/c/515161/ (d0ugal will work on proper
fix for https://bugs.launchpad.net/tripleo/+bug/1727454)


Merged - Dougal will work on the real fix this week but not urgent anymore.


- Fixing zaqar/notification issues on
https://review.openstack.org/#/c/515123 - we hope that helps to reduce
some failures in gate


In gate right now and hopefully merged in less than 2 hours.
Otherwise, please keep rechecking it.
According to Thomas Hervé, il will reduce the change to timeout.


- puppet-tripleo gate broken on stable branches (syntax jobs not
running properly) - jeblair is looking at it now


jeblair will provide a fix hopefully this week but this is not
critical at this time.
Thanks Jim for your help.


Once again, we'll need to retrospect and see why we reached that
terrible state but let's focus on bringing our CI in a good shape
again.
Thanks a ton to everyone who is involved,


I'm now restoring all patches that I killed from the gate.
You can now recheck / rebase / approve what you want, but please save
our CI resources and do it with moderation. We are not done yet.

I won't call victory but we've merged almost all our blockers, one is
missing but currently in gate:
https://review.openstack.org/515123 - need babysit until merged.

Now let's see how RDO promotion works. We're close :-)


We also have to change the tenant rc file from overcloudrc to 
overcloudrc.v3 for the validate-simple role to unblock promotion on master.


I created a bug to track that problem and going to post a fix soon:

https://bugs.launchpad.net/tripleo/+bug/1727698

Attila

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

Re: [openstack-dev] [all][charms][fuel][Packaging-Deb] Remove old numeric branches

[Andrey Kurilin]

Hi Tony and folks,

I missed the original thread (had read just [charms][fuel][Packaging-Deb]
tags), so disappeared branch surprised me a lot.

stable/0.9 branch of Rally project was created for supporting the previous
major release (last week, 0.9 was the current major release).
We released 0.10.0 just several days ago and want to continue supporting
0.9 for awhile.

Since this is critical for several our customers, it would be nice if we
can push stable/0.9 back (I have a local copy in the final state [0]).
Also, I'll be happy, if we can remove 0.9-eol tag from the git.o.o, gihtub
and pypi.

PS: it would be nice if tags for all affected projects is added next time.
or, even better, if all PTLs of affected projects is added to CC

[0] - https://github.com/andreykurilin/rally/tree/stable/0.9

2017-10-25 6:38 GMT+03:00 Tony Breeds :

> On Wed, Sep 20, 2017 at 01:52:11PM -0400, Tony Breeds wrote:
> > Hello all,
> > Now we have cleaned up some of the older series based branches I've
> > taken a look at some of the numeric based branches.
> >
> > The projects in $subject are particularly impacted.  I've made my best
> > guess at which branches are current, but I'd really appreciate guidance
> > on the life span of these branches.
> >
> > As before as the ultimate consumer of the data is infra I've presented
> > this in a form that's easy for them to consume:
> >
> > Ideally I'd like to move on this this week but that isn't enough
> > consultation.  So I'll pass the list to infra Monday 2nd October
>
> The branches in http://lists.openstack.org/pipermail/openstack-dev/2017-
> September/122381.html
> have been removed now.
>
> There was small issues with the openstack/deb-gnocchi and
> openstack/deb-python-gnocchiclient in that the .gitreview file pointed
> at the wrong repo (upstream in this case).  These were corrected
> manually
>
> Also:
>  - openstack/deb-python-django-pyscss
>  - openstack/charm-plumgrid-director
>  - openstack/charm-plumgrid-edge
>  - openstack/charm-plumgrid-gateway
>
> All seemed to be missing .gitreview files to the remote needed to be
> added manually.
>
> Yours Tony.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Best regards,
Andrey Kurilin.
__
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][containerized][osp12] Unable to deploy containerised overcloud

[Raoul Scarazzini]

On 10/26/2017 10:17 AM, Pranav Sarwate wrote:
> How do I debug this further? What logs can I look at? Also, it would be
> great if someone can validate that we are using the correct reference link.

Hi Pranav,
I can't help you about the validation, but I bet the error at that stage
means that you've problems while getting container images from the repo
you configured. Of course having the logs from the controller will help
a lot (check for status_code != 0 in /var/lib/heat-config/deployed
directory).

Bye,

-- 
Raoul Scarazzini
ra...@redhat.com

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

Re: [openstack-dev] [all] [elections] Technical Committee Election Results

[Thierry Carrez]

Tony Breeds wrote:
> On Wed, Oct 25, 2017 at 10:06:46PM -0400, David Moreau Simard wrote:
>> Was it just me or did the "official" period for campaigning/questions was
>> awfully short ?
>>
>> The schedule [1] went:
>> ​TC Campaigning: (Start) Oct 11, 2017 23:59 UTC (End) Oct 14, 2017 23:45
>> UTC​
> 
> The original was:
>   - name: 'TC Campaigning'
> start: '2017-10-09T23:59'
> end:   '2017-10-12T23:45'
> 
> but that needed to be adjusted (https://review.openstack.org/509654/)
> 
> While that was still the same duration it was mid-week.
> 
>> ​That's three days, one of which was a saturday.
>> Was it always this short ? It seems to me that this is not a lot of time to
>> the community to ask (read, and answer) thoughful ​questions.

There used to be no campaigning period at all, so it had been shorter :)

>> I realize this doesn't mean you can't keep asking questions once the actual
>> election voting start but I wonder if we should cut a few days from the
>> nomination and give it to the campaigning.
> 
> I can't find anything that documents how long the nomination period
> needed to be, perhaps I missed it?  So we could do this but it's already
> quite short.  So more likely we could just extend the Campaigning period
> if that's the consensus.

Duration of campaigning period is not mandated by the TC charter, so
left at the appreciation of election officials.

> The whole election takes close to 3 weeks of officials time so I'd like
> to ask we be mindful of that before we extend things too much

It's clearly a balance between having interesting discussions and
triggering election fatigue. I'd say we need to have /some/ campaigning
time but not too much :)

Ideally discussions would start once people self-nominate, and we could
keep the period between nomination close and election start relatively
short (3/4 business days max).

-- 
Thierry Carrez (ttx)



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] [tripleo] Blocking gate - do not recheck / rebase / approve any patch now (please)

[Bogdan Dobrelya]

Thank you for working on this!
I know it is needed to unblock development of tripleo. I have though a 
few comments inline.


On 10/26/17 6:14 AM, Emilien Macchi wrote:

On Wed, Oct 25, 2017 at 1:59 PM, Emilien Macchi  wrote:

Quick update before being afk for some hours:

- Still trying to land https://review.openstack.org/#/c/513701 (thanks
Paul for promoting it in gate).


Landed.


- Disabling voting on scenario001 and scenario004 container jobs:
https://review.openstack.org/#/c/515188/


Done, please be very careful while these jobs are not voting.
If any doubt, please ping me or fultonj or gfidente on #tripleo.


- overcloudrc/keystone v2 workaround:
https://review.openstack.org/#/c/515161/ (d0ugal will work on proper
fix for https://bugs.launchpad.net/tripleo/+bug/1727454)


Merged - Dougal will work on the real fix this week but not urgent anymore.


- Fixing zaqar/notification issues on
https://review.openstack.org/#/c/515123 - we hope that helps to reduce
some failures in gate


In gate right now and hopefully merged in less than 2 hours.
Otherwise, please keep rechecking it.
According to Thomas Hervé, il will reduce the change to timeout.


- puppet-tripleo gate broken on stable branches (syntax jobs not
running properly) - jeblair is looking at it now


jeblair will provide a fix hopefully this week but this is not
critical at this time.
Thanks Jim for your help.


Once again, we'll need to retrospect and see why we reached that
terrible state but let's focus on bringing our CI in a good shape
again.
Thanks a ton to everyone who is involved,


I'm now restoring all patches that I killed from the gate.
You can now recheck / rebase / approve what you want, but please save
our CI resources and do it with moderation. We are not done yet.

I won't call victory but we've merged almost all our blockers, one is
missing but currently in gate:
https://review.openstack.org/515123 - need babysit until merged.


I have to warn tripleo folks about any instack-only changes these days.
Please make sure each instack-only change, like Hiera overrides, has 
follow-up patches for containerized cases as well, which do not use 
instack. Otherwise, we're putting the whole containers thing under high 
risk to keep in place the regressions fixed for non-containers. That is 
dangerous, given that we disable voting for it from time to time.


For this particular case, please add it in a separate review in 
puppet/services/zaqar*. Thanks @bandini for confirming that on IRC.




Now let's see how RDO promotion works. We're close :-)

Thanks everyone,


On Wed, Oct 25, 2017 at 7:25 AM, Emilien Macchi  wrote:

Status:

- Heat Convergence switch *might* be a reason why overcloud timeout so
much. Thomas proposed to disable it:
https://review.openstack.org/515077
- Every time a patch fails in the tripleo gate queue, it reset the
gate. I proposed to remove this common queue:
https://review.openstack.org/515070
- I cleared the patches in check and queue to make sure the 2 blockers
are tested and can be merged in priority. I'll keep an eye on it
today.

Any help is very welcome.

On Wed, Oct 25, 2017 at 5:58 AM, Emilien Macchi  wrote:

We have been working very hard to get a package/container promotions
(since 44 days) and now our blocker is
https://review.openstack.org/#/c/513701/.

Because the gate queue is huge, we decided to block the gate and kill
all the jobs running there until we can get
https://review.openstack.org/#/c/513701/ and its backport
https://review.openstack.org/#/c/514584 (both are blocking the whole
production chain).
We hope to promote after these 2 patches, unless there is something
else, in that case we would iterate to the next problem.

We hope you understand and support us during this effort.
So please do not recheck, rebase or approve any patch until further notice.

Thank you,
--
Emilien Macchi




--
Emilien Macchi




--
Emilien Macchi







--
Best regards,
Bogdan Dobrelya,
Irc #bogdando

__
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][containerized][osp12] Unable to deploy containerised overcloud

[Pranav Sarwate]

Hi,

I am currently attempting to deploy containerized overcloud using steps 
documented @ 
https://docs.openstack.org/tripleo-docs/latest/install/containers_deployment/overcloud.html
 . But the overcloud deployment fails at step3 of controller configuration. 
Documenting the steps and error description below.


  1.  Deploy overcloud using command below. Highlighted are the Error and time 
taken. PFA the docker_registry.yaml file used to deploy.



$ time openstack overcloud deploy --templates --control-flavor control 
--compute-flavor compute --block-storage-flavor block-storage --control-scale 1 
--compute-scale 1 --block-storage-scale 1 -e 
/usr/share/openstack-tripleo-heat-templates/environments/docker.yaml -e 
~/docker_registry.yaml --validation-errors --verbose  -e 
/usr/share/openstack-tripleo-heat-templates/environments/veritas-hyperscale/cinder-veritas-hyperscale-config.yaml
 -e 
/usr/share/openstack-tripleo-heat-templates/environments/veritas-hyperscale/veritas-hyperscale-config.yaml
 | tee oc_deploy.log

…..

Stack overcloud UPDATE_FAILED



overcloud.AllNodesDeploySteps.ControllerDeployment_Step3.0:

  resource_type: OS::Heat::StructuredDeployment

  physical_resource_id: 5ec81534-73bc-46bd-8d53-82451e4ce7dd

  status: CREATE_FAILED

  status_reason: |

CREATE aborted

  deploy_stdout: |

None

  deploy_stderr: |

None



real242m3.904s

user0m20.034s

sys 0m0.969s

  1.  Not able to get a descriptive error for stack errors.
$ openstack stack failures list overcloud --long
overcloud.AllNodesDeploySteps.ControllerDeployment_Step3.0:
  resource_type: OS::Heat::StructuredDeployment
  physical_resource_id: 5ec81534-73bc-46bd-8d53-82451e4ce7dd
  status: CREATE_FAILED
  status_reason: |
CREATE aborted
  deploy_stdout: |
None
  deploy_stderr: |
None
$ openstack stack resource list overcloud | grep -i fail
| AllNodesDeploySteps   | 
167544d7-f765-4cfb-9b3c-e064366a17b5  | 
OS::TripleO::PostDeploySteps | UPDATE_FAILED   | 
2017-10-14T02:11:31Z |


How do I debug this further? What logs can I look at? Also, it would be great 
if someone can validate that we are using the correct reference link.

Thanks & Regards
Pranav Sarwate
__
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 listener heartbeat

[李田清]

Hello,
   i see this in impl_rabbit.py  
# NOTE(sileht): if purpose is PURPOSE_LISTEN
# the consume code does the heartbeat stuff
# we don't need a thread
self._heartbeat_thread = None
if purpose == rpc_common.PURPOSE_SEND:
self._heartbeat_start()



 When a create a batch listener, i do not find where it start the heartbeat?
Can someone help me point it out?


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