Re: [openstack-dev] [oslo] Redis as Messaging System

[Clint Byrum]

Excerpts from Todd Crane's message of 2015-05-23 12:09:10 -0700:
> Does anybody know of a way (either current projects or future plans) to use 
> Redis PubSub as the messaging system for OpenStack?
> 

You'd need to write a driver for oslo.messaging. AFAIK nobody has done
that as of yet. Also it's worth noting we're working on a policy for
drivers in-tree that would require that a community of more than one
individual stand up to support it, or it would need to live outside
the tree.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [heat][nova]: anti-affinity policy via heat in IceHouse?

[Fox, Kevin M]

It works with heat. You can use a scheduler hint on the instance and the server 
group resource to make a new one.

Thanks,
Kevin


From: Daniel Comnea
Sent: Saturday, May 23, 2015 3:17:11 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [heat][nova]: anti-affinity policy via heat in 
IceHouse?

Hi,

I'm aware of the anti-affinity policy which you can create via nova cli and 
associated instances with it.
I'm also aware of the default policies in nova.conf

by creating instances via HEAT is any alternatives to create instances part of 
anti-affinity group?

Thx,
Dani
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [heat][nova]: anti-affinity policy via heat in IceHouse?

[Daniel Comnea]

Hi,

I'm aware of the anti-affinity policy which you can create via nova cli and
associated instances with it.
I'm also aware of the default policies in nova.conf

by creating instances via HEAT is any alternatives to create instances part
of anti-affinity group?

Thx,
Dani
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [puppet] Distribution (in)dependent acceptance tests

[Spencer Krum]

For the puppet software itself, using the puppetlabs apt and yum repos
is the standard installation procedure. The distribution provided
versions are always to old, and the development effort has always been
targeting the latest stable puppet release.

For modules, I have always disagreed with packaging puppet modules by
the operating system. Even library modules like inifile have too much
volatility to be good candidates for packaging in a LTS distro.

For openstack technology like puppet-keystone, the goal is to move to
zuul-cloner (currently being driven by infra) so that the puppet modules
can all share a gate test with each other.

-- 
  Spencer Krum
  n...@spencerkrum.com

On Fri, May 22, 2015, at 05:21 PM, Gabriele Cerami wrote:
> Hi,
> 
> why are current beaker-rspec tests installing puppet from puppetlabs
> instead of using a package from a distribution repo, like what is done
> for git ?
> 
> More generally, spec_helper_acceptance.rb is setting up what it seems to
> be a distribution independent environment that is using a lot of
> external repos, and only in part the packages offered by the
> distributions. Generic dependencies (like puppet-inifile) and even
> specific dependencies (like puppet-keystone) are probably already
> offered by distribution packages.
> 
> I think that doing this defeats in part the purpose of launching
> acceptance tests on different distributions, because a consistent part
> of the test environment remains always the same.
> 
> --
> Gabriele "panda" Cerami
> Software Engineer, Openstack CI
> Red Hat
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] Redis as Messaging System

[Todd Crane]

Does anybody know of a way (either current projects or future plans) to use 
Redis PubSub as the messaging system for OpenStack?

-Todd


signature.asc
Description: Message signed with OpenPGP using GPGMail
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [security] Nominating Mike McCune as Security-Doc Core

[Clark, Robert Graham]

+1 from me

> On 22 May 2015, at 13:55, "Nathan Kinder"  wrote:
> 
>> On 05/19/2015 05:20 PM, Dillon, Nathaniel wrote:
>> To the Security and Docs groups as well as other interested parties, 
>> 
>> I would like to nominate Mike McCune to the Security Guide core. He has been 
>> contributing to the Security Guide for about six months now, and he has been 
>> a consistent participant improving content and helping new submittors. In 
>> addition, he knows the inner workings of the guide, having created and 
>> merged for the security guide the chapter on Sahara.
>> 
>> Please chime in with your agreement, or concerns.
> 
> +1!  Mike's work has been great.
> 
> -NGK
> 
>> 
>> Thanks,
>> 
>> Nathaniel
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [api] [docs] improving app Dev docs

[Lana Brindley]

On 21 May 2015, at 2:12 pm, michael mccune  wrote:

> On 05/21/2015 01:10 PM, Anne Gentle wrote:
>> Hi all, please come to the API doc working session this morning at 11:50 in 
>> 305 if you want to work on plans for next-gen API docs in Liberty.
>> 
>> https://libertydesignsummit.sched.org/mobile/#session:29e7d4effc10832b4d6aa50339e0c973
> 
> is there an etherpad available for this session?

