Re: [openstack-dev] [nova] about notification in nova

This regarding keystone ? Thanks & Regards Ranjan Kumar Mob: 9284158762 > On 03-Dec-2018, at 8:01 AM, Zhenyu Zheng wrote: > > Hi, > > Are you using versioned notification? If you are using versioned > nofitication, you should get an ``action_initiator_user`` and an >

Re: [openstack-dev] [nova] about notification in nova

Hi, Are you using versioned notification? If you are using versioned nofitication, you should get an ``action_initiator_user`` and an ``action_initiator_project`` indicating who initiated this action, we had them since I649d8a27baa8840bc1bb567fef027c749c663432

[openstack-dev] [nova] about notification in nova

Hi, all： I have a question about the notification in nova, that is the actual operator is different from the operator was record in panko. Such as the delete action, we create the VM as user1, and we delete the VM as user2， but the operator is user1 who delete the VM in panko

Re: [openstack-dev] [nova] Would an api option to create an instance without powering on be useful?

On 11/30/18 6:06 AM, Matthew Booth wrote: I have a request to do $SUBJECT in relation to a V2V workflow. The use case here is conversion of a VM/Physical which was previously powered off. We want to move its data, but we don't want to be powering on stuff which wasn't previously on. This

[openstack-dev] [nova] Would an api option to create an instance without powering on be useful?

I have a request to do $SUBJECT in relation to a V2V workflow. The use case here is conversion of a VM/Physical which was previously powered off. We want to move its data, but we don't want to be powering on stuff which wasn't previously on. This would involve an api change, and a hopefully very

[openstack-dev] [nova][placement] Please help to review XenServer vgpu related patches

Hi, Sylvain, Jay, Eric and Matt, I saw the n-rp and reshaper patches in upstream have almost finished. Could you help to review XenServer vGPU related patches when you have the time? https://review.openstack.org/#/c/520313/ https://review.openstack.org/#/c/521041/

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

On 11/19/2018 9:32 PM, Rambo wrote:       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

Re: [openstack-dev] [nova] Stein forum session notes

On Mon, 19 Nov 2018 17:19:22 +0100, Surya Seetharaman wrote: On Mon, Nov 19, 2018 at 2:39 PM Matt Riedemann > wrote: On 11/19/2018 3:17 AM, melanie witt wrote: > - Not directly related to the session, but CERN (hallway track) and > NeCTAR (dev ML)

