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

On 11/8/2018 5:30 AM, Rambo wrote:  When I resize the instance, the compute node report that "libvirtError: internal error: qemu unexpectedly closed the monitor: 2018-11-08T09:42:04.695681Z qemu-kvm: cannot set up guest memory 'pc.ram': Cannot allocate memory".Has anyone seen this

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 quo

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] Supporting force live-migrate and force evacuate with nested allocations

On 10/9/2018 1:20 PM, Jay Pipes wrote: On 10/09/2018 11:04 AM, Balázs Gibizer wrote: If you do the force flag removal in a nw microversion that also means (at least to me) that you should not change the behavior of the force flag in the old microversions. Agreed. Keep the old, buggy and

[openstack-dev] [nova] agreement on how to specify options that impact scheduling and configuration

While discussing the "Add HPET timer support for x86 guests" blueprint[1] one of the items that came up was how to represent what are essentially flags that impact both scheduling and configuration. Eric Fried posted a spec to start a discussion[2], and a number of nova developers met on a

Re: [openstack-dev] [helm] multiple nova compute nodes

On 10/2/2018 4:15 PM, Giridhar Jayavelu wrote: Hi, Currently, all nova components are packaged in same helm chart "nova". Are there any plans to separate nova-compute from rest of the services ? What should be the approach for deploying multiple nova computes nodes using OpenStack helm charts?

[openstack-dev] [storyboard] why use different "bug" tags per project?

Hi, At the PTG, it was suggested that each project should tag their bugs with "-bug" to avoid tags being "leaked" across projects, or something like that. Could someone elaborate on why this was recommended? It seems to me that it'd be better for all projects to just use the "bug" tag for

Re: [openstack-dev] [goals][python3] mixed versions?

On 9/12/2018 12:04 PM, Doug Hellmann wrote: This came up in a Vancouver summit session (the python3 one I think). General consensus there seemed to be that we should have grenade jobs that run python2 on the old side and python3 on the new side and test the update from one to another through

Re: [openstack-dev] [all] Bringing the community together (combine the lists!)

On 08/30/2018 11:03 AM, Jeremy Stanley wrote: The proposal is simple: create a new openstack-discuss mailing list to cover all the above sorts of discussion and stop using the other four. Do we want to merge usage and development onto one list? That could be a busy list for someone who's

Re: [openstack-dev] [all] [nova] [placement] placement below or beside compute after extraction?

On 08/21/2018 04:33 PM, melanie witt wrote: If we separate into two different groups, all of the items I discussed in my previous reply will become cross-project efforts. To me, this means that the placement group will have their own priorities and goal setting process and if their priorities

Re: [openstack-dev] [all] [nova] [placement] placement below or beside compute after extraction?

On 08/21/2018 01:53 PM, melanie witt wrote: Given all of that, I'm not seeing how *now* is a good time to separate the placement project under separate governance with separate goals and priorities. If operators need things for compute, that are well-known and that placement was created to

Re: [openstack-dev] [all] [nova] [placement] placement below or beside compute after extraction?

On 08/20/2018 11:44 AM, Zane Bitter wrote: If you want my personal opinion then I'm a big believer in incremental change. So, despite recognising that it is born of long experience of which I have been blissfully mostly unaware, I have to disagree with Chris's position that if anybody lets you

Re: [openstack-dev] [nova] How to debug no valid host failures with placement

On 08/04/2018 05:18 PM, Matt Riedemann wrote: On 8/3/2018 9:14 AM, Chris Friesen wrote: I'm of two minds here. On the one hand, you have the case where the end user has accidentally requested some combination of things that isn't normally available, and they need to be able to ask the provider

Re: [openstack-dev] [puppet] migrating to storyboard

On 08/14/2018 10:33 AM, Tobias Urdin wrote: My goal is that we will be able to swap to Storyboard during the Stein cycle but considering that we have a low activity on bugs my opinion is that we could do this swap very easily anything soon as long as everybody is in favor of it. Please let me

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

On 08/07/2018 07:29 AM, Matt Riedemann wrote: 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

Re: [openstack-dev] [nova] Do we still want to lowercase metadata keys?

