ok nvm. i patched CloudPoller.php myself todo that. If anyone is
interessted. just add a continue; from line 347 on in
/opt/scalr-server/embedded/scalr/app/src/Scalr/System/Zmq/Cron/Task/CloudPoller.php
example:
// If openstack server is in ERROR state we need
more details
if ($openstackErrorState) {
try {
$info =
$p->GetServerExtendedInformation($DBServer);
$status = empty($info['Status']) ? false :
$info['Status'];
} catch (Exception $e) {}
// added by Enrico. ignore error (i hope)
$this->getLogger()->error("openstack error and
i want to terminate it... oh wait i better let it alone");
continue;
}
On Tuesday, February 7, 2017 at 8:16:46 PM UTC+1, Enrico Kern wrote:
>
> Hello all,
>
> was there something implemented already? we have the same issues with the
> latest open source scalr. Sometimes on hypervisor reboot openstack reports
> error state or cant boot up vms for whatever reasons and then scalr packs
> the hammer and terminates the instance. Would love to only allow manual
> termination in whatever state.
>
> On Monday, December 5, 2016 at 11:12:24 PM UTC+1, Marc O'Brien wrote:
>>
>> Hi Brandon,
>>
>> Thank you for the details. This helps us to better understand our
>> customer's needs and prioritize future development efforts.
>>
>> By the way, welcome to the Scalr Open Source community! We're excited to
>> have you join us. Please feel free to post any issues or questions you
>> have moving forward and we will do our best to lend a hand.
>>
>> Cheers,
>> Wm. Marc O'Brien
>> Scalr Technical Support
>>
>> On Monday, December 5, 2016 at 12:34:25 PM UTC-7, Brandon Newport wrote:
>>>
>>> We had an incident a few weeks ago with a Farm that was deployed. It
>>> lost its DHCP address for some reason and while we were troubleshooting, we
>>> attempted a live migration from one host to another in Openstack, when this
>>> happened it forced the instance into Error state, which terminated the
>>> instance.
>>>
>>> Since then we have been testing Scalr actions by forcing instances into
>>> error state in OpenStack.
>>>
>>> However when we were testing today we forced a Hypervisor to shut down.
>>> Which did nothing to the Instance, until the Hypervisor was powered on,
>>> changed the Instance to shut off state. This forced the Replace.
>>>
>>> I hope this helped answer your question.
>>>
>>> Brandon
>>>
>>> On Monday, December 5, 2016 at 1:21:11 PM UTC-6, Marc O'Brien wrote:
>>>>
>>>> Hi Brandon,
>>>>
>>>> To clarify, the ignore on missing setting will not impact servers in
>>>> Error state so this does not directly apply to this case as you stated
>>>> these instances are in Error state. Could you provide some additional
>>>> details on why you would not want to terminate servers in Error state? Do
>>>> you have a specific use case for this?
>>>>
>>>> Many thanks,
>>>> Wm. Marc O'Brien
>>>> Scalr Technical Support
>>>>
>>>> On Monday, December 5, 2016 at 10:55:38 AM UTC-7, Marc O'Brien wrote:
>>>>>
>>>>> Hi Brandon,
>>>>>
>>>>> This is expected behavior as Scalr implements a Replace vs a Repair
>>>>> methodology to resource management. You may wish to merge
>>>>> "scalr.openstack.action_on_missing_server = ignore" in to your
>>>>> scalr-server.rb
>>>>> <https://scalr-wiki.atlassian.net/wiki/display/docs/Advanced+Configuration>
>>>>>
>>>>> to prevent Scalr from terminating instances that are marked as "Missing"
>>>>> but there is not currently a method to completely prevent termination of
>>>>> resources that enter an "Error" state. This is intentional, but we do
>>>>> understand your perspective/situation and have considered this
>>>>> previously.
>>>>> We are exploring possible changes to this behavior in future versions of
>>>>> Enterprise Scalr, but this is currently a fundamental behavior of our
>>>>> Desired State Engine and is not something that can be disabled.
>>>>>
>>>>> Many thanks,
>>>>> Wm. Marc O'Brien
>>>>> Scalr Technical Support
>>>>>
>>>>>
>>>>> On Monday, December 5, 2016 at 8:19:38 AM UTC-7, Brandon Newport wrote:
>>>>>>
>>>>>> We are using this version of Scalr, Version 5.11.22.
>>>>>>
>>>>>> On Monday, December 5, 2016 at 9:18:37 AM UTC-6, Brandon Newport
>>>>>> wrote:
>>>>>>>
>>>>>>> Is there a way to disable the automatic termination of an Instance
>>>>>>> with Scaling function in the Farm Role settings.
>>>>>>>
>>>>>>> We currently have a Community version of Scalr deployed, and
>>>>>>> connected to OpenStack. By default when an instance goes into ERROR
>>>>>>> state
>>>>>>> in openstack. Scalr will terminate the existing instance and deploy a
>>>>>>> new
>>>>>>> one. Is there a way to disable this or ignore the instance in error
>>>>>>> state?
>>>>>>> We have tested the manual Scaling, but it will still terminate the
>>>>>>> instance and wait for you to redeploy the new instance.
>>>>>>>
>>>>>>> We are gradually working our way to using scaling the way it is
>>>>>>> designed but we are just not there yet.
>>>>>>>
>>>>>>> Any help here would be appreciated.
>>>>>>>
>>>>>>> Brandon
>>>>>>>
>>>>>>
--
You received this message because you are subscribed to the Google Groups
"scalr-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
