Re: [openstack-dev] [nova]API update week 5-11

On 7/11/2018 8:14 PM, Ghanshyam Mann wrote: 4. Volume multiattach enhancements: -https://blueprints.launchpad.net/nova/+spec/volume-multiattach-enhancements -https://review.openstack.org/#/q/topic:bp/volume-multiattach-enhancements+(status:open+OR+status:merged) - Weekly Progress: mriedem men

Re: [openstack-dev] [nova] What do we lose if the reshaper stuff doesn't land in Rocky?

DB work is now pushed for the single transaction reshape() function: https://review.openstack.org/#/c/582383 Note that in working on that, I uncovered a bug in AllocationList.delete_all() which needed to first be fixed: https://bugs.launchpad.net/nova/+bug/1781430 A fix has been pushed here:

Re: [openstack-dev] [nova] What do we lose if the reshaper stuff doesn't land in Rocky?

Let's just get the darn thing done in Rocky. I will have the DB work up for review today. -jay On 07/12/2018 10:45 AM, Matt Riedemann wrote: Continuing the discussion from the nova meeting today [1], I'm trying to figure out what the risk / benefit / contingency is if we don't get the reshape

[openstack-dev] [nova] What do we lose if the reshaper stuff doesn't land in Rocky?

Continuing the discussion from the nova meeting today [1], I'm trying to figure out what the risk / benefit / contingency is if we don't get the reshaper stuff done in Rocky. In a nutshell, we need reshaper to migrate VGPU inventory for the libvirt and xenapi drivers from the root compute node

Re: [openstack-dev] [nova]API update week 5-11

> > 2. Abort live migration in queued state: > - > https://blueprints.launchpad.net/nova/+spec/abort-live-migration-in-queued-status > > - > https://review.openstack.org/#/q/topic:bp/abort-live-migration-in-queued-status+(status:open+OR+status:merged) > > - Weekly Progress: Review is going and it i

[openstack-dev] [nova]API update week 5-11

Hi All, Please find the Nova API highlights of this week. Weekly Office Hour: === We had more attendees in this week office hours. What we discussed this week: - Discussion on API related BP. Discussion points are embedded inline with BP weekly progress in next section. - Tr

[openstack-dev] [nova] Denver Stein ptg planning

Hello Devs and Ops, I've created an etherpad where we can start collecting ideas for topics to cover at the Stein PTG. Please feel free to add your comments and topics with your IRC nick next to it to make it easier to discuss with you. https://etherpad.openstack.org/p/nova-ptg-stein Cheers,

[openstack-dev] [nova] review runway status

Howdy everyone, Here is the current review runway [1] status for blueprints in runways. Milestone r-3 (feature freeze) is coming up soon July 26, so this will be the last runway before FF unless we can complete some earlier than their end dates. * Allow abort live migrations in queued status

Re: [openstack-dev] [nova] Rocky blueprint status tracking

On Fri, 15 Jun 2018 16:12:21 -0500, Matt Riedemann wrote: On 6/15/2018 11:23 AM, melanie witt wrote: Similar to last cycle, we have an etherpad for tracking the status of approved nova blueprints for Rocky here: https://etherpad.openstack.org/p/nova-rocky-blueprint-status that we can use to he

Re: [openstack-dev] [nova] [placement] placement update 18-27

On 07/06/2018 10:09 AM, Chris Dent wrote: # Questions * Will consumer id, project and user id always be a UUID? We've   established for certain that user id will not, but things are   less clear for the other two. This issue is compounded by the   fact that these two strings are different but

Re: [openstack-dev] [nova] [placement] placement update 18-27