On 08/13/2018 08:26 AM, Jay Pipes wrote: On 08/13/2018 10:10 AM, Matthew Booth wrote: I suspect I've misunderstood, but I was arguing this is an anti-goal. There's no reason to do this if the db is working correctly, and it would violate the principal of least surprise in dbs with legacy

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

On 08/13/2018 02:07 AM, Rambo wrote: Hi,all I find it is important that live-resize the instance in production environment,especially live downsize the disk.And we have talked it many years.But I don't know why the bp[1] didn't approved.Can you tell me more about this ?Thank you very

Re: [openstack-dev] [nova] How to debug no valid host failures with placement

On 08/02/2018 06:27 PM, Jay Pipes wrote: On 08/02/2018 06:18 PM, Michael Glasgow wrote: More generally, any time a service fails to deliver a resource which it is primarily designed to deliver, it seems to me at this stage that should probably be taken a bit more seriously than just "check

Re: [openstack-dev] [nova] How to debug no valid host failures with placement

On 08/02/2018 01:04 PM, melanie witt wrote: The problem is an infamous one, which is, your users are trying to boot instances and they get "No Valid Host" and an instance in ERROR state. They contact support, and now support is trying to determine why NoValidHost happened. In the past, they

Re: [openstack-dev] [nova] How to debug no valid host failures with placement

On 08/02/2018 04:10 AM, Chris Dent wrote: When people ask for something like what Chris mentioned: hosts with enough CPU: hosts that also have enough disk: hosts that also have enough memory: hosts that also meet extra spec host aggregate keys: hosts that also meet

Re: [openstack-dev] [nova] How to debug no valid host failures with placement

On 08/01/2018 11:34 PM, Joshua Harlow wrote: And I would be able to say request the explanation for a given request id (historical even) so that analysis could be done post-change and pre-change (say I update the algorithm for selection) so that the effects of alternations to said decisions

Re: [openstack-dev] [nova] How to debug no valid host failures with placement

On 08/01/2018 11:32 AM, melanie witt wrote: I think it's definitely a significant issue that troubleshooting "No allocation candidates returned" from placement is so difficult. However, it's not straightforward to log detail in placement when the request for allocation candidates is essentially

Re: [openstack-dev] [nova] How to debug no valid host failures with placement

On 08/01/2018 11:17 AM, Ben Nemec wrote: On 08/01/2018 11:23 AM, Chris Friesen wrote: The fact that there is no real way to get the equivalent of the old detailed scheduler logs is a known shortcoming in placement, and will become more of a problem if/when we move more complicated things

Re: [openstack-dev] [nova] How to debug no valid host failures with placement

On 08/01/2018 09:58 AM, Andrey Volkov wrote: Hi, It seems you need first to check what placement knows about resources of your cloud. This can be done either with REST API [1] or with osc-placement [2]. For osc-placement you could use: pip install osc-placement openstack allocation candidate

Re: [openstack-dev] [nova] keypair quota usage info for user

On 07/25/2018 06:22 PM, Alex Xu wrote: 2018-07-26 1:43 GMT+08:00 Chris Friesen mailto:chris.frie...@windriver.com>>: Keypairs are weird in that they're owned by users, not projects. This is arguably wrong, since it can cause problems if a user boots an in

Re: [openstack-dev] [nova] keypair quota usage info for user

On 07/25/2018 06:21 PM, Alex Xu wrote: 2018-07-26 0:29 GMT+08:00 William M Edmonds mailto:edmon...@us.ibm.com>>: Ghanshyam Mann mailto:gm...@ghanshyammann.com>> wrote on 07/25/2018 05:44:46 AM: ... snip ... > 1. is it ok to show the keypair used info via API ? any original

Re: [openstack-dev] [nova] keypair quota usage info for user

On 07/25/2018 10:29 AM, William M Edmonds wrote: Ghanshyam Mann wrote on 07/25/2018 05:44:46 AM: ... snip ... > 1. is it ok to show the keypair used info via API ? any original > rational not to do so or it was just like that from starting. keypairs aren't tied to a tenant/project, so how

Re: [openstack-dev] [infra][nova] Running NFV tests in CI

