+1, almost a 'must-have' feature in nowdays.
At 2019-08-09 00:40:57, "Sven Vogel" wrote:
>+1 from me too. I hope so with refactor or without :)
>
>Von meinem iPhone gesendet
>
>
>__
>
>Sven Vogel
>Teamlead Platform
>
>EWERK RZ GmbH
>Brühl 24, D-04109 Leipzig
>P +49 341 42649 - 11
>F +49 341
+1 from me too. I hope so with refactor or without :)
Von meinem iPhone gesendet
__
Sven Vogel
Teamlead Platform
EWERK RZ GmbH
Brühl 24, D-04109 Leipzig
P +49 341 42649 - 11
F +49 341 42649 - 18
s.vo...@ewerk.com
www.ewerk.com
Geschäftsführer:
Dr. Erik Wende, Hendrik Schubert, Frank Richter
R
+1 to the feature.
@Fariborz, perhaps open a github issue as a new feature request?
From: Simon Weller
Sent: Thursday, August 8, 2019 6:30 PM
To: dev@cloudstack.apache.org
Subject: Re: Dynamic scaling support for KVM
Hi Fariboz,
We'd definitely like to add that
Hi Fariboz,
We'd definitely like to add that functionality, but it's going to be a fairly
big lift, as the libxml configs are currently built as a single block. A large
refactor of how we interact with libvirt will be required.
This is definitely something we have on our list and hopefully we ca
Hello Devs,
Since long time ago libvirt supports live horizental scaling of VMs. Do you
intend for ACS 4.13 to support dynamic scaling of KVM VMs?
TIA
You can also configure event bus (Kafka perhaps) and use that to get events.
Alternately you can also use below API -
(local) 🐵 > list events type="MAINT.PREPARE" listall=true
{
"count": 6,
"event": [
{
"account": "system",
"created": "2019-08-08T17:06:23+0530",
"descrip
All,
We're aiming to cut to 4.13.0.0 RC1 by EOD Monday 12th August, assuming all the
blockers will be fixed by then.
I'll kick smoketests this weekend before RC1 is cut.
If you've found any critical/blocker issue against the latest master, kindly
raise them. Thanks.
Regards,
Rohit Yadav
So then I guess the correct way to check if host is in maintenance is through
querying DB.
Sent from my iPhone
> On 08-Aug-2019, at 12:03 PM, Anurag Awasthi
> wrote:
>
> Hi Rakesh,
>
> Andrija is correct. Internally, all the API call does is move the host to a
> different state. Periodicall
Hi Rakesh,
Andrija is correct. Internally, all the API call does is move the host to a
different state. Periodically (ping.interval duration apart) MS would attempt
migration of VMs. Once the host has zero running VMs and no VM in failure/error
state it would be marked in maintenance mode.
Re
Rakesh,
I'm not quite sure if this is a bug/misbehaviour, but it is indeed a
confusing one.
When you ask a host to go to maintenance mode, , you are using
prepareHostForMaintenance as you said, and this will trigger the host to go
into the "PrepareForMaintenance" state... so the job does indeed c
Hello Anurag
Thanks for the reply. The host does transit to maintenance mode eventually but
the asynchronous job status never changes. Right now I'm periodically fetching
the resource_state from DB to see if it changes to "Maintenance". Is there any
better way to do it like using triggers or
Hi Rakesh,
You seem to be doing the right thing. I think what you have encoutered is a bug
in prepareForMaintenance API. The host tends to be stuck in that state in some
scenarios. Perhaps, when a VM enters an error state. I would advise canceling
maintenance mode and examining what states the
Hello
I want to know what is the best way to query the async job result using
queryAsyncJobResult api. According to the documentation in
http://docs.cloudstack.apache.org/projects/archived-cloudstack-getting-started/en/latest/dev.html
,
the "jobstatus" of 1 means the command completed but im faci
13 matches
Mail list logo
