[openstack-dev] [masakari]py35 unit tests are failed
Hello, py35 unit tests of masakari are failed by same errors on gerrit. e.g. * https://review.openstack.org/#/c/441796/ =>http://logs.openstack.org/96/441796/3/check/openstack-tox-py35/d958f3f/testr_results.html.gz * https://review.openstack.org/#/c/509782/ =>http://logs.openstack.org/82/509782/23/check/openstack-tox-py35/9612809/testr_results.html.gz It seems to have been caused by sqlalchemy, but I haven't analyzed it enough yet. Please tell in this ML or submit a patch if you can solve it. Best regards, -- _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ Rikimaru Honjo E-mail:honjo.rikim...@po.ntt-tx.co.jp __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Openstack-operators] [nova][neutron] How do you use the instance IP filter?
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?
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?
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?
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
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?
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?
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
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?
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?
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
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 follow up on this one... > > I hope my traits spec will replace
Re: [openstack-dev] [openstack-infra][stable][urgent][rally] Someone deleted Rally stable branch, we need to restore
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"
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
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
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
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
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
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
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
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
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?
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
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
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
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
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
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)
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
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
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
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)
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
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