On 07/24/2018 12:47 PM, Clark Boylan wrote: Can you get by with qemu or is nested virt required? Pretty sure that nested virt is needed in order to test CPU pinning. As for hugepages, I've done a quick survey of cpuinfo across our clouds and all seem to have pse available but not all have

[openstack-dev] [StoryBoard] issues found while using storyboard

Hi, I'm on a team that is starting to use StoryBoard, and I just thought I'd raise some issues I've recently run into. It may be that I'm making assumptions based on previous tools that I've used (Launchpad and Atlassian's Jira) and perhaps StoryBoard is intended to be used differently, so

Re: [openstack-dev] [nova] Bug 1781710 killing the check queue

On 07/18/2018 03:43 PM, melanie witt wrote: On Wed, 18 Jul 2018 15:14:55 -0500, Matt Riedemann wrote: On 7/18/2018 1:13 PM, melanie witt wrote: Can we get rid of multi-create? It keeps causing complications, and it already has weird behaviour if you ask for min_count=X and max_count=Y and

Re: [openstack-dev] [nova] Bug 1781710 killing the check queue

On 07/18/2018 10:14 AM, Matt Riedemann wrote: As can be seen from logstash [1] this bug is hurting us pretty bad in the check queue. I thought I originally had this fixed with [2] but that turned out to only be part of the issue. I think I've identified the problem but I have failed to write a

Re: [openstack-dev] creating instance

On 07/10/2018 03:04 AM, jayshankar nair wrote: Hi, I am trying to create an instance of cirros os(Project/Compute/Instances). I am getting the following error. Error: Failed to perform requested operation on instance "cirros1", the instance has an error status: Please try again later [Error:

Re: [openstack-dev] [cinder] making volume available without stopping VM

On 06/23/2018 08:38 AM, Volodymyr Litovka wrote: Dear friends, I did some tests with making volume available without stopping VM. I'm using CEPH and these steps produce the following results: 1) openstack volume set --state available [UUID] - nothing changed inside both VM (volume is still

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

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

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

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

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

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

On 06/07/2018 12:07 PM, Matt Riedemann wrote: On 6/7/2018 12:56 PM, melanie witt wrote: C) Create a configurable API limit for maximum number of volumes to attach to a single instance that is either a quota or similar to a quota. Pros: lets operators opt-in to a maximum that works in their

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

On 05/31/2018 04:14 PM, Moore, Curt wrote: The challenge is that transferring the Glance image transfer is _glacially slow_ when using the Glance HTTP API (~30 min for a 50GB Windows image (It’s Windows, it’s huge with all of the necessary tools installed)). If libvirt can instead perform an

Re: [openstack-dev] [cyborg] [nova] Cyborg quotas

On 05/19/2018 05:58 PM, Blair Bethwaite wrote: G'day Jay, On 20 May 2018 at 08:37, Jay Pipes wrote: If it's not the VM or baremetal machine that is using the accelerator, what is? It will be a VM or BM, but I don't think accelerators should be tied to the life of a

Re: [openstack-dev] openstack-dev] [nova] Cannot live migrattion, because error:libvirtError: the CPU is incompatible with host CPU: Host CPU does not provide required features: cmt, mbm_total, mbm_lo

On 05/13/2018 09:23 PM, 何健乐 wrote: Hi, all When I did live-miration , I met the following error: |result ||=||proxy_call(||self||._autowrap, f, ||*||args, ||*||*||kwargs)| |May ||14| |10||:||33||:||11| |nova||-||compute[||981335||]: ||File| |"/usr/lib64/python2.7/site-packages/libvirt.py"||,

Re: [openstack-dev] [nova] reboot a rescued instance?

On 05/04/2018 07:50 AM, Matt Riedemann wrote: For full details on this, see the IRC conversation [1]. tl;dr: the nova compute manager and xen virt driver assume that you can reboot a rescued instance [2] but the API does not allow that [3] and as far as I can tell, it never has. I can only

Re: [openstack-dev] [nova] Heads up for out-of-tree drivers: supports_recreate -> supports_evacuate

