You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@brooklyn.apache.org by Aled Sage <al...@gmail.com> on 2015/02/01 00:54:33 UTC

Re: Softlayer max name length

Hi Duncan,

That's annoying, and surprising! Is there no hostname set at all, or a 
non-unique hostname?

Do you know if the previous max length of 30 is the cut-off for hostname 
being set on the VM? Maybe we could choose a number significantly bigger 
than 30 but still not too big?

For Ambari, does it need a hostname that can be resolved from other VMs 
or just a non-empty hostname?
(in some clouds for some apps, we ended up running a DNS server so that 
hostnames would all resolve).

Aled


On 30/01/2015 16:51, Duncan Grant wrote:
> Without a maximum name length (see
> https://github.com/apache/incubator-brooklyn/pull/481) softlayer VMs are
> created without a hostname.
> Under these circumstances Ambari refuses to install.
>
> Should I implement something specific to the ambari entities so that they
> can work round this or do we need to find a more general fix?
>
> I'd really like to keep the long names as then I can tell this difference
> between my vms and those provisioned by Duncan.
>
> Regards
>
> Duncan
>


Re: Softlayer max name length

Posted by Duncan Grant <du...@cloudsoftcorp.com>.
PR here:
https://github.com/apache/incubator-brooklyn/pull/500

On 2 February 2015 at 14:19, Duncan Grant <du...@cloudsoftcorp.com>
wrote:

> After extensive testing it would appear that anything up to 55 chars seems
> to be fine.  Between 56-58 characters you could jclouds exceptions while
> provisioning.  From 59 chars up to around 80 ish you get a provisioned
> machine with no hostname and if you set the chars at higher than 100(ish)
> you get an error saying that the maximum length had been exceeded.
>
> I'll create a PR with a 55 character limit but I'd appreciate it if
> someone else could test this before it is merged.
>
> Sam,
>
> Thanks for the feedback - I don't keep my logs for long but I'll have a
> look the next time it happens.
>
> thanks
>
> Duncan
>
> On 2 February 2015 at 10:50, Sam Corbett <sa...@cloudsoftcorp.com>
> wrote:
>
>> For issue with the Bind entity you might like to look for strings
>> matching these messages in your debug log:
>>
>> "Skipped update of {} when service state is {} and running is {}"
>> "Member {} of {} does not have an SSH location so will not be configured"
>>
>> It also logs "updating with entities: <list>" which will indicate whether
>> your missing entities were ever under consideration.
>>
>> Sam
>>
>>
>> On 02/02/2015 09:25, Duncan Grant wrote:
>>
>>> I agree, it's really annoying. The hostname resolves to "(none)" , which
>>> I
>>> assume means there isn't one set.
>>>
>>> I'll do some testing on the maximum size.
>>>
>>>
>>> Ambari does a test when it starts that the hostname resolves to the
>>> machines ip and refuses to start if it doesn't.  For softlayer I
>>> currently
>>> use the binddns entity to make the hostnames resolve, although I'm
>>> finding
>>> this a bit hit and miss - sometimes all my entities get configured
>>> properly
>>> and sometimes one or two won't have a dns entry - I assume this is a
>>> timing
>>> issue but I haven't looked into it at the moment.
>>>
>>>
>>> On 31 Jan 2015 23:55, "Aled Sage" <al...@gmail.com> wrote:
>>>
>>>  Hi Duncan,
>>>>
>>>> That's annoying, and surprising! Is there no hostname set at all, or a
>>>> non-unique hostname?
>>>>
>>>> Do you know if the previous max length of 30 is the cut-off for hostname
>>>> being set on the VM? Maybe we could choose a number significantly bigger
>>>> than 30 but still not too big?
>>>>
>>>> For Ambari, does it need a hostname that can be resolved from other VMs
>>>> or
>>>> just a non-empty hostname?
>>>> (in some clouds for some apps, we ended up running a DNS server so that
>>>> hostnames would all resolve).
>>>>
>>>> Aled
>>>>
>>>>
>>>> On 30/01/2015 16:51, Duncan Grant wrote:
>>>>
>>>>  Without a maximum name length (see
>>>>> https://github.com/apache/incubator-brooklyn/pull/481) softlayer VMs
>>>>> are
>>>>> created without a hostname.
>>>>> Under these circumstances Ambari refuses to install.
>>>>>
>>>>> Should I implement something specific to the ambari entities so that
>>>>> they
>>>>> can work round this or do we need to find a more general fix?
>>>>>
>>>>> I'd really like to keep the long names as then I can tell this
>>>>> difference
>>>>> between my vms and those provisioned by Duncan.
>>>>>
>>>>> Regards
>>>>>
>>>>> Duncan
>>>>>
>>>>>
>>>>>
>>
>

Re: Softlayer max name length

Posted by Duncan Grant <du...@cloudsoftcorp.com>.
After extensive testing it would appear that anything up to 55 chars seems
to be fine.  Between 56-58 characters you could jclouds exceptions while
provisioning.  From 59 chars up to around 80 ish you get a provisioned
machine with no hostname and if you set the chars at higher than 100(ish)
you get an error saying that the maximum length had been exceeded.

I'll create a PR with a 55 character limit but I'd appreciate it if someone
else could test this before it is merged.

Sam,

Thanks for the feedback - I don't keep my logs for long but I'll have a
look the next time it happens.

thanks

Duncan

On 2 February 2015 at 10:50, Sam Corbett <sa...@cloudsoftcorp.com>
wrote:

> For issue with the Bind entity you might like to look for strings matching
> these messages in your debug log:
>
> "Skipped update of {} when service state is {} and running is {}"
> "Member {} of {} does not have an SSH location so will not be configured"
>
> It also logs "updating with entities: <list>" which will indicate whether
> your missing entities were ever under consideration.
>
> Sam
>
>
> On 02/02/2015 09:25, Duncan Grant wrote:
>
>> I agree, it's really annoying. The hostname resolves to "(none)" , which I
>> assume means there isn't one set.
>>
>> I'll do some testing on the maximum size.
>>
>>
>> Ambari does a test when it starts that the hostname resolves to the
>> machines ip and refuses to start if it doesn't.  For softlayer I currently
>> use the binddns entity to make the hostnames resolve, although I'm finding
>> this a bit hit and miss - sometimes all my entities get configured
>> properly
>> and sometimes one or two won't have a dns entry - I assume this is a
>> timing
>> issue but I haven't looked into it at the moment.
>>
>>
>> On 31 Jan 2015 23:55, "Aled Sage" <al...@gmail.com> wrote:
>>
>>  Hi Duncan,
>>>
>>> That's annoying, and surprising! Is there no hostname set at all, or a
>>> non-unique hostname?
>>>
>>> Do you know if the previous max length of 30 is the cut-off for hostname
>>> being set on the VM? Maybe we could choose a number significantly bigger
>>> than 30 but still not too big?
>>>
>>> For Ambari, does it need a hostname that can be resolved from other VMs
>>> or
>>> just a non-empty hostname?
>>> (in some clouds for some apps, we ended up running a DNS server so that
>>> hostnames would all resolve).
>>>
>>> Aled
>>>
>>>
>>> On 30/01/2015 16:51, Duncan Grant wrote:
>>>
>>>  Without a maximum name length (see
>>>> https://github.com/apache/incubator-brooklyn/pull/481) softlayer VMs
>>>> are
>>>> created without a hostname.
>>>> Under these circumstances Ambari refuses to install.
>>>>
>>>> Should I implement something specific to the ambari entities so that
>>>> they
>>>> can work round this or do we need to find a more general fix?
>>>>
>>>> I'd really like to keep the long names as then I can tell this
>>>> difference
>>>> between my vms and those provisioned by Duncan.
>>>>
>>>> Regards
>>>>
>>>> Duncan
>>>>
>>>>
>>>>
>

Re: Softlayer max name length

Posted by Sam Corbett <sa...@cloudsoftcorp.com>.
For issue with the Bind entity you might like to look for strings 
matching these messages in your debug log:

"Skipped update of {} when service state is {} and running is {}"
"Member {} of {} does not have an SSH location so will not be configured"

It also logs "updating with entities: <list>" which will indicate 
whether your missing entities were ever under consideration.

Sam

On 02/02/2015 09:25, Duncan Grant wrote:
> I agree, it's really annoying. The hostname resolves to "(none)" , which I
> assume means there isn't one set.
>
> I'll do some testing on the maximum size.
>
>
> Ambari does a test when it starts that the hostname resolves to the
> machines ip and refuses to start if it doesn't.  For softlayer I currently
> use the binddns entity to make the hostnames resolve, although I'm finding
> this a bit hit and miss - sometimes all my entities get configured properly
> and sometimes one or two won't have a dns entry - I assume this is a timing
> issue but I haven't looked into it at the moment.
>
>
> On 31 Jan 2015 23:55, "Aled Sage" <al...@gmail.com> wrote:
>
>> Hi Duncan,
>>
>> That's annoying, and surprising! Is there no hostname set at all, or a
>> non-unique hostname?
>>
>> Do you know if the previous max length of 30 is the cut-off for hostname
>> being set on the VM? Maybe we could choose a number significantly bigger
>> than 30 but still not too big?
>>
>> For Ambari, does it need a hostname that can be resolved from other VMs or
>> just a non-empty hostname?
>> (in some clouds for some apps, we ended up running a DNS server so that
>> hostnames would all resolve).
>>
>> Aled
>>
>>
>> On 30/01/2015 16:51, Duncan Grant wrote:
>>
>>> Without a maximum name length (see
>>> https://github.com/apache/incubator-brooklyn/pull/481) softlayer VMs are
>>> created without a hostname.
>>> Under these circumstances Ambari refuses to install.
>>>
>>> Should I implement something specific to the ambari entities so that they
>>> can work round this or do we need to find a more general fix?
>>>
>>> I'd really like to keep the long names as then I can tell this difference
>>> between my vms and those provisioned by Duncan.
>>>
>>> Regards
>>>
>>> Duncan
>>>
>>>


Re: Softlayer max name length

Posted by Duncan Grant <du...@cloudsoftcorp.com>.
I agree, it's really annoying. The hostname resolves to "(none)" , which I
assume means there isn't one set.

I'll do some testing on the maximum size.


Ambari does a test when it starts that the hostname resolves to the
machines ip and refuses to start if it doesn't.  For softlayer I currently
use the binddns entity to make the hostnames resolve, although I'm finding
this a bit hit and miss - sometimes all my entities get configured properly
and sometimes one or two won't have a dns entry - I assume this is a timing
issue but I haven't looked into it at the moment.


On 31 Jan 2015 23:55, "Aled Sage" <al...@gmail.com> wrote:

> Hi Duncan,
>
> That's annoying, and surprising! Is there no hostname set at all, or a
> non-unique hostname?
>
> Do you know if the previous max length of 30 is the cut-off for hostname
> being set on the VM? Maybe we could choose a number significantly bigger
> than 30 but still not too big?
>
> For Ambari, does it need a hostname that can be resolved from other VMs or
> just a non-empty hostname?
> (in some clouds for some apps, we ended up running a DNS server so that
> hostnames would all resolve).
>
> Aled
>
>
> On 30/01/2015 16:51, Duncan Grant wrote:
>
>> Without a maximum name length (see
>> https://github.com/apache/incubator-brooklyn/pull/481) softlayer VMs are
>> created without a hostname.
>> Under these circumstances Ambari refuses to install.
>>
>> Should I implement something specific to the ambari entities so that they
>> can work round this or do we need to find a more general fix?
>>
>> I'd really like to keep the long names as then I can tell this difference
>> between my vms and those provisioned by Duncan.
>>
>> Regards
>>
>> Duncan
>>
>>
>