https://etherpad.openstack.org/p/Documentation__API_Work_Session

L

> 
> i was, sadly, unable to attend but i am very interested in this effort.
> 
> mike
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Lana Brindley
Technical Writer
Rackspace Cloud Builders Australia





signature.asc
Description: Message signed with OpenPGP using GPGMail
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] PCI pass-through SRIOV

[Moshe Levi]

Hi Kamsali,
According to the logs you got binding failed error, which mean neutron failed 
to bind the port.
Can you send the neutron server log and the your neutron ml2 conf file?

Thank,
   Moshe Levi

From: Kamsali, RaghavendraChari 
(Artesyn)
Sent: ?Saturday?, ?May? ?23?, ?2015 ?6?:?38? ?AM
To: OpenStack Development Mailing List (not for usage 
questions), 
openst...@lists.openstack.org

Hi,

Am deploying controller-compute openstack setup , in controller I configured 
openvswitch bridges and in computed node I configured PCI nic supported SRIOV 
capability and while am spawning VM am getting following error as in attached 
file:

I followed the link for setting up the sriov 
https://wiki.openstack.org/wiki/SR-IOV-Passthrough-For-Networking and 
http://www.qlogic.com/solutions/Documents/UsersGuide_OpenStack_SR-IOV.pdf

Could any one help me regarding this issue


Thanks and Regards,
Raghavendrachari kamsali,
Embedded Computing and Power,
Hyderabad, AndhraPradesh , India


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] PCI pass-through SRIOV

[Kamsali, RaghavendraChari (Artesyn)]

Hi,

Am deploying controller-compute openstack setup , in controller I configured 
openvswitch bridges and in computed node I configured PCI nic supported SRIOV 
capability and while am spawning VM am getting following error as in attached 
file:

I followed the link for setting up the sriov 
https://wiki.openstack.org/wiki/SR-IOV-Passthrough-For-Networking and 
http://www.qlogic.com/solutions/Documents/UsersGuide_OpenStack_SR-IOV.pdf

Could any one help me regarding this issue


Thanks and Regards,
Raghavendrachari kamsali,
Embedded Computing and Power,
Hyderabad, AndhraPradesh , India


2015-05-23 21:24:35.061 DEBUG nova.virt.libvirt.vif [-] vif_type=binding_failed 
instance=Instance(access_ip_v4=Non
e,access_ip_v6=None,architecture=None,auto_disk_config=False,availability_zone=None,cell_name=None,cleaned=False,c
onfig_drive='',created_at=2015-05-23T04:23:17Z,default_ephemeral_device=None,default_swap_device=None,deleted=Fals
e,deleted_at=None,disable_terminate=False,display_description='ubuntuvm',display_name='ubuntuvm',ephemeral_gb=0,ep
hemeral_key_uuid=None,fault=,host='atca7480',hostname='ubuntuvm',id=6,image_ref='0f945b95-df76-4ef1-9ed0-3d072b
ac360f',info_cache=InstanceInfoCache,instance_type_id=5,kernel_id='',key_data=None,key_name=None,launch_index=0,la
unched_at=None,launched_on='atca7480',locked=False,locked_by=None,memory_mb=2048,metadata={},node='atca7480',numa_
topology=None,os_type=None,pci_devices=PciDeviceList,power_state=0,progress=0,project_id='51b00a98b1ac471684cad9b1
ee248cc5',ramdisk_id='',reservation_id='r-2r0v9idg',root_device_name='/dev/vda',root_gb=20,scheduled_at=None,secur
ity_groups=SecurityGroupList,shutdown_terminate=False,system_metadata={image_base_image_ref='0f945b95-df76-4ef1-9e
d0-3d072bac360f',image_container_format='bare',image_disk_format='qcow2',image_min_disk='20',image_min_ram='0',ins
tance_type_ephemeral_gb='0',instance_type_flavorid='2',instance_type_id='5',instance_type_memory_mb='2048',instanc
e_type_name='m1.small',instance_type_root_gb='20',instance_type_rxtx_factor='1.0',instance_type_swap='0',instance_
type_vcpu_weight=None,instance_type_vcpus='1',network_allocated='True'},task_state='spawning',terminated_at=None,u
pdated_at=2015-05-23T04:23:20Z,user_data=None,user_id='e51e176aee744f35bb1e2fb05ecd615f',uuid=39d27b92-295f-4f18-b
b76-e0bba4d0666b,vcpus=1,vm_mode=None,vm_state='building') vif=VIF({'profile': 
{u'pci_slot': u':81:02.3', u'ph
ysical_network': u'default', u'pci_vendor_info': u'8086:154c'}, 
'ovs_interfaceid': None, 'network': Network({'brid
ge': None, 'subnets': [Subnet({'ips': [FixedIP({'meta': {}, 'version': 4, 
'type': 'fixed', 'floating_ips': [], 'ad
dress': u'11.0.0.8'})], 'version': 4, 'meta': {'dhcp_server': u'11.0.0.7'}, 
'dns': [], 'routes': [], 'cidr': u'11.
0.0.0/24', 'gateway': IP({'meta': {}, 'version': 4, 'type': 'gateway', 
'address': u'11.0.0.1'})})], 'meta': {'inje
cted': False, 'tenant_id': u'51b00a98b1ac471684cad9b1ee248cc5', 
'physical_network': u'default'}, 'id': u'5ef1662f-
8bb4-4124-8b68-2a2fe240170e', 'label': u'sriov'}), 'devname': 
u'tap5281222e-4c', 'vnic_type': u'direct', 'qbh_para
ms': None, 'meta': {}, 'details': {}, 'address': u'fa:16:3e:fd:55:1e', 
'active': False, 'type': u'binding_failed',
 'id': u'5281222e-4c3b-47af-a851-6b0254c0d85a', 'qbg_params': None}) 