On 04/19/2018 08:33 AM, Jay Pipes wrote: On 04/19/2018 09:15 AM, Matthew Booth wrote: We've had inconsistent naming of recreate/evacuate in Nova for a long time, and it will persist in a couple of places for a while more. However, I've proposed the following to rename 'recreate' to 'evacuate'

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

On 04/18/2018 10:57 AM, Jay Pipes wrote: On 04/18/2018 12:41 PM, Matt Riedemann 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

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

On 04/18/2018 09:17 AM, Artom Lifshitz wrote: To that end, we'd like to know what filters operators are enabling in their deployment. If you can, please reply to this email with your [filter_scheduler]/enabled_filters (or [DEFAULT]/scheduler_default_filters if you're using an older version)

Re: [openstack-dev] [placement][nova] Decision time on granular request groups for like resources

On 04/18/2018 09:58 AM, Matt Riedemann wrote: On 4/18/2018 9:06 AM, Jay Pipes wrote: "By default, should resources/traits submitted in different numbered request groups be supplied by separate resource providers?" Without knowing all of the hairy use cases, I'm trying to channel my inner

Re: [openstack-dev] [placement][nova] Decision time on granular request groups for like resources

On 04/18/2018 08:06 AM, Jay Pipes wrote: Stackers, Eric Fried and I are currently at an impasse regarding a decision that will have far-reaching (and end-user facing) impacts to the placement API and how nova interacts with the placement service from the nova scheduler. We need to make a

Re: [openstack-dev] [novaclient] invoking methods on the same client object in different theads caused malformed requests

On 04/03/2018 04:25 AM, Xiong, Huan wrote: Hi, I'm using a cloud benchmarking tool [1], which creates a *single* nova client object in main thread and invoke methods on that object in different worker threads. I find it generated malformed requests at random (my system has python-novaclient

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

