Re: OpenStack Module

[YOUNG OH <oh...@gmail.com>]

Yes, I agree with that. Especially,  the detail information of images would
be very useful for qcow2 images due to the lack of metadata information.
And it would be helpful for migration. Thank you.

Best regards,
Young


On Wed, Jul 30, 2014 at 6:23 PM, Curtis <se...@gmail.com> wrote:

> Hi all,
>
> We found out today that windows images in openstack should have the
> glance os_type set to windows:
>
> http://docs.openstack.org/image-guide/content/windows-image.html
>
> So might not be a bad idea for the vcl openstack plugin to add that
> metadata if the image being created is a windows os.
>
> Thanks,
> Curtis.
>
> On Wed, Jul 23, 2014 at 8:35 PM, YOUNG OH <oh...@gmail.com> wrote:
> > Then option 2 sounds reasonable.  Just warn and log if openstack gets
> > failed to delete the instance but continue to load a new instance. It
> seems
> > okay to me.
> >
> > Best regards,
> > Young
> >
> >
> > On Wed, Jul 23, 2014 at 12:38 PM, Cameron Mann <ca...@cybera.ca>
> > wrote:
> >
> >> The new instance that gets created is completely independent from the
> old
> >> one; both could remain powered on with no problems. OpenStack handles
> the
> >> IP addresses and if one is already in use it won't be assigned again.
> Just
> >> in case there's any confusion, the issue before was that the module was
> >> using looking up the instance using an identifier which wouldn't be
> unique
> >> between the new and old instances. Now that it's using a unique
> identifier
> >> it could never delete an instance and there'd never be a conflict
> barring a
> >> problem in OpenStack.
> >>
> >> Cameron
> >>
> >>
> >> On Wed, Jul 23, 2014 at 9:31 AM, Andy Kurth <an...@ncsu.edu>
> wrote:
> >>
> >> > Option 2 sounds reasonable as long as there is no possibility the VM
> >> which
> >> > could not be deleted can not cause conflicts with other VMs.  The main
> >> > concern would be if the VM remained powered on with an IP address that
> >> > could be reused.  Would this be possible?  If you encounter a problem
> >> > deleting a VM, can you reliably verify that it is powered off?
> >> >
> >> > I think the priorities should be:
> >> > 1) avoid conflicts
> >> > 2) reduce reservation failures
> >> > 3) optimize load time
> >> >
> >> > Load time is important, but the deletion issue should really only
> affect
> >> > the user experience when the image requested is not preloaded.  If VMs
> >> are
> >> > being reloaded for every reservation then there is another problem.
> >> >
> >> > -Andy
> >> >
> >> >
> >> >
> >> >
> >> > On Tue, Jul 22, 2014 at 3:37 PM, Cameron Mann <cameron.mann@cybera.ca
> >
> >> > wrote:
> >> >
> >> > > Agreed, this goes back to more general VCL behaviour so it would be
> >> good
> >> > to
> >> > > get others' input.
> >> > >
> >> > > Cameron
> >> > >
> >> > >
> >> > > On Tue, Jul 22, 2014 at 1:22 PM, YOUNG OH <oh...@gmail.com>
> >> > wrote:
> >> > >
> >> > > > That's great observation. I think option 1 and 2 can provide fast
> >> > loading
> >> > > > time due to no load failure. But, to avoid quota issues, an admin
> >> > should
> >> > > > periodically check the all the instances whether there are any
> >> > duplicate
> >> > > > instance names and defunct instances. The option 3 is safe but
> slow
> >> to
> >> > > load
> >> > > > if any deleting instance fails. I also agree that option 2 would
> be a
> >> > > good
> >> > > > choice because it can provide lower load time for end-users and
> also
> >> we
> >> > > > cannot exactly estimate the deletion time. But I hope to hear
> others'
> >> > > > thoughts.
> >> > > >
> >> > > > Best regards
> >> > > > Young
> >> > > >
> >> > > >
> >> > > > On Tue, Jul 22, 2014 at 2:46 PM, Cameron Mann <
> >> cameron.mann@cybera.ca>
> >> > > > wrote:
> >> > > >
> >> > > > > Looks good. Though I do wonder if it's necessary to fail the
> entire
> >> > > load
> >> > > > > process just because the old instance doesn't get deleted. I
> think
> >> > > > there's
> >> > > > > three possibilities:
> >> > > > >
> >> > > > > 1. Don't check for successful deletion; there won't be any
> >> conflicts
> >> > > > > because we're using openstackComputerMap. This would give the
> >> fastest
> >> > > > load
> >> > > > > times, but the only way to find out that something went wrong
> would
> >> > be
> >> > > to
> >> > > > > look at the list of instances and see if there are any duplicate
> >> > names.
> >> > > > > Could cause issues with quotas if running near capacity since
> there
> >> > > could
> >> > > > > be extra instances lying around.
> >> > > > >
> >> > > > > 2. Check for successful deletion, but only log the error, don't
> >> fail
> >> > > the
> >> > > > > load. Slower load times, but the load won't fail and the error
> will
> >> > be
> >> > > > > logged. Could cause issues with quotas if running near capacity
> >> since
> >> > > > there
> >> > > > > could be extra instances lying around.
> >> > > > >
> >> > > > > 3. What the module does now, check for successful deletion and
> fail
> >> > if
> >> > > > not.
> >> > > > > Least end user friendly since they might encounter failures, but
> >> the
> >> > > > safest
> >> > > > > option. Won't cause quota issues on it's own, though an admin
> could
> >> > > still
> >> > > > > change the computer back to available without deleting the
> defunct
> >> > > > > instance.
> >> > > > >
> >> > > > > Instance deletion time is also not very consistent in my
> >> experience;
> >> > > I've
> >> > > > > seen anything from seconds to over a minute and I imagine it
> could
> >> go
> >> > > > > higher on OpenStack systems that see heavier usage. If we stick
> >> with
> >> > > > option
> >> > > > > 3 I'd recommend bumping the timeout by another minute or two
> just
> >> to
> >> > be
> >> > > > > safe. I think it's less necessary for option 2 since it doesn't
> >> fail
> >> > on
> >> > > > > timeout.
> >> > > > >
> >> > > > > I took a look at some of the other provisioning modules to see
> what
> >> > > they
> >> > > > > do:
> >> > > > >
> >> > > > > - VMware logs a warning if it fails to delete the old VM, but
> only
> >> > > fails
> >> > > > if
> >> > > > > the VM is still responding to SSH
> >> > > > > - Libvirt fails if deletion fails
> >> > > > > - VirtualBox doesn't check for successful deletion, though it
> will
> >> > fail
> >> > > > if
> >> > > > > it can't find the old VM to delete
> >> > > > >
> >> > > > > I think options 2 or 3 would be most consistent with existing
> >> > > behaviour.
> >> > > > > I'd lean towards option 2 since end users won't see any extra
> >> > failures
> >> > > > and
> >> > > > > we can keep a lower timeout which will mean lower load times
> even
> >> if
> >> > a
> >> > > > > deletion takes a long time.
> >> > > > >
> >> > > > > What are you thoughts?
> >> > > > >
> >> > > > > Cameron
> >> > > > >
> >> > > > >
> >> > > > > On Tue, Jul 22, 2014 at 9:05 AM, YOUNG OH <
> oh.younghyun2@gmail.com
> >> >
> >> > > > wrote:
> >> > > > >
> >> > > > > > Cameron,
> >> > > > > >
> >> > > > > > Yes, you are definitely right. I was noticed that using
> hostname
> >> to
> >> > > > find
> >> > > > > > the openstack instance id is not working properly and also can
> >> > cause
> >> > > > the
> >> > > > > > problem you described. I've back to use the
> openstackComputerMap
> >> > > table
> >> > > > to
> >> > > > > > get_os_instance_id when the instance is pingable and also add
> a
> >> > loop
> >> > > in
> >> > > > > > _terminate_os_instance to check whether the instance is
> >> completely
> >> > > > > deleted
> >> > > > > > or not. Please take a look at it again and let me know if you
> >> have
> >> > > any
> >> > > > > > concerns. Thank you.
> >> > > > > >
> >> > > > > > Best regards,
> >> > > > > > Young
> >> > > > > >
> >> > > > > >
> >> > > > > > On Mon, Jul 21, 2014 at 4:18 PM, Cameron Mann <
> >> > > cameron.mann@cybera.ca>
> >> > > > > > wrote:
> >> > > > > >
> >> > > > > > > Sounds like good progress to me. One comment though, it
> looks
> >> > like
> >> > > > > > > _terminate_os_instance does the DELETE request, checks the
> >> > response
> >> > > > for
> >> > > > > > > success and then sleeps for 30 seconds while the instance
> >> > deletes.
> >> > > > > > However,
> >> > > > > > > I don't believe a successful response to the DELETE request
> >> > > > guarantees
> >> > > > > > the
> >> > > > > > > instance will actually be deleted. I've run into situations
> >> where
> >> > > an
> >> > > > > > > instance gets stuck in the error or deleting states but the
> >> > command
> >> > > > > line
> >> > > > > > > client reports no errors when trying to delete it. This
> could
> >> > > result
> >> > > > > in a
> >> > > > > > > situation where multiple instances with the same name exist
> >> which
> >> > > > could
> >> > > > > > > cause _get_os_instance_id to return the wrong ID since it
> >> filters
> >> > > the
> >> > > > > > > instances based on name and selects the first in the list.
> >> > > > > > >
> >> > > > > > > I think either returning to using openstackComputerMap or
> >> looping
> >> > > > with
> >> > > > > a
> >> > > > > > > timeout until the instance is actually deleted would be
> better
> >> > > > choices.
> >> > > > > > The
> >> > > > > > > former would allow the new instance to be created even if
> the
> >> > > > deletion
> >> > > > > of
> >> > > > > > > the old one fails. The latter would put the computer in VCL
> >> into
> >> > an
> >> > > > > error
> >> > > > > > > state which would make it more obvious something has gone
> >> wrong,
> >> > > > though
> >> > > > > > at
> >> > > > > > > the cost of potentially failing a user's reservation. As an
> >> added
> >> > > > > > > precaution It might also be worth having _get_os_instance_id
> >> fail
> >> > > if
> >> > > > > > > there's more than one instance in the response.
> >> > > > > > >
> >> > > > > > > Cameron
> >> > > > > > >
> >> > > > > > >
> >> > > > > > > On Fri, Jul 18, 2014 at 9:25 AM, YOUNG OH <
> >> > oh.younghyun2@gmail.com
> >> > > >
> >> > > > > > wrote:
> >> > > > > > >
> >> > > > > > > > Cameron,
> >> > > > > > > >
> >> > > > > > > > I hope you had a great time and welcome back to work :-).
> >> And,
> >> > > yes,
> >> > > > > the
> >> > > > > > > > OpenStack module with directly using OpenStack APIs can
> solve
> >> > the
> >> > > > > > > concerns
> >> > > > > > > > we've discussed and it's more flexible to apply new
> version
> >> of
> >> > > > > > OpenStack
> >> > > > > > > > APIs, if necessary. In the updated openstack module, I've
> >> > changed
> >> > > > the
> >> > > > > > two
> >> > > > > > > > main things. First, I've used the hostname in Computer
> table
> >> > > > (unique
> >> > > > > in
> >> > > > > > > the
> >> > > > > > > > same VCL database) to create an instance and get the
> instance
> >> > id
> >> > > to
> >> > > > > > > > terminate rather than using the openstackComputerMap
> table.
> >> > This
> >> > > > can
> >> > > > > > > avoid
> >> > > > > > > > using an additional table and database transactions.
> Second,
> >> > I've
> >> > > > > > changed
> >> > > > > > > > the openstackImageMap to openstackimagerevision table that
> >> maps
> >> > > the
> >> > > > > > > > imagerevision id with the openstack image id. This table
> >> > consists
> >> > > > of
> >> > > > > > > three
> >> > > > > > > > fields (imagerevisionid, imagedetails, flavordetails). The
> >> > > > > imagedetails
> >> > > > > > > and
> >> > > > > > > > flavordetails contains the details image and flavor
> >> information
> >> > > > with
> >> > > > > > json
> >> > > > > > > > format. Thus, when VCL creates an instance, it gets each
> >> detail
> >> > > > > > > information
> >> > > > > > > > and parse them to find the corresponding openstack image
> id
> >> and
> >> > > > > flavor
> >> > > > > > > id.
> >> > > > > > > > In addition, I've implemented the get_image_size()
> subroutine
> >> > > > because
> >> > > > > > the
> >> > > > > > > > image size information was not supported in OpenStack
> ESSEX
> >> but
> >> > > it
> >> > > > > > > supports
> >> > > > > > > > now. This is a short summary about the changes. So, if you
> >> have
> >> > > any
> >> > > > > > > concern
> >> > > > > > > > or questions about the updates, please let me know. Thank
> >> you.
> >> > > > > > > >
> >> > > > > > > > Best regards,
> >> > > > > > > > Young-Hyun
> >> > > > > > > >
> >> > > > > > > >
> >> > > > > > > > On Thu, Jul 17, 2014 at 11:53 AM, Cameron Mann <
> >> > > > > cameron.mann@cybera.ca
> >> > > > > > >
> >> > > > > > > > wrote:
> >> > > > > > > >
> >> > > > > > > > > Sorry for the silence from my end, I realized I forgot
> to
> >> > > > mention I
> >> > > > > > was
> >> > > > > > > > > going to be on vacation for the last week and a half.
> >> > Anyways,
> >> > > it
> >> > > > > > looks
> >> > > > > > > > > like Young's updates have addressed the main concerns we
> >> were
> >> > > > > having
> >> > > > > > > with
> >> > > > > > > > > regards to the command line client. Given the progress
> he's
> >> > > made
> >> > > > we
> >> > > > > > > think
> >> > > > > > > > > going ahead with his module makes the most sense.
> >> > > > > > > > >
> >> > > > > > > > > Cameron
> >> > > > > > > > >
> >> > > > > > > > >
> >> > > > > > > > > On Wed, Jul 16, 2014 at 9:27 AM, YOUNG OH <
> >> > > > oh.younghyun2@gmail.com
> >> > > > > >
> >> > > > > > > > wrote:
> >> > > > > > > > >
> >> > > > > > > > > > Andy,
> >> > > > > > > > > >
> >> > > > > > > > > > Thank you for your comments. I've tried to apply what
> you
> >> > > > > addressed
> >> > > > > > > and
> >> > > > > > > > > > committed my module again. This module finds all
> >> openstack
> >> > > > > > > information
> >> > > > > > > > > > using OpenStack APIs and database. Thank you.
> >> > > > > > > > > >
> >> > > > > > > > > > Best regards,
> >> > > > > > > > > > Young-Hyun
> >> > > > > > > > > >
> >> > > > > > > > > >
> >> > > > > > > > > >
> >> > > > > > > > > > On Wed, Jul 9, 2014 at 10:24 AM, Andy Kurth <
> >> > > > andy_kurth@ncsu.edu
> >> > > > > >
> >> > > > > > > > wrote:
> >> > > > > > > > > >
> >> > > > > > > > > > > Thanks Young.  Looks good!  If I understand
> correctly,
> >> > you
> >> > > > are
> >> > > > > > > > avoiding
> >> > > > > > > > > > the
> >> > > > > > > > > > > need to use the CLI or cpan module by interacting
> >> > directly
> >> > > > with
> >> > > > > > > > > OpenStack
> >> > > > > > > > > > > via the REST API?
> >> > > > > > > > > > >
> >> > > > > > > > > > > It looks like the only commands you're running on
> the
> >> > > > > management
> >> > > > > > > node
> >> > > > > > > > > are
> >> > > > > > > > > > > "nova" and "qemu-img" in _get_flavor_type.  Would
> it be
> >> > > > > possible
> >> > > > > > to
> >> > > > > > > > > > > accomplish this via the API?  I haven't traced
> through
> >> > how
> >> > > > your
> >> > > > > > > code
> >> > > > > > > > > > works
> >> > > > > > > > > > > too deeply, but was wondering if the following
> could be
> >> > > used:
> >> > > > > > > > > > > http://docs.openstack.org/api/openstack
> >> > > > > > > > > > > -compute/2/content/Flavors-d1e4180.html
> >> > > > > > > > > > >
> >> > > > > > > > > > > It would be wonderful if you can eliminate the need
> for
> >> > > these
> >> > > > > to
> >> > > > > > be
> >> > > > > > > > > > > executed.  This would mean a pure API solution with
> >> > nothing
> >> > > > > > special
> >> > > > > > > > > > needing
> >> > > > > > > > > > > to be installed on the management node.
> >> > > > > > > > > > >
> >> > > > > > > > > > > If you do need to call these commands, instead of
> using
> >> > qx
> >> > > > and
> >> > > > > > > > > backticks
> >> > > > > > > > > > > are used to run commands on the management node.
> >>  Please
> >> > > > change
> >> > > > > > > this
> >> > > > > > > > to
> >> > > > > > > > > > > use:
> >> > > > > > > > > > > my ($exit_status, $output) =
> >> > > $self->mn_os->execute($command);
> >> > > > > > > > > > >
> >> > > > > > > > > > > Also, always, always, always make sure $output and
> >> > anything
> >> > > > > else
> >> > > > > > > you
> >> > > > > > > > > try
> >> > > > > > > > > > to
> >> > > > > > > > > > > parse with a regex are defined first.  This will
> avoid
> >> > some
> >> > > > > nasty
> >> > > > > > > > "Use
> >> > > > > > > > > of
> >> > > > > > > > > > > uninitialized value in pattern match" errors which
> >> could
> >> > > > > > > potentially
> >> > > > > > > > > lead
> >> > > > > > > > > > > to the entire process dying.
> >> > > > > > > > > > >
> >> > > > > > > > > > > The indentation looks great!  :)  There are a few
> >> places
> >> > > > where
> >> > > > > > the
> >> > > > > > > > > curly
> >> > > > > > > > > > > bracket style could be modified.  Just about all of
> the
> >> > > > > existing
> >> > > > > > > code
> >> > > > > > > > > > > places opening brackets on the same line as the
> >> while/for
> >> > > > > > statement
> >> > > > > > > > > such
> >> > > > > > > > > > > as:
> >> > > > > > > > > > > while ($loop > 0) {
> >> > > > > > > > > > > -instead of-
> >> > > > > > > > > > > while ($loop > 0)
> >> > > > > > > > > > >    {
> >> > > > > > > > > > >
> >> > > > > > > > > > > Please add a pod "=head2 subroutine_name ... =cut"
> >> > heading
> >> > > > for
> >> > > > > > > every
> >> > > > > > > > > > > subroutine.  This is helpful for others to
> >> > read/understand
> >> > > > your
> >> > > > > > > code.
> >> > > > > > > > > >  The
> >> > > > > > > > > > > pod syntax can be a bit finicky.  You can tell if
> it is
> >> > > > > formatted
> >> > > > > > > > > > properly
> >> > > > > > > > > > > by running "pod2text openstack.pm".
> >> > > > > > > > > > >
> >> > > > > > > > > > > Lastly (as mainly a reminder), we will need to
> >> > incorporate
> >> > > > all
> >> > > > > of
> >> > > > > > > the
> >> > > > > > > > > > > database changes in vcl.sql and whatever method we
> use
> >> > for
> >> > > > the
> >> > > > > > next
> >> > > > > > > > > > release
> >> > > > > > > > > > > to replace update-vcl.sql.  I made a reminder
> comment
> >> > here:
> >> > > > > > > > > > > https://issues.apache.org/jira/browse/VCL-764
> >> > > > > > > > > > >
> >> > > > > > > > > > > Regards,
> >> > > > > > > > > > > Andy
> >> > > > > > > > > > >
> >> > > > > > > > > >
> >> > > > > > > > >
> >> > > > > > > >
> >> > > > > > >
> >> > > > > >
> >> > > > >
> >> > > >
> >> > >
> >> >
> >>
>
>
>
> --
> Twitter: @serverascode
> Blog: serverascode.com
>