>
> 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.
The OpenStack SDK throws exceptions when requests that delete/modify/create
resources fail, no die exceptions though. There wasn't any specific feature
that made me choose Try::Tiny, it was more my unfamiliarity with exception
handling in Perl which seemed to have a number of gotchas prior to 5.14 so
I figured it'd be better to let someone else's code worry about that.
http://blog.twoshortplanks.com/2011/06/06/unexceptional-exceptions-in-perl-5-14/
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.
Sounds good. I agree that avoiding the hosts file would be best, especially
in a case like this where it needs to be continuously modified. Here's our
changed get_computer_private_ip_address, lines 45-55 are the new code:
https://gist.github.com/cmann/9896513
Finally we're still working on putting together more comprehensive
installation documentation for anyone who wants to try it out. We're use
automation for a number of the tasks and I haven't had a chance to run
through it from scratch yet. For anyone feeling adventurous these are the
most basic instructions:
1. Apply the NAT patch
(https://issues.apache.org/jira/browse/VCL-174tested on 2.3 and 2.3.1,
make sure to read the Google doc)
2. Follow the instructions in the readme in the Github repo for the
OpenStack module.
Cameron
On Fri, Mar 28, 2014 at 7:54 AM, Andy Kurth <[email protected]> wrote:
> >
> >
> > 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
>