virt_typekvm from (pid=29295) get_config /opt
/stack/nova/nova/virt/libvirt/vif.py:342
2015-05-23 21:24:35.063 ERROR nova.compute.manager [-] [instance: 
39d27b92-295f-4f18-bb76-e0bba4d0666b] Instance f
ailed to spawn
2015-05-23 21:24:35.063 TRACE nova.compute.manager [instance: 
39d27b92-295f-4f18-bb76-e0bba4d0666b] Traceback (mos
t recent call last):
2015-05-23 21:24:35.063 TRACE nova.compute.manager [instance: 
39d27b92-295f-4f18-bb76-e0bba4d0666b]   File "/opt/s
tack/nova/nova/compute/manager.py", line 2266, in _build_resources
2015-05-23 21:24:35.063 TRACE nova.compute.manager [instance: 
39d27b92-295f-4f18-bb76-e0bba4d0666b] yield reso
urces
2015-05-23 21:24:35.063 TRACE nova.compute.manager [instance: 
39d27b92-295f-4f18-bb76-e0bba4d0666b]   File "/opt/s
tack/nova/nova/compute/manager.py", line 2136, in _build_and_run_instance
2015-05-23 21:24:35.063 TRACE nova.compute.manager [instance: 
39d27b92-295f-4f18-bb76-e0bba4d0666b] block_device_info=block_device_info)
2015-05-23 21:24:35.063 TRACE nova.compute.manager [instance: 
39d27b92-295f-4f18-bb76-e0bba4d0666b]   File 
"/opt/stack/nova/nova/virt/libvirt/driver.py", line 2662, in spawn
2015-05-23 21:24:35.063 TRACE nova.compute.manager [instance: 
39d27b92-295f-4f18-bb76-e0bba4d0666b] write_to_disk=True)
2015-05-23 21:24:35.063 TRACE nova.compute.manager [instance: 
39d27b92-295f-4f18-bb76-e0bba4d0666b]   File 
"/opt/stack/nova/nova/virt/libvirt/driver.py", line 4200, in _get_guest_xml
2015-05-23 21:24:35.063 TRACE nova.compute.manager [instance: 
39d27b92-295f-4f18-bb76-e0bba4d0666b] context)
2015-05-23 21:24:35.063 TRACE nova.compute.manager [instance: 
39d27b92-295f-4f18-bb76-e0b

Re: [openstack-dev] [nova] usefulness of device parameter at volumeAttachment

[Fox, Kevin M]

I believe xen supports it.

Thanks,
Kevin


From: Géza Gémes
Sent: Saturday, May 23, 2015 2:00:32 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [nova] usefulness of device parameter at 
volumeAttachment

Hi,

When someone calls nova volume-attach or the block-device-mapping
parameter at boot, it is possible to specify a device name for the
guest. However I couldn't find any guest OS which would honor this. E.g.
with libvirt/kvm, if the guest has two virtio disks already (vda and
vdb), specifying vdf would be ignored and the disk will be attached as
vdc in the guest.
I propose to deprecate this option and at boot where it is not optional
to accept only auto as an option.

Best regards,

Geza

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] meeting with the zaqar team at summit; my notes