On 03/27/2018 10:42 AM, 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 identifier in the instance (not the

Re: [openstack-dev] [keystone] batch processing with unified limits

On 03/07/2018 06:10 PM, Lance Bragstad wrote: The keystone team is parsing the unified limits discussions from last week. One of the things we went over as a group was the usability of the current API [0]. Currently, the create and update APIs support batch processing. So specifying a list of

Re: [openstack-dev] [Openstack-sigs] [keystone] [oslo] new unified limit library

On 03/07/2018 10:44 AM, Tim Bell wrote: I think nested quotas would give the same thing, i.e. you have a parent project for the group and child projects for the users. This would not need user/group quotas but continue with the ‘project owns resources’ approach. Agreed, I think that if we

Re: [openstack-dev] [keystone] [oslo] new unified limit library

On 03/07/2018 09:49 AM, Lance Bragstad wrote: On 03/07/2018 09:31 AM, Chris Friesen wrote: On 03/07/2018 08:58 AM, Lance Bragstad wrote: Hi all, Per the identity-integration track at the PTG [0], I proposed a new oslo library for services to use for hierarchical quota enforcement [1]. Let

Re: [openstack-dev] [keystone] [oslo] new unified limit library

On 03/07/2018 10:33 AM, Tim Bell wrote: Sorry, I remember more detail now... it was using the 'owner' of the VM as part of the policy rather than quota. Is there a per-user/per-group quota in Nova? Nova supports setting quotas for individual users within a project (as long as they are

Re: [openstack-dev] [keystone] [oslo] new unified limit library

On 03/07/2018 08:58 AM, Lance Bragstad wrote: Hi all, Per the identity-integration track at the PTG [0], I proposed a new oslo library for services to use for hierarchical quota enforcement [1]. Let me know if you have any questions or concerns about the library. If the oslo team would like, I

Re: [openstack-dev] [libvrit] Can QEMU or LIBVIRT know VM is powering-off

On 02/21/2018 03:19 PM, Kwan, Louie wrote: When turning off a VM by doing nova stop, the Status and Task State is there for Nova. But can Libvirt / qemu programmatically figure out the ‘Task State’ that the VM is trying to powering-off ?. For libvirt, it seems only know the “Power State”?

Re: [openstack-dev] [all][Kingbird]Multi-Region Orchestrator

On 02/05/2018 06:33 PM, Jay Pipes wrote: It does seem to me, however, that if the intention is *not* to get into the multi-cloud orchestration game, that a simpler solution to this multi-region OpenStack deployment use case would be to simply have a global Glance and Keystone infrastructure

Re: [openstack-dev] [nova][osc] How to deal with add/remove fixed/floating CLIs after novaclient 10.0.0?

On 01/30/2018 09:15 AM, Matt Riedemann wrote: The 10.0.0 release of python-novaclient dropped some deprecated CLIs and python API bindings for the server actions to add/remove fixed and floating IPs: https://docs.openstack.org/releasenotes/python-novaclient/queens.html#id2

Re: [openstack-dev] [nova] heads up to users of Aggregate[Core|Ram|Disk]Filter: behavior change in >= Ocata

On 01/18/2018 02:54 PM, Mathieu Gagné wrote: We use this feature to segregate capacity/hosts based on CPU allocation ratio using aggregates. This is because we have different offers/flavors based on those allocation ratios. This is part of our business model. A flavor extra_specs is use to

Re: [openstack-dev] [ironic] Booting IPA from cinder: Was: Summary of ironic sessions from Sydney

On 11/24/2017 10:23 AM, Julia Kreger wrote: Greetings Michael, I believe It would need to involve multiple machines at the same time. I guess there are two different approaches that I think _could_ be taken to facilitate this: 1) Provide a facility to use a specific volume as the "golden

Re: [openstack-dev] Upstream LTS Releases

On 11/14/2017 02:10 PM, Doug Hellmann wrote: Excerpts from Chris Friesen's message of 2017-11-14 14:01:58 -0600: On 11/14/2017 01:28 PM, Dmitry Tantsur wrote: The quality of backported fixes is expected to be a direct (and only?) interest of those new teams of new cores, coming from users and

Re: [openstack-dev] Upstream LTS Releases

On 11/14/2017 01:28 PM, Dmitry Tantsur wrote: The quality of backported fixes is expected to be a direct (and only?) interest of those new teams of new cores, coming from users and operators and vendors. I'm not assuming bad intentions, not at all. But there is a lot of involved in a decision

Re: [openstack-dev] Upstream LTS Releases

On 11/14/2017 10:25 AM, Doug Hellmann wrote: Why would we have third-party jobs on an old branch that we don't have on master, for instance? One possible reason is to test the stable version of OpenStack against a stable version of the underlying OS distro. (Where that distro may not meet

Re: [openstack-dev] [nova] Interesting bug when unshelving an instance in an AZ and the AZ is gone

On 10/16/2017 09:22 AM, Matt Riedemann wrote: 2. Should we null out the instance.availability_zone when it's shelved offloaded like we do for the instance.host and instance.node attributes? Similarly, we would not take into account the RequestSpec.availability_zone when scheduling during

Re: [openstack-dev] [nova] Should we make rebuild + new image on a volume-backed instance fail fast?

On 10/06/2017 11:32 AM, Mathieu Gagné wrote: Why not supporting this use case? I don't think anyone is suggesting we support do it, but nobody has stepped up to actually merge a change that implements it. I think what Matt is suggesting is that we make it fail fast *now*, and if someone

Re: [openstack-dev] [nova] What is the goal of AggregateImagePropertiesIsolation filter?

On 10/05/2017 03:47 AM, Kekane, Abhishek wrote: So the question here is, what is the exact goal of AggregateImagePropertiesIsolation' scheduler filter: - Is it one of the following:- 1. Matching all metadata of host aggregate with image properties. 2. Matching image properties with host

Re: [openstack-dev] [nova] Running large instances with CPU pinning and OOM

On 09/28/2017 05:29 AM, Sahid Orentino Ferdjaoui wrote: Only the memory mapped for the guest is striclty allocated from the NUMA node selected. The QEMU overhead should float on the host NUMA nodes. So it seems that the "reserved_host_memory_mb" is enough. What I see in the code/docs doesn't

Re: [openstack-dev] [nova] Running large instances with CPU pinning and OOM

On 09/27/2017 04:55 PM, Blair Bethwaite wrote: Hi Prema On 28 September 2017 at 07:10, Premysl Kouril wrote: Hi, I work with Jakub (the op of this thread) and here is my two cents: I think what is critical to realize is that KVM virtual machines can have substantial

Re: [openstack-dev] [nova] Running large instances with CPU pinning and OOM

On 09/27/2017 03:10 PM, Premysl Kouril wrote: Lastly, qemu has overhead that varies depending on what you're doing in the guest. In particular, there are various IO queues that can consume significant amounts of memory. The company that I work for put in a good bit of effort engineering things

Re: [openstack-dev] [nova] Running large instances with CPU pinning and OOM

On 09/27/2017 08:01 AM, Blair Bethwaite wrote: On 27 September 2017 at 23:19, Jakub Jursa wrote: 'hw:cpu_policy=dedicated' (while NOT setting 'hw:numa_nodes') results in libvirt pinning CPU in 'strict' memory mode (from libvirt xml for given instance) ...

Re: [openstack-dev] [nova] Running large instances with CPU pinning and OOM

On 09/27/2017 03:12 AM, Jakub Jursa wrote: On 27.09.2017 10:40, Blair Bethwaite wrote: On 27 September 2017 at 18:14, Stephen Finucane wrote: What you're probably looking for is the 'reserved_host_memory_mb' option. This defaults to 512 (at least in the latest master)

Re: [openstack-dev] [nova] Is there any reason to exclude originally failed build hosts during live migration?

On 09/20/2017 12:47 PM, Matt Riedemann wrote: I wanted to bring it up here in case anyone had a good reason why we should not continue to exclude originally failed hosts during live migration, even if the admin is specifying one of those hosts for the live migration destination. Presumably

Re: [openstack-dev] [nova] Should we add the 'force' option to the cold migrate API too?

On 08/30/2017 10:56 AM, Matt Riedemann wrote: On 8/30/2017 11:35 AM, Chris Friesen wrote: (We might even want to fail a live migration/evacuation with a forced destination that could cause a conflict in these non-shareable resources, but that'd be a behaviour change and therefore a new

Re: [openstack-dev] [nova] Should we add the 'force' option to the cold migrate API too?

On 08/30/2017 09:09 AM, Matt Riedemann wrote: Given the recent bugs [1][2] due to the force flag in the live migrate and evacuate APIs related to Placement, and some other long standing bugs about bypassing the scheduler [3], I don't think we should add the force option to the cold migrate API,

Re: [openstack-dev] [Horizon][Nova] Editing flavor causing instance flavor display error

On 08/03/2017 04:21 AM, Sean Dague wrote: On 08/03/2017 06:13 AM, Zhenyu Zheng wrote: I was thinking, the current "edit" in Horizon is delete-and-create, and it is there maybe just because flavor has many fields, user may want to have a new flavor but just modify one of the old flavor, so they

Re: [openstack-dev] [nova][docs] Concerns with docs migration

On 08/02/2017 09:22 AM, Stephen Finucane wrote: On Wed, 2017-08-02 at 09:55 -0500, Matt Riedemann wrote: 3. The patch for the import of the admin guide [8] is missing some CLI specific pages which are pretty useful given they aren't documented anywhere else, like the forced_host part of the

Re: [openstack-dev] Help regarding VM Migration

On 07/25/2017 10:21 PM, Ziad Nayyer wrote: Can anybody help me out regarding VM migration between two devstacks installed on two different physical machines? Hot or cold? Are you configured as per https://docs.openstack.org/devstack/latest/guides/multinode-lab.html ? Chris

Re: [openstack-dev] realtime kvm cpu affinities

On 06/30/2017 07:06 AM, sfinu...@redhat.com wrote: On Thu, 2017-06-29 at 12:20 -0600, Chris Friesen wrote: On 06/29/2017 10:59 AM, sfinu...@redhat.com wrote: From the above, there are 3-4 work items: - Add a 'emulator_pin_set' or 'cpu_emulator_threads_mask' configuration option

Re: [openstack-dev] realtime kvm cpu affinities

On 06/29/2017 10:59 AM, sfinu...@redhat.com wrote: Thus far, we've no clear conclusions on directions to go, so I've took a stab below. Henning, Sahid, Chris: does the above/below make sense, and is there anything we need to further clarify? The above is close enough. :) # Problem 1 From

Re: [openstack-dev] [all][tc] How to deal with confusion around "hosted projects"

On 06/29/2017 09:23 AM, Monty Taylor wrote: We are already WELL past where we can solve the problem you are describing. Pandora's box has been opened - we have defined ourselves as an Open community. Our only requirement to be official is that you behave as one of us. There is nothing stopping

Re: [openstack-dev] [masakari][nova] Allow evacuation of instances in resized state

On 06/28/2017 05:50 AM, Kekane, Abhishek wrote: In masakari, we are setting an instance to an error state if the vmstate is resized before evacuating it to a new host. Arguably the instance should be set to an error state as soon as you notice that the compute node is down. Once an

Re: [openstack-dev] realtime kvm cpu affinities

On 06/28/2017 03:34 AM, Sahid Orentino Ferdjaoui wrote: On Tue, Jun 27, 2017 at 04:00:35PM +0200, Henning Schild wrote: As far as i remember it was not straight forward to get two novas onto one host in the older release, i am not surprised that causing trouble with the update to mitaka. If

Re: [openstack-dev] realtime kvm cpu affinities

On 06/27/2017 09:36 AM, Henning Schild wrote: Am Tue, 27 Jun 2017 09:28:34 -0600 schrieb Chris Friesen <chris.frie...@windriver.com>: Once you use "isolcpus" on the host, the host scheduler won't "float" threads between the CPUs based on load. To get the

Re: [openstack-dev] realtime kvm cpu affinities

On 06/27/2017 01:45 AM, Sahid Orentino Ferdjaoui wrote: On Mon, Jun 26, 2017 at 12:12:49PM -0600, Chris Friesen wrote: On 06/25/2017 02:09 AM, Sahid Orentino Ferdjaoui wrote: On Fri, Jun 23, 2017 at 10:34:26AM -0600, Chris Friesen wrote: On 06/23/2017 09:35 AM, Henning Schild wrote: Am Fri

Re: [openstack-dev] realtime kvm cpu affinities

On 06/27/2017 01:44 AM, Sahid Orentino Ferdjaoui wrote: On Mon, Jun 26, 2017 at 10:19:12AM +0200, Henning Schild wrote: Am Sun, 25 Jun 2017 10:09:10 +0200 schrieb Sahid Orentino Ferdjaoui <sferd...@redhat.com>: On Fri, Jun 23, 2017 at 10:34:26AM -0600, Chris Friesen wrote: On 06/23/2

Re: [openstack-dev] realtime kvm cpu affinities

On 06/25/2017 02:09 AM, Sahid Orentino Ferdjaoui wrote: On Fri, Jun 23, 2017 at 10:34:26AM -0600, Chris Friesen wrote: On 06/23/2017 09:35 AM, Henning Schild wrote: Am Fri, 23 Jun 2017 11:11:10 +0200 schrieb Sahid Orentino Ferdjaoui <sferd...@redhat.com>: In Linux RT context, and

Re: [openstack-dev] realtime kvm cpu affinities

On 06/23/2017 09:35 AM, Henning Schild wrote: Am Fri, 23 Jun 2017 11:11:10 +0200 schrieb Sahid Orentino Ferdjaoui : In Linux RT context, and as you mentioned, the non-RT vCPU can acquire some guest kernel lock, then be pre-empted by emulator thread while holding this

Re: [openstack-dev] realtime kvm cpu affinities

On 06/22/2017 01:47 AM, Henning Schild wrote: Am Wed, 21 Jun 2017 11:40:14 -0600 schrieb Chris Friesen <chris.frie...@windriver.com>: On 06/21/2017 10:46 AM, Henning Schild wrote: As we know from our setup, and as Luiz confirmed - it is _not_ "critical to separate emula

Re: [openstack-dev] realtime kvm cpu affinities

On 06/21/2017 10:46 AM, Henning Schild wrote: Am Wed, 21 Jun 2017 10:04:52 -0600 schrieb Chris Friesen <chris.frie...@windriver.com>: i guess you are talking about that section from [1]: We could use a host level tunable to just reserve a set of host pCPUs for running emulator t

Re: [openstack-dev] realtime kvm cpu affinities

On 06/21/2017 02:42 AM, Henning Schild wrote: Am Tue, 20 Jun 2017 10:41:44 -0600 schrieb Chris Friesen <chris.frie...@windriver.com>: Our goal is to reach a high packing density of realtime VMs. Our pragmatic first choice was to run all non-vcpu-threads on a shared set of pcpus where w

Re: [openstack-dev] [nova][scheduler][placement] Trying to understand the proposed direction

On 06/20/2017 09:51 AM, Eric Fried wrote: Nice Stephen! For those who aren't aware, the rendered version (pretty, so pretty) can be accessed via the gate-nova-docs-ubuntu-xenial jenkins job:

Re: [openstack-dev] [nova] How to handle nova show --minimal with embedded flavors

On 06/20/2017 07:59 AM, Matt Riedemann wrote: Personally I think that if I specify --minimal I want minimal output, which would just be the flavor's original name after the new microversion, which is closer in behavior to how --minimal works today before the 2.47 microversion. In the existing

Re: [openstack-dev] [openstack-dev[[nova] Simple question about sorting CPU topologies

On 06/20/2017 06:29 AM, Jay Pipes wrote: On 06/19/2017 10:45 PM, Zhenyu Zheng wrote: Sorry, The mail sent accidentally by mis-typing ... My question is, what is the benefit of the above preference? Hi Kevin! I believe the benefit is so that the compute node prefers CPU topologies that do

Re: [openstack-dev] realtime kvm cpu affinities

On 06/20/2017 01:48 AM, Henning Schild wrote: Hi, We are using OpenStack for managing realtime guests. We modified it and contributed to discussions on how to model the realtime feature. More recent versions of OpenStack have support for realtime, and there are a few proposals on how to improve

Re: [openstack-dev] [all][tc] Moving away from "big tent" terminology

On 06/16/2017 02:57 AM, Julien Danjou wrote: On Thu, Jun 15 2017, Doug Hellmann wrote: One of the *most* common complaints the TC gets from outside the contributor community is that people do not understand what projects are part of OpenStack and what parts are not. We have a clear definition

Re: [openstack-dev] [all][tc][glance] Glance needs help, it's getting critical

On 06/12/2017 01:50 PM, Flavio Percoco wrote: Glance can be very exciting if one focuses on the interesting bits and it's an *AWESOME* place where new comers can start contributing, new developers can learn and practice, etc. That said, I believe that code doesn't have to be challenging to be

Re: [openstack-dev] Is the pendulum swinging on PaaS layers?

On 05/19/2017 04:06 PM, Dean Troyer wrote: On Fri, May 19, 2017 at 4:01 PM, Matt Riedemann wrote: I'm confused by this. Creating a server takes a volume ID if you're booting from volume, and that's actually preferred (by nova devs) since then Nova doesn't have to

Re: [openstack-dev] Is the pendulum swinging on PaaS layers?

On 05/20/2017 10:36 AM, Monty Taylor wrote: On 05/19/2017 03:13 PM, Monty Taylor wrote: On 05/19/2017 01:53 PM, Sean Dague wrote: On 05/19/2017 02:34 PM, Dean Troyer wrote: On Fri, May 19, 2017 at 1:04 PM, Sean Dague wrote: These should be used as ways to experiment with the

[openstack-dev] [nova][neutron] massive overhead processing "network-changed" events during live migration

Recently we noticed failures in Newton when we attempted to live-migrate an instance with 16 vifs. We tracked it down to an RPC timeout in nova which timed out waiting for the 'refresh_cache-%s' lock in get_instance_nw_info(). This led to a few other discoveries. First, we have no fair

Re: [openstack-dev] Is the pendulum swinging on PaaS layers?

On 05/19/2017 07:18 AM, Sean Dague wrote: There was a conversation in the Cell v2 discussion around searchlight that puts me more firmly in the anti enamel camp. Because of some complexities around server list, Nova was planning on using Searchlight to provide an efficient backend. Q: Who in

  1   2   3   4   5   6   >