[openstack-dev] [nova] [placement] placement extraction session at forum

I've started an etherpad related to the Vancouver Forum session on extracting placement from nova. It's mostly just an outline for now but is evolving: https://etherpad.openstack.org/p/YVR-placement-extraction If we can get some real information in there before the session we are much more

Re: [openstack-dev] [nova][third-party-ci]zKVM (s390x) CI broken

The root cause seems to be bug [1]. It’s related to nova cells v2 configuration in devstack. Stephen Finucane already promised to have a look later the day (thx!!!). I keep the CI running for now... [1] https://bugs.launchpad.net/devstack/+bug/1770143 --- Andreas Scheuring (andreas_s) On 9.

[openstack-dev] [nova][third-party-ci]zKVM (s390x) CI broken

Hi all, the nova CI for zKVM is currently broken - need to investigate. It seems like the vnc console gets configured for some reason (vnc is not supported on s390x)... --- Andreas Scheuring (andreas_s) __ OpenStack

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

On 5/8/2018 7:41 AM, Bob Ball wrote: I'd be hesitant to permit reboot-from-rescue for all drivers as I'm not sure the drivers would have consistent (or perhaps working!) behaviours? Is there a way to enable this when using XenAPI? Off the top of my head the virt driver could report a

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

) <openstack-dev@lists.openstack.org> Subject: [openstack-dev] [nova] reboot a rescued instance? 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 t

[openstack-dev] [nova] nova-manage cell_v2 map_instances uses invalid UUID as marker in the db

Hi, The oslo UUIDField emits a warning if the string used as a field value does not pass the validation of the uuid.UUID(str(value)) call [3]. All the offending places are fixed in nova except the nova-manage cell_v2 map_instances call [1][2]. That call uses markers in the DB that are not

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

Hi, After a bit of silence here is the latest notification status. Bugs [Low] https://bugs.launchpad.net/nova/+bug/1757407 Notification sending sometimes hits the keystone API to get glance endpoints Fix has been proposed has many +1s https://review.openstack.org/#/c/564528/ [Medium]

Re: [openstack-dev] [nova] Extra feature of vCPU allocation on demands

On 05/07/2018 05:55 AM, 倪蔚辰 wrote: Hi, all I would like to propose a blueprint (not proposed yet), which is related to openstack nova. I hope to have some comments by explaining my idea through this e-mail. Please contact me if anyone has any comment. Background Under current OpenStack,

Re: [openstack-dev] [nova] Extra feature of vCPU allocation on demands

I will be interested to watch this develop. In PowerVM we already have shared vs. dedicated processors [1] along with concepts like capped vs. uncapped, min/max proc units, weights, etc. But obviously it's all heavily customized to be PowerVM-specific. If these concepts made their way into

[openstack-dev] [nova] review runway status

Howdy everyone, This is just a brief status about the blueprints currently occupying review runways [0] and an ask for the nova-core team to give these reviews priority for their code review focus. * XenAPI: Support a new image handler for non-FS based SRs

[openstack-dev] [nova] Extra feature of vCPU allocation on demands

Hi, all I would like to propose a blueprint (not proposed yet), which is related to openstack nova. I hope to have some comments by explaining my idea through this e-mail. Please contact me if anyone has any comment. Background Under current OpenStack, vCPUs assigned to each VM can be

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

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

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 assume that Rackspace had an out of tree change

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

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 assume that Rackspace had an out of tree change

[openstack-dev] [nova] A short guide to adding privsep'ed methods in Nova

I was asked yesterday for a guide on how to write new escalated methods with oslo privsep, so I wrote up a blog post about it this morning. It might be useful to others here. http://www.madebymikal.com/how-to-make-a-privileged-call-with-oslo-privsep/ I intend to write up how to add privsep to a

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

>> verify with placement >> whether the image traits requested are 1) supported by the compute >> host the instance is residing on and 2) coincide with the >> already-existing allocations. Note that #2 is a subset of #1. The only potential advantage of including #1 is efficiency: We can do #1 in

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

