Hi Cameron, Thanks for provided details of the modifications you added in to make the module work at your site. I don't see any issues with what you mentioned. Number 3 isn't really a major issue and the VCL core code can be modified to not use the /etc/hosts file for the openstack provisioning module.
Look forward to getting your changes included. By the way the office hours call that is mentioned is not a design / development call, no development decisions are made. It is a general discussion call on all things VCL, also sometimes includes non-VCL related topics. If you interested in joining the call it is at 11am-12pm (EDT) 1-888-426-6840 passcode7369874 Aaron On Wed, Mar 26, 2014 at 12:42 PM, Cameron Mann <[email protected]> wrote: > Hi all, > > At Cybera we've been running VCL on OpenStack in production for a little > over a year now using a modified version of Young Oh's module. We talked > with Aaron, Josh and Andy last week about getting our code contributed back > into VCL and there are a few points that would need to be addressed before > that can happen. For reference our code is available here: > > https://github.com/cybera/openstack-vcl-module > > 1. Currently our module depends on our NAT patch ( > https://issues.apache.org/jira/browse/VCL-174) to make reservations > publicly accessible, it doesn't assign floating IP addresses to instances. > This should be configurable, unfortunately we don't currently have the > extra IP addresses available to do any testing. Is there anyone who is in a > position to make/test these changes? I don't believe it should be too > challenging. > > 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? > > 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 apologize for the wall of text, but I think that covers everything. We'll > also be on the office hours call tomorrow to talk about the module. > > Cameron -- Aaron Peeler Program Manager Virtual Computing Lab NC State University All electronic mail messages in connection with State business which are sent to or received by this account are subject to the NC Public Records Law and may be disclosed to third parties.
