>
>
> 2. We use the Try::Tiny module to handle exceptions since the version of
> Perl VCL 2.3 uses doesn't support the saner try/catch mechanisms available
> in newer releases, however this would add an additional dependency to VCL.
> Depending on the version of Perl VCL 2.4 is planning to use what are
> people's thoughts on using Try::Tiny versus switching to Perl's internal
> mechanisms?
>
I haven't looked at Try::Tiny or any newer exception handling features of
Perl, but I'd prefer to keep the number of external modules to a minimum if
possible. If there are new features in Perl which would be beneficial, I'd
rather make the newer version of Perl a requirement and use the built in
features. Otherwise, we're locked into using an external module, usually
from CPAN, which has no quality assurance. I regret adding some of the
current modules such as InsideOut, rather then writing the code which could
accomplish the same objective.
Did you need to catch exceptions because one of the OpenStack modules
you're using may throw a die exception? When this happens, the entire vcld
process for the reservation exits abruptly which causes problems such as
the request state remaining in pending indefinitely. This happens even if
you wrap the call in an eval block. I have worked around this problem
before by locally overriding the die handler. Take a look at
vSphere_SDK.pm and find lines such as:
# Override the die handler
local $SIG{__DIE__} = sub{};
The vSphere SDK is one example which may call die (via Carp). If this
happens with die overridden, the eval block returns normally. If an
exception occurred, $EVAL_ERROR should be set.
>
> 3. I've saved the best for last, but first some background. The biggest
> change we've made is that we no longer rely on the /etc/hosts file at all
> (though we haven't removed the code that keeps it up to date). We had a
> number of issues with duplicate entries ending up in the hosts file and
> weren't able to pin down the exact cause. This led us to adding a table to
> the database to track VCL computer to OpenStack instance mappings. The next
> issue we ran into was the private IP address not being populated in the
> hosts file. This happened very rarely and we're still unsure of the cause
> especially since there's an explicit check that the address is populated
> with a value before we write the hosts file. I'd assume that the Nova API
> occasionally returns a response where the addresses component is structured
> differently than we expect, though I was never able to directly observe
> this behavior. Since OpenStack automatically creates DNS entries for new
> instances we decided the best course of action was to bypass the hosts file
> entirely. In the end we modified get_computer_private_ip_address in
> DataStructure.pm to do a DNS lookup rather than looking in the hosts file.
>
> The question for the community is are changes to core VCL code acceptable?
> Or should we find a solution that keeps everything contained to the
> provisioning module? If changes to core code are acceptable we'd also have
> to decide on a method of detecting when to do a DNS lookup. Should it
> depend on the provisioning module in use? A configuration option?
I see no problems. Any barriers or difficulty you encounter with the core
code should be addressed by improving the core code.
Reworking the dependency on /etc/hosts is something I'd like to improve
regardless. People often encounter problems with this if they forget to
add entries to /etc/hosts for all their computers, including the management
node(s). I'd like to not read /etc/hosts on the management node at all and
have the value in the computer table be authoritative. This should
facilitate cases where the provisioning module needs to do something
different regarding private IPs such as if they are dynamically allocated.
The provisioning module would retrieve the IP when the image gets loaded
by querying DNS or some other method and then update the database. The OS
module would then use this value to configure the computer.
One comment regarding adding tables... great! Add all the tables you think
are beneficial. I have seen some try to work around the current database
schema rather than adding to it. There's no reason for this. If there are
configuration options which apply only to OpenStack, add something like an
openstackconfig table. If the vmprofile table doesn't align, add something
like an openstackprofile table. If there are general options such as how
to handle DNS or private IP resolution, we could add a more general table
or possibly extend the managementnode or computer table.
Thanks,
Andy
