Hi All, I have tested my openstack module ( https://issues.apache.org/jira/browse/VCL-590) on the OpenStack Icehouse (The ninth release of OpenStack, April 17, 2014) and I could provisioning a Linux image through it.
The environment details are as follows: 1. Host Blade :- CPU: Intel(R) Xeon(R) CPU E5645 @ 2.40GHz :- Memory: 49G :- Disk: 134G :- OS: RHEL 6.4 x64 with KVM hypervisor 2. OpenStack Icehouse Components :- Compute :- Network (Nova-Network, not OpenStack Neutron) :- Glance 3. Provisioning Linux image :- CentOS 6.3 x64 4. VCL 2.3 In this test, I've just tested the provisioning an image but I would like to post the detail information to jira once I finish other test. In addition, I will try to add a function of selecting OpenStack flavors based on the size of an image. The current openstack module sets flavors for each image because the previous OpenStack releases (Essex as I know) didn't support the size information of images but now it supports. I will also post to jira issue when I add the function to my module. Thank you. Best regards, Young-Hyun On Mon, Mar 31, 2014 at 12:55 PM, Cameron Mann <[email protected]> wrote: > > > > 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 > > >