[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

Re: [openstack-dev] [nova] Stein forum session notes

On Mon, Nov 19, 2018 at 2:39 PM Matt Riedemann wrote: > On 11/19/2018 3:17 AM, melanie witt wrote: > > - Not directly related to the session, but CERN (hallway track) and > > NeCTAR (dev ML) have both given feedback and asked that the > > policy-driven idea for handling quota for down cells be

Re: [openstack-dev] [nova] Stein forum session notes

On 11/19/2018 3:17 AM, melanie witt wrote: - Not directly related to the session, but CERN (hallway track) and NeCTAR (dev ML) have both given feedback and asked that the policy-driven idea for handling quota for down cells be avoided. Revived the "propose counting quota in placement" spec to

Re: [openstack-dev] [nova] Can we deprecate the server backup API please?

On 11/18/2018 6:51 AM, Alex Xu wrote: Sounds make sense to me, and then we needn't fix this strange behaviour also https://review.openstack.org/#/c/409644/ The same discussion was had in the spec for that change: https://review.openstack.org/#/c/511825/ Ultimately it amounted to a big "meh,

[openstack-dev] [nova] Stein forum session notes

Hey all, Here's some notes I took in forum sessions I attended -- feel free to add notes on sessions I missed. Etherpad links: https://wiki.openstack.org/wiki/Forum/Berlin2018 Cheers, -melanie TUE --- Cells v2 updates - Went over the etherpad, no objections to anything -

Re: [openstack-dev] [nova] Can we deprecate the server backup API please?

Sounds make sense to me, and then we needn't fix this strange behaviour also https://review.openstack.org/#/c/409644/ Jay Pipes 于2018年11月17日周六 上午3:56写道： > The server backup API was added 8 years ago. It has Nova basically > implementing a poor-man's cron for some unknown reason (probably

Re: [openstack-dev] [nova] Can we deprecate the server backup API please?

s.openstack.org" Subject: [openstack-dev] [nova] Can we deprecate the server backup API please? The server backup API was added 8 years ago. It has Nova basically implementing a poor-man's cron for some unknown reason (probably because the original RAX Cloud Servers API had some

[openstack-dev] [nova] Can we deprecate the server backup API please?

The server backup API was added 8 years ago. It has Nova basically implementing a poor-man's cron for some unknown reason (probably because the original RAX Cloud Servers API had some similar or identical functionality, who knows...). Can we deprecate this functionality please? It's confusing

Re: [openstack-dev] [nova][neutron] boot server with more than one subnet selection question

On Tue, 2018-11-13 at 12:27 +0100, Matt Riedemann wrote: > On 11/13/2018 4:45 AM, Chen CH Ji wrote: > > Got it, this is what I am looking for .. thank you > > Regarding that you can do with server create, I believe it's: > > 1. don't specify anything for networking, you get a port on the network

Re: [openstack-dev] [nova][neutron] boot server with more than one subnet selection question

On 11/13/2018 4:45 AM, Chen CH Ji wrote: Got it, this is what I am looking for .. thank you Regarding that you can do with server create, I believe it's: 1. don't specify anything for networking, you get a port on the network available to you; if there are multiple networks, it's a failure

Re: [openstack-dev] [nova][neutron] boot server with more than one subnet selection question

Got it, this is what I am looking for .. thank you   - Original message -From: Slawomir Kaplonski To: "OpenStack Development Mailing List (not for usage questions)" Cc:Subject: Re: [openstack-dev] [nova][neutron] boot server with more than one subnet selection questionDate: T

Re: [openstack-dev] [nova][neutron] boot server with more than one subnet selection question

Hi, You can choose which subnet (and even IP address) should be used, see „fixed_ips” field in [1]. If You will not provide anything Neutron will choose for You one IPv4 address and one IPv6 address and in both cases it will be chosen randomly from available IPs from all subnets. [1]

[openstack-dev] [nova][neutron] boot server with more than one subnet selection question

I have a network created like below:   1 network with 3 subnets (1 ipv6 and 2 ipv4) ,when boot, whether I can select subnet to boot from or the subnet will be force selected by the order the subnet created? Any document or code can be  referred? Thanks   | fd0e2078-044d-4c5c-b114-3858631e6328 |

Re: [openstack-dev] [nova][cinder] about unified limits

Sending a follow up here since there has been some movement on this recently. There is a nova specification up for review that goes through the work to consume unified limits out of keystone [0]. John and Jay have also been working through the oslo.limit integration, which is forcing us to think

[openstack-dev] [nova] no meeting the next two weeks

Howdy all, This is a heads up that we will not hold a nova meeting next week November 15 because of summit week. And we will also not hold a nova meeting the following week November 22 because of the US holiday of Thanksgiving, as we're unlikely to find anyone to run it during the 2100 UTC

[openstack-dev] [nova] about resize the instance

Hi,all When we resize/migrate instance, if error occurs on source compute node, the instance state can rollback to active currently.But if error occurs in "finish_resize" function on destination compute node, the instance state would not rollback to active. Is there a bug, or

[openstack-dev] [nova][placement] No n-sch meeting next week

...due to summit. -efried __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

Re: [openstack-dev] [nova][cinder][neutron] Cross-cell cold migration

After hacking on the PoC for awhile [1] I have finally pushed up a spec [2]. Behold it in all its dark glory! [1] https://review.openstack.org/#/c/603930/ [2] https://review.openstack.org/#/c/616037/ On 8/22/2018 8:23 PM, Matt Riedemann wrote: Hi everyone, I have started an etherpad for

Re: [openstack-dev] [nova][placement] Placement requests and caching in the resource tracker

I do intend to respond to all the excellent discussion on this thread, but right now I just want to offer an update on the code: I've split the effort apart into multiple changes starting at [1]. A few of these are ready for review. One opinion was that a specless blueprint would be appropriate.

Re: [openstack-dev] [NOVA] pci alias device_type and numa_policy and device_type meanings

On Mon, Nov 5, 2018 at 11:02 PM Manuel Sopena Ballesteros wrote: > > Dear Openstack community. > > > > I am setting up pci passthrough for GPUs using aliases. > > > > I was wondering the meaning of the fields device_type and numa_policy and how > should I use them as I could not find much

[openstack-dev] [NOVA] pci alias device_type and numa_policy and device_type meanings

Dear Openstack community. I am setting up pci passthrough for GPUs using aliases. I was wondering the meaning of the fields device_type and numa_policy and how should I use them as I could not find much details in the official documentation.

Re: [openstack-dev] [nova][placement] Placement requests and caching in the resource tracker

On 11/5/2018 1:17 PM, Matt Riedemann wrote: I'm thinking of a case like, resize and instance but rather than confirm/revert it, the user deletes the instance. That would cleanup the allocations from the target node but potentially not from the source node. Well this case is at least not an

Re: [openstack-dev] [nova][placement] Placement requests and caching in the resource tracker

On 11/5/2018 12:28 PM, Mohammed Naser wrote: Have you dug into any of the operations around these instances to determine what might have gone wrong? For example, was a live migration performed recently on these instances and if so, did it fail? How about evacuations (rebuild from a down host).

Re: [openstack-dev] [nova] Announcing new Focal Point for s390x libvirt/kvm Nova

On Fri, 2 Nov 2018 09:47:42 +0100, Andreas Scheuring wrote: Dear Nova Community, I want to announce the new focal point for Nova s390x libvirt/kvm. Please welcome "Cathy Zhang” to the Nova team. She and her team will be responsible for maintaining the s390x libvirt/kvm Thirdparty CI [1] and

Re: [openstack-dev] [nova][placement] Placement requests and caching in the resource tracker

On Mon, Nov 5, 2018 at 4:17 PM Matt Riedemann wrote: > > On 11/4/2018 4:22 AM, Mohammed Naser wrote: > > Just for information sake, a clean state cloud which had no reported issues > > over maybe a period of 2-3 months already has 4 allocations which are > > incorrect and 12 allocations pointing

Re: [openstack-dev] [nova] Announcing new Focal Point for s390x libvirt/kvm Nova

On 11/2/2018 3:47 AM, Andreas Scheuring wrote: Dear Nova Community, I want to announce the new focal point for Nova s390x libvirt/kvm. Please welcome "Cathy Zhang” to the Nova team. She and her team will be responsible for maintaining the s390x libvirt/kvm Thirdparty CI [1] and any s390x

Re: [openstack-dev] [nova] about live-resize the instance

On 11/4/2018 10:17 PM, Chen CH Ji wrote: Yes, this has been discussed for long time and If I remember this correctly seems S PTG also had some discussion on it (maybe public Cloud WG ? ), Claudiu has been pushing this for several cycles and he actually had some code at [1] but no additional

Re: [openstack-dev] [nova][placement] Placement requests and caching in the resource tracker

On 11/5/2018 5:52 AM, Chris Dent wrote: * We need to have further discussion and investigation on   allocations getting out of sync. Volunteers? This is something I've already spent a lot of time on with the heal_allocations CLI, and have already started asking mnaser questions about this

Re: [openstack-dev] [nova][placement] Placement requests and caching in the resource tracker

On 11/4/2018 4:22 AM, Mohammed Naser wrote: Just for information sake, a clean state cloud which had no reported issues over maybe a period of 2-3 months already has 4 allocations which are incorrect and 12 allocations pointing to the wrong resource provider, so I think this comes does to

Re: [openstack-dev] [nova][placement] Placement requests and caching in the resource tracker

Thus we should only read from placement: > * at compute node startup > * when a write fails > And we should only write to placement: > * at compute node startup > * when the virt driver tells us something has changed I agree with this. We could also prepare an interface for

Re: [openstack-dev] [nova][placement] Placement requests and caching in the resource tracker

On Sun, 4 Nov 2018, Jay Pipes wrote: Now that we have generation markers protecting both providers and consumers, we can rely on those generations to signal to the scheduler report client that it needs to pull fresh information about a provider or consumer. So, there's really no need to

Re: [openstack-dev] [nova][cinder] Using externally stored keys for encryption

Dear Mohammed, with SecuStack we've been integrating end-to-end (E2E) transfer of secrets into the OpenStack code. From your problem description, it sounds like our implementation would address some of your points. For below explanation, I will refer to those secrets as "keys". Our solution

Re: [openstack-dev] [nova][placement] Placement requests and caching in the resource tracker

Thanks Eric for the patch. This will help keeping placement calls under control. Belmiro On Sun, Nov 4, 2018 at 1:01 PM Jay Pipes wrote: > On 11/02/2018 03:22 PM, Eric Fried wrote: > > All- > > > > Based on a (long) discussion yesterday [1] I have put up a patch [2] > > whereby you can set

Re: [openstack-dev] [nova] about live-resize the instance

://review.openstack.org/#/q/status:abandoned+topic:bp/instance-live-resize   - Original message -From: "Rambo" To: "OpenStack Developmen" Cc:Subject: [openstack-dev] [nova] about live-resize the instanceDate: Mon, Nov 5, 2018 10:28 AM  Hi,all         I find it is important that live

[openstack-dev] [nova] about live-resize the instance

Hi,all I find it is important that live-resize the instance in production environment. We have talked it many years and we agreed this in Rocky PTG, then the author remove the spec to Stein, but there is no information about this spec, is there anyone to push the spec and achieve it?

Re: [openstack-dev] [nova][placement] Placement requests and caching in the resource tracker

On 11/02/2018 03:22 PM, Eric Fried wrote: All- Based on a (long) discussion yesterday [1] I have put up a patch [2] whereby you can set [compute]resource_provider_association_refresh to zero and the resource tracker will never* refresh the report client's provider cache. Philosophically, we're

[openstack-dev] [nova][cinder] Using externally stored keys for encryption

Hi everyone: I've been digging around the documentation of Nova, Cinder and the encrypted disks feature and I've been a bit stumped on something which I think is a very relevant use case that might not be possible (or it is and I have totally missed it!) It seems that both Cinder and Nova assume

Re: [openstack-dev] [nova][placement] Placement requests and caching in the resource tracker

Ugh, hit send accidentally. Please take my comments lightly as I have not been as involved with the developments but just chiming in as an operator with some ideas. On Fri, Nov 2, 2018 at 9:32 PM Matt Riedemann wrote: > > On 11/2/2018 2:22 PM, Eric Fried wrote: > > Based on a (long) discussion

Re: [openstack-dev] [nova][placement] Placement requests and caching in the resource tracker

On Fri, Nov 2, 2018 at 9:32 PM Matt Riedemann wrote: > > On 11/2/2018 2:22 PM, Eric Fried wrote: > > Based on a (long) discussion yesterday [1] I have put up a patch [2] > > whereby you can set [compute]resource_provider_association_refresh to > > zero and the resource tracker will never* refresh

Re: [openstack-dev] [nova][placement] Placement requests and caching in the resource tracker

On 11/2/2018 2:22 PM, Eric Fried wrote: Based on a (long) discussion yesterday [1] I have put up a patch [2] whereby you can set [compute]resource_provider_association_refresh to zero and the resource tracker will never* refresh the report client's provider cache. Philosophically, we're removing

[openstack-dev] [nova][placement] Placement requests and caching in the resource tracker

All- Based on a (long) discussion yesterday [1] I have put up a patch [2] whereby you can set [compute]resource_provider_association_refresh to zero and the resource tracker will never* refresh the report client's provider cache. Philosophically, we're removing the "healing" aspect of the

[openstack-dev] [nova] Announcing new Focal Point for s390x libvirt/kvm Nova

Dear Nova Community, I want to announce the new focal point for Nova s390x libvirt/kvm. Please welcome "Cathy Zhang” to the Nova team. She and her team will be responsible for maintaining the s390x libvirt/kvm Thirdparty CI [1] and any s390x specific code in nova and os-brick. I personally

[openstack-dev] [nova] Stein summit forum sessions and presentations of interest

Howdy all, We've made a list of cross-project forum sessions and nova-related sessions/presentations that you might be interested in attending at the summit and added them to our forum etherpad: https://etherpad.openstack.org/p/nova-forum-stein The "Cross-project Forum sessions that should

[openstack-dev] [nova] Is anyone running their own script to purge old instance_faults table entries?

I came across this bug [1] in triage today and I thought this was fixed already [2] but either something regressed or there is more to do here. I'm mostly just wondering, are operators already running any kind of script which purges old instance_faults table records before an instance is

Re: [openstack-dev] [NOVA] nova GPU suppot and find GPU type

On Tue, Oct 30, 2018 at 12:21 AM Manuel Sopena Ballesteros < manuel...@garvan.org.au> wrote: > Dear Nova community, > > > > This is the first time I work with GPUs. > > > > I have a Dell C4140 with x4 Nvidia Tesla V100 SXM2 16GB I would like to > setup on Openstack Rocky. > > > > I checked the

Re: [openstack-dev] [nova][limits] Does ANYONE at all use the quota class functionality in Nova?

Hi, Basically we should kill quota classes. It required out of tree stuff that was never implemented, AFAIK. When I checked with Kevin about this, my memory says the idea was out of tree authorization plugin would populate context.quota_class with something like "i_have_big_credit_limit" or

Re: [openstack-dev] [nova] Volunteer needed to write reshaper FFU hook

I would like to help since I have now finished all the downstream works. But I may need to take some time understanding all the background information On Mon, Oct 29, 2018 at 11:25 PM Matt Riedemann wrote: > Given the outstanding results of my recruiting job last week [1] I have > been tasked

[openstack-dev] [NOVA] nova GPU suppot and find GPU type

Dear Nova community, This is the first time I work with GPUs. I have a Dell C4140 with x4 Nvidia Tesla V100 SXM2 16GB I would like to setup on Openstack Rocky. I checked the documentation and I have 2 questions I would like to ask: 1. Docs (1) says As of the Queens release, there is no

[openstack-dev] [nova] FYI: change in semantics for virt driver update_provider_tree()

This is a notice to any out of tree virt driver implementors of the ComputeDriver.update_provider_tree() interface that they now need to set the allocation_ratio and reserved amounts for VCPU, MEMORY_MB and DISK_GB inventory from the update_provider_tree() method assuming [1] merges. The patch

[openstack-dev] [nova] Volunteer needed to write reshaper FFU hook

Given the outstanding results of my recruiting job last week [1] I have been tasked with recruiting one of our glorious and most talented contributors to work on the fast-forward-upgrade script changes needed for the reshape-provider-tree blueprint. The work item is nicely detailed in the

Re: [openstack-dev] [nova] nova cellsv2 and DBs / down cells / quotas

> On 26 Oct 2018, at 1:42 am, Dan Smith wrote: > >> I guess our architecture is pretty unique in a way but I wonder if >> other people are also a little scared about the whole all DB servers >> need to up to serve API requests? > > When we started down this path, we acknowledged that this

Re: [openstack-dev] [nova][limits] Does ANYONE at all use the quota class functionality in Nova?

On 10/25/2018 02:44 PM, melanie witt wrote: On Thu, 25 Oct 2018 14:00:08 -0400, Jay Pipes wrote: On 10/25/2018 01:38 PM, Chris Friesen wrote: On 10/24/2018 9:10 AM, Jay Pipes wrote: Nova's API has the ability to create "quota classes", which are basically limits for a set of resource types.

Re: [openstack-dev] [nova] nova cellsv2 and DBs / down cells / quotas

Hi Matt, The Searchlight team decided to revive the required feature in Stein [1] and We're working with Kevin to review the patch this weekend. If Nova team needs some help, just let me know. [1] https://review.openstack.org/#/c/453352/ Bests, On Fri, Oct 26, 2018 at 12:58 AM Matt Riedemann

Re: [openstack-dev] [nova][limits] Does ANYONE at all use the quota class functionality in Nova?

On Thu, 25 Oct 2018 15:06:38 -0500, Matt Riedemann wrote: On 10/25/2018 2:55 PM, Chris Friesen wrote: 2) The main benefit (as I see it) of the quota class API is to allow dynamic adjustment of the default quotas without restarting services. I could be making this up, but I want to say back at

Re: [openstack-dev] [nova][limits] Does ANYONE at all use the quota class functionality in Nova?

On 10/25/2018 2:55 PM, Chris Friesen wrote: 2) The main benefit (as I see it) of the quota class API is to allow dynamic adjustment of the default quotas without restarting services. I could be making this up, but I want to say back at the Pike PTG people were also complaining that not having

