On 5/24/2018 8:33 PM, Jeffrey Zhang wrote:
Recently, i am trying to implement a function which aggregate nova
hypervisors
rather than nova compute host. But seems nova only aggregate
nova-compute host.
On the other hand, since Ocata, nova depends on placement api which supports
aggregating
I'd like to understand the phrase "StarlingX is an OpenStack Foundation Edge
focus area project".
My understanding of the current situation is that "StarlingX would like to be
OpenStack Foundation Edge focus area project".
I have not been able to keep up with all of the discussions so I'd be
not sure whether it will helpful , FYI
https://developer.openstack.org/api-ref/placement/
The primary differences between Nova’s host aggregates and placement
aggregates are the following:
In Nova, a host aggregate associates a nova-compute service with
other nova-compute services.
Recently, i am trying to implement a function which aggregate nova
hypervisors
rather than nova compute host. But seems nova only aggregate nova-compute
host.
On the other hand, since Ocata, nova depends on placement api which supports
aggregating resource providers. But nova-scheduler doesn't
Hi,
I'd like to know what's the status of neutron-rpc-server. As I switched
the Debian package from neutron-server to neutron-api using uwsgi, I
tried using it, and it seems it kind of works, if I apply this patch:
https://review.openstack.org/#/c/555608
Is there anything else that I should
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
> For example, I look at your nova fork and it has a "don't allow this
> call during an upgrade" decorator on many API calls. Why wasn't that
> done upstream? It doesn't seem overly controversial, so it would be
> useful to understand the reasoning for that change.
Interesting. We have internal
Hello,
Please, try `cinder --os-volume-api-versio=3 manageable-list
openstack-dev@VMAX_ISCSI_DIAMOND#Diamond+DSS+SRP_1+000297000333` or
`OS_VOLUME_API_VERSION=3 cinder manageable-list openstack-dev@VMAX_ISCSI_
DIAMOND#Diamond+DSS+SRP_1+000297000333`
Devstack used Cinder API v2 by default before
On 5/23/18 6:49 PM, Sagi Shnaidman wrote:
Alex,
the problem is that you're working and focusing mostly on release
specific code like featuresets and some scripts. But
tripleo-quickstart(-extras) and tripleo-ci is much *much* more than set
of featuresets. Only 10% of the code may be related
As discussed in the IRC over , here is the outline:
* Derive parameters workflow could be used for deriving FixedIPs
parameters also (started as part of the review
https://review.openstack.org/#/c/569818/)
* Above derivation should be done for all the deployments, so invoking
of derive parameters
Sending on Michael's behalf...
From: McAleer, Michael
Sent: Monday 21 May 2018 15:18
To: 'openstack-dev@lists.openstack.org'
Subject: FW: [openstack-dev] [cinder]
Hi Cinder Devs,
I would like to ask a question concerning Cinder CLI commands in DevStack
13.0.0.0b2.dev167.
I stacked a clean
+1 .. his reviews have always been helpful to me
On Thu, May 24, 2018 at 7:57 AM, Shivanand Tendulker
wrote:
> +1 from me.
>
>
>
> On Sun, May 20, 2018 at 8:15 PM, Julia Kreger > wrote:
>
>> Greetings everyone!
>>
>> I would like to propose
12 matches
Mail list logo