> But 4.x was EOL over a year ago:
>
> http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2039567
...and was released in 2010.
We're supporting a minimum version of libvirt from 2014, so I think that
dropping support for five-year-old EOL'd VMware is go
> The proposed patch also drops support for 5.0, which as I understand
> it is not EOL'd? The documentation appears to indicate that some
> functionality will not work with < 5.1, but it's not explicitly clear
> what that it is.
Yeah, I guess I assumed that anyone on 5.0 was just late moving to
>=
> Worth mentioning that OpenStack releases that come out at the same time
> as Ubuntu LTS releases (12.04 + Essex, 14.04 + Icehouse, 16.04 + Mitaka)
> are supported for 5 years by Canonical so are already kind of an LTS.
> Support in this context means patches, updates and commercial support
> (for
> As providing OpenStack community with understandable recommendations
> and instructions on performant OpenStack cloud deployments is part
> of Performance Team mission, I'm kindly asking you to share your
> experience on safe cloud deployment ratio between various types of
> nodes you're having r
Hi all,
I just wanted to float this past the operators list for visibility:
Historically Nova has seeded some default flavors in an initial install.
The way it has done this is really atypical of anything else we do, as
it's embedded in the initial database schema migration. Since we're
moving wh
> I like the idea of checking the md5 matches before each boot, as it
> mirrors the check we do after downloading from glance. Its possible
> thats very unlikely to spot anything that shouldn't already be worried
> about by something else. It may just be my love of symmetry that makes
> me like tha
> It was my impression we were trying to prevent bitrot, not defend
> against an attacker that has gained control over the compute node.
I think we've established that addressing bitrot at the nova layer is
(far) out of scope and not something we want or need to do in nova.
--Dan
___
> +1 to everything Daniel said. Nova really expects release-to-release
> upgrades. We do online data migrations between releases. Maybe one
> reason you're getting this to work is we have a nova-manage command to
> force the migration of data between releases rather than doing the
> online data mig
>> The current sticking point is that nova-core doesn't want to pass
>> system-metadata to plugins, as the internal format of that changes
>> between releases and isn't intended to be versioned. Instead, we want to
>> pass just the specific bits people need.
>>
>> So -- what things are you using fr
> To be clear, they are able to communicate, and do, as long as you
> configure them to be able to do so. The long-term goal is that you don't
> have to configure them to be able to do so, so we're trying to design
> and work in that mode toward that goal.
No, the cell conductor doesn't have a way
> In a no-reschedules-by-nova world, if a deploy fails on host 1, how does
> the orchestrator (whatever that may be) ask nova to deploy in such a way
> that it'll still try to find a good host, but *avoid* host 1? If host 1
> was an attractive candidate the first time around, wouldn't it be likely
> Whoah, but that's after 10 tries (by default). And if e.g. it bounced
> because the instance is too big for the host, but other, smaller
> instances come in and succeed in the meantime, that could wind up being
> stretched indefinitely. Doesn't sound like a complete answer to this issue.
No du
> As most of the upgrade issues center around database migrations, we
> discussed some of the potential pitfalls at length. One approach was to
> roll-up all DB migrations into a single repository and run all upgrades
> for a given project in one step. Another was to simply have mutliple
> python v
So it seems our options are:
1. Allow PUT /os-services/{service_uuid} on any type of service, even if
doesn't make sense for non-nova-compute services.
2. Change the behavior of [1] to only disable new "nova-compute" services.
Please, #2. Please.
--Dan
___
Are we allowed to cheat and say auto-disabling non-nova-compute services
on startup is a bug and just fix it that way for #2? :) Because (1) it
doesn't make sense, as far as we know, and (2) it forces the operator to
have to use the API to enable them later just to fix their nova
service-list outp
> 2. Dan Smith mentioned another idea such that we could index the
> aggregate metadata keys like filter_tenant_id0, filter_tenant_id1,
> ... filter_tenant_idN and then combine those so you have one host
> aggregate filter_tenant_id* key per tenant.
Yep, and that's wha
> Rather than overload delete_on_termination, could another flag like
> delete_on_rebuild be added?
Isn't delete_on_termination already the field we want? To me, that field
means "nova owns this". If that is true, then we should be able to
re-image the volume (in-place is ideal, IMHO) and if not,
> Deleting all snapshots would seem dangerous though...
>
> 1. I want to reset my instance to how it was before
> 2. I'll just do a snapshot in case I need any data in the future
> 3. rebuild
> 4. oops
Yep, for sure. I think if there are snapshots, we have to refuse to do
te thing. My comment was
> 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, and
> Some ideas that have been discussed so far include:
FYI, these are already in my order of preference.
> A) Selecting a new, higher maximum that still yields reasonable
> performance on a single compute host (64 or 128, for example). Pros:
> helps prevent the potential for poor performance on a
> I think Nova should never have to rely on Cinder's hosts/backends
> information to do migrations or any other operation.
>
> In this case even if Nova had that info, it wouldn't be the solution.
> Cinder would reject migrations if there's an incompatibility on the
> Volume Type (AZ, Referenced ba
>> * Cells can shard across flavors (and hardware type) so operators
>> would like to move users off the old flavors/hardware (old cell) to
>> new flavors in a new cell.
>
> So cell migrations are kind of the new release upgrade dance. Got it.
No, cell migrations are about moving instances between
> A release upgrade dance involves coordination of multiple moving
> parts. It's about as similar to this scenario as I can imagine. And
> there's a reason release upgrades are not done entirely within Nova;
> clearly an external upgrade tool or script is needed to orchestrate
> the many steps and
> - The VMs to be migrated are not generally not expensive
> configurations, just hardware lifecycles where boxes go out of
> warranty or computer centre rack/cooling needs re-organising. For
> CERN, this is a 6-12 month frequency of ~10,000 VMs per year (with a
> ~30% pet share)
> - We make a cell
> I think there was a period in time where the nova_api database was created
> where entires would try to get pulled out from the original nova database and
> then checking nova_api if it doesn't exist afterwards (or vice versa). One
> of the cases that this was done to deal with was for things li
> The other obvious thing is the database. The placement repo code as-is
> today still has the check for whether or not it should use the
> placement database but falls back to using the nova_api database
> [5]. So technically you could point the extracted placement at the
> same nova_api database
> How do people feel about this? It seems pretty straight-forward to
> me. If people are generally in favor of this, then the question is
> what would be sane defaults - or should we not assume a default and
> force operators to opt into this?
I dunno, adding something to nova.conf that is only us
> I'm just a bit worried to limit that role to the elected TC members. If
> we say "it's the role of the TC to do cross-project PM in OpenStack"
> then we artificially limit the number of people who would sign up to do
> that kind of work. You mention Ildiko and Lance: they did that line of
> work
>> I disagree on this. I'd rather just do a simple check for >1
>> provider in the allocations on the source and if True, fail hard.
>>
>> The reverse (going from a non-nested source to a nested destination)
>> will hard fail anyway on the destination because the POST
>> /allocations won't work due
29 matches
Mail list logo