[Fox, Kevin M]

Thank you. Ill look for this right away.

Long term, we would prefer some way for the resources to be associated with the 
tenant so that it simplifies quotas/billing since there are just 
instances/volumes we already quota. This would need some kind of service vm 
flag in nova to prevent via policy non admins from messing with them.

In addition, this is still a case where some users had an opertunity to get 
into a vm they shouldnt, and a multitenant message queue would then have 
privided extra protection.

Thanks,
Kevin


From: Zane Bitter
Sent: Friday, May 22, 2015 10:07:42 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] meeting with the zaqar team at summit; my notes

On 22/05/15 19:01, Fox, Kevin M wrote:
> I believe that trove still needs the multi tenant isolation of a multi
> tenant message queue due to the fact that the vm runs in the tenant, and
> the tenant can then force a reboot, go to the console, root it, and
> inject messages at queues destened for other tenants vm's. And there are
> other routes too.

So what I gathered is that according to the Trove folks you are Doing It
Wrong(TM), even though you installed it in the default configuration.
You should have modified the Trove code in undocumented ways to create
the VMs in a project that Trove itself owns, not the user's project.

> This is a major problem, and I think our site is going to have to
> strongly consider uninstalling trove until fixed.

I think if you made that change the configuration it would be a lot less
dangerous. Arguably even then it would be better to use something
multi-tenant capable and authenticated (if it's so safe why not use the
same RabbitMQ as all the other services?), but it would be less of an
'immediate uninstall' case.

cheers,
Zane.

> Thanks,
> Kevin *
> *
> 
> *From:* Zane Bitter
> *Sent:* Friday, May 22, 2015 12:34:01 PM
> *To:* openstack-dev@lists.openstack.org
> *Subject:* Re: [openstack-dev] meeting with the zaqar team at summit; my
> notes
>
> On 22/05/15 11:48, Amrith Kumar wrote:
>> I’m posting this to the mailing list to summarize my notes from a
>> meeting at 5pm yesterday at Summit relative to Zaqar and lightweight
>> multi-tenant messaging and how it may be applicable to a number of projects.
>>
>> I’ll begin by saying these are not ‘minutes’ of a meeting, merely my
>> notes and observations after the meeting and how they relate
>> specifically to Trove. I don’t claim to speak for Trove, other
>> contributors to Trove, other projects who were at the meeting, for
>> zaqar, etc., etc.,
>>
>> After the meeting I think I have a slightly better understanding of what
>> Zaqar is but I am still not entirely sure. As best as I can tell, it is
>> a lightweight, keystone authenticated, multi-tenant messaging system.
>
> I'm not sure what 'lightweight' means in this context. I'd describe it
> as a keystone-authenticated multi-tenant reliable messaging system a la
> Amazon SQS.
>
>> I
>> am still a little troubled that of the many people in the room who were
>> knowledgeable of zaqar, there appeared to be some disagreement on how
>> best to describe or explain the project.
>
> I don't think there's any disagreement. It just seems to be hard to
> explain to people, because everyone instinctively wants to compare it to
> Rabbit, which is a completely different thing with completely different
> use cases. IMHO part of the problem has been that folks have been
> reluctant to name SQS specifically, and so we end up talking elliptically.
>
>> I learned that users of zaqar can authenticate with keystone and then
>> interact with zaqar, and pass messages using it. I learned also that
>> zaqar is spelt with a ‘q’ that is not followed by a ‘u’. i.e. it isn’t
>> zaquar as I had thought it was.
>>
>> It became clear that the underlying transport in zaqar is not based on
>> an existing AMQP service, rather zaqar is a “from the ground up”
>> implementation. This scares me (a lot).
>
> Yes, literally every person who has ever heard of Zaqar complains about
> this and it's getting a little boring. It's irrelevant because Zaqar is
> not a replacement for AMQP, it's a replacement for SQS.
>
>> I gather there is currently no oslo.messaging integration with zaqar;
>
> Right, Zaqar has never been intended as a replacement for Rabbit in Oslo
> messaging.
>
> (Although that could be an interesting idea, it's another discussion
> altogether.)
>
>> for Trove to use zaqar we would have to either (a) abandon
>> oslo.messaging and use zaqar, or (b) build in smarts within Trove to
>> determine at run time whether we are using zaqar or o.m and implement
>> code in Trove to handle the differences between them if any.
>>
>> It wasn’t clear to me after the meeting what differences there may be
>> with Trove; one which was alluded to was the inability to do a
>> synchronous (call()) style message and the statemen