On 5/3/2018 3:26 PM, Dan Smith wrote: Well, it's a little itcky in that it makes a random part of conductor a bit like the scheduler in its understanding of and iteraction with placement. I don't love it, but I think it's what we have to do. Trying to do the trait math with what was used before,

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

> I'm late to this thread but I finally went through the replies and my > thought is, we should do a pre-flight check to verify with placement > whether the image traits requested are 1) supported by the compute > host the instance is residing on and 2) coincide with the > already-existing

Re: [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:

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

On Wed, 2 May 2018 17:45:37 -0500, Matt Riedemann wrote: 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

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

Isnt this an existing issue with traits specified in flavor as well? Server is created using flavor1 requiring trait A on RP1. Before the rebuild is called, the underlying RP1 can be updated to remove trait A and when a rebuild is requested(regardless of whether the image is updated or not), we

Re: [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-dev] [nova][placement] Trying to summarize bp/glance-image-traits scheduling alternatives for rebuild

On 05/02/2018 10:07 AM, Matt Riedemann wrote: 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

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

On Wed, May 2, 2018 at 1:39 PM, Matt Riedemann wrote: > > I know you're just one case, but I don't know how many people are really > running the CachingScheduler with ironic either, so it might be rare. It > would be nice to get other operator input here, like I'm guessing

Re: [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-dev] [nova][ironic] ironic_host_manager and baremetal scheduler options removal

On Wed, May 2, 2018 at 12:49 PM, Matt Riedemann wrote: > 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 >

Re: [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

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

What's the state of caching_scheduler which could still be using those configs? Mathieu On Wed, May 2, 2018 at 12:25 PM, Matt Riedemann wrote: > The baremetal scheduling options were deprecated in Pike [1] and the > ironic_host_manager was deprecated in Queens [2] and is

[openstack-dev] [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-dev] [nova][placement] Trying to summarize bp/glance-image-traits scheduling alternatives for rebuild

> What if the API compares the original image required traits against the new image required traits, and if the new image has required traits which weren't in the original image, then (punt) fail in the API? Then you would at least have a chance > to rebuild with a new image that has required

Re: [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-dev] [nova][placement] Trying to summarize bp/glance-image-traits scheduling alternatives for rebuild

On 4/24/2018 8:26 AM, Sylvain Bauza wrote: We also have pre-flight checks for move operations like live and cold migrations, and I'd really like to keep all the conditionals in the conductor, because it knows better than the scheduler which operation is asked. I'm not sure what "pre-flight

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

On 4/24/2018 3:25 AM, Balázs Gibizer wrote: The algorithm Eric provided in a previous mail do the filtering for the RPs that are part of the instance allocation so that sounds good to me. Yeah I've been wondering if that solves this VF case. I think we should not try to adjust allocations

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

On 4/23/2018 4:51 PM, Arvind N wrote: For #1, we can make the explanation very clear that we rejected the request because the original traits specified in the original image and the new traits specified in the new image do not match and hence rebuild is not supported. We don't reject rebuild

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

On 4/23/2018 4:43 PM, Jay Pipes wrote: How about just having the conductor call GET /resource_providers?in_tree==, see if there is a result, and if not, don't even call the scheduler at all (because conductor would already know there would be a NoValidHost returned)? This makes filtering on

Re: [openstack-dev] [Nova] z/VM introducing a new config driveformat

stack-dev@lists.openstack.org> Date: 04/30/2018 10:55 PM Subject:Re: [openstack-dev] [Nova] z/VM introducing a new config driveformat > According to requirements and comments, now we opened the CI runs with > run_validation = True And according to [1] below, for e

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

Reminder for Operators, Please provide feedback either way. 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

[openstack-dev] [nova] Virtuozzo CI status

Hi Stackers, Lately, I noticed the Virtuozzo CI has been having some problems, for example on a recent example run [0], the job link is broken: "The requested URL /22/563722/4/check/check-dsvm-tempest-vz7-exe-minimal/d1d1707 was not found on this server." Prior to that, I noticed that the

Re: [openstack-dev] [Nova] z/VM introducing a new config driveformat

On Mon, 30 Apr 2018 12:42:40 -0400, Matthew Treinish wrote: On Mon, Apr 30, 2018 at 09:21:22AM -0700, melanie witt wrote: On Fri, 27 Apr 2018 17:40:20 +0800, Chen Ch Ji wrote: According to requirements and comments, now we opened the CI runs with run_validation = True And according to [1]

[openstack-dev] [nova] review runway status

Howdy everyone, This is just a brief status about the blueprints currently occupying review runways [0] and an ask for the nova-core team to give these reviews priority for their code review focus. * XenAPI: Support a new image handler for non-FS based SRs

Re: [openstack-dev] [Nova] z/VM introducing a new config driveformat

On Mon, Apr 30, 2018 at 09:21:22AM -0700, melanie witt wrote: > On Fri, 27 Apr 2018 17:40:20 +0800, Chen Ch Ji wrote: > > According to requirements and comments, now we opened the CI runs with > > run_validation = True > > And according to [1] below, for example, [2] need the ssh validation > >

Re: [openstack-dev] [Nova] z/VM introducing a new config driveformat

On Fri, 27 Apr 2018 17:40:20 +0800, Chen Ch Ji wrote: According to requirements and comments, now we opened the CI runs with run_validation = True And according to [1] below, for example, [2] need the ssh validation passed the test And there are a couple of comments need some enhancement on

Re: [openstack-dev] [Nova] z/VM introducing a new config driveformat

> According to requirements and comments, now we opened the CI runs with > run_validation = True And according to [1] below, for example, [2] > need the ssh validation passed the test > > And there are a couple of comments need some enhancement on the logs > of CI such as format and legacy

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

Thanks everyone for your input! I wrote a small Python script [1] to present all your responses in an understandable format. Here's the output: Filters common to all deployments: {'ComputeFilter', 'ServerGroupAntiAffinityFilter'} Filter counts (out of 9 deployments):

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

At Catalyst Cloud: RetryFilter AvailabilityZoneFilter RamFilter ComputeFilter AggregateCoreFilter DiskFilter AggregateInstanceExtraSpecsFilter ImagePropertiesFilter ServerGroupAntiAffinityFilter SameHostFilter Cheers, Lingxian Kong On Sat, Apr 28, 2018 at 3:04 AM Jim Rollenhagen

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

On Wed, Apr 18, 2018 at 11:17 AM, Artom Lifshitz wrote: > Hi all, > > A CI issue [1] caused by tempest thinking some filters are enabled > when they're really not, and a proposed patch [2] to add > (Same|Different)HostFilter to the default filters as a workaround, has > led

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

Welcome to placement update 18-17. This is an expand update, meaning I've gone searching for new stuff to add to the lists. In other news: I'll be on holiday next week so there won't be one of these next week, unless somebody else wants to do one. # Most Important A great deal of stuff is

[openstack-dev] [nova] Next notification subteam meeting is cancelled

Hi, I have to cancel the next notification subteam meeting as it happens to be on 1st of May which is (inter)national holiday. So the next meeting expected to be held on 8th of May. Cheers, gibi __ OpenStack

Re: [openstack-dev] [Nova] z/VM introducing a new config driveformat

District, Beijing 100193, PRC From: melanie witt <melwi...@gmail.com> To: openstack-dev@lists.openstack.org Date: 04/18/2018 01:41 AM Subject: Re: [openstack-dev] [Nova] z/VM introducing a new config driveformat On Tue, 17 Apr 2018 16:58:22 +0800, Chen Ch Ji

Re: [openstack-dev] [nova] Help needed in debugging issue - ClientException: Unable to update the attachment. (HTTP 500)

On 25/04/18 9:09 PM, Matt Riedemann wrote: On 4/25/2018 10:34 AM, Sreeram Vancheeswaran wrote: Thank you so much Matt for the detailed steps. We are doing boot from image and are probably running into the issue mentioned in [2] in your email. Hmm, OK, but that doesn't really make sense

Re: [openstack-dev] [nova] Help needed in debugging issue - ClientException: Unable to update the attachment. (HTTP 500)

On 4/25/2018 10:34 AM, Sreeram Vancheeswaran wrote: Thank you so much Matt for the detailed steps.  We are doing boot from image and are probably running into the issue mentioned in [2] in your email. Hmm, OK, but that doesn't really make sense how you're going down this path [1] in the code

Re: [openstack-dev] [nova] Help needed in debugging issue - ClientException: Unable to update the attachment. (HTTP 500)

On 25/04/18 7:40 PM, Matt Riedemann wrote: On 4/25/2018 3:32 AM, Sreeram Vancheeswaran wrote: Hi team! We are currently facing an issue in our out-of-tree driver nova-dpm [1] with nova and cinder on master, where instance launch in devstack is failing due to communication/time-out issues

Re: [openstack-dev] [nova] Help needed in debugging issue - ClientException: Unable to update the attachment. (HTTP 500)

On 4/25/2018 3:32 AM, Sreeram Vancheeswaran wrote: Hi team! We are currently facing  an issue in our out-of-tree driver nova-dpm [1] with nova and cinder on master, where instance launch in devstack is failing due to communication/time-out issues in nova-cinder.   We are unable to get to the

[openstack-dev] [nova] Help needed in debugging issue - ClientException: Unable to update the attachment. (HTTP 500)

Hi team! We are currently facing an issue in our out-of-tree driver nova-dpm [1] with nova and cinder on master, where instance launch in devstack is failing due to communication/time-out issues in nova-cinder. We are unable to get to the root cause of the issue and we need your help on

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

On 4/23/2018 8:07 AM, Balázs Gibizer wrote: Add versioned notifications for removing a member from a server group - The specless bp https://blueprints.launchpad.net/nova/+spec/add-server-group-remove-member-notifications is

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

Alex- On 04/24/2018 09:21 AM, Alex Xu wrote: > > > 2018-04-24 20:53 GMT+08:00 Eric Fried >: > > > The problem isn't just checking the traits in the nested resource > > provider. We also need to ensure the trait in the exactly same child

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

2018-04-24 20:53 GMT+08:00 Eric Fried : > > The problem isn't just checking the traits in the nested resource > > provider. We also need to ensure the trait in the exactly same child > > resource provider. > > No, we can't get "granular" with image traits. We accepted this as

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

Sorry folks for the late reply, I'll try to also weigh in the Gerrit change. On Tue, Apr 24, 2018 at 2:55 PM, Jay Pipes wrote: > On 04/23/2018 05:51 PM, Arvind N wrote: > >> Thanks for the detailed options Matt/eric/jay. >> >> Just few of my thoughts, >> >> For #1, we can

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

On 04/23/2018 05:51 PM, Arvind N wrote: Thanks for the detailed options Matt/eric/jay. Just few of my thoughts, For #1, we can make the explanation very clear that we rejected the request because the original traits specified in the original image and the new traits specified in the new

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

> The problem isn't just checking the traits in the nested resource > provider. We also need to ensure the trait in the exactly same child > resource provider. No, we can't get "granular" with image traits. We accepted this as a limitation for the spawn aspect of this spec [1], for all the same

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

On Tue, Apr 24, 2018 at 9:08 AM, Alex Xu wrote: 2018-04-24 5:51 GMT+08:00 Arvind N : Thanks for the detailed options Matt/eric/jay. Just few of my thoughts, For #1, we can make the explanation very clear that we rejected the request because the

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

2018-04-24 5:51 GMT+08:00 Arvind N : > Thanks for the detailed options Matt/eric/jay. > > Just few of my thoughts, > > For #1, we can make the explanation very clear that we rejected the > request because the original traits specified in the original image and the > new

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

> > 1. Fail in the API saying you can't rebuild with a new image with new > required traits. Pros: - Simple way to keep the new image off a host that doesn't support it. > - Similar solution to volume-backed rebuild with a new image. Cons: - Confusing user experience since they might be able

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

> for the GET > /resource_providers?in_tree==, nested > resource providers and allocation pose a problem see #3 above. This *would* work as a quick up-front check as Jay described (if you get no results from this, you know that at least one of your image traits doesn't exist anywhere in the tree)

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

Thanks for the detailed options Matt/eric/jay. Just few of my thoughts, For #1, we can make the explanation very clear that we rejected the request because the original traits specified in the original image and the new traits specified in the new image do not match and hence rebuild is not

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

On 04/23/2018 03:48 PM, Matt Riedemann wrote: We seem to be at a bit of an impasse in this spec amendment [1] so I want to try and summarize the alternative solutions as I see them. The overall goal of the blueprint is to allow defining traits via image properties, like flavor extra specs.

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

Following the discussion on IRC, here's what I think you need to do: - Assuming the set of traits from your new image is called image_traits... - Use GET /allocations/{instance_uuid} and pull out the set of all RP UUIDs. Let's call this instance_rp_uuids. - Use the

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

On 4/23/2018 3:26 PM, Eric Fried wrote: No, the question you're really asking in this case is, "Do the resource providers in this tree contain (or not contain) these traits?" Which to me, translates directly to: GET /resource_providers?in_tree=$rp_uuid={$TRAIT|!$TRAIT, ...} ...which we

[openstack-dev] [nova] Do we need bp/list-show-all-server-migration-types?

Looking over the things in the runways queue [1], excluding the zVM driver (because I'm not sure what the status is on that thread), the next in line is blueprint list-show-all-server-migration-types [2]. I know this has been approved since Pike, but I wanted to raise some questions again [3]

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

Semantically, GET /allocation_candidates where we don't actually want to allocate anything (i.e. we don't want to use the returned candidates) is goofy, and talking about what the result would look like when there's no `resources` is going to spider into some weird questions. Like what does the

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

We seem to be at a bit of an impasse in this spec amendment [1] so I want to try and summarize the alternative solutions as I see them. The overall goal of the blueprint is to allow defining traits via image properties, like flavor extra specs. Those image-defined traits are used to filter

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

Hi, New week, new status mail. Bugs New bugs [Undecided] https://bugs.launchpad.net/nova/+bug/1764927 Should send out notification when instance metadata get updated Nova already sends instance.update notification when instance.metadata is changed so I marked the bug invalid.

Re: [openstack-dev] [Nova] z/VM introducing a new config driveformat

, PRC From: Jim Rollenhagen <j...@jimrollenhagen.com> To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org> Date: 04/20/2018 10:13 PM Subject: Re: [openstack-dev] [Nova] z/VM introducing a new config

Re: [openstack-dev] [Nova] z/VM introducing a new config driveformat

On Fri, Apr 20, 2018 at 4:02 AM, Chen CH Ji wrote: > Thanks a lot for your sharing, that's good info, just curious why [1] need > zip and base64 encode if my understand is correct > I was told nova need format should be pure vfat or iso9660, I assume it's > because actually

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

This is a "contract" update, the lists of specs and other has not had new things added to it, only stuff that is done removed. There are of course new things out there, but they will be added next week. # Most Important Nested providers in allocation candidates remains the important stuff.

Re: [openstack-dev] [Nova] z/VM introducing a new config driveformat

AM Subject: Re: [openstack-dev] [Nova] z/VM introducing a new config driveformat On Wed, Apr 18, 2018 at 10:56 AM, Matthew Booth <mbo...@redhat.com> wrote: > I agree with Mikal that needing more agent behavior than cloud-init does > a disservice to the users

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

On 04/19/2018 12:27 PM, Matt Riedemann wrote: On 4/19/2018 11:06 AM, Matthew Booth wrote: I'm ambivalent, tbh, but I think it's better to pick one. I thought we'd picked 'evacuate' based on the TODOs from Matt R: http://git.openstack.org/cgit/openstack/nova/tree/nova/compute/manager.py#n2985

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

On 4/19/2018 10:46 AM, Chris Friesen wrote: From the CLI perspective, it makes no sense that "nova evacuate" operates after a host is already down, but "nova evacuate-live" operates on a running host. http://www.danplanet.com/blog/2016/03/03/evacuate-in-nova-one-command-to-confuse-us-all/

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

On 4/19/2018 11:06 AM, Matthew Booth wrote: I'm ambivalent, tbh, but I think it's better to pick one. I thought we'd picked 'evacuate' based on the TODOs from Matt R: http://git.openstack.org/cgit/openstack/nova/tree/nova/compute/manager.py#n2985

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

On 19 April 2018 at 16:46, Chris Friesen wrote: > 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

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

On 19 April 2018 at 15:33, 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

Re: [openstack-dev] [nova][placement] Scheduler VM distribution

Привет, Андрей! Comments inline... On 04/19/2018 10:27 AM, Andrey Volkov wrote: Hello, From my understanding, we have a race between the scheduling process and host weight update. I made a simple experiment. On the 50 fake host environment it was asked to boot 40 VMs those should be placed 1

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'

[openstack-dev] [nova][placement] Scheduler VM distribution

Hello, >From my understanding, we have a race between the scheduling process and host weight update. I made a simple experiment. On the 50 fake host environment it was asked to boot 40 VMs those should be placed 1 on each host. The hosts are equal to each other in terms of inventory.

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

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' everywhere with no rpc/api impact here:

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

Two different setups, very basic. AggregateInstanceExtraSpecsFilter RetryFilter AvailabilityZoneFilter ComputeFilter ComputeCapabilitiesFilter ImagePropertiesFilter ServerGroupAntiAffinityFilter ServerGroupAffinityFilter RetryFilter AvailabilityZoneFilter RamFilter ComputeFilter

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

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' everywhere with no rpc/api impact here: https://review.openstack.org/560900 One of the

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

Artom Lifshitz writes: > 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) > option from

Re: [openstack-dev] [Nova] z/VM introducing a new config driveformat

> Having briefly read the cloud-init snippet which was linked earlier in > this thread, the requirement seems to be that the guest exposes the > device as /dev/srX or /dev/cdX. So I guess in order to make this work: > > * You need to tell z/VM to expose the virtual disk as an optical disk > * The

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

> Maybe it wasn't clear but I'm not advocating that we block the change > until volume-backed instances are supported with trusted certs. I'm > suggesting we add a policy rule which allows deployers to at least > disable it via policy if it's not supported for their cloud. That's fine with me,

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

<chris.frie...@windriver.com> :Reply-To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org> :Date: Wednesday, 18 April 2018 at 18:34 :To: "openstack-dev@lists.openstack.org" <openstack-dev@lists.openstack.org> :Subje

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

<openstack-dev@lists.openstack.org> Date: Wednesday, 18 April 2018 at 18:34 To: "openstack-dev@lists.openstack.org" <openstack-dev@lists.openstack.org> Subject: Re: [openstack-dev] [nova] Default scheduler filters survey On 04/18/2018 09:17 AM, Artom Lifshitz wrote:

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

On 04/18/2018 01:14 PM, Matt Riedemann wrote: On 4/18/2018 12:09 PM, Chris Friesen wrote: If this happens, is it clear to the end-user that the reason the boot failed is that the cloud doesn't support trusted cert IDs for boot-from-vol?  If so, then I think that's totally fine. If you're

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

On 4/18/2018 12:09 PM, Chris Friesen wrote: If this happens, is it clear to the end-user that the reason the boot failed is that the cloud doesn't support trusted cert IDs for boot-from-vol?  If so, then I think that's totally fine. If you're creating an image-backed server and requesting

Re: [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,

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] Concern about trusted certificates API change

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 on certificates stored in some key

[openstack-dev] [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-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] [nova] Rocky forum topics brainstorming

On Fri, 13 Apr 2018 08:00:31 -0700, Melanie Witt wrote: +openstack-operators (apologies that I forgot to add originally) On Mon, 9 Apr 2018 10:09:12 -0700, Melanie Witt wrote: Hey everyone, Let's collect forum topic brainstorming ideas for the Forum sessions in Vancouver in this etherpad [0].

<    3   4   5   6   7   8   9   10   11   12   >