Open Stack

Hey Anthony,

On Sat, Feb 18, 2012 at 10:14 AM, Anthony Young
<sleepsonthefloor at gmail.com>wrote:

> Hey Tomoe,
>
>
>>
>>  -  a launched instance cannot go outside the world and failed
>>    to get the cirros image with floating ip.
>>
>
> For this to work, the floating ip range defined by FLOATING_RANGE have to
> be configured on your network.  An easy solution for this is to set
> FLOATING_RANGE as some unused ips in your host network (like FLOATING_RANGE=
> 192.168.2.196/30).
>

Thanks for the explanation. Sorry I totally missed on this. I'll try with
proper settings next time.


>
>
>>  - I had to go inside nova-compute session to enter password
>>  for executing guestmount and fusermount with sudo.
>>
>
> Hmm, this doesn't happen for me.  If it is reproducible, perhaps open a
> bug describing the repro steps?
>

Will post a bug report if it happens again.


> As for creating a bootable volume through an api.  Is it that you'd want
> to do something like:
>
>  > nova bootable-volume-create --instance_id=x # That would create a
> bootable volume based on an image
>
> Or:
>
> > nova bootable-volume-create --image_id=x # Create a bootable volume from
> an image
>
> Those are of course imaginary calls - just trying to get a feel for what
> you think would be most useful.
>

Great idea! Both of those sound good to me. Would you like to implement
this?:)
Also what do you think about the issue on required imageRef? Do you still
think it's a bug?

Cheers,
Tomoe