Re: [openstack-dev] Why need br-int and br-tun in openstack neutron

[Assaf Muller]

There's no real reason as far as I'm aware, just an implementation decision.



> On 21 במאי 2015, at 01:48, Na Zhu  wrote:
> 
> Dear,
> 
> 
> When OVS plugin is used with GRE option in Neutron, I see that each compute 
> node has br-tun and br-int bridges created. 
> 
> I'm trying to understand why we need the additional br-tun bridge here. 
> Can't we create tunneling ports in br-int bridge, and have br-int relay 
> traffic between VM ports and tunneling ports directly? Why do we have to 
> introduce another br-tun bridge?  
> 
> 
> Regards,
> Juno Zhu
> Staff Software Engineer, System Networking
> China Systems and Technology Lab (CSTL), IBM Wuxi
> Email: na...@cn.ibm.com
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Fuel] Setting cluster status when provisioning a node

[Roman Prykhodchenko]

Hi folks!

Recently I encountered an issue [1] that the Deploy Changes button in the web 
ui is still active when a provisioning of single node is started using the 
command line client.
The background for that issue is that the provisioning task does not seem to 
update the cluster status correctly and Nailgun’s API returns it as NEW even 
while some of the node are been provisioned.

The reason for raising this thread in the mailing list is that provisioning a 
node is a feature for developers and basically end-users should not do that. 
What is the best solution for that: fix Nailgun to set the correct status, or 
make this provisioning feature available only for developers?

1. https://bugs.launchpad.net/fuel/7.0.x/+bug/1449086


- romcheg



signature.asc
Description: Message signed with OpenPGP using GPGMail
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [nova] usefulness of device parameter at volumeAttachment

[Géza Gémes]

Hi,

When someone calls nova volume-attach or the block-device-mapping 
parameter at boot, it is possible to specify a device name for the 
guest. However I couldn't find any guest OS which would honor this. E.g. 
with libvirt/kvm, if the guest has two virtio disks already (vda and 
vdb), specifying vdf would be ignored and the disk will be attached as 
vdc in the guest.
I propose to deprecate this option and at boot where it is not optional 
to accept only auto as an option.


Best regards,

Geza

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [cinder] Thanks to all the folks on the plane tour to glaciers

[Jay S. Bryant]

Vincent,

So sorry you were not feeling well during the tour.  Those things happen 
though...No worries.


We were glad to get the e-mail letting us know that you were ok and 
feeling better!


Glad that you could join us on the trip and see the Alpine lake and get 
pictures with us.  I will send you a copy of the pictures.


Safe travels back home!

Jay


On 05/22/2015 10:53 PM, Sheng Bo Hou wrote:

Hi all the folks on the plane tour to the glaciers,

This is Vincent Hou. I am sorry about getting a bit plane-sick during 
our trip. It was a sort of harsh for me, but the wonderful thing is that
I really enjoyed the snow, the mountain, the lake, the glaciers, etc. 
I hope the uncomfortable me did not bring too much trouble to you folks.
It felt like that the blood in my body had stopped flowing. I got no 
strength to see, no strength to hear, no strength to sit, even no 
strength
to think... Sorry about that I did not even say goodbye and wish you 
folks a nice trip back to your place.


Thank Kurt. This trip is perhaps the only once in my life with the 
best view I ever see.
Thank Sean. You words helped me a lot. I might not be able to make the 
trip in the last section without them.

Thank Jay, Walter... Thank everybody.

One more request in the end. Can you guys share some photos you have 
taken in our tour? I have missed some view. Thank you so much.


I am feeling much better now in the hotel. Take care, folks! Safe trip 
back home! See you.



Best wishes,
Vincent Hou (侯胜博)

Staff Software Engineer, Open Standards and Open Source Team, Emerging 
Technology Institute, IBM China Software Development Lab


Tel: 86-10-82450778 Fax: 86-10-82453660
Notes ID: Sheng Bo Hou/China/IBM@IBMCNE-mail: sb...@cn.ibm.com
Address:3F Ring, Building 28 Zhongguancun Software Park, 8 Dongbeiwang 
West Road, Haidian District, Beijing, P.R.C.100193

地址:北京市海淀区东北旺西路8号中关村软件园28号楼环宇大厦3层 邮编：100193


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev