Re: [Openstack-operators] Fwd: Nova hypervisor uuid

On 11/29/2018 10:27 AM, Ignazio Cassano wrote: I did in the DB directly. I am using queens now. Any python client command to delete hold records or I must use api ? You can use the CLI: https://docs.openstack.org/python-novaclient/latest/cli/nova.html#nova-service-delete

Re: [Openstack-operators] Fwd: Nova hypervisor uuid

On 11/29/2018 12:49 AM, Ignazio Cassano wrote: Hello Mattm Yes I mean sometimes I have same host/node names with different uuid in compute_nodes table in nova database I must delete nodes with uuid those not match with nova-hypervisor list command. At this time I have the following: MariaDB

Re: [Openstack-operators] Fwd: Nova hypervisor uuid

On 11/28/2018 4:19 AM, Ignazio Cassano wrote: Hi Matt, sorry but I lost your answer and Gianpiero forwarded it to me. I am sure kvm nodes names are note changed. Tables where uuid are duplicated are: dataresource_providers in nova_api db compute_nodes in nova db Regards Ignazio It would be

Re: [Openstack-operators] Nova hypervisor uuid

On 11/27/2018 11:32 AM, Ignazio Cassano wrote: Hi  All, Please anyone know where hypervisor uuid is retrived? Sometime updating kmv nodes with yum update it changes and in nova database 2 uuids are assigned to the same node. regards Ignazio ___

Re: [Openstack-operators] [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-operators] [openstack-dev] [Openstack-sigs] Dropping lazy translation support

On 11/6/2018 5:24 PM, Rochelle Grober wrote: Maybe the fastest way to get info would be to turn it off and see where the code barfs in a long run (to catch as many projects as possible)? There is zero integration testing for lazy translation, so "turning it off and seeing what breaks"

Re: [Openstack-operators] [Openstack-sigs] Dropping lazy translation support

On 11/5/2018 1:36 PM, Doug Hellmann wrote: I think the lazy stuff was all about the API responses. The log translations worked a completely different way. Yeah maybe. And if so, I came across this in one of the blueprints: https://etherpad.openstack.org/p/disable-lazy-translation Which says

[Openstack-operators] Dropping lazy translation support

This is a follow up to a dev ML email [1] where I noticed that some implementations of the upgrade-checkers goal were failing because some projects still use the oslo_i18n.enable_lazy() hook for lazy log message translation (and maybe API responses?). The very old blueprints related to this

[Openstack-operators] [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-operators] [nova] Removing the CachingScheduler

On 10/18/2018 5:07 PM, Matt Riedemann wrote: It's been deprecated since Pike, and the time has come to remove it [1]. mgagne has been the most vocal CachingScheduler operator I know and he has tested out the "nova-manage placement heal_allocations" CLI, added in Rocky, and said it

[Openstack-operators] [nova] Removing the CachingScheduler

It's been deprecated since Pike, and the time has come to remove it [1]. mgagne has been the most vocal CachingScheduler operator I know and he has tested out the "nova-manage placement heal_allocations" CLI, added in Rocky, and said it will work for migrating his deployment from the

Re: [Openstack-operators] [openstack-dev] [horizon][nova][cinder][keystone][glance][neutron][swift] Horizon feature gaps

On 10/17/2018 9:24 AM, Ivan Kolodyazhny wrote: As you may know, unfortunately, Horizon doesn't support all features provided by APIs. That's why we created feature gaps list [1]. I'd got a lot of great conversations with projects teams during the PTG and we tried to figure out what should

Re: [Openstack-operators] nova_api resource_providers table issues on ocata

On 10/17/2018 9:13 AM, Ignazio Cassano wrote: Hello Sylvain, here the output of some selects: MariaDB [nova]> select host,hypervisor_hostname from compute_nodes; +--+-+ | host | hypervisor_hostname | +--+-+ | podto1-kvm01 |

[Openstack-operators] [goals][upgrade-checkers] Week R-26 Update

The big update this week is version 0.1.0 of oslo.upgradecheck was released. The documentation along with usage examples can be found here [1]. A big thanks to Ben Nemec for getting that done since a few projects were waiting for it. In other updates, some changes were proposed in other

Re: [Openstack-operators] [openstack-dev] [nova] Supporting force live-migrate and force evacuate with nested allocations

On 10/10/2018 7:46 AM, Jay Pipes wrote: 2) in the old microversions change the blind allocation copy to gather every resource from a nested source RPs too and try to allocate that from the destination root RP. In nested allocation cases putting this allocation to placement will fail and nova

Re: [Openstack-operators] [openstack-dev] [nova] Supporting force live-migrate and force evacuate with nested allocations

On 10/9/2018 10:08 AM, Balázs Gibizer wrote: Question for you as well: if we remove (or change) the force flag in a new microversion then how should the old microversions behave when nested allocations would be required? Fail fast if we can detect we have nested. We don't support forcing

Re: [Openstack-operators] [openstack-dev] [ironic] [nova] [tripleo] Deprecation of Nova's integration with Ironic Capabilities and ComputeCapabilitiesFilter

On 9/27/2018 3:02 PM, Jay Pipes wrote: A great example of this would be the proposed "deploy template" from [2]. This is nothing more than abusing the placement traits API in order to allow passthrough of instance configuration data from the nova flavor extra spec directly into the

Re: [Openstack-operators] [openstack-dev] [goals][tc][ptl][uc] starting goal selection for T series

On 9/26/2018 3:01 PM, Doug Hellmann wrote: Monty Taylor writes: On 09/26/2018 01:55 PM, Tim Bell wrote: Doug, Thanks for raising this. I'd like to highlight the goal "Finish moving legacy python-*client CLIs to python-openstackclient" from the etherpad and propose this for a T/U series

Re: [Openstack-operators] [openstack-dev] [ironic] [nova] [tripleo] Deprecation of Nova's integration with Ironic Capabilities and ComputeCapabilitiesFilter

On 9/25/2018 8:36 AM, John Garbutt wrote: Another thing is about existing flavors configured for these capabilities-scoped specs. Are you saying during the deprecation we'd continue to use those even if the filter is disabled? In the review I had suggested that we add a

Re: [Openstack-operators] [openstack-dev] Forum Topic Submission Period

On 9/20/2018 10:23 AM, Jimmy McArthur wrote: This is basically the CFP equivalent: https://www.openstack.org/summit/berlin-2018/vote-for-speakers  Voting isn't necessary, of course, but it should allow you to see submissions as they roll in. Does this work for your purposes? Yup, that

Re: [Openstack-operators] [openstack-dev] [ironic] [nova] [tripleo] Deprecation of Nova's integration with Ironic Capabilities and ComputeCapabilitiesFilter

On 9/20/2018 4:16 AM, John Garbutt wrote: Following on from the PTG discussions, I wanted to bring everyone's attention to Nova's plans to deprecate ComputeCapabilitiesFilter, including most of the the integration with Ironic Capabilities. To be specific, this is my proposal in code form:

Re: [Openstack-operators] [openstack-dev] Forum Topic Submission Period

On 9/17/2018 11:13 AM, Jimmy McArthur wrote: The Forum Topic Submission session started September 12 and will run through September 26th.  Now is the time to wrangle the topics you gathered during your Brainstorming Phase and start pushing forum topics through. Don't rely only on a PTL to make

[Openstack-operators] Are we ready to put stable/ocata into extended maintenance mode?

The release page says Ocata is planned to go into extended maintenance mode on Aug 27 [1]. There really isn't much to this except it means we don't do releases for Ocata anymore [2]. There is a caveat that project teams that do not wish to maintain stable/ocata after this point can immediately

[Openstack-operators] [nova][publiccloud-wg] Proposal to shelve on stop/suspend

tl;dr: I'm proposing a new parameter to the server stop (and suspend?) APIs to control if nova shelve offloads the server. Long form: This came up during the public cloud WG session this week based on a couple of feature requests [1][2]. When a user stops/suspends a server, the hypervisor

Re: [Openstack-operators] [openstack-dev] [nova] Hard fail if you try to rename an AZ with instances in it?

On 3/28/2018 4:35 PM, Jay Pipes wrote: On 03/28/2018 03:35 PM, Matt Riedemann wrote: On 3/27/2018 10:37 AM, Jay Pipes wrote: If we want to actually fix the issue once and for all, we need to make availability zones a real thing that has a permanent identifier (UUID) and store that permanent

Re: [Openstack-operators] [openstack-dev] [Openstack-sigs] Open letter/request to TC candidates (and existing elected officials)