Re: [openstack-dev] [nova][limits] Does ANYONE at all use the quota class functionality in Nova?

On 10/25/2018 12:00 PM, Jay Pipes wrote: On 10/25/2018 01:38 PM, Chris Friesen wrote: On 10/24/2018 9:10 AM, Jay Pipes wrote: Nova's API has the ability to create "quota classes", which are basically limits for a set of resource types. There is something called the "default quota class" which

Re: [openstack-dev] [nova][limits] Does ANYONE at all use the quota class functionality in Nova?

On Thu, 25 Oct 2018 14:00:08 -0400, Jay Pipes wrote: On 10/25/2018 01:38 PM, Chris Friesen wrote: On 10/24/2018 9:10 AM, Jay Pipes wrote: Nova's API has the ability to create "quota classes", which are basically limits for a set of resource types. There is something called the "default quota

Re: [openstack-dev] [nova][limits] Does ANYONE at all use the quota class functionality in Nova?

On 10/25/2018 01:38 PM, Chris Friesen wrote: On 10/24/2018 9:10 AM, Jay Pipes wrote: Nova's API has the ability to create "quota classes", which are basically limits for a set of resource types. There is something called the "default quota class" which corresponds to the limits in the

Re: [openstack-dev] [nova][limits] Does ANYONE at all use the quota class functionality in Nova?

On 10/24/2018 9:10 AM, Jay Pipes wrote: Nova's API has the ability to create "quota classes", which are basically limits for a set of resource types. There is something called the "default quota class" which corresponds to the limits in the CONF.quota section. Quota classes are basically

Re: [openstack-dev] [nova][limits] Does ANYONE at all use the quota class functionality in Nova?

melanie witt wrote on 10/25/2018 02:14:40 AM: > On Thu, 25 Oct 2018 14:12:51 +0900, ボーアディネシュ[bhor Dinesh] wrote: > > We were having a similar use case like *Preemptible Instances* called as > > *Rich-VM’s* which > > > > are high in resources and are deployed each per hypervisor. We have a > >

Re: [openstack-dev] [nova] nova cellsv2 and DBs / down cells / quotas

On 10/24/2018 6:55 PM, Sam Morrison wrote: I’ve been thinking of some hybrid cellsv1/v2 thing where we’d still have the top level api cell DB but the API would only ever read from it. Nova-api would only write to the compute cell DBs. Then keep the nova-cells processes just doing

Re: [openstack-dev] [nova] nova cellsv2 and DBs / down cells / quotas

> I guess our architecture is pretty unique in a way but I wonder if > other people are also a little scared about the whole all DB servers > need to up to serve API requests? When we started down this path, we acknowledged that this would create a different access pattern which would require ops

Re: [openstack-dev] [nova][NFS] Inexplicable utime permission denied when launching instance

I'm still seeing the same problem after disabling AppArmor, so I think it must be some other root problem. On Wed, Oct 24, 2018 at 2:41 PM Neil Jerram wrote: > > Thanks so much for these hints, Erlon. I will look closer at AppArmor. > > Neil > > On Wed, Oct 24, 2018 at 1:41 PM Erlon Cruz

Re: [openstack-dev] [nova] nova cellsv2 and DBs / down cells / quotas

On Thu, 25 Oct 2018 10:55:15 +1100, Sam Morrison wrote: On 24 Oct 2018, at 4:01 pm, melanie witt wrote: On Wed, 24 Oct 2018 10:54:31 +1100, Sam Morrison wrote: Hi nova devs, Have been having a good look into cellsv2 and how we migrate to them (we’re still on cellsv1 and about to upgrade

Re: [openstack-dev] [nova][limits] Does ANYONE at all use the quota class functionality in Nova?

On Thu, 25 Oct 2018 14:12:51 +0900, ボーアディネシュ[bhor Dinesh] wrote: We were having a similar use case like *Preemptible Instances* called as *Rich-VM’s* which are high in resources and are deployed each per hypervisor. We have a custom code in production which tracks the quota for such

Re: [openstack-dev] [nova][limits] Does ANYONE at all use the quota class functionality in Nova?

On Wed, 24 Oct 2018 12:54:00 -0700, Melanie Witt wrote: On Wed, 24 Oct 2018 13:57:05 -0500, Matt Riedemann wrote: On 10/24/2018 10:10 AM, Jay Pipes wrote: I'd like to propose deprecating this API and getting rid of this functionality since it conflicts with the new Keystone /limits endpoint,

Re: [openstack-dev] [nova][limits] Does ANYONE at all use the quota class functionality in Nova?

Message- From: "Kevin L. Mitchell" To: "OpenStack Development Mailing List (not for usage questions)"; "openstack-operat...@lists.openstack.org"; Cc: Sent: Oct 25, 2018 (Thu) 11:35:08 Subject: Re: [openstack-dev] [nova][limits] Does ANYONE at all use the quot

Re: [openstack-dev] [nova][limits] Does ANYONE at all use the quota class functionality in Nova?

> On 10/24/18 10:10, Jay Pipes wrote: > > Nova's API has the ability to create "quota classes", which are > > basically limits for a set of resource types. There is something called > > the "default quota class" which corresponds to the limits in the > > CONF.quota section. Quota classes are

Re: [openstack-dev] [nova][limits] Does ANYONE at all use the quota class functionality in Nova?

so FYI, in case people missing this spec, there is spec from John https://review.openstack.org/#/c/602201/3/specs/stein/approved/unified-limits-stein.rst@170 the roadmap of this spec is also saying deprecate the quota-class API. melanie witt 于2018年10月25日周四 上午3:54写道： > On Wed, 24 Oct 2018

Re: [openstack-dev] [nova] nova cellsv2 and DBs / down cells / quotas

> On 24 Oct 2018, at 4:01 pm, melanie witt wrote: > > On Wed, 24 Oct 2018 10:54:31 +1100, Sam Morrison wrote: >> Hi nova devs, >> Have been having a good look into cellsv2 and how we migrate to them (we’re >> still on cellsv1 and about to upgrade to queens and still run cells v1 for >> now).

Re: [openstack-dev] [nova][limits] Does ANYONE at all use the quota class functionality in Nova?

On Wed, Oct 24, 2018 at 2:49 PM Jay Pipes wrote: > On 10/24/2018 02:57 PM, Matt Riedemann wrote: > > On 10/24/2018 10:10 AM, Jay Pipes wrote: > >> I'd like to propose deprecating this API and getting rid of this > >> functionality since it conflicts with the new Keystone /limits > >> endpoint,

Re: [openstack-dev] [nova][limits] Does ANYONE at all use the quota class functionality in Nova?

On Wed, 24 Oct 2018 13:57:05 -0500, Matt Riedemann wrote: On 10/24/2018 10:10 AM, Jay Pipes wrote: I'd like to propose deprecating this API and getting rid of this functionality since it conflicts with the new Keystone /limits endpoint, is highly coupled with RAX's turnstile middleware and I

Re: [openstack-dev] [nova][limits] Does ANYONE at all use the quota class functionality in Nova?

On 10/24/2018 02:57 PM, Matt Riedemann wrote: On 10/24/2018 10:10 AM, Jay Pipes wrote: I'd like to propose deprecating this API and getting rid of this functionality since it conflicts with the new Keystone /limits endpoint, is highly coupled with RAX's turnstile middleware and I can't seem

Re: [openstack-dev] [nova][limits] Does ANYONE at all use the quota class functionality in Nova?

On 10/24/2018 10:10 AM, Jay Pipes wrote: I'd like to propose deprecating this API and getting rid of this functionality since it conflicts with the new Keystone /limits endpoint, is highly coupled with RAX's turnstile middleware and I can't seem to find anyone who has ever used it. Deprecating

Re: [openstack-dev] [nova][limits] Does ANYONE at all use the quota class functionality in Nova?

Forwarding to openstack-operators per Jay. On 10/24/18 10:10, Jay Pipes wrote: > Nova's API has the ability to create "quota classes", which are > basically limits for a set of resource types. There is something called > the "default quota class" which corresponds to the limits in the >

[openstack-dev] [nova][limits] Does ANYONE at all use the quota class functionality in Nova?

Nova's API has the ability to create "quota classes", which are basically limits for a set of resource types. There is something called the "default quota class" which corresponds to the limits in the CONF.quota section. Quota classes are basically templates of limits to be applied if the

[openstack-dev] [nova][tc] Seeking feedback on the OpenStack cloud vision

Greetings, Nova team! As you may be aware, I've been working with other folks in the community on documenting a vision for OpenStack clouds (formerly known as the 'Technical Vision') - essentially to interpret the mission statement in long-form, in a way that we can use to actually help guide

Re: [openstack-dev] [nova][NFS] Inexplicable utime permission denied when launching instance

Thanks so much for these hints, Erlon. I will look closer at AppArmor. Neil On Wed, Oct 24, 2018 at 1:41 PM Erlon Cruz wrote: > > PS. Don't forget that if you change or disable AppArmor you will have to > reboot the host so the kernel gets reloaded. > > Em qua, 24 de out de 2018 às 09:40,

Re: [openstack-dev] [nova][NFS] Inexplicable utime permission denied when launching instance

PS. Don't forget that if you change or disable AppArmor you will have to reboot the host so the kernel gets reloaded. Em qua, 24 de out de 2018 às 09:40, Erlon Cruz escreveu: > I think that there's a change that AppArmor is blocking the access. Have > you checked the dmesg messages related with

Re: [openstack-dev] [nova][NFS] Inexplicable utime permission denied when launching instance

I think that there's a change that AppArmor is blocking the access. Have you checked the dmesg messages related with apparmor? Em sex, 19 de out de 2018 às 09:38, Neil Jerram escreveu: > Wracking my brains over this one, would appreciate any pointers... > > Setup: Small test deployment with

Re: [openstack-dev] [nova] nova cellsv2 and DBs / down cells / quotas

On Wed, 24 Oct 2018 10:54:31 +1100, Sam Morrison wrote: Hi nova devs, Have been having a good look into cellsv2 and how we migrate to them (we’re still on cellsv1 and about to upgrade to queens and still run cells v1 for now). One of the problems I have is that now all our nova cell

[openstack-dev] [nova] nova cellsv2 and DBs / down cells / quotas

Hi nova devs, Have been having a good look into cellsv2 and how we migrate to them (we’re still on cellsv1 and about to upgrade to queens and still run cells v1 for now). One of the problems I have is that now all our nova cell database servers need to respond to API requests. With cellsv1 our

Re: [openstack-dev] [nova] Metadata API cross joining "instance_metadata" and "instance_system_metadata"

Make sense, Dan. Thanks so much for your help. Sergio On Tue, Oct 23, 2018 at 5:01 PM Dan Smith wrote: > > I tested a code change that essentially reverts > > https://review.openstack.org/#/c/276861/1/nova/api/metadata/base.py > > > > In other words, with this change metadata tables are not

Re: [openstack-dev] [nova] Metadata API cross joining "instance_metadata" and "instance_system_metadata"

> I tested a code change that essentially reverts > https://review.openstack.org/#/c/276861/1/nova/api/metadata/base.py > > In other words, with this change metadata tables are not fetched by > default in API requests. If I understand correctly, metadata is > fetched in separate queries as the

Re: [openstack-dev] [nova] Metadata API cross joining "instance_metadata" and "instance_system_metadata"

I tested a code change that essentially reverts https://review.openstack.org/#/c/276861/1/nova/api/metadata/base.py In other words, with this change metadata tables are not fetched by default in API requests. If I understand correctly, metadata is fetched in separate queries as the instance

Re: [openstack-dev] [nova] Metadata API cross joining "instance_metadata" and "instance_system_metadata"

https://bugs.launchpad.net/nova/+bug/1799298 On Mon, Oct 22, 2018 at 9:15 PM Sergio A. de Carvalho Jr. < scarvalh...@gmail.com> wrote: > Cool, I'll open a bug then. > > I was wondering if, before joining the metadata tables with the rest of > instance data, we could do a UNION, since both tables

Re: [openstack-dev] [nova] Metadata API cross joining "instance_metadata" and "instance_system_metadata"

Cool, I'll open a bug then. I was wondering if, before joining the metadata tables with the rest of instance data, we could do a UNION, since both tables are structurally identical. On Mon, Oct 22, 2018 at 9:04 PM Dan Smith wrote: > > Do you guys see an easy fix here? > > > > Should I open a

Re: [openstack-dev] [nova] Metadata API cross joining "instance_metadata" and "instance_system_metadata"

> Do you guys see an easy fix here? > > Should I open a bug report? Definitely open a bug. IMHO, we should just make the single-instance load work like the multi ones, where we load the metadata separately if requested. We might be able to get away without sysmeta these days, but we needed it for

Re: [openstack-dev] [nova] Metadata API cross joining "instance_metadata" and "instance_system_metadata"

Thanks so much for the replies, guys. > Have you debugged to the point of knowing where the initial DB query is starting from? > > Looking at history, my guess is this is the change which introduced it for all requests: > > https://review.openstack.org/#/c/276861/ That is my understanding too.

Re: [openstack-dev] [nova] Metadata API cross joining "instance_metadata" and "instance_system_metadata"

> We haven't been doing this (intentionally) for quite some time, as we > query and fill metadata linearly: > > https://github.com/openstack/nova/blob/master/nova/db/sqlalchemy/api.py#L2244 > > and have since 2013 (Havana): > > https://review.openstack.org/#/c/26136/ > > So unless there has been a

Re: [openstack-dev] [nova] Metadata API cross joining "instance_metadata" and "instance_system_metadata"

> Of course this is only a problem when instances have a lot of metadata > records. An instance with 50 records in "instance_metadata" and 50 > records in "instance_system_metadata" will fetch 50 x 50 = 2,500 rows > from the database. It's not difficult to see how this can escalate > quickly. This

Re: [openstack-dev] [nova] Metadata API cross joining "instance_metadata" and "instance_system_metadata"

On 10/22/2018 11:59 AM, Matt Riedemann wrote: Thanks for this. Have you debugged to the point of knowing where the initial DB query is starting from? Looking at history, my guess is this is the change which introduced it for all requests: https://review.openstack.org/#/c/276861/ From that

  1   2   3   4   5   6   7   8   9   10   >