On 07/09/2018 02:52 PM, Chris Dent wrote: On Fri, 6 Jul 2018, Chris Dent wrote: This is placement update 18-27, a weekly update of ongoing development related to the [OpenStack](https://www.openstack.org/) [placement service](https://developer.openstack.org/api-ref/placement/). This is a contra

Re: [openstack-dev] [nova]Notification update week 28

On Mon, Jul 9, 2018 at 12:38 PM, Balázs Gibizer wrote: Hi, Here is the latest notification subteam update. [...] Weekly meeting -- The next meeting is planned to be held on 10th of June on #openstack-meeting-4 https://www.timeanddate.com/worldclock/fixedtime.html?iso=20180710T

Re: [openstack-dev] [nova] [placement] placement update 18-27

On Fri, 6 Jul 2018, Chris Dent wrote: This is placement update 18-27, a weekly update of ongoing development related to the [OpenStack](https://www.openstack.org/) [placement service](https://developer.openstack.org/api-ref/placement/). This is a contract version. Forgot to mention: There won'

Re: [openstack-dev] [nova]API update week 28-4

On 7/4/2018 6:10 AM, Ghanshyam Mann wrote: Planned Features : == Below are the API related features for Rocky cycle. Nova API Sub team will start reviewing those to give their regular feedback. If anythings missing there feel free to add those in etherpad-https://etherpad.openstack.or

Re: [openstack-dev] [nova]API update week 28-4

Thanks for sending out this update, it's useful for me when I'm not attending the office hours. On 7/4/2018 6:10 AM, Ghanshyam Mann wrote: 1. Servers Ips non-unique network names : -https://blueprints.launchpad.net/nova/+spec/servers-ips-non-unique-network-names - Spec Update need

Re: [openstack-dev] [nova] Supporting volume_type when booting from volume

On 5/23/2017 7:12 PM, Michael Glasgow wrote: A slight disadvantage of this approach is that the resulting incongruence between the client and the API is obfuscating.  When an end user can make accurate inferences about the API based on how the client works, that's a form of transparency that

[openstack-dev] [nova] [placement] placement update 18-27

HTML: https://anticdent.org/placement-update-18-27.html This is placement update 18-27, a weekly update of ongoing development related to the [OpenStack](https://www.openstack.org/) [placement service](https://developer.openstack.org/api-ref/placement/). This is a contract version. # Most Impor

Re: [openstack-dev] [nova] about filter the flavor

demann"; > Date: Mon, Jul 2, 2018 10:36 PM > To: "OpenStack Developmen"; > Subject: Re: [openstack-dev] [nova] about filter the flavor > > On 7/2/2018 2:43 AM, 李杰 wrote: > > Oh,sorry,not this means,in my opinion,we could filter the flavor in > > flavor list.su

Re: [openstack-dev] [nova] about filter the flavor

Does the "OSC“ meas the osc placement? -- Original -- From: "Matt Riedemann"; Date: Mon, Jul 2, 2018 10:36 PM To: "OpenStack Developmen"; Subject: Re: [openstack-dev] [nova] about filter the flavor On 7/2/2018 2:43 AM, 李杰 w

[openstack-dev] [nova]API update week 28-4

Hi All, Please find the Nova API highlights of this week. Weekly Office Hour: === We have re-started the Nova API discussion in office hour. I have updated the wiki page for more information about office hours: https://wiki.openstack.org/wiki/Meetings/NovaAPI What we discussed th

Re: [openstack-dev] [nova] Continuously growing request_specs table

Thanks, I may have missed that one. On Mon, Jul 2, 2018 at 10:29 PM Matt Riedemann wrote: > On 7/2/2018 2:47 AM, Zhenyu Zheng wrote: > > It seems that the current request_specs record did not got removed even > > when the related instance is gone, which lead to a continuously growing > > request

Re: [openstack-dev] [nova] about filter the flavor

On 7/2/2018 2:43 AM, 李杰 wrote: Oh,sorry,not this means,in my opinion,we could filter the flavor in flavor list.such as the cli:openstack flavor list --property key:value. There is no support for natively filtering flavors by extra specs in the compute REST API so that would have to be added wi

Re: [openstack-dev] [nova] Continuously growing request_specs table

On 7/2/2018 2:47 AM, Zhenyu Zheng wrote: It seems that the current request_specs record did not got removed even when the related instance is gone, which lead to a continuously growing request_specs table. How is that so? Is it because the delete process could be error and we have to recover

[openstack-dev] [nova] Continuously growing request_specs table

Hi, It seems that the current request_specs record did not got removed even when the related instance is gone, which lead to a continuously growing request_specs table. How is that so? Is it because the delete process could be error and we have to recover the request_spec if we deleted it? How a

Re: [openstack-dev] [nova] about filter the flavor

"; Subject: Re: [openstack-dev] [nova] about filter the flavor On Mon, Jul 02, 2018 at 11:08:51AM +0800, Rambo wrote: > Hi,all > > I have an idea.Now we can't filter the special flavor according to > the property.Can we achieve it?If we achieved this,we can filter the >

Re: [openstack-dev] [nova] about filter the flavor

On Mon, Jul 02, 2018 at 11:08:51AM +0800, Rambo wrote: > Hi,all > > I have an idea.Now we can't filter the special flavor according to > the property.Can we achieve it?If we achieved this,we can filter the > flavor according the property's key and value to filter the > flavor. What do you think of

[openstack-dev] [nova] about filter the flavor

Hi,all I have an idea.Now we can't filter the special flavor according to the property.Can we achieve it?If we achieved this,we can filter the flavor according the property's key and value to filter the flavor. What do you think of the idea?Can you tell me more about this ?Thank you very

Re: [openstack-dev] [nova] [placement] placement update 18-26

Thanks for the notes Matt, I'll try to incorporate this stuff into the next one where it makes some. A response within. On Fri, 29 Jun 2018, Matt Riedemann wrote: On 6/29/2018 8:03 AM, Chris Dent wrote: There are a patches left on the consumer generation topic, some tidy ups, and some stuff re

Re: [openstack-dev] [nova] [placement] placement update 18-26

On 6/29/2018 8:03 AM, Chris Dent wrote: # Questions As far as I can tell there was no discussion on last week's question, so here it is again: In [IRC [last week]](http://eavesdrop.openstack.org/irclogs/%23openstack-placement/%23openstack-placement.2018-06-21.log.html#t2018-06-21T13:21:14)

[openstack-dev] [nova] [placement] placement update 18-26

HTML: https://anticdent.org/placement-update-18-26.html This is placement update 18-26, a weekly update of ongoing development related to the [OpenStack](https://www.openstack.org/) [placement service](https://developer.openstack.org/api-ref/placement/). This is an expand version. For the next

Re: [openstack-dev] [nova] Shared envdir across tox environments

On 06/28/2018 11:18 AM, Stephen Finucane wrote: Just a quick heads up that an upcoming change to nova's 'tox.ini' will change the behaviour of multiple environments slightly. https://review.openstack.org/#/c/534382/9 With this change applied, tox will start sharing environment directories (e

[openstack-dev] [nova] Shared envdir across tox environments

Just a quick heads up that an upcoming change to nova's 'tox.ini' will change the behaviour of multiple environments slightly. https://review.openstack.org/#/c/534382/9 With this change applied, tox will start sharing environment directories (e.g. '.tox/py27') among environments with identical

Re: [openstack-dev] [nova] Adding hostId to metadata

On 2018-06-27 12:37:43 -0400 (-0400), Jay Pipes wrote: [...] > the hostId was not, in fact, the host identifier, but rather a > SHA-224 hash of the host and project_id. [...] Oh, that's slick. Yeah, it would basically take brute-forcing the UUID space to divine the actual host identifier from that

Re: [openstack-dev] [nova] Adding hostId to metadata

On 06/27/2018 12:20 PM, Matt Riedemann wrote: On 6/27/2018 10:13 AM, Jay Pipes wrote: I'm -2'd the patch in question because of these concerns about crossing the line between administrative and guest/virtual domains. It may seem like a very trivial patch, but from what I can tell, it would be

Re: [openstack-dev] [nova] Adding hostId to metadata

On 06/27/18 11:20, Matt Riedemann wrote: To be clear, this is exposing the exact same hashed host+project_id value via the metadata API that you can already get, as a non-admin user, from the compute REST API: https://github.com/openstack/nova/blob/c8b93fa2493dce82ef4c0b1e7a503ba9b81c2e86/nova

Re: [openstack-dev] [nova] Adding hostId to metadata

On 2018-06-27 11:13:04 -0400 (-0400), Jay Pipes wrote: [...] > Virtual machines and the software running in them should not need > to know what particular piece of hardware they are running on. VMs > having knowledge of the underlying hardware and host violates the > principle of least privilege an

Re: [openstack-dev] [nova] Adding hostId to metadata

On 6/27/2018 10:13 AM, Jay Pipes wrote: I'm -2'd the patch in question because of these concerns about crossing the line between administrative and guest/virtual domains. It may seem like a very trivial patch, but from what I can tell, it would be a very big departure from the types of informat

Re: [openstack-dev] [nova] Adding hostId to metadata

On 06/25/2018 05:28 PM, Mohammed Naser wrote: Hi everyone: While working with the OpenStack infrastructure team, we noticed that we were having some intermittent issues where we wanted to identify a theory if all VMs with this issue were landing on the same hypervisor. However, there seems to b

[openstack-dev] [nova] Nova API Office Hour

Hi All, From today, we will be hosting the office hour for Nova API discussions which will cover the Nova API priority and API Bug triage things. I have updated the information about agenda and time in wiki page [1]. All are welcome to join. We will continue this on every Wedneday 06.00 UTC [1

[openstack-dev] [nova]Notification update week 26

Hi, Here is the latest notification subteam update. Bugs [Undecided] "IndexError: list index out of range" in ExceptionPayload.from_exception during resize failure https://bugs.launchpad.net/nova/+bug/1777540 I failed to reproduce and based on the newly provided logs in the parent bug h

Re: [openstack-dev] [nova] Adding hostId to metadata

We only bump the version if something has changed IIRC. I think bumping when nothing has changed would create a burden for implementers of client software. So its not like you get a chance to sneak this in "for free". Does this information really need to be available in the host OS? Its trivial to

[openstack-dev] [nova] Adding hostId to metadata

Hi everyone: While working with the OpenStack infrastructure team, we noticed that we were having some intermittent issues where we wanted to identify a theory if all VMs with this issue were landing on the same hypervisor. However, there seems to be no way of directly accessing `hostId` from ins

Re: [openstack-dev] [nova] Need feedback on spec for handling down cells in the API

On 6/7/2018 9:02 AM, Matt Riedemann wrote: We have a nova spec [1] which is at the point that it needs some API user (and operator) feedback on what nova API should be doing when listing servers and there are down cells (unable to reach the cell DB or it times out). tl;dr: the spec proposes t

[openstack-dev] [nova] [placement] placement update 18-25

HTML: https://anticdent.org/placement-update-18-25.html This is placement update 18-25, a weekly update of ongoing development related to the [OpenStack](https://www.openstack.org/) [placement service](https://developer.openstack.org/api-ref/placement/). This is a "contract" version, meaning th

Re: [openstack-dev] [Nova] [Cyborg] [Glance] Updated spec for Cyborg-Nova-Glance interaction, including os-acc

s/review the new version is/review the new version/ Regards, Sundar On 6/22/2018 8:06 AM, Nadathur, Sundar wrote: Hello folks, The os-acc spec [1] has been updated substantially. Please review the new version is https://review.openstack.org/#/c/577438/ . The background for the update is that

[openstack-dev] [Nova] [Cyborg] [Glance] Updated spec for Cyborg-Nova-Glance interaction, including os-acc

Hello folks, The os-acc spec [1] has been updated substantially. Please review the new version is https://review.openstack.org/#/c/577438/ . The background for the update is that several important aspects were raised as comments on the previous spec ([1], [2]). An alternative workflow for att

Re: [openstack-dev] [nova] NUMA-aware live migration: easy but incomplete vs complete but hard

On 06/21/2018 07:04 AM, Artom Lifshitz wrote: As I understand it, Artom is proposing to have a larger race window, essentially from when the scheduler selects a node until the resource audit runs on that node. Exactly. When writing the spec I thought we could just call the resou

Re: [openstack-dev] [nova] NUMA-aware live migration: easy but incomplete vs complete but hard

On 06/21/2018 07:50 AM, Mooney, Sean K wrote: -Original Message- From: Jay Pipes [mailto:jaypi...@gmail.com] Side question... does either approach touch PCI device management during live migration? I ask because the only workloads I've ever seen that pin guest vCPU threads to specific

Re: [openstack-dev] [nova] NUMA-aware live migration: easy but incomplete vs complete but hard

On Thu, Jun 21, 2018 at 09:36:58AM -0400, Jay Pipes wrote: > On 06/18/2018 10:16 AM, Artom Lifshitz wrote: > > Hey all, > > > > For Rocky I'm trying to get live migration to work properly for > > instances that have a NUMA topology [1]. > > > > A question that came up on one of patches [2] is how

Re: [openstack-dev] [nova] NUMA-aware live migration: easy but incomplete vs complete but hard

> Side question... does either approach touch PCI device management during > live migration? Nope. I'd need to do some research to see what, if anything, is needed at the lower levels (kernel, libvirt) to enable this. > I ask because the only workloads I've ever seen that pin guest vCPU threads >

Re: [openstack-dev] [nova] NUMA-aware live migration: easy but incomplete vs complete but hard

> -Original Message- > From: Jay Pipes [mailto:jaypi...@gmail.com] > Sent: Thursday, June 21, 2018 2:37 PM > To: openstack-dev@lists.openstack.org > Subject: Re: [openstack-dev] [nova] NUMA-aware live migration: easy but > incomplete vs complete but hard > >

Re: [openstack-dev] [nova] NUMA-aware live migration: easy but incomplete vs complete but hard

On 06/18/2018 10:16 AM, Artom Lifshitz wrote: Hey all, For Rocky I'm trying to get live migration to work properly for instances that have a NUMA topology [1]. A question that came up on one of patches [2] is how to handle resources claims on the destination, or indeed whether to handle that at

Re: [openstack-dev] [nova] NUMA-aware live migration: easy but incomplete vs complete but hard

> > As I understand it, Artom is proposing to have a larger race window, > essentially > from when the scheduler selects a node until the resource audit runs on > that node. > Exactly. When writing the spec I thought we could just call the resource tracker to claim the resources when the migration

Re: [openstack-dev] [nova] NUMA-aware live migration: easy but incomplete vs complete but hard

On Mon, Jun 18, 2018 at 10:16:05AM -0400, Artom Lifshitz wrote: > Hey all, > > For Rocky I'm trying to get live migration to work properly for > instances that have a NUMA topology [1]. > > A question that came up on one of patches [2] is how to handle > resources claims on the destination, or in

Re: [openstack-dev] [nova] NUMA-aware live migration: easy but incomplete vs complete but hard

On 06/20/2018 10:00 AM, Sylvain Bauza wrote: When we reviewed the spec, we agreed as a community to say that we should still get race conditions once the series is implemented, but at least it helps operators. Quoting : "It would also be possible for another instance to steal NUMA resources fro

Re: [openstack-dev] [nova] [placement] placement update 18-24

Thanks for this, a few things inline. On 6/15/2018 10:04 AM, Chris Dent wrote: The flip side of this is that it highlights that we have a growing documentation debt with the many features provided by placement and how to make best use of them in nova (and other services that might like to use p

Re: [openstack-dev] [nova] NUMA-aware live migration: easy but incomplete vs complete but hard

On Tue, Jun 19, 2018 at 9:59 PM, Artom Lifshitz wrote: > > Adding > > claims support later on wouldn't change any on-the-wire messaging, it > would > > just make things work more robustly. > > I'm not even sure about that. Assuming [1] has at least the right > idea, it looks like it's an either-o

Re: [openstack-dev] [nova]Notification update week 25

On Tue, Jun 19, 2018 at 7:07 PM, Matt Riedemann wrote: On 6/18/2018 10:10 AM, Balázs Gibizer wrote: * Introduce instance.lock and instance.unlock notifications https://blueprints.launchpad.net/nova/+spec/trigger-notifications-when-lock-unlock-instances This hasn't been updated in quite awhi

Re: [openstack-dev] [nova]Notification update week 25

I'd like to help it. : ) Regards, Yikun Jiang Yikun（Kero） Mail: yikunk...@gmail.com Matt Riedemann 于2018年6月20日周三 上午1:07写道： > On 6/18/2018 10:10 AM, Balázs Gibizer wrote: > > * Introduce instance.lock and instance.unlock notifications > > > https://bluep

Re: [openstack-dev] [nova] NUMA-aware live migration: easy but incomplete vs complete but hard

On 06/19/2018 01:59 PM, Artom Lifshitz wrote: Adding claims support later on wouldn't change any on-the-wire messaging, it would just make things work more robustly. I'm not even sure about that. Assuming [1] has at least the right idea, it looks like it's an either-or kind of thing: either we

[openstack-dev] [nova][oot drivers] Putting a contract out on ComputeDriver.get_traits()

All (but especially out-of-tree compute driver maintainers)- ComputeDriver.get_traits() was introduced mere months ago [1] for initial implementation by Ironic [2] mainly because the whole update_provider_tree framework [3] wasn't fully baked yet. Now that update_provider_tree is a thing,

Re: [openstack-dev] [nova] NUMA-aware live migration: easy but incomplete vs complete but hard

> Adding > claims support later on wouldn't change any on-the-wire messaging, it would > just make things work more robustly. I'm not even sure about that. Assuming [1] has at least the right idea, it looks like it's an either-or kind of thing: either we use resource tracker claims and get the new

Re: [openstack-dev] [nova]Notification update week 25

On 6/18/2018 10:10 AM, Balázs Gibizer wrote: * Introduce instance.lock and instance.unlock notifications https://blueprints.launchpad.net/nova/+spec/trigger-notifications-when-lock-unlock-instances This hasn't been updated in quite awhile. I wonder if someone else wants to pick that up now?

Re: [openstack-dev] [nova] nova API meeting schedule

Thanks for response. We will go with options 2 which is to cancel the meeting and continue on nova channel. We will start API office hour on every Wednesday (27th June onwards) 06:00 UTC on #openstack-nova channel. I pushed the patch to free the current slot of API meeting[1] and will update

Re: [openstack-dev] [nova] NUMA-aware live migration: easy but incomplete vs complete but hard

> For what it's worth, I think the previous patch languished for a number of > reasons other than the complexity of the code...the original author left, > the coding style was a bit odd, there was an attempt to make it work even if > the source was an earlier version, etc. I think a fresh implemen

Re: [openstack-dev] [nova] NUMA-aware live migration: easy but incomplete vs complete but hard

On 06/18/2018 08:16 AM, Artom Lifshitz wrote: Hey all, For Rocky I'm trying to get live migration to work properly for instances that have a NUMA topology [1]. A question that came up on one of patches [2] is how to handle resources claims on the destination, or indeed whether to handle that at

Re: [openstack-dev] [nova] increasing the number of allowed volumes attached per instance > 26

Hi, this looks reasonable to me but I would prefer B. In this case the operator can configure the hard limit. I don't think we more granularity or expose it using the API. Belmiro On Fri, Jun 8, 2018 at 3:46 PM Dan Smith wrote: > > Some ideas that have been discussed so far include: > > FYI, th

[openstack-dev] [nova]Notification update week 25

Hi, Here is the latest notification subteam update. Bugs No update on bugs and we have no new bugs tagged with notifications. Features Sending full traceback in versioned notifications ~ https://blueprints.launchpad.net/nova/+spec

[openstack-dev] [nova] NUMA-aware live migration: easy but incomplete vs complete but hard

Hey all, For Rocky I'm trying to get live migration to work properly for instances that have a NUMA topology [1]. A question that came up on one of patches [2] is how to handle resources claims on the destination, or indeed whether to handle that at all. The previous attempt's approach [3] (call

Re: [openstack-dev] [nova] [placement] placement update 18-24

Thank you as always for doing this, Chris. > Some of the older items in this list are not getting much attention. > That's a shame. The list is ordered (oldest first) the way it is on > purpose. > > * >   Purge comp_node and res_prvdr records during dele

Re: [openstack-dev] [nova] Rocky blueprint status tracking

On 6/15/2018 11:23 AM, melanie witt wrote: Similar to last cycle, we have an etherpad for tracking the status of approved nova blueprints for Rocky here: https://etherpad.openstack.org/p/nova-rocky-blueprint-status that we can use to help us review patches. If I've missed any blueprints or if

Re: [openstack-dev] [nova] increasing the number of allowed volumes attached per instance > 26

> I thought we were leaning toward the option where nova itself doesn't > impose a limit, but lets the virt driver decide. > > I would really like NOT to see logic like this in any nova code: > >> if kvm|qemu: >> return 256 >> elif POWER: >> return 4000 >> elif: >>

[openstack-dev] [nova] Rocky blueprint status tracking

Howdy everyone, Similar to last cycle, we have an etherpad for tracking the status of approved nova blueprints for Rocky here: https://etherpad.openstack.org/p/nova-rocky-blueprint-status that we can use to help us review patches. If I've missed any blueprints or if anything needs an update,

[openstack-dev] [nova] [placement] placement update 18-24

HTML: https://anticdent.org/placement-update-18-24.html This is placement update 18-24, a weekly update of ongoing development related to the [OpenStack](https://www.openstack.org/) [placement service](https://developer.openstack.org/api-ref/placement/). It's been quite a while since the last o

Re: [openstack-dev] [nova] increasing the number of allowed volumes attached per instance > 26

On Mon, Jun 11, 2018 at 10:14:33AM -0500, Eric Fried wrote: > I thought we were leaning toward the option where nova itself doesn't > impose a limit, but lets the virt driver decide. Yeah, I agree with that, if we can't arrive at a sensible limit for Nova, after testing with all drivers that matte

Re: [openstack-dev] [nova] review runways check-in and feedback

On Wed, Jun 13, 2018 at 10:33 PM, melanie witt wrote: Howdy everyone, We've been experimenting with a new process this cycle, Review Runways [1] and we're about at the middle of the cycle now as we had the r-2 milestone last week June 7. I wanted to start a thread and gather thoughts and

Re: [openstack-dev] [nova] review runways check-in and feedback

> While I have tried to review a few of the runway-slotted efforts, I > have gotten burned out on a number of them. Other runway-slotted > efforts, I simply don't care enough about or once I've seen some of > the code, simply can't bring myself to review it (sorry, just being > honest). I have the

Re: [openstack-dev] [nova] nova-cells-v1 intermittent gate failure

On Wed, 13 Jun 2018 15:47:33 -0700, Melanie Witt wrote: Hi everybody, Just a heads up that we have an intermittent gate failure of the nova-cells-v1 job happening right now [1] and a revert of the tempest change related to it has been approved [2] and will be making its way through the gate. The

Re: [openstack-dev] [nova] review runways check-in and feedback

On 06/13/2018 05:33 PM, Matt Riedemann wrote: On 6/13/2018 3:33 PM, melanie witt wrote: We've been experimenting with a new process this cycle, Review Runways [1] and we're about at the middle of the cycle now as we had the r-2 milestone last week June 7. I wanted to start a thread and gath

[openstack-dev] [nova] nova-cells-v1 intermittent gate failure

Hi everybody, Just a heads up that we have an intermittent gate failure of the nova-cells-v1 job happening right now [1] and a revert of the tempest change related to it has been approved [2] and will be making its way through the gate. The nova-cells-v1 job will be failing until [2] merges.

Re: [openstack-dev] [nova] review runways check-in and feedback

On 6/13/2018 3:33 PM, melanie witt wrote: We've been experimenting with a new process this cycle, Review Runways [1] and we're about at the middle of the cycle now as we had the r-2 milestone last week June 7. I wanted to start a thread and gather thoughts and feedback from the nova communi

[openstack-dev] [nova] review runways check-in and feedback

Howdy everyone, We've been experimenting with a new process this cycle, Review Runways [1] and we're about at the middle of the cycle now as we had the r-2 milestone last week June 7. I wanted to start a thread and gather thoughts and feedback from the nova community about how they think run

Re: [openstack-dev] [nova] Confusion over how enable_certificate_validation is meant to be used

Matt, The end goal is that certificate validation will always occur alongside signature validation, but we wanted there to be an upgrade path that would allow signature validation to continue to work until certificate validation was set up. See the first paragraph of the proposed change in the

Re: [openstack-dev] [nova] Confusion over how enable_certificate_validation is meant to be used

On 2018-06-12 09:00:47 -0500 (-0500), Matt Riedemann wrote: [...] > In this scenario, if the user fails to provide trusted certs when > creating or rebuilding a server, it's going to result in a build > abort exception (NoValidHost) from the compute. Is that the > intention? [...] It's at least on

[openstack-dev] [nova] Confusion over how enable_certificate_validation is meant to be used

Sylvain and I were reviewing https://review.openstack.org/#/c/479949/ today and I'm at least a bit confused over how the enable_certificate_validation config option is meant to be used. The current logic during driver.spawn() on the compute is going to be: if the user supplied trusted certs or

Re: [openstack-dev] [nova] review runway status

A few small status updates inline. On 6/11/2018 4:14 PM, melanie witt wrote: Hi everybody, This is just a brief status about the blueprints currently occupying review runways [0] and an ask for the nova-core team to give these reviews priority for their code review focus. * Certificate Validat

[openstack-dev] [nova] review runway status

Hi everybody, This is just a brief status about the blueprints currently occupying review runways [0] and an ask for the nova-core team to give these reviews priority for their code review focus. * Certificate Validation - https://blueprints.launchpad.net/nova/+spec/nova-validate-certificates

Re: [openstack-dev] [nova] increasing the number of allowed volumes attached per instance > 26

I thought we were leaning toward the option where nova itself doesn't impose a limit, but lets the virt driver decide. I would really like NOT to see logic like this in any nova code: > if kvm|qemu: > return 256 > elif POWER: > return 4000 > elif: > ... On 06/

Re: [openstack-dev] [nova] increasing the number of allowed volumes attached per instance > 26

On Mon, Jun 11, 2018 at 11:55:29AM +0200, Sahid Orentino Ferdjaoui wrote: > On Fri, Jun 08, 2018 at 11:35:45AM +0200, Kashyap Chamarthy wrote: > > On Thu, Jun 07, 2018 at 01:07:48PM -0500, Matt Riedemann wrote: [...] > > > The 26 volumes thing is a libvirt driver restriction. > > > > The origina

[openstack-dev] [nova] Notification update week 24

Hi, Here is the latest notification subteam update. Bugs [Medium] https://bugs.launchpad.net/nova/+bug/1739325 Server operations fail to complete with versioned notifications if payload contains unset non-nullable fields This is also visible in tssurya's environment. I'm wondering if we

Re: [openstack-dev] [nova] nova API meeting schedule

On Mon, 11 Jun 2018, Ghanshyam wrote: 2. If no member from USA/Europe TZ then, myself and Alex will conduct the API meeting as office hour on Nova channel during our day time (something between UTC+1 to UTC + 9). There is not much activity on Nova channel during our TZ so it will be ok to use N

Re: [openstack-dev] [nova] increasing the number of allowed volumes attached per instance > 26

On Fri, Jun 08, 2018 at 11:35:45AM +0200, Kashyap Chamarthy wrote: > On Thu, Jun 07, 2018 at 01:07:48PM -0500, Matt Riedemann wrote: > > On 6/7/2018 12:56 PM, melanie witt wrote: > > > Recently, we've received interest about increasing the maximum number of > > > allowed volumes to attach to a sing

Re: [openstack-dev] [nova] nova API meeting schedule

Glad to hear that the API meeting is happening again, I would also love to join. On Mon, Jun 11, 2018 at 10:49 AM Ghanshyam wrote: > Hi All, > > As you might know, we used to have Nova API subteam meeting on Wed [1] but > we did not continue that this year due to unavailability of members. > > A

[openstack-dev] [nova] nova API meeting schedule

Hi All, As you might know, we used to have Nova API subteam meeting on Wed [1] but we did not continue that this year due to unavailability of members. As per discussion with melanie , we would like to continue the API meeting either on meeting channel (openstack-meeting-4) or as office hour

Re: [openstack-dev] [nova][osc] Documenting compute API microversion gaps in OSC

On Fri, 08 Jun 2018 17:16:01 +0900 Sylvain Bauza wrote > > > On Fri, Jun 8, 2018 at 3:35 AM, Matt Riedemann wrote: > I've started an etherpad [1] to identify the compute API microversion gaps > in python-openstackclient. > > It's a small start right now so I would appre

Re: [openstack-dev] [nova] [placement] Upgrade concerns with nested Resource Providers

There is now a blueprint [1] and draft spec [2]. Reviews welcomed. [1] https://blueprints.launchpad.net/nova/+spec/reshape-provider-tree [2] https://review.openstack.org/#/c/572583/ On 06/04/2018 06:00 PM, Eric Fried wrote: > There has been much discussion. We've gotten to a point of an initial

Re: [openstack-dev] [nova] increasing the number of allowed volumes attached per instance > 26

Dan Smith wrote on 06/08/2018 08:46:01 AM: > From: Dan Smith > To: melanie witt > Cc: "OpenStack Development Mailing List \(not for usage questions\)" > , openstack-operat...@lists.openstack.org > Date: 06/08/2018 08:48 AM > Subject: Re: [openstack-dev] [nova] incr

Re: [openstack-dev] [nova] increasing the number of allowed volumes attached per instance > 26

> Some ideas that have been discussed so far include: FYI, these are already in my order of preference. > A) Selecting a new, higher maximum that still yields reasonable > performance on a single compute host (64 or 128, for example). Pros: > helps prevent the potential for poor performance on a

Re: [openstack-dev] [nova] increasing the number of allowed volumes attached per instance > 26

On Thu, Jun 07, 2018 at 01:07:48PM -0500, Matt Riedemann wrote: > On 6/7/2018 12:56 PM, melanie witt wrote: > > Recently, we've received interest about increasing the maximum number of > > allowed volumes to attach to a single instance > 26. The limit of 26 is > > because of a historical limitation

Re: [openstack-dev] [nova][osc] Documenting compute API microversion gaps in OSC

On Fri, Jun 8, 2018 at 3:35 AM, Matt Riedemann wrote: > I've started an etherpad [1] to identify the compute API microversion gaps > in python-openstackclient. > > It's a small start right now so I would appreciate some help on this, even > just a few people looking at a couple of these per day w

<    1   2   3   4   5   6   7   8   9   10   >