On 9/12/2018 5:32 PM, Melvin Hillsman wrote: We basically spent the day focusing on two things specific to what you bring up and are in agreement with you regarding action not just talk around feedback and outreach. [1] We wiped the agenda clean, discussed our availability (set reasonable

Re: [Openstack-operators] [openstack-dev] [Openstack-sigs] Open letter/request to TC candidates (and existing elected officials)

On 9/12/2018 5:13 PM, Jeremy Stanley wrote: Sure, and I'm saying that instead I think the influence of TC members_can_ be more valuable in finding and helping additional people to do these things rather than doing it all themselves, and it's not just about the limited number of available hours

Re: [Openstack-operators] [Openstack-sigs] [openstack-dev] Open letter/request to TC candidates (and existing elected officials)

On 9/12/2018 4:14 PM, Jeremy Stanley wrote: I think Doug's work leading the Python 3 First effort is a great example. He has helped find and enable several other goal champions to collaborate on this. I appreciate the variety of other things Doug already does with his available time and would

Re: [Openstack-operators] [Openstack-sigs] Open letter/request to TC candidates (and existing elected officials)

On 9/12/2018 3:55 PM, Jeremy Stanley wrote: I almost agree with you. I think the OpenStack TC members should be actively engaged in recruiting and enabling interested people in the community to do those things, but I don't think such work should be solely the domain of the TC and would hate to

[Openstack-operators] Open letter/request to TC candidates (and existing elected officials)

Rather than take a tangent on Kristi's candidacy thread [1], I'll bring this up separately. Kristi said: "Ultimately, this list isn’t exclusive and I’d love to hear your and other people's opinions about what you think the I should focus on." Well since you asked... Some feedback I gave to

Re: [Openstack-operators] [openstack-dev] [upgrade] request for pre-upgrade check for db purge

On 9/11/2018 9:01 AM, Dan Smith wrote: I dunno, adding something to nova.conf that is only used for nova-status like that seems kinda weird to me. It's just a warning/informational sort of thing so it just doesn't seem worth the complication to me. It doesn't seem complicated to me, I'm not

[Openstack-operators] [upgrade] request for pre-upgrade check for db purge

I created a nova bug [1] to track a request that came up in the upgrades SIG room at the PTG today [2] and would like to see if there is any feedback from other operators/developers that weren't part of the discussion. The basic problem is that failing to archive/purge deleted records* from

Re: [Openstack-operators] leaving Openstack mailing lists

On 9/6/2018 6:42 AM, Saverio Proto wrote: Hello, I will be leaving this mailing list in a few days. I am going to a new job and I will not be involved with Openstack at least in the short term future. Still, it was great working with the Openstack community in the past few years. If you need

[Openstack-operators] [nova][placement][upgrade][qa] Some upgrade-specific news on extraction

I wanted to recap some upgrade-specific stuff from today outside of the other [1] technical extraction thread. Chris has a change up for review [2] which prompted the discussion. That change makes placement only work with placement.conf, not nova.conf, but does get a passing tempest run in

Re: [Openstack-operators] [openstack-dev] OpenStack Summit Forum in Berlin: Topic Selection Process

On 9/6/2018 2:56 PM, Jeremy Stanley wrote: On 2018-09-06 14:31:01 -0500 (-0500), Matt Riedemann wrote: On 8/29/2018 1:08 PM, Jim Rollenhagen wrote: On Wed, Aug 29, 2018 at 12:51 PM, Jimmy McArthur mailto:ji...@openstack.org>> wrote: Examples of typical sessions that make for a

Re: [Openstack-operators] [openstack-dev] OpenStack Summit Forum in Berlin: Topic Selection Process

On 8/29/2018 1:08 PM, Jim Rollenhagen wrote: On Wed, Aug 29, 2018 at 12:51 PM, Jimmy McArthur > wrote: Examples of typical sessions that make for a great Forum: Strategic, whole-of-community discussions, to think about the big picture, including beyond

Re: [Openstack-operators] [openstack-dev] [nova] [placement] extraction (technical) update

On 9/5/2018 8:47 AM, Mohammed Naser wrote: Could placement not do what happened for a while when the nova_api database was created? Can you be more specific? I'm having a brain fart here and not remembering what you are referring to with respect to the nova_api DB. I say this because I

Re: [Openstack-operators] [nova][cinder][neutron] Cross-cell cold migration

On 8/29/2018 3:21 PM, Tim Bell wrote: Sounds like a good topic for PTG/Forum? Yeah it's already on the PTG agenda [1][2]. I started the thread because I wanted to get the ball rolling as early as possible, and with people that won't attend the PTG and/or the Forum, to weigh in on not only

[Openstack-operators] [nova] Deprecating Core/Disk/RamFilter

This is just an FYI that I have proposed that we deprecate the core/ram/disk filters [1]. We should have probably done this back in Pike when we removed them from the default enabled_filters list and also deprecated the CachingScheduler, which is the only in-tree scheduler driver that benefits

Re: [Openstack-operators] [openstack-dev] [nova][cinder] Disabling nova volume-update (aka swap volume; aka cinder live migration)

On 8/21/2018 5:36 AM, Lee Yarwood wrote: I'm definitely in favor of hiding this from users eventually but wouldn't this require some form of deprecation cycle? Warnings within the API documentation would also be useful and even something we could backport to stable to highlight just how fragile

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

+operators On 8/24/2018 4:08 PM, Matt Riedemann wrote: On 8/23/2018 10:22 AM, Sean McGinnis wrote: I haven't gone through the workflow, but I thought shelve/unshelve could detach the volume on shelving and reattach it on unshelve. In that workflow, assuming the networking is in place

[Openstack-operators] [nova][cinder][neutron] Cross-cell cold migration

Hi everyone, I have started an etherpad for cells topics at the Stein PTG [1]. The main issue in there right now is dealing with cross-cell cold migration in nova. At a high level, I am going off these requirements: * Cells can shard across flavors (and hardware type) so operators would

Re: [Openstack-operators] [openstack-dev] [nova] deployment question consultation

+ops list On 8/18/2018 10:20 PM, Matt Riedemann wrote: On 8/13/2018 9:30 PM, Rambo wrote:         1.Only in one region situation,what will happen in the cloud as expansion of cluster size?Then how solve it?If have the limit physical node number under the one region situation?How many nodes

Re: [Openstack-operators] [nova][glance] nova-compute choosing incorrect qemu binary when scheduling 'alternate' (ppc64, armv7l) architectures?

On 8/11/2018 12:50 AM, Chris Apsey wrote: This sounds promising and there seems to be a feasible way to do this, but it also sounds like a decent amount of effort and would be a new feature in a future release rather than a bugfix - am I correct in that assessment? Yes I'd say it's a

Re: [Openstack-operators] [nova][glance] nova-compute choosing incorrect qemu binary when scheduling 'alternate' (ppc64, armv7l) architectures?

On 8/8/2018 2:42 PM, Chris Apsey wrote: qemu-system-arm, qemu-system-ppc64, etc. in our environment are all x86 packages, but they perform system-mode emulation (via dynamic instruction translation) for those target environments.  So, you run qemu-system-ppc64 on an x86 host in order to get a

Re: [Openstack-operators] [nova][glance] nova-compute choosing incorrect qemu binary when scheduling 'alternate' (ppc64, armv7l) architectures?

On 8/7/2018 8:54 AM, Chris Apsey wrote: We don't actually have any non-x86 hardware at the moment - we're just looking to run certain workloads in qemu full emulation mode sans KVM extensions (we know there is a huge performance hit - it's just for a few very specific things).  The hosts I'm

Re: [Openstack-operators] [nova][glance] nova-compute choosing incorrect qemu binary when scheduling 'alternate' (ppc64, armv7l) architectures?

On 8/5/2018 1:43 PM, Chris Apsey wrote: Trying to enable some alternate (non-x86) architectures on xenial + queens.  I can load up images and set the property correctly according to the supported values (https://docs.openstack.org/nova/queens/configuration/config.html) in

Re: [Openstack-operators] [nova] StarlingX diff analysis

On 8/7/2018 1:10 AM, Flint WALRUS wrote: I didn’t had time to check StarlingX code quality, how did you feel it while you were doing your analysis? I didn't dig into the test diffs themselves, but it was my impression that from what I was poking around in the local git repo, there were

Re: [Openstack-operators] Live-migration experiences?

On 8/6/2018 8:12 AM, Clint Byrum wrote: First a few facts about our installation: * We're using kolla-ansible and basically leaving most nova settings at the default, meaning libvirt+kvm * We will be using block migration, as we have no shared storage of any kind. * We use routed networks to

[Openstack-operators] [nova] StarlingX diff analysis

In case you haven't heard, there was this StarlingX thing announced at the last summit. I have gone through the enormous nova diff in their repo and the results are in a spreadsheet [1]. Given the enormous spreadsheet (see a pattern?), I have further refined that into a set of high-level

Re: [Openstack-operators] [openstack-ansible] How to manage system upgrades ?

On 7/27/2018 3:34 AM, Gilles Mocellin wrote: - for compute nodes : disable compute node and live-evacuate instances... To be clear, what do you mean exactly by "live-evacuate"? I assume you mean live migration of all instances off each (disabled) compute node *before* you upgrade it. I

Re: [Openstack-operators] [nova] Couple of CellsV2 questions

I'll try to help a bit inline. Also cross-posting to openstack-dev and tagging with [nova] to highlight it. On 7/23/2018 10:43 AM, Jonathan Mills wrote: I am looking at implementing CellsV2 with multiple cells, and there's a few things I'm seeking clarification on: 1) How does a

Re: [Openstack-operators] [openstack-community] Running instance snapshot

On 7/12/2018 10:09 AM, Alfredo De Luca wrote: ​I tried with glance image-create or nova backup but I got the following Neither of those are server snapshot operations (well backup is, but it's probably not what you're looking for). glance image-create is creating an image in glance, not

Re: [Openstack-operators] [nova] Cinder cross_az_attach=False changes/fixes

Just an update on an old thread, but I've been working on the cross_az_attach=False issues again this past week and I think I have a couple of decent fixes. On 5/31/2017 6:08 PM, Matt Riedemann wrote: This is a request for any operators out there that configure nova to set: [cinder

Re: [Openstack-operators] [openstack-client] - missing commands?

On 6/13/2018 1:42 PM, Flint WALRUS wrote: Hi guys, I use the «new» openstack-client command as much as possible since a couple of years now, but yet I had a hard time recently to find equivalent command of the following: nova force-delete & The command on swift that permit to recursively

Re: [Openstack-operators] large high-performance ephemeral storage

On 6/13/2018 10:54 AM, Chris Friesen wrote: Also, migration and resize are not supported for LVM-backed instances. I proposed a patch to support them (https://review.openstack.org/#/c/337334/) but hit issues and never got around to fixing them up. Yup, I guess I should have read the entire

Re: [Openstack-operators] large high-performance ephemeral storage

On 6/13/2018 8:58 AM, Blair Bethwaite wrote: Though we have not used LVM based instance storage before, are there any significant gotchas? I know you can't resize/cold migrate lvm-backed ephemeral root disk instances:

[Openstack-operators] Reminder to add "nova-status upgrade check" to deployment tooling

I was going through some recently reported nova bugs and came across [1] which I opened at the Summit during one of the FFU sessions where I realized the nova upgrade docs don't mention the nova-status upgrade check CLI [2] (added in Ocata). As a result, I was wondering how many deployment

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

On 6/7/2018 1:54 PM, Jay Pipes wrote: If Cinder tracks volume attachments as consumable resources, then this would be my preference. Cinder does: https://developer.openstack.org/api-ref/block-storage/v3/#attachments However, there is no limit in Cinder on those as far as I know. --

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

+operators (I forgot) On 6/7/2018 1:07 PM, 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 limitat

Re: [Openstack-operators] [nova] nova-compute automatically disabling itself?

On 2/6/2018 6:44 PM, Matt Riedemann wrote: On 2/6/2018 2:14 PM, Chris Apsey wrote: but we would rather have intermittent build failures rather than compute nodes falling over in the future. Note that once a compute has a successful build, the consecutive build failures counter is reset. So

[Openstack-operators] [nova] Need feedback on spec for handling down cells in the API

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 to return "shell" instances which have the

Re: [Openstack-operators] [openstack-dev] [TC] Stein Goal Selection

+openstack-operators since we need to have more operator feedback in our community-wide goals decisions. +Melvin as my elected user committee person for the same reasons as adding operators into the discussion. On 6/4/2018 3:38 PM, Matt Riedemann wrote: On 6/4/2018 1:07 PM, Sean McGinnis

Re: [Openstack-operators] [openstack-dev] [nova][glance] Deprecation of nova.image.download.modules extension point

+openstack-operators to see if others have the same use case On 5/31/2018 5:14 PM, Moore, Curt wrote: We recently upgraded from Liberty to Pike and looking ahead to the code in Queens, noticed the image download deprecation notice with instructions to post here if this interface was in use. 

Re: [Openstack-operators] [nova] isolate hypervisor to project

On 6/4/2018 6:43 AM, Tobias Urdin wrote: I have received a question about a more specialized use case where we need to isolate several hypervisors to a specific project. My first thinking was using nova flavors for only that project and add extra specs properties to use a specific host

Re: [Openstack-operators] attaching network cards to VMs taking a very long time

On 6/2/2018 1:37 AM, Chris Apsey wrote: This is great.  I would even go so far as to say the install docs should be updated to capture this as the default; as far as I know there is no negative impact when running in daemon mode, even on very small deployments.  I would imagine that there are

Re: [Openstack-operators] attaching network cards to VMs taking a very long time

On 5/30/2018 9:30 AM, Matt Riedemann wrote: I can start pushing some docs patches and report back here for review help. Here are the docs patches in both nova and neutron: https://review.openstack.org/#/q/topic:bug/1774217+(status:open+OR+status:merged) -- Thanks, Matt

Re: [Openstack-operators] [openstack-dev] [nova] proposal to postpone nova-network core functionality removal to Stein

+openstack-operators On 5/31/2018 3:04 PM, Matt Riedemann wrote: On 5/31/2018 1:35 PM, melanie witt wrote: This cycle at the PTG, we had decided to start making some progress toward removing nova-network [1] (thanks to those who have helped!) and so far, we've landed some patches to extract

Re: [Openstack-operators] Problems with AggregateMultiTenancyIsolation while migrating an instance

On 5/30/2018 9:41 AM, Matt Riedemann wrote: Thanks for your patience in debugging this Massimo! I'll get a bug reported and patch posted to fix it. I'm tracking the problem with this bug: https://bugs.launchpad.net/nova/+bug/1774205 I found that this has actually been fixed since Pike

Re: [Openstack-operators] Problems with AggregateMultiTenancyIsolation while migrating an instance

On 5/30/2018 5:21 AM, Massimo Sgaravatto wrote: The problem is indeed with the tenant_id When I create a VM, tenant_id is ee1865a76440481cbcff08544c7d580a (SgaraPrj1), as expected But when, as admin, I run the "nova migrate" command to migrate the very same instance, the tenant_id is 

Re: [Openstack-operators] attaching network cards to VMs taking a very long time

On 5/29/2018 8:23 PM, Chris Apsey wrote: I want to echo the effectiveness of this change - we had vif failures when launching more than 50 or so cirros instances simultaneously, but moving to daemon mode made this issue disappear and we've tested 5x that amount.  This has been the single

Re: [Openstack-operators] Problems with AggregateMultiTenancyIsolation while migrating an instance

On 5/29/2018 3:07 PM, Massimo Sgaravatto wrote: The VM that I am trying to migrate was created when the Cloud was already running Ocata OK, I'd added the tenant_id variable in scope to the log message here:

Re: [Openstack-operators] Problems with AggregateMultiTenancyIsolation while migrating an instance

On 5/29/2018 12:44 PM, Jay Pipes wrote: Either that, or the wrong project_id is being used when attempting to migrate? Maybe the admin project_id is being used instead of the original project_id who launched the instance? Could be, but we should be pulling the request spec from the database

Re: [Openstack-operators] Problems with AggregateMultiTenancyIsolation while migrating an instance

On 5/29/2018 11:10 AM, Jay Pipes wrote: The hosts you are attempting to migrate *to* do not have the filter_tenant_id property set to the same tenant ID as the compute host 2 that originally hosted the instance. That is why you see this in the scheduler logs when evaluating the fitness of

Re: [Openstack-operators] [nova] Need some feedback on the proposed heal_allocations CLI

On 5/28/2018 7:31 AM, Sylvain Bauza wrote: That said, given I'm now working on using Nested Resource Providers for VGPU inventories, I wonder about a possible upgrade problem with VGPU allocations. Given that :  - in Queens, VGPU inventories are for the root RP (ie. the compute node RP), but,

[Openstack-operators] [nova] Need some feedback on the proposed heal_allocations CLI

I've written a nova-manage placement heal_allocations CLI [1] which was a TODO from the PTG in Dublin as a step toward getting existing CachingScheduler users to roll off that (which is deprecated). During the CERN cells v1 upgrade talk it was pointed out that CERN was able to go from

Re: [Openstack-operators] Multiple Ceph pools for Nova?

On 5/21/2018 11:51 AM, Smith, Eric wrote: I have 2 Ceph pools, one backed by SSDs and one backed by spinning disks (Separate roots within the CRUSH hierarchy). I’d like to run all instances in a single project / tenant on SSDs and the rest on spinning disks. How would I go about setting this

[Openstack-operators] [nova] FYI on changes that might impact out of tree scheduler filters

CERN has upgraded to Cells v2 and is doing performance testing of the scheduler and were reporting some things today which got us back to this bug [1]. So I've starting pushing some patches related to this but also related to an older blueprint I created [2]. In summary, we do quite a bit of

Re: [Openstack-operators] Need feedback for nova aborting cold migration function

On 5/15/2018 3:48 AM, saga...@nttdata.co.jp wrote: We store the service logs which are created by VM on that storage. I don't mean to be glib, but have you considered maybe not doing that? -- Thanks, Matt ___ OpenStack-operators mailing list

Re: [Openstack-operators] attaching network cards to VMs taking a very long time

On 5/17/2018 9:46 AM, George Mihaiescu wrote: and large rally tests of 500 instances complete with no issues. Sure, except you can't ssh into the guests. The whole reason the vif plugging is fatal and timeout and callback code was because the upstream CI was unstable without it. The server

Re: [Openstack-operators] attaching network cards to VMs taking a very long time

On 5/16/2018 10:30 AM, Radu Popescu | eMAG, Technology wrote: but I can see nova attaching the interface after a huge amount of time. What specifically are you looking for in the logs when you see this? Are you passing pre-created ports to attach to nova or are you passing a network ID so

Re: [Openstack-operators] New project creation fails because of a Nova check in a multi-region cloud

On 5/10/2018 6:30 PM, Jean-Philippe Méthot wrote: 1.I was talking about the region-name parameter underneath keystone_authtoken. That is in the pike doc you linked, but I am unaware if this is only used for token generation or not. Anyhow, it doesn’t seem to have any impact on the issue at

Re: [Openstack-operators] Need feedback for nova aborting cold migration function

On 5/9/2018 9:33 PM, saga...@nttdata.co.jp wrote: We always do the maintenance work on midnight during limited time-slot to minimize impact to our users. Also, why are you doing maintenance with cold migration? Why not do live migration for your maintenance (which already supports the abort

Re: [Openstack-operators] New project creation fails because of a Nova check in a multi-region cloud

On 5/9/2018 8:11 PM, Jean-Philippe Méthot wrote: I currently operate a multi-region cloud split between 2 geographic locations. I have updated it to Pike not too long ago, but I've been running into a peculiar issue. Ever since the Pike release, Nova now asks Keystone if a new project exists

Re: [Openstack-operators] [openstack-dev] [nova][ironic] ironic_host_manager and baremetal scheduler options removal

On 5/2/2018 12:39 PM, Matt Riedemann wrote: FWIW, I think we can also backport the data migration CLI to stable branches once we have it available so you can do your migration in let's say Queens before g FYI, here is the start on the data migration CLI: https://review.openstack.org/#/c

Re: [Openstack-operators] [openstack-dev] [nova][placement] Trying to summarize bp/glance-image-traits scheduling alternatives for rebuild

On 5/2/2018 5:39 PM, Jay Pipes wrote: My personal preference is to add less technical debt and go with a solution that checks if image traits have changed in nova-api and if so, simply refuse to perform a rebuild. So, what if when I created my server, the image I used, let's say image1, had

Re: [Openstack-operators] [openstack-dev] [nova][ironic] ironic_host_manager and baremetal scheduler options removal

On 5/2/2018 12:00 PM, Mathieu Gagné wrote: If one can still run CachingScheduler (even if it's deprecated), I think we shouldn't remove the above options. As you can end up with a broken setup and IIUC no way to migrate to placement since migration script has yet to be written. You're

Re: [Openstack-operators] [openstack-dev] [nova][ironic] ironic_host_manager and baremetal scheduler options removal

On 5/2/2018 11:40 AM, Mathieu Gagné wrote: What's the state of caching_scheduler which could still be using those configs? The CachingScheduler has been deprecated since Pike [1]. We discussed the CachingScheduler at the Rocky PTG in Dublin [2] and have a TODO to write a nova-manage data

[Openstack-operators] [nova][ironic] ironic_host_manager and baremetal scheduler options removal

The baremetal scheduling options were deprecated in Pike [1] and the ironic_host_manager was deprecated in Queens [2] and is now being removed [3]. Deployments must use resource classes now for baremetal scheduling. [4] The large host subset size value is also no longer needed. [5] I've gone

Re: [Openstack-operators] [openstack-dev] [nova][placement] Trying to summarize bp/glance-image-traits scheduling alternatives for rebuild

On 5/1/2018 5:26 PM, Arvind N wrote: In cases of rebuilding of an instance using a different image where the image traits have changed between the original launch and the rebuild, is it reasonable to ask to just re-launch a new instance with the new image? The argument for this approach is

Re: [Openstack-operators] [openstack-dev] [nova] Default scheduler filters survey

On 4/30/2018 11:41 AM, Mathieu Gagné wrote: [6] Used to filter Ironic nodes based on the 'reserved_for_user_id' Ironic node property. This is mainly used when enrolling existing nodes already living on a different system. We reserve the node to a special internal user so the customer

Re: [Openstack-operators] [openstack-dev] [nova] Default scheduler filters survey

On 4/27/2018 4:02 AM, Tomáš Vondra wrote: Also, Windows host isolation is done using image metadata. I have filled a bug somewhere that it does not work correctly with Boot from Volume. Likely because for boot from volume the instance.image_id is ''. The request spec, which the filter has

Re: [Openstack-operators] [openstack-dev] [nova] Concern about trusted certificates API change

On 4/18/2018 11:57 AM, Jay Pipes wrote: There is a compute REST API change proposed [1] which will allow users to pass trusted certificate IDs to be used with validation of images when creating or rebuilding a server. The trusted cert IDs are based on certificates stored in some key manager,

[Openstack-operators] [nova] Concern about trusted certificates API change

There is a compute REST API change proposed [1] which will allow users to pass trusted certificate IDs to be used with validation of images when creating or rebuilding a server. The trusted cert IDs are based on certificates stored in some key manager, e.g. Barbican. The full nova spec is

Re: [Openstack-operators] [openstack-dev] RFC: Next minimum libvirt / QEMU versions for "Stein" release

On 4/9/2018 4:58 AM, Kashyap Chamarthy wrote: Keep in mind that Matt has a tendency to sometimes unfairly over-simplify others views;-). More seriously, c'mon Matt; I went out of my way to spend time learning about Debian's packaging structure and trying to get the details right by talking to

Re: [Openstack-operators] [openstack-dev] RFC: Next minimum libvirt / QEMU versions for "Stein" release

On 4/6/2018 12:07 PM, Kashyap Chamarthy wrote: FWIW, I'd suggest so, if it's not too much maintenance. It'll just spare you additional bug reports in that area, and the overall default experience when dealing with CPU models would be relatively much better. (Another way to look at it is,

Re: [Openstack-operators] [openstack-dev] RFC: Next minimum libvirt / QEMU versions for "Stein" release

On 4/5/2018 3:32 PM, Thomas Goirand wrote: If you don't absolutely need new features from libvirt 3.2.0 and 3.0.0 is fine, please choose 3.0.0 as minimum. If you don't absolutely need new features from qemu 2.9.0 and 2.8.0 is fine, please choose 2.8.0 as minimum. If you don't absolutely need

Re: [Openstack-operators] nova-placement-api tuning

On 3/29/2018 12:05 PM, Chris Dent wrote: Other suggestions? I'm looking at things like turning off scheduler_tracks_instance_changes, since affinity scheduling is not needed (at least so-far), but not sure that that will help with placement load (seems like it might, though?) This won't

Re: [Openstack-operators] [openstack-dev] [all][stable] No more stable Phases welcome Extended Maintenance

On 3/29/2018 3:36 AM, Tony Breeds wrote: Hi all, At Sydney we started the process of change on the stable branches. Recently we merged a TC resolution[1] to alter the EOL process. The next step is refinining the stable policy itself. I've created a review to do that. I think it covers

Re: [Openstack-operators] IMPORTANT - future of ops meetups!

On 3/27/2018 12:49 PM, Chris Morgan wrote: With the current level of support for this idea, it looks likely to happen, but, particularly if you object, please speak up ASAP. Note that this would be instead of the tentative idea we had of an event in NYC in August. If this is welcomed by the

  1   2   3   >