>
> A
>
>
>
>>
>> So, I made some changes with the patch below and got it working.
>>
>> midokura at midokura-iMac:~/git/devstack.forked/exercises$ diff  -u
>> boot_from_volume_new-8fe133bebcd90fa94c7a1d12c00b3f2cca18a35c.sh
>> bfv.sh
>> --- boot_from_volume_new-8fe133bebcd90fa94c7a1d12c00b3f2cca18a35c.sh
>>  2012-02-11
>> 05:49:08.000000000 +0900
>> +++ bfv.sh      2012-02-14 14:30:44.233636001 +0900
>> @@ -99,13 +99,13 @@
>>  fi
>>
>>  # Add floating ip to our server
>> -nova add-floating-ip $VM_UUID $FLOATING_IP
>> +#nova add-floating-ip $VM_UUID $FLOATING_IP
>>
>>  # Test we can ping our floating ip within ASSOCIATE_TIMEOUT seconds
>> -if ! timeout $ASSOCIATE_TIMEOUT sh -c "while ! ping -c1 -w1
>> $FLOATING_IP; do sleep 1; done"; then
>> -    echo "Couldn't ping server with floating ip"
>> -    exit 1
>> -fi
>> +#if ! timeout $ASSOCIATE_TIMEOUT sh -c "while ! ping -c1 -w1
>> $FLOATING_IP; do sleep 1; done"; then
>> +#    echo "Couldn't ping server with floating ip"
>> +#    exit 1
>> +#fi
>>
>>  # Create our volume
>>  nova volume-create --display_name=$VOL_NAME 1
>> @@ -116,6 +116,9 @@
>>     exit 1
>>  fi
>>
>> +# get private ip
>> +IP=$(nova show $VM_UUID |grep priv | awk -F '|' '{print $3}'|sed -e 's/
>> //')
>> +
>>  # FIXME (anthony) - python-novaclient should accept a volume_id for
>> the attachment param
>>  DEVICE=/dev/vdb
>>  VOLUME_ID=`nova volume-list | grep $VOL_NAME  | cut -d '|' -f 2 | tr -d
>> ' '`
>> @@ -131,7 +134,7 @@
>>  # To do this, ssh to the builder instance, mount volume, and build a
>> volume-backed image.
>>  STAGING_DIR=/tmp/stage
>>  CIRROS_DIR=/tmp/cirros
>> -ssh -o StrictHostKeyChecking=no -i $KEY_FILE cirros@$FLOATING_IP << EOF
>> +ssh -o StrictHostKeyChecking=no -i $KEY_FILE cirros@$IP << EOF
>>  set -o errexit
>>  set -o xtrace
>>  sudo mkdir -p $STAGING_DIR
>> @@ -177,16 +180,16 @@
>>  sleep 1
>>
>>  # Add floating ip to our server
>> -nova add-floating-ip $VOL_VM_UUID $FLOATING_IP
>> +#nova add-floating-ip $VOL_VM_UUID $FLOATING_IP
>>
>>  # Test we can ping our floating ip within ASSOCIATE_TIMEOUT seconds
>> -if ! timeout $ASSOCIATE_TIMEOUT sh -c "while ! ping -c1 -w1
>> $FLOATING_IP; do sleep 1; done"; then
>> -    echo "Couldn't ping volume-backed server with floating ip"
>> -    exit 1
>> -fi
>> +#if ! timeout $ASSOCIATE_TIMEOUT sh -c "while ! ping -c1 -w1
>> $FLOATING_IP; do sleep 1; done"; then
>> +#    echo "Couldn't ping volume-backed server with floating ip"
>> +#    exit 1
>> +#fi
>>
>>  # Make sure our volume-backed instance launched
>> -ssh -o StrictHostKeyChecking=no -i $KEY_FILE cirros@$FLOATING_IP << EOF
>> +ssh -o StrictHostKeyChecking=no -i $KEY_FILE cirros@$IP << EOF
>>  echo "success!"
>>  EOF
>>
>> @@ -206,7 +209,7 @@
>>  nova delete $INSTANCE_NAME
>>
>>  # De-allocate the floating ip
>> -nova floating-ip-delete $FLOATING_IP
>> +#nova floating-ip-delete $FLOATING_IP
>>
>>  # Delete secgroup
>>  nova secgroup-delete $SECGROUP
>> ----------------------------------------------
>>
>> Hope this helps.
>>
>> Cheers,
>> Tomoe
>>
>>
>> On Sat, Feb 11, 2012 at 10:31 PM, Tomoe Sugihara <tomoe at midokura.com>
>> wrote:
>> > Hi Anthony,
>> >
>> > Thanks for following it up.
>> >
>> > On Sat, Feb 11, 2012 at 2:58 PM, Anthony Young
>> > <sleepsonthefloor at gmail.com> wrote:
>> >> On Fri, Feb 10, 2012 at 8:51 PM, Tomoe Sugihara <tomoe at midokura.com>
>> wrote:
>> >>>
>> >>> Hi folks,
>> >>>
>> >>> Could someone tell me what is the right way to do boot-from-volume?
>> >>> Especially, how to create boot-from-volume capable image and volume?
>> >>> My understanding is that, since openstack API requires imageRef, we
>> >>> need to pass in both image and volume ids.
>> >>
>> >>
>> >> I was actually playing with this today, and just put up a review that
>> adds a
>> >> devstack exercise to create and launch a bootable volume.  It is true
>> that
>> >> --image is still required when booting from a volume - I have not
>> >> investigated yet if that is a bug or a consequence of how
>> boot-from-volume
>> >> is implemented as an extension (which still may fall into the bug
>> category).
>> >>
>> >> https://review.openstack.org/4044
>> >
>> > Current servers API, which boot-from-volume inherits from, throws an
>> > exception when imageRef is missing:
>> >
>> https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/servers.py#L646
>> >
>> https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/servers.py#L965
>> >
>> >>
>> >>>
>> >>> I thought that create_image in EC2 API would be the one and tried, but
>> >>> it's totally broken now:
>> >>> https://bugs.launchpad.net/nova/+bug/923546
>> >>> And, I didn't find equivalent code in OpenStack API.
>> >>>
>> >>>
>> >>> I'd appreciate any help on this and I'd be happy to help debug the
>> issue.
>> >>
>> >>
>> >> Hopefully the code above will give you some direction to get started.
>>  My
>> >> experience thus far is that the end-to-end experience of using this
>> feature
>> >> needs some work, so I'll probably file some bugs and patches while I
>> muck
>> >> with it.  So it would be great if you took a look and did the same:)
>> >
>> > That helps me understand the end-to-end workflow a lot :)
>> > In your script, you log in to a guest and copy a bootable image by cp
>> > command to a volume, but I'm wondering if there's a way to create
>> > bootable volume using only APIs. Otherwise it's a bit hard to manage
>> > from operator's or dashboard's point of view.
>> >
>> > I'll run your script next week and see how it goes. Thanks a lot!
>> >
>> > Tomoe
>> >
>> >>
>> >> Anthony
>> >>
>> >>>
>> >>> Cheers,
>> >>> Tomoe
>> >>>
>> >>> _______________________________________________
>> >>> Mailing list: https://launchpad.net/~openstack
>> >>> Post to     : openstack at lists.launchpad.net
>> >>> Unsubscribe : https://launchpad.net/~openstack
>> >>> More help   : https://help.launchpad.net/ListHelp
>> >>
>> >>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20120219/4bafbb8d/attachment.html>