I tested this patch in our environment and it worked. Scalr ignored the
openstack error state.
Thanks for the fix, this was a big help.
On Wednesday, February 8, 2017 at 1:14:14 PM UTC-6, Enrico Kern wrote:
>
> 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 scalr-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
