date:20130305


Le 04/03/2013 19:45, Dan Wendlandt a écrit :


On Mon, Mar 4, 2013 at 6:44 AM, Sylvain Bauza 
mailto:sylvain.ba...@digimind.com>> wrote:



Another classic error is to forget to add a static route from the
controller node (if hosting metadata service) to the external
router IP of the VM (see

http://docs.openstack.org/folsom/openstack-network/admin/content/adv_cfg_l3_agent_metadata.html
)


The good news is that this will no longer be a requirement in Grizzly, 
thanks to Mark's work on integrating metadata into Quantum.  Thanks Mark!


Dan



That's great news ! You mean metadata service will no longer be managed 
by nova-api, but quantum instead ?

Wow, cool.

-Sylvain

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] How to create a Image which can extend the partition automatically.

If you look at 
http://www.pixelbeat.org/docs/openstack_libvirt_images/#1361764412, 
you'll see that resize2fs is performed. But there is a caveat with RHEL6 
which is Linux 2.6 (contrary to Ubuntu 12.04 which is Linux 3.0).

If you look at "man resize2fs" :

   The resize2fs program will resize ext2, ext3, or ext4 file 
systems.  It
   can  be  used  to enlarge or shrink an unmounted file system 
located on
   device.  If the filesystem is mounted, it can be  used  to 
expand  the
   size  of  the  mounted filesystem, assuming the kernel supports 
on-line
   resizing.  (As of this writing, the Linux 2.6 kernel supports  
on-line

   resize for filesystems mounted using ext3 only.).

You absolutely need to create ext3 root partition for that working.

-Sylvain

Le 05/03/2013 05:59, Lei Zhang a écrit :


Hi all,

I am making the RHEL Image for the Openstack. But what type of 
partition layout is preferred?
The question is that when resize the image, the FS can be aware of the 
expansion and enlarge automatically. I found the ubuntu image from the 
http://cloud-images.ubuntu.com/precise/ have this feature. But the 
image I create can not.
So how to make the image created can re-partitioned in resize process 
automatically and how the re-partitioned implemented?


--
Lei Zhang

Blog: http://jeffrey4l.github.com
twitter/weibo: @jeffrey4l


___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp


___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] VM guest can't access outside world.

2013-03-05 Thread livemoon

Hi, Barrow Kwan.
I have the same problem in ubuntu.


On Tue, Mar 5, 2013 at 3:37 AM, Barrow Kwan  wrote:

> Hi,
> Thanks Jeff.  this is what I got from tcpdump.  The target (10.38.1.2 )
> didn't
> seem to reply.  might be the target ( 10.38.1.2 ) didn't know how to route
> the
>
> packet to 192.168.151.3?  could that be SNAT issue? or like you said it
> needs IP
> masquerading rule.  might be a bug in Quantum?
>
>
> Barrow
>
>
>
>
> tcpdump: WARNING: em1: no IPv4 address assigned
> tcpdump: listening on em1, link-type EN10MB (Ethernet), capture size 65535
> bytes
> 11:31:02.825150 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto
> ICMP (1),
>
> length 84)
> 192.168.151.3 > 10.38.1.2: ICMP echo request, id 11910, seq 133,
> length 64
> 11:31:03.825338 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto
> ICMP (1),
>
> length 84)
> 192.168.151.3 > 10.38.1.2: ICMP echo request, id 11910, seq 134,
> length 64
> 2 packets captured
> 3 packets received by filter
> 0 packets dropped by kernel
>
>
>
>
> - Original Message 
> From: Jeff Peeler 
> To: openstack@lists.launchpad.net
> Sent: Mon, March 4, 2013 7:39:03 AM
> Subject: Re: [Openstack] VM guest can't access outside world.
>
> On Wed, Feb 27, 2013 at 12:38:45PM -0800, Barrow Kwan wrote:
> > [root@optst01 quantum]# service iptables status
> > Table: nat
> > Chain PREROUTING (policy ACCEPT)
> > num  target prot opt source   destination
> > 1nova-compute-PREROUTING  all  --  0.0.0.0/00.0.0.0/0
>
>
> > 2quantum-l3-agent-PREROUTING  all  --  0.0.0.0/0
> 0.0.0.0/0
>
>
> >
> > 3nova-api-PREROUTING  all  --  0.0.0.0/00.0.0.0/0
> >
> > Chain POSTROUTING (policy ACCEPT)
> > num  target prot opt source   destination
> > 1nova-compute-POSTROUTING  all  --  0.0.0.0/00.0.0.0/0
> >
> > 2quantum-l3-agent-POSTROUTING  all  --  0.0.0.0/0
> 0.0.0.0/0
> >
> >
> >
> > 3quantum-postrouting-bottom  all  --  0.0.0.0/00.0.0.0/0
> >
> >
> >
> > 4nova-api-POSTROUTING  all  --  0.0.0.0/00.0.0.0/0
> > 5nova-postrouting-bottom  all  --  0.0.0.0/00.0.0.0/0
>
>
> >
> > Chain OUTPUT (policy ACCEPT)
> > num  target prot opt source   destination
> > 1nova-compute-OUTPUT  all  --  0.0.0.0/00.0.0.0/0
> > 2quantum-l3-agent-OUTPUT  all  --  0.0.0.0/00.0.0.0/0
>
>
> > 3nova-api-OUTPUT  all  --  0.0.0.0/00.0.0.0/0
> >
> > Chain nova-api-OUTPUT (1 references)
> > num  target prot opt source   destination
> >
> > Chain nova-api-POSTROUTING (1 references)
> > num  target prot opt source   destination
> >
> > Chain nova-api-PREROUTING (1 references)
> > num  target prot opt source   destination
> >
> > Chain nova-api-float-snat (1 references)
> > num  target prot opt source   destination
> >
> > Chain nova-api-snat (1 references)
> > num  target prot opt source   destination
> > 1nova-api-float-snat  all  --  0.0.0.0/00.0.0.0/0
> >
> > Chain nova-compute-OUTPUT (1 references)
> > num  target prot opt source   destination
> >
> > Chain nova-compute-POSTROUTING (1 references)
> > num  target prot opt source   destination
> >
> > Chain nova-compute-PREROUTING (1 references)
> > num  target prot opt source   destination
> >
> > Chain nova-compute-float-snat (1 references)
> > num  target prot opt source   destination
> >
> > Chain nova-compute-snat (1 references)
> > num  target prot opt source   destination
> > 1nova-compute-float-snat  all  --  0.0.0.0/00.0.0.0/0
>
>
> >
> > Chain nova-postrouting-bottom (1 references)
> > num  target prot opt source   destination
> > 1nova-compute-snat  all  --  0.0.0.0/00.0.0.0/0
> > 2nova-api-snat  all  --  0.0.0.0/00.0.0.0/0
> >
> > Chain quantum-l3-agent-OUTPUT (1 references)
> > num  target prot opt source   destination
> >
> > Chain quantum-l3-agent-POSTROUTING (1 references)
> > num  target prot opt source   destination
> > 1ACCEPT all  --  0.0.0.0/00.0.0.0/0   !
> ctstate
> > DNAT
> >
> > Chain quantum-l3-agent-PREROUTING (1 references)
> > num  target prot opt source   destination
> >
> > Chain quantum-l3-agent-float-snat (1 references)
> > num  target prot opt source   destination
> >
> > Chain quantum-l3-agent-snat (1 references)
> > num  target prot opt source   destination
> > 1quantum-l3-agent-float-snat  all  --  0.0.0.0/0
> 0.0.0.0/0
>
>
> >
> > 2SNAT   all  --  192.168.151.0/24 0.0.0.0/0
> to:10.38.17.1
> >
> >
> >
> > Chain quantum-postrouting-bottom (1 references)
> > num  target prot opt source   destination
> > 1quantum-l3-agent-snat  all  --  0.0.0.0

Re: [Openstack] How to create a Image which can extend the partition automatically.

On Tue, Mar 5, 2013 at 4:24 PM, Sylvain Bauza 
wrote:

resize2fs

but the resize2fs tools is not working and raise following error

$ resize2fs rhel6.3-x86_64.img
resize2fs 1.42.5 (29-Jul-2012)
resize2fs: Bad magic number in super-block while trying to open
rhel6.3-x86_64.img
Couldn't find valid filesystem superblock.

In fact, I have found the partition-resize is implemented in the ubuntu OS.
It is related to could-utils package.
the could-utils has a command tool name growpart, which can rewrite the
partition table and extend space.
When the ubuntu is boot, there are scrips in the initrd.img that can call
the growpart and resize2fs to re-partition.

But on the RHEL, I didn't found the could-utils( it is under development) ,
and no kernel that can call the something like grouppart. So what should I
do on the RHEL to implement re-partition?
-- 
Lei Zhang

Blog: http://jeffrey4l.github.com
twitter/weibo: @jeffrey4l
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

[Openstack] [openstack-dev] [Swift] Design note of geo-distributed Swift cluster

2013-03-05 Thread David Hadas

This discussion of geo-distributed Swift is of great interest to us as 
well. Yet, based on our analysis, the proposed ring of ring seem to not 
meet a basic requirement that we see.


One of the basic disadvantages (and advantages) of the consistent 
hashing at the core of the Swift Ring concept is that it takes control 
over the placement of objects. As long as one considers a fairly unified 
cluster - and does not care which object is placed where in that 
cluster, consistent hashing does a great job.


However, in the case of geo-distributed Swift, many customers do care 
and need control over the placement decision - hence making the use of 
consistent hashing to decide where an object should be placed will not 
do. We actually believe that placement decisions can be made in 
the resolution of containers - not individual objects. Hence, container 
sync seems like a reasonable starting point.


We plan to contribute improvements to container sync, making it a more 
attractive, scalable, and easier to use replication mechanism such that 
it can serve as a basis of a placement aware system controlling where 
replicas reside in a geo-distributed Swift. It would be great if the the 
community align on the need to offer control over placement, between geo 
distributed sites, but if this is not the case, we need to find a way 
to accommodate the different requirements without complicating the design.


Regards,
David Hadas

--
DH



Regards,
David Hadas
IBM Research Labs, Haifa

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

[Openstack] iptables being overwritten

2013-03-05 Thread Javier Alvarez


Hello,

When using FlatDHCPManager, every time I start a new instance, 
nova-network overwrites my iptables. Does anyone know if there is a way 
to disable that behavior?


Thanks in advance,

Javi

--
Javier Álvarez Cid-Fuentes
Grid Computing and Clusters Group
Barcelona Supercomputing Center (BSC-CNS)
Tel. (+34) 93 413 72 46


WARNING / LEGAL TEXT: This message is intended only for the use of the
individual or entity to which it is addressed and may contain
information which is privileged, confidential, proprietary, or exempt
from disclosure under applicable law. If you are not the intended
recipient or the person responsible for delivering the message to the
intended recipient, you are strictly prohibited from disclosing,
distributing, copying, or in any way using this message. If you have
received this communication in error, please notify the sender and
destroy and delete any copies you may have received.

http://www.bsc.es/disclaimer

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

[Openstack] [OpenStack] Guest OS shows just one CPU core instead of two

Hi,

I am running Folsom 2.2 with a KVM compute node. When I launch a windows
instance with flavor that has 2 VCPUs and 2Gb RAM, the guest seems the RAM
fine but not the 2 CPUs. It reports only one Virtual processor. Whne I look
at the command line options with which KVM has launched the instance, I see
that in -smp argument, sockets is set to 2 and core is set to 1. How can I
get the core to be 2 so that the guest OS can see it?


107   7764 1 14 14:35 ?00:11:27 /usr/bin/kvm -name
instance-000e -S -M pc-1.0 -cpu
core2duo,+lahf_lm,+osxsave,+xsave,+sse4.1,+dca,+pdcm,+xtpr,+cx16,+tm2,+est,+vmx,+ds_cpl,+dtes64,+pbe,+tm,+ht,+ss,+acpi,+ds
-enable-kvm -m 2048* -smp 2,sockets=2,cores=1,threads=1* -uuid
cd6dd64c-d792-4b31-92bf-ed8ad1ea46cb -nodefconfig -nodefaults -chardev
socket,id=charmonitor,path=/var/lib/libvirt/qemu/instance-000e.monitor,server,nowait
-mon chardev=charmonitor,id=monitor,mode=control -rtc
base=utc,driftfix=slew -no-kvm-pit-reinjection -no-shutdown -device
piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive
file=/var/lib/nova/instances/instance-000e/disk,if=none,id=drive-virtio-disk0,format=qcow2,cache=none
-device
virtio-blk-pci,scsi=off,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1
-netdev tap,fd=24,id=hostnet0 -device
virtio-net-pci,netdev=hostnet0,id=net0,mac=fa:16:3e:46:68:2e,bus=pci.0,addr=0x3
-chardev
file,id=charserial0,path=/var/lib/nova/instances/instance-000e/console.log
-device isa-serial,chardev=charserial0,id=serial0 -chardev
pty,id=charserial1 -device isa-serial,chardev=charserial1,id=serial1
-device usb-tablet,id=input0 -vnc 0.0.0.0:3 -k en-us -vga cirrus -device
virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5
root@openstack-kvm1:~#



Regards,
Balu
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

[Openstack] [OpenStack] How to speed up the instance launch time?

Hi,

I have a Folsom 2012.2 3 nodes setup like the one specified at
https://github.com/mseknibilel/OpenStack-Folsom-Install-guide/blob/master/OpenStack_Folsom_Install_Guide_WebVersion.rst.
Each node has a 1Tb hard disk with no raid.

Be it the image creation or the Instance creation, takes a long time(factor
of the disk size of the image), about 15mins for a 20gb image. I can
understand the slow image creation due to the http transfer of the file
from a seperate web server hosting my images to the controller node. But
even the instance creation takes that much or even a bit longer. I see that
the image is copied from the Controller to Compute node and multiple copies
are make in the compute node. So all this takes long an dis proportional to
the image size. Is there any way to speed up this process? Is a SAN based
backend the only way to go?

Regards,
Balu
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

[Openstack] Minutes from the Technical Committee meeting (Feb 26)

2013-03-05 Thread Thierry Carrez

The OpenStack Technical Committee ("TC") met in #openstack-meeting at
20:00 UTC Tuesday last week.

Here is a quick summary of the outcome of this meeting:

* The TC approved the graduation of the Ceilometer project (to be
integrated in common Havana release)

See details and full logs at:
http://eavesdrop.openstack.org/meetings/tc/2013/tc.2013-02-26-20.03.html

More information on the Technical Committee at:
http://wiki.openstack.org/Governance/TechnicalCommittee

-- 
Thierry Carrez (ttx)
Chair, OpenStack Technical Committee

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] [OpenStack] How to speed up the instance launch time?

On 03/05/2013 11:03 AM, Balamurugan V G wrote:
> Hi,
> 
> I have a Folsom 2012.2 3 nodes setup like the one specified at 
> https://github.com/mseknibilel/OpenStack-Folsom-Install-guide/blob/master/OpenStack_Folsom_Install_Guide_WebVersion.rst.
>  Each node has a 1Tb hard disk with no raid.
> 
> Be it the image creation or the Instance creation, takes a long time(factor 
> of the disk size of the image), about 15mins for a 20gb image. I can 
> understand the slow image creation due to the http transfer of the file from 
> a seperate web server hosting my images to the controller node. But even the 
> instance creation takes that much or even a bit longer. I see that the image 
> is copied from the Controller to Compute node and multiple copies are make in 
> the compute node. So all this takes long an dis proportional to the image 
> size. Is there any way to speed up this process? Is a SAN based backend the 
> only way to go?

It sounds like you're using raw images throughout?
You might consider using qcow2 images in glance.
Then you can avoid the conversion to raw in the libvirt base
directory by setting force_raw_images=False in nova.conf
That will avoid some of the initial caching penalty.

Ensuring that you have use_cow_images=True set,
with use CoW images for the instances and improve
instance startup latency.

Details of the operations and tradeoffs involved are at:
http://www.pixelbeat.org/docs/openstack_libvirt_images/

thanks,
Pádraig.


___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] [OpenStack] How to speed up the instance launch time?

Thanks for the response. I have the images as .img in the web server which
is external to OpenStack nodes. But while I create the image in Horizon, I
set the format to QCOW2. So once th image is created it shows as QCOW2.
Then the instance is launched from this QCOW2 image.

Do you mean that I original image should also be QCOW2?

I will also try the settings which you recommended.

Regards,
Balu

On Tue, Mar 5, 2013 at 4:50 PM, Pádraig Brady  wrote:

> On 03/05/2013 11:03 AM, Balamurugan V G wrote:
> > Hi,
> >
> > I have a Folsom 2012.2 3 nodes setup like the one specified at
> https://github.com/mseknibilel/OpenStack-Folsom-Install-guide/blob/master/OpenStack_Folsom_Install_Guide_WebVersion.rst.
> Each node has a 1Tb hard disk with no raid.
> >
> > Be it the image creation or the Instance creation, takes a long
> time(factor of the disk size of the image), about 15mins for a 20gb image.
> I can understand the slow image creation due to the http transfer of the
> file from a seperate web server hosting my images to the controller node.
> But even the instance creation takes that much or even a bit longer. I see
> that the image is copied from the Controller to Compute node and multiple
> copies are make in the compute node. So all this takes long an dis
> proportional to the image size. Is there any way to speed up this process?
> Is a SAN based backend the only way to go?
>
> It sounds like you're using raw images throughout?
> You might consider using qcow2 images in glance.
> Then you can avoid the conversion to raw in the libvirt base
> directory by setting force_raw_images=False in nova.conf
> That will avoid some of the initial caching penalty.
>
> Ensuring that you have use_cow_images=True set,
> with use CoW images for the instances and improve
> instance startup latency.
>
> Details of the operations and tradeoffs involved are at:
> http://www.pixelbeat.org/docs/openstack_libvirt_images/
>
> thanks,
> Pádraig.
>
>
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] [OpenStack] How to speed up the instance launch time?

2013-03-05 Thread Staicu Gabriel

Hi,

As a rule of thumb how I worked around this issue was to add a new hdd. I 
allocated this new hdd only to /var/lib/nova/instances/_base and the other hdd 
to /var/lib/nova/instances/ so in this manner to the first time a instance  is 
spawn on server the process use the full capacity of a hdd.

Regards,
Gabriel

 From: Pádraig Brady 
To: Balamurugan V G  
Cc: openstack@lists.launchpad.net 
Sent: Tuesday, March 5, 2013 1:20 PM
Subject: Re: [Openstack] [OpenStack] How to speed up the instance launch time?

On 03/05/2013 11:03 AM, Balamurugan V G wrote:
> Hi,
> 
> I have a Folsom 2012.2 3 nodes setup like the one specified at 
> https://github.com/mseknibilel/OpenStack-Folsom-Install-guide/blob/master/OpenStack_Folsom_Install_Guide_WebVersion.rst.
>  Each node has a 1Tb hard disk with no raid.
> 
> Be it the image creation or the Instance creation, takes a long time(factor 
> of the disk size of the image), about 15mins for a 20gb image. I can 
> understand the slow image creation due to the http transfer of the file from 
> a seperate web server hosting my images to the controller node. But even the 
> instance creation takes that much or even a bit longer. I see that the image 
> is copied from the Controller to Compute node and multiple copies are make in 
> the compute node. So all this takes long an dis proportional to the image 
> size. Is there any way to speed up this process? Is a SAN based backend the 
> only way to go?

It sounds like you're using raw images throughout?
You might consider using qcow2 images in glance.
Then you can avoid the conversion to raw in the libvirt base
directory by setting force_raw_images=False in nova.conf
That will avoid some of the initial caching penalty.

Ensuring that you have use_cow_images=True set,
with use CoW images for the instances and improve
instance startup latency.

Details of the operations and tradeoffs involved are at:
http://www.pixelbeat.org/docs/openstack_libvirt_images/

thanks,
Pádraig.

___
Mailing list: https://launchpad.net/~openstack
Post to     : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

[Openstack] OpenStack login page

Hi folks,

I am following this link
to setup
OpenStack but am
unable to login to OpenStack dashboard page.

Below are few Django error messages which i get

[Tue Mar 05 22:59:28 2013] [error]
/usr/lib/python2.6/site-packages/django/conf/__init__.py:75:
DeprecationWarning: The ADMIN_MEDIA_PREFIX setting has been removed; use
STATIC_URL instead.
[Tue Mar 05 22:59:28 2013] [error]   "use STATIC_URL instead.",
DeprecationWarning)
[Tue Mar 05 22:59:28 2013] [error]
/usr/lib/python2.6/site-packages/django/conf/__init__.py:110:
DeprecationWarning: The SECRET_KEY setting must not be empty.
[Tue Mar 05 22:59:28 2013] [error]   warnings.warn("The SECRET_KEY setting
must not be empty.", DeprecationWarning)
[Tue Mar 05 22:59:28 2013] [error]
/usr/lib/python2.6/site-packages/django/core/cache/__init__.py:82:
DeprecationWarning: settings.CACHE_* is deprecated; use settings.CACHES
instead.
[Tue Mar 05 22:59:28 2013] [error]   DeprecationWarning
[Tue Mar 05 22:59:28 2013] [error]
/usr/lib/python2.6/site-packages/django/utils/translation/__init__.py:63:
DeprecationWarning: Translations in the project directory aren't supported
anymore. Use the LOCALE_PATHS setting instead.
[Tue Mar 05 22:59:28 2013] [error]   DeprecationWarning)
[Tue Mar 05 22:59:28 2013] [error]
/usr/lib/python2.6/site-packages/django/contrib/auth/__init__.py:26:
DeprecationWarning: Authentication backends without a
`supports_inactive_user` attribute are deprecated. Please define it in
.
[Tue Mar 05 22:59:28 2013] [error]   DeprecationWarning)
[Tue Mar 05 22:59:28 2013] [error]
/usr/lib/python2.6/site-packages/django/template/defaulttags.py:1235:
DeprecationWarning: The syntax for the url template tag is changing. Load
the `url` tag from the `future` tag library to start using the new behavior.
[Tue Mar 05 22:59:28 2013] [error]   category=DeprecationWarning)

The installation happened with the help of
script
.
There were no errors when I executed the script.
Relevant services were also running fine.

Is the issue because of Django version embedded in script ?

Support appreciated.

Thank you,
-- 
Ashutosh Narayan

http://ashutoshn.wordpress.com/
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Rebooted, now can't ping my guest

2013-03-05 Thread Filipe Manco

I read the bug description
(https://bugs.launchpad.net/quantum/+bug/1091605) and
the fix (https://review.openstack.org/#/c/18302/). But I don't understand
who is the responsible to call the script on the startup.

Should I put it on something like rc.local? Or is quantum plugins'
responsibility to run the utility?


2013/3/1 Sylvain Bauza 

>  There is a known bug for the network bridges, when rebooting :
> https://bugs.launchpad.net/quantum/+bug/1091605
>
> Try to delete/recreate your br-int/br-ex and then restart
> openvswitch_plugin/l3/dhcp agents, it should fix the issue.
>
> -Sylvain
>
> Le 01/03/2013 15:04, The King in Yellow a écrit :
>
>  In my case, it actually appears that my vms aren't up-- the instances
> panel says they are up, but looking at the console, it appears they aren't
> getting an IP address.  This is a new instance:
>
> Begin: Running /scripts/init-bottom ... done.
> [2.849416] EXT4-fs (vda1): re-mounted. Opts: (null)
> cloud-init start-local running: Thu, 28 Feb 2013 13:29:09 +. up 10.41 
> seconds
>
> no instance data found in start-local
>
> cloud-init-nonet waiting 120 seconds for a network device.
>
> cloud-init-nonet gave up waiting for a network device.
>
> ci-info: lo: 1 127.0.0.1   255.0.0.0   .
>
> ci-info: eth0  : 1 .   .   fa:16:3e:e0:17:f0
>
> route_info failed
>
> Waiting for network configuration...
>
> It looks like it made an OVS port, though.  This is on the compute node,
> openvswitch-agent.log:
>
>
> 2013-02-28 08:34:19DEBUG [quantum.agent.linux.utils]
> Command: ['sudo', '/usr/bin/quantum-rootwrap',
> '/etc/quantum/rootwrap.conf', 'ovs-vsctl', '--timeout=2', 'get',
> 'Interface', 'qvo4f36c3ea-5c', 'external_ids']
> Exit code: 0
> Stdout: '{attached-mac="fa:16:3e:e0:17:f0",
> iface-id="4f36c3ea-5c49-4625-a830-0c81f27ba139", iface-status=active,
> vm-uuid="239d3051-255e-4213-9511-af0a82fcc744"}\n'
> Stderr: ''
> 2013-02-28 08:34:19DEBUG [quantum.agent.linux.utils] Running command:
> sudo /usr/bin/quantum-rootwrap /etc/quantum/rootwrap.conf ovs-vsctl
> --timeout=2 get Interface qvo62721ee8-08 external_ids
> 2013-02-28 08:34:19DEBUG [quantum.agent.linux.utils]
> :
> root@os-compute-01:/var/log/quantum# ovs-vsctl show
> 3a52a17f-9846-4b32-b309-b49faf91bfc4
> Bridge br-int
> Port "qvo62721ee8-08"
> tag: 1
> Interface "qvo62721ee8-08"
> Port "qvo1ed73bcc-9d"
> tag: 1
> Interface "qvo1ed73bcc-9d"
> Port "qvoce0c94a9-ef"
> tag: 1
> Interface "qvoce0c94a9-ef"
> Port "qvo135e78dd-8e"
> tag: 4095
> Interface "qvo135e78dd-8e"
> Port "qvof37b7a55-a3"
> tag: 1
> Interface "qvof37b7a55-a3"
>
> Port br-int
> Interface br-int
> type: internal
> Port patch-tun
> Interface patch-tun
> type: patch
> options: {peer=patch-int}
>  Port "qvoaed25b41-9c"
> tag: 1
> Interface "qvoaed25b41-9c"
> Port "qvo4f36c3ea-5c"
> tag: 1
> Interface "qvo4f36c3ea-5c"
> Bridge br-tun
>
> Port patch-int
> Interface patch-int
> type: patch
> options: {peer=patch-tun}
>  Port "gre-1"
> Interface "gre-1"
> type: gre
> options: {in_key=flow, out_key=flow,
> remote_ip="10.10.10.1"}
>
> Port br-tun
> Interface br-tun
> type: internal
> ovs_version: "1.4.0+build0"
>  root@os-compute-01:/var/log/quantum#
>
>
>  I supposed it should be getting address via DHCP from quantum-dhcp-agent
> on the network node?  It was running, nothing regarding this MAC in the
> logs.  I restarted quantum-dhcp-agent and rebooted, no change.
>
>  In fact, I got two CirrOS vms up, logged on the console and manually IPed
> them (10.5.5.10/24 and 10.5.5.11/24), and they can't ping each other.  I
> would expect them to, right?  They should both be connected to OVS switch
> br-int, right?
>
> Any pointers?
>
>
>
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
>
>
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
>


-- 
Filipe Manco
about.me/fmanco
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] OpenStack login page

2013-03-05 Thread Syed Armani


These are just deprecation warnings. Could you please elaborate what you
mean by not able to login to dashboard page. Are you able to fire up
dashboard on the ip address specified at OPENSTACK_HOST in
local_settings.py ?

Cheers,
Syed Armani


On Tuesday 05 March 2013 05:54 PM, Ashutosh Narayan wrote:
> Hi folks,
> 
> I am following this link
> to
> setup OpenStack but am 
> unable to login to OpenStack dashboard page.
> 
> Below are few Django error messages which i get
> 
> [Tue Mar 05 22:59:28 2013] [error]
> /usr/lib/python2.6/site-packages/django/conf/__init__.py:75:
> DeprecationWarning: The ADMIN_MEDIA_PREFIX setting has been removed; use
> STATIC_URL instead.
> [Tue Mar 05 22:59:28 2013] [error]   "use STATIC_URL instead.",
> DeprecationWarning)
> [Tue Mar 05 22:59:28 2013] [error]
> /usr/lib/python2.6/site-packages/django/conf/__init__.py:110:
> DeprecationWarning: The SECRET_KEY setting must not be empty.
> [Tue Mar 05 22:59:28 2013] [error]   warnings.warn("The SECRET_KEY
> setting must not be empty.", DeprecationWarning)
> [Tue Mar 05 22:59:28 2013] [error]
> /usr/lib/python2.6/site-packages/django/core/cache/__init__.py:82:
> DeprecationWarning: settings.CACHE_* is deprecated; use settings.CACHES
> instead.
> [Tue Mar 05 22:59:28 2013] [error]   DeprecationWarning
> [Tue Mar 05 22:59:28 2013] [error]
> /usr/lib/python2.6/site-packages/django/utils/translation/__init__.py:63: 
> DeprecationWarning:
> Translations in the project directory aren't supported anymore. Use the
> LOCALE_PATHS setting instead.
> [Tue Mar 05 22:59:28 2013] [error]   DeprecationWarning)
> [Tue Mar 05 22:59:28 2013] [error]
> /usr/lib/python2.6/site-packages/django/contrib/auth/__init__.py:26:
> DeprecationWarning: Authentication backends without a
> `supports_inactive_user` attribute are deprecated. Please define it in
> .
> [Tue Mar 05 22:59:28 2013] [error]   DeprecationWarning)
> [Tue Mar 05 22:59:28 2013] [error]
> /usr/lib/python2.6/site-packages/django/template/defaulttags.py:1235:
> DeprecationWarning: The syntax for the url template tag is changing.
> Load the `url` tag from the `future` tag library to start using the new
> behavior.
> [Tue Mar 05 22:59:28 2013] [error]   category=DeprecationWarning)
> 
> The installation happened with the help ofscript
> .
> There were no errors when I executed the script.
> Relevant services were also running fine.
> 
> Is the issue because of Django version embedded in script ?
> 
> Support appreciated.
> 
> Thank you,
> -- 
> Ashutosh Narayan
> 
> http://ashutoshn.wordpress.com/
> 
> 
> 
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
> 


___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] [OpenStack] How to speed up the instance launch time?

Another option is to merge both Glance and Nova datadirs on GlusterFS in
distributed/replicated array.
That way, all _base images and glance images are on the same
"filesystem" but with distributed I/O.

-Sylvain

Le 05/03/2013 13:10, Staicu Gabriel a écrit :

Hi,

As a rule of thumb how I worked around this issue was to add a new
hdd. I allocated this new hdd only to /var/lib/nova/instances/_base
and the other hdd to /var/lib/nova/instances/ so in this manner to the
first time a instance is spawn on server the process use the full
capacity of a hdd.

Regards,
Gabriel

*From:* Pádraig Brady
*To:* Balamurugan V G
*Cc:* openstack@lists.launchpad.net
*Sent:* Tuesday, March 5, 2013 1:20 PM
*Subject:* Re: [Openstack] [OpenStack] How to speed up the instance
launch time?

On 03/05/2013 11:03 AM, Balamurugan V G wrote:
> Hi,
>
> I have a Folsom 2012.2 3 nodes setup like the one specified at
https://github.com/mseknibilel/OpenStack-Folsom-Install-guide/blob/master/OpenStack_Folsom_Install_Guide_WebVersion.rst.
Each node has a 1Tb hard disk with no raid.

>
> Be it the image creation or the Instance creation, takes a long
time(factor of the disk size of the image), about 15mins for a 20gb
image. I can understand the slow image creation due to the http
transfer of the file from a seperate web server hosting my images to
the controller node. But even the instance creation takes that much or
even a bit longer. I see that the image is copied from the Controller
to Compute node and multiple copies are make in the compute node. So
all this takes long an dis proportional to the image size. Is there
any way to speed up this process? Is a SAN based backend the only way
to go?

It sounds like you're using raw images throughout?
You might consider using qcow2 images in glance.
Then you can avoid the conversion to raw in the libvirt base
directory by setting force_raw_images=False in nova.conf
That will avoid some of the initial caching penalty.

Ensuring that you have use_cow_images=True set,
with use CoW images for the instances and improve
instance startup latency.

Details of the operations and tradeoffs involved are at:
http://www.pixelbeat.org/docs/openstack_libvirt_images/

thanks,
Pádraig.

___
Mailing list: https://launchpad.net/~openstack

Post to: openstack@lists.launchpad.net

Unsubscribe : https://launchpad.net/~openstack

More help : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp

Re: [Openstack] [OpenStack] Guest OS shows just one CPU core instead of two


Could you please tell us what is your libvirt_cpu_model ?
Please check both nova.conf and instance's libvirt.xml.

-Sylvain

Le 05/03/2013 11:30, Balamurugan V G a écrit :

Hi,

I am running Folsom 2.2 with a KVM compute node. When I launch a 
windows instance with flavor that has 2 VCPUs and 2Gb RAM, the guest 
seems the RAM fine but not the 2 CPUs. It reports only one Virtual 
processor. Whne I look at the command line options with which KVM has 
launched the instance, I see that in -smp argument, sockets is set to 
2 and core is set to 1. How can I get the core to be 2 so that the 
guest OS can see it?



107   7764 1 14 14:35 ?00:11:27 /usr/bin/kvm -name 
instance-000e -S -M pc-1.0 -cpu 
core2duo,+lahf_lm,+osxsave,+xsave,+sse4.1,+dca,+pdcm,+xtpr,+cx16,+tm2,+est,+vmx,+ds_cpl,+dtes64,+pbe,+tm,+ht,+ss,+acpi,+ds 
-enable-kvm -m 2048*-smp 2,sockets=2,cores=1,threads=1* -uuid 
cd6dd64c-d792-4b31-92bf-ed8ad1ea46cb -nodefconfig -nodefaults -chardev 
socket,id=charmonitor,path=/var/lib/libvirt/qemu/instance-000e.monitor,server,nowait 
-mon chardev=charmonitor,id=monitor,mode=control -rtc 
base=utc,driftfix=slew -no-kvm-pit-reinjection -no-shutdown -device 
piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive 
file=/var/lib/nova/instances/instance-000e/disk,if=none,id=drive-virtio-disk0,format=qcow2,cache=none 
-device 
virtio-blk-pci,scsi=off,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 
-netdev tap,fd=24,id=hostnet0 -device 
virtio-net-pci,netdev=hostnet0,id=net0,mac=fa:16:3e:46:68:2e,bus=pci.0,addr=0x3 
-chardev 
file,id=charserial0,path=/var/lib/nova/instances/instance-000e/console.log 
-device isa-serial,chardev=charserial0,id=serial0 -chardev 
pty,id=charserial1 -device isa-serial,chardev=charserial1,id=serial1 
-device usb-tablet,id=input0 -vnc 0.0.0.0:3  -k 
en-us -vga cirrus -device 
virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5

root@openstack-kvm1:~#



Regards,
Balu





___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp


___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] [OpenStack] Guest OS shows just one CPU core instead of two

2013-03-05 Thread Daniel P. Berrange

On Tue, Mar 05, 2013 at 04:00:06PM +0530, Balamurugan V G wrote:
> Hi,
> 
> I am running Folsom 2.2 with a KVM compute node. When I launch a windows
> instance with flavor that has 2 VCPUs and 2Gb RAM, the guest seems the RAM
> fine but not the 2 CPUs. It reports only one Virtual processor. Whne I look
> at the command line options with which KVM has launched the instance, I see
> that in -smp argument, sockets is set to 2 and core is set to 1. How can I
> get the core to be 2 so that the guest OS can see it?

There's nothing wrong with what the command line set here. It is
simply configuring 2 vCPUS where each vCPU is represented as a
separate socket to the guest, rather than what you describe which
would be 1 socket with dual-cores.

You don't mention what Windows version you are using, but some versions
are not clever enough to switch between a uniprocessor config and SMP
config. So if you installed those versions on a 1 CPU guest, then even
if you later boot the image on 1 CPU guest, it won't see the extra CPUs.
There are hacks you can do to "upgrade" a windows install from the
uniprocessor to multiprocessor HAL - see the microsoft kbase for more
info

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Rebooted, now can't ping my guest


This is up to your responsability to hit the script, afaik.
I haven't deployed the bugfix, I preferred creating my own script called 
by rc.local by convenience (and also because I found the issue and 
mitigated it before talking to the forum)


Once I'll migrate to 2012.2.3, I'll use this .py instead.

-Sylvain

Le 05/03/2013 13:23, Filipe Manco a écrit :
I read the bug description 
(https://bugs.launchpad.net/quantum/+bug/1091605) and the fix 
(https://review.openstack.org/#/c/18302/). But I don't understand who 
is the responsible to call the script on the startup.


Should I put it on something like rc.local? Or is quantum plugins' 
responsibility to run the utility?



2013/3/1 Sylvain Bauza >


There is a known bug for the network bridges, when rebooting :
https://bugs.launchpad.net/quantum/+bug/1091605

Try to delete/recreate your br-int/br-ex and then restart
openvswitch_plugin/l3/dhcp agents, it should fix the issue.

-Sylvain

Le 01/03/2013 15:04, The King in Yellow a écrit :

In my case, it actually appears that my vms aren't up-- the
instances panel says they are up, but looking at the console, it
appears they aren't getting an IP address.  This is a new instance:

Begin: Running /scripts/init-bottom ... done.
[2.849416] EXT4-fs (vda1): re-mounted. Opts: (null)
cloud-init start-local running: Thu, 28 Feb 2013 13:29:09 +. up 10.41 
seconds

no instance data found in start-local

cloud-init-nonet waiting 120 seconds for a network device.

cloud-init-nonet gave up waiting for a network device.

ci-info: lo: 1 127.0.0.1   255.0.0.0   .

ci-info: eth0  : 1 .   .   fa:16:3e:e0:17:f0

route_info failed

Waiting for network configuration...

It looks like it made an OVS port, though. This is on the compute
node, openvswitch-agent.log:


2013-02-28 08:34:19DEBUG [quantum.agent.linux.utils]
Command: ['sudo', '/usr/bin/quantum-rootwrap',
'/etc/quantum/rootwrap.conf', 'ovs-vsctl', '--timeout=2', 'get',
'Interface', 'qvo4f36c3ea-5c', 'external_ids']
Exit code: 0
Stdout: '{attached-mac="fa:16:3e:e0:17:f0",
iface-id="4f36c3ea-5c49-4625-a830-0c81f27ba139",
iface-status=active,
vm-uuid="239d3051-255e-4213-9511-af0a82fcc744"}\n'
Stderr: ''
2013-02-28 08:34:19DEBUG [quantum.agent.linux.utils] Running
command: sudo /usr/bin/quantum-rootwrap
/etc/quantum/rootwrap.conf ovs-vsctl --timeout=2 get Interface
qvo62721ee8-08 external_ids
2013-02-28 08:34:19DEBUG [quantum.agent.linux.utils]
:
root@os-compute-01:/var/log/quantum# ovs-vsctl show
3a52a17f-9846-4b32-b309-b49faf91bfc4
Bridge br-int
Port "qvo62721ee8-08"
tag: 1
Interface "qvo62721ee8-08"
Port "qvo1ed73bcc-9d"
tag: 1
Interface "qvo1ed73bcc-9d"
Port "qvoce0c94a9-ef"
tag: 1
Interface "qvoce0c94a9-ef"
Port "qvo135e78dd-8e"
tag: 4095
Interface "qvo135e78dd-8e"
Port "qvof37b7a55-a3"
tag: 1
Interface "qvof37b7a55-a3"

Port br-int
Interface br-int
type: internal
Port patch-tun
Interface patch-tun
type: patch
options: {peer=patch-int}
Port "qvoaed25b41-9c"
tag: 1
Interface "qvoaed25b41-9c"
Port "qvo4f36c3ea-5c"
tag: 1
Interface "qvo4f36c3ea-5c"
Bridge br-tun

Port patch-int
Interface patch-int
type: patch
options: {peer=patch-tun}
Port "gre-1"
Interface "gre-1"
type: gre
options: {in_key=flow, out_key=flow,
remote_ip="10.10.10.1"}

Port br-tun
Interface br-tun
type: internal
ovs_version: "1.4.0+build0"
root@os-compute-01:/var/log/quantum#


I supposed it should be getting address via DHCP from
quantum-dhcp-agent on the network node?  It was running, nothing
regarding this MAC in the logs.  I restarted quantum-dhcp-agent
and rebooted, no change.

In fact, I got two CirrOS vms up, logged on the console and
manually IPed them (10.5.5.10/24  and
10.5.5.11/24 ), and they can't ping each
other.  I would expect them to, right?  They should both be
connected to OVS switch br-int, right?

Any pointers?



___
Mailing list:https://launchpad.net/~openstack  

Post to :openstack@lists.launchpad.net

Re: [Openstack] OpenStack login page

Hi Syed,

Yes, I am able to fire up dashboard on IP ( which in my case is 127.0.0.1)
specified at OPENSTACK_HOST in local_settings.py.
But the dashboard login page is not allowing me to login with 'admin' user
and password provided in script or keystonerc file.

Thank you,

On Tue, Mar 5, 2013 at 6:02 PM, Syed Armani  wrote:

>
> These are just deprecation warnings. Could you please elaborate what you
> mean by not able to login to dashboard page. Are you able to fire up
> dashboard on the ip address specified at OPENSTACK_HOST in
> local_settings.py ?
>
> Cheers,
> Syed Armani
>
>
> On Tuesday 05 March 2013 05:54 PM, Ashutosh Narayan wrote:
> > Hi folks,
> >
> > I am following this link
> > to
> > setup OpenStack but am
> > unable to login to OpenStack dashboard page.
> >
> > Below are few Django error messages which i get
> >
> > [Tue Mar 05 22:59:28 2013] [error]
> > /usr/lib/python2.6/site-packages/django/conf/__init__.py:75:
> > DeprecationWarning: The ADMIN_MEDIA_PREFIX setting has been removed; use
> > STATIC_URL instead.
> > [Tue Mar 05 22:59:28 2013] [error]   "use STATIC_URL instead.",
> > DeprecationWarning)
> > [Tue Mar 05 22:59:28 2013] [error]
> > /usr/lib/python2.6/site-packages/django/conf/__init__.py:110:
> > DeprecationWarning: The SECRET_KEY setting must not be empty.
> > [Tue Mar 05 22:59:28 2013] [error]   warnings.warn("The SECRET_KEY
> > setting must not be empty.", DeprecationWarning)
> > [Tue Mar 05 22:59:28 2013] [error]
> > /usr/lib/python2.6/site-packages/django/core/cache/__init__.py:82:
> > DeprecationWarning: settings.CACHE_* is deprecated; use settings.CACHES
> > instead.
> > [Tue Mar 05 22:59:28 2013] [error]   DeprecationWarning
> > [Tue Mar 05 22:59:28 2013] [error]
> >
> /usr/lib/python2.6/site-packages/django/utils/translation/__init__.py:63:
> DeprecationWarning:
> > Translations in the project directory aren't supported anymore. Use the
> > LOCALE_PATHS setting instead.
> > [Tue Mar 05 22:59:28 2013] [error]   DeprecationWarning)
> > [Tue Mar 05 22:59:28 2013] [error]
> > /usr/lib/python2.6/site-packages/django/contrib/auth/__init__.py:26:
> > DeprecationWarning: Authentication backends without a
> > `supports_inactive_user` attribute are deprecated. Please define it in
> > .
> > [Tue Mar 05 22:59:28 2013] [error]   DeprecationWarning)
> > [Tue Mar 05 22:59:28 2013] [error]
> > /usr/lib/python2.6/site-packages/django/template/defaulttags.py:1235:
> > DeprecationWarning: The syntax for the url template tag is changing.
> > Load the `url` tag from the `future` tag library to start using the new
> > behavior.
> > [Tue Mar 05 22:59:28 2013] [error]   category=DeprecationWarning)
> >
> > The installation happened with the help ofscript
> > <
> https://github.com/fedora-openstack/openstack-utils/blob/master/utils/openstack-demo-install
> >.
> > There were no errors when I executed the script.
> > Relevant services were also running fine.
> >
> > Is the issue because of Django version embedded in script ?
> >
> > Support appreciated.
> >
> > Thank you,
> > --
> > Ashutosh Narayan
> >
> > http://ashutoshn.wordpress.com/
> >
> >
> >
> > ___
> > Mailing list: https://launchpad.net/~openstack
> > Post to : openstack@lists.launchpad.net
> > Unsubscribe : https://launchpad.net/~openstack
> > More help   : https://help.launchpad.net/ListHelp
> >
>
>


-- 
Ashutosh Narayan

http://ashutoshn.wordpress.com/
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Rebooted, now can't ping my guest

2013-03-05 Thread Filipe Manco

Ok

I'm using the script (I'm calling it from rc.local) and everything works
fine, even for instances that already exist.

Thanks


2013/3/5 Sylvain Bauza 

>  This is up to your responsability to hit the script, afaik.
> I haven't deployed the bugfix, I preferred creating my own script called
> by rc.local by convenience (and also because I found the issue and
> mitigated it before talking to the forum)
>
> Once I'll migrate to 2012.2.3, I'll use this .py instead.
>
> -Sylvain
>
> Le 05/03/2013 13:23, Filipe Manco a écrit :
>
>  I read the bug description (
> https://bugs.launchpad.net/quantum/+bug/1091605) and the fix (
> https://review.openstack.org/#/c/18302/). But I don't understand who is
> the responsible to call the script on the startup.
>
>  Should I put it on something like rc.local? Or is quantum plugins'
> responsibility to run the utility?
>
>
> 2013/3/1 Sylvain Bauza 
>
>>  There is a known bug for the network bridges, when rebooting :
>> https://bugs.launchpad.net/quantum/+bug/1091605
>>
>> Try to delete/recreate your br-int/br-ex and then restart
>> openvswitch_plugin/l3/dhcp agents, it should fix the issue.
>>
>> -Sylvain
>>
>> Le 01/03/2013 15:04, The King in Yellow a écrit :
>>
>>   In my case, it actually appears that my vms aren't up-- the instances
>> panel says they are up, but looking at the console, it appears they aren't
>> getting an IP address.  This is a new instance:
>>
>> Begin: Running /scripts/init-bottom ... done.
>> [2.849416] EXT4-fs (vda1): re-mounted. Opts: (null)
>> cloud-init start-local running: Thu, 28 Feb 2013 13:29:09 +. up 10.41 
>> seconds
>>
>> no instance data found in start-local
>>
>> cloud-init-nonet waiting 120 seconds for a network device.
>>
>> cloud-init-nonet gave up waiting for a network device.
>>
>> ci-info: lo: 1 127.0.0.1   255.0.0.0   .
>>
>> ci-info: eth0  : 1 .   .   fa:16:3e:e0:17:f0
>>
>> route_info failed
>>
>> Waiting for network configuration...
>>
>> It looks like it made an OVS port, though.  This is on the compute node,
>> openvswitch-agent.log:
>>
>>
>> 2013-02-28 08:34:19DEBUG [quantum.agent.linux.utils]
>> Command: ['sudo', '/usr/bin/quantum-rootwrap',
>> '/etc/quantum/rootwrap.conf', 'ovs-vsctl', '--timeout=2', 'get',
>> 'Interface', 'qvo4f36c3ea-5c', 'external_ids']
>> Exit code: 0
>> Stdout: '{attached-mac="fa:16:3e:e0:17:f0",
>> iface-id="4f36c3ea-5c49-4625-a830-0c81f27ba139", iface-status=active,
>> vm-uuid="239d3051-255e-4213-9511-af0a82fcc744"}\n'
>> Stderr: ''
>> 2013-02-28 08:34:19DEBUG [quantum.agent.linux.utils] Running command:
>> sudo /usr/bin/quantum-rootwrap /etc/quantum/rootwrap.conf ovs-vsctl
>> --timeout=2 get Interface qvo62721ee8-08 external_ids
>> 2013-02-28 08:34:19DEBUG [quantum.agent.linux.utils]
>> :
>> root@os-compute-01:/var/log/quantum# ovs-vsctl show
>> 3a52a17f-9846-4b32-b309-b49faf91bfc4
>> Bridge br-int
>> Port "qvo62721ee8-08"
>> tag: 1
>> Interface "qvo62721ee8-08"
>> Port "qvo1ed73bcc-9d"
>> tag: 1
>> Interface "qvo1ed73bcc-9d"
>> Port "qvoce0c94a9-ef"
>> tag: 1
>> Interface "qvoce0c94a9-ef"
>> Port "qvo135e78dd-8e"
>> tag: 4095
>> Interface "qvo135e78dd-8e"
>> Port "qvof37b7a55-a3"
>> tag: 1
>> Interface "qvof37b7a55-a3"
>>
>> Port br-int
>> Interface br-int
>> type: internal
>> Port patch-tun
>> Interface patch-tun
>> type: patch
>> options: {peer=patch-int}
>>  Port "qvoaed25b41-9c"
>> tag: 1
>> Interface "qvoaed25b41-9c"
>> Port "qvo4f36c3ea-5c"
>> tag: 1
>> Interface "qvo4f36c3ea-5c"
>> Bridge br-tun
>>
>> Port patch-int
>> Interface patch-int
>> type: patch
>> options: {peer=patch-tun}
>>  Port "gre-1"
>> Interface "gre-1"
>> type: gre
>> options: {in_key=flow, out_key=flow,
>> remote_ip="10.10.10.1"}
>>
>> Port br-tun
>> Interface br-tun
>> type: internal
>> ovs_version: "1.4.0+build0"
>>  root@os-compute-01:/var/log/quantum#
>>
>>
>>  I supposed it should be getting address via DHCP from quantum-dhcp-agent
>> on the network node?  It was running, nothing regarding this MAC in the
>> logs.  I restarted quantum-dhcp-agent and rebooted, no change.
>>
>>  In fact, I got two CirrOS vms up, logged on the console and manually
>> IPed them (10.5.5.10/24 and 10.5.5.11/24), and they can't ping each
>> other.  I would expect them to, right?  They should both be connected to
>> OVS switch br-int, right?
>>
>> Any pointers?
>>
>>
>>
>>   ___
>> Mailing list: https://launchpad.net/~openstack
>> Post to : openstack@lists.launchpad.net
>> Unsubscri

Re: [Openstack] Rebooted, now can't ping my guest

You get it. This is the bug I mentioned related to compute nodes. Folks, 
anyone knowing the bug tracking numbre, btw ?


'ovs-dpctl show' shows you that only qvo7dcd14b3-70 is bridged to br-int 
(and mapped to vnet4, which I guess is the vnet device for the correct VM).


Could you please try :
sudo ovs-vsctl add-port br-int qvo0b459c65-a0
sudo ovs-vsctl add-port br-int qvo4f36c3ea-5c
sudo ovs-vsctl add-port br-int qvo62721ee8-08
sudo ovs-vsctl add-port br-int qvocf833d2a-9e
sudo service quantum-plugin-openvswitch-agent restart

and check that your VMs get network back ?

-Sylvain



Le 04/03/2013 15:26, The King in Yellow a écrit :
On Mon, Mar 4, 2013 at 3:18 AM, Sylvain Bauza 
mailto:sylvain.ba...@digimind.com>> wrote:


Is the network node also acting as a Compute node ?


No, I am running three separate nodes-- network, compute and controller.

The issue you were mentioning was related to the tap virtual
device (for DHCP leases) : if the network node goes down, then the
DHCP lease is expiring on the vm without being reack, and then
your instance is loosing its IP address.
By recreating the bridges upon reboot on the network node, the tap
interface will be back up. On the VMs, only a DHCP request is
enough, not a reboot (or even a compute node reboot).

I know there is also a second bug related to virtio bridges on the
compute nodes. This is still a bit unclear to me, but upon compute
node reboot, virtio bridges are also not reattached, only new
instances created afterwards.

Could you please run 'ovs-dpctl show br-int' (provided br-int is
the right bridge), 'ovs-vsctl show' and 'brctl show' ?


This is on the compute node, where I assume the issue is.  For the 
record, I have five vms running here-- four created before rebuilding 
the networking, and one after. Only the one after is working.


root@os-compute-01:/var/log# ovs-dpctl show br-int
system@br-int:
lookups: hit:235944 missed:33169 lost:0
flows: 0
port 0: br-int (internal)
port 1: patch-tun (patch: peer=patch-int)
port 2: qvo7dcd14b3-70
root@os-compute-01:/var/log# ovs-vsctl show
3a52a17f-9846-4b32-b309-b49faf91bfc4
Bridge br-tun
Port br-tun
Interface br-tun
type: internal
Port "gre-1"
Interface "gre-1"
type: gre
options: {in_key=flow, out_key=flow, 
remote_ip="10.10.10.1"}

Port patch-int
Interface patch-int
type: patch
options: {peer=patch-tun}
Bridge br-int
Port br-int
Interface br-int
type: internal
Port "qvo7dcd14b3-70"
tag: 1
Interface "qvo7dcd14b3-70"
Port patch-tun
Interface patch-tun
type: patch
options: {peer=patch-int}
ovs_version: "1.4.0+build0"
root@os-compute-01:/var/log# brctl show
bridge name bridge id   STP enabled interfaces
br-int  .222603554b47   no qvo7dcd14b3-70
br-tun  .36c126165e42   no
qbr0b459c65-a0  8000.3af05347af11 no  qvb0b459c65-a0
vnet2
qbr4f36c3ea-5c  8000.e6a5faf9a181 no  qvb4f36c3ea-5c
vnet1
qbr62721ee8-08  8000.8af675d45ed7 no  qvb62721ee8-08
vnet0
qbr7dcd14b3-70  8000.aabc605c1b2c no  qvb7dcd14b3-70
vnet4
qbrcf833d2a-9e  8000.36e77dfc6018 no  qvbcf833d2a-9e
vnet3
root@os-compute-01:/var/log#

Thank you for the assistance!  Lot of new stuff here I'm trying to 
come up to speed on.



Le 01/03/2013 21:28, The King in Yellow a écrit :

On Fri, Mar 1, 2013 at 10:11 AM, Sylvain Bauza
mailto:sylvain.ba...@digimind.com>>
wrote:

There is a known bug for the network bridges, when rebooting :
https://bugs.launchpad.net/quantum/+bug/1091605

Try to delete/recreate your br-int/br-ex and then restart
openvswitch_plugin/l3/dhcp agents, it should fix the issue.


Thanks!  Now, I can create a new instance, and that works.  My
previous instances don't work, however.  What do I need to do to
get them reattached?


root@os-network:/var/log/quantum# ping 10.5.5.6
PING 10.5.5.6 (10.5.5.6) 56(84) bytes of data.
^C
--- 10.5.5.6 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 1008ms

root@os-network:/var/log/quantum# ping 10.5.5.7
PING 10.5.5.7 (10.5.5.7) 56(84) bytes of data.
64 bytes from 10.5.5.7 : icmp_req=1 ttl=64
time=2.13 ms
64 bytes from 10.5.5.7 : icmp_req=2 ttl=64
time=1.69 ms
64 bytes from 10.5.5.7 : icmp_req=3 ttl=64
time=1.93 ms
64 bytes from 10.5.5.7 : icmp_req=4 ttl=64
time=1.01 ms
^C
--- 10.5.5.7 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3003ms

Re: [Openstack] Rebooted, now can't ping my guest


Le 05/03/2013 13:57, Filipe Manco a écrit :

Ok

I'm using the script (I'm calling it from rc.local) and everything 
works fine, even for instances that already exist.


Thanks



The bug is related to the "tap" device, ie. DHCP agent reboot.
The second bug I mentioned is related to a compute node reboot, where 
existing ovs ports to br-int are not recreated.


Different reboots, different issues ;-)

-Sylvain



___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] [OpenStack] Guest OS shows just one CPU core instead of two

I had Windows 8 64bit which shows just 1 Virtual Core and 1 Socket in the
task manager->Performance->CPU tab. I then tried Windows Server 2012 which
shows 2 sockets and 2 Virtual Cores for the same flavor. So it must be some
compatibility issue with KVM and certain versions of Windows.

Thanks for the response.

Regards,
Balu

On Tue, Mar 5, 2013 at 6:19 PM, Daniel P. Berrange wrote:

> On Tue, Mar 05, 2013 at 04:00:06PM +0530, Balamurugan V G wrote:
> > Hi,
> >
> > I am running Folsom 2.2 with a KVM compute node. When I launch a windows
> > instance with flavor that has 2 VCPUs and 2Gb RAM, the guest seems the
> RAM
> > fine but not the 2 CPUs. It reports only one Virtual processor. Whne I
> look
> > at the command line options with which KVM has launched the instance, I
> see
> > that in -smp argument, sockets is set to 2 and core is set to 1. How can
> I
> > get the core to be 2 so that the guest OS can see it?
>
> There's nothing wrong with what the command line set here. It is
> simply configuring 2 vCPUS where each vCPU is represented as a
> separate socket to the guest, rather than what you describe which
> would be 1 socket with dual-cores.
>
> You don't mention what Windows version you are using, but some versions
> are not clever enough to switch between a uniprocessor config and SMP
> config. So if you installed those versions on a 1 CPU guest, then even
> if you later boot the image on 1 CPU guest, it won't see the extra CPUs.
> There are hacks you can do to "upgrade" a windows install from the
> uniprocessor to multiprocessor HAL - see the microsoft kbase for more
> info
>
> Regards,
> Daniel
> --
> |: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/:|
> |: http://libvirt.org  -o- http://virt-manager.org:|
> |: http://autobuild.org   -o- http://search.cpan.org/~danberr/:|
> |: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc:|
>
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] [OpenStack] Guest OS shows just one CPU core instead of two

I initially did not have this setting in the nova.conf. I then read the
OpenStack docs and set it to as below and resstarted nova services and
re-created the instance but with same outcome.

libvirt_cpu_mode=host-passthrough

But I didnt have this issue with Windows Server 2012, it reported 2 virtal
CPUs correctly.

Regards,
Balu

On Tue, Mar 5, 2013 at 6:10 PM, Sylvain Bauza wrote:

>  Could you please tell us what is your libvirt_cpu_model ?
> Please check both nova.conf and instance's libvirt.xml.
>
> -Sylvain
>
> Le 05/03/2013 11:30, Balamurugan V G a écrit :
>
> Hi,
>
> I am running Folsom 2.2 with a KVM compute node. When I launch a windows
> instance with flavor that has 2 VCPUs and 2Gb RAM, the guest seems the RAM
> fine but not the 2 CPUs. It reports only one Virtual processor. Whne I look
> at the command line options with which KVM has launched the instance, I see
> that in -smp argument, sockets is set to 2 and core is set to 1. How can I
> get the core to be 2 so that the guest OS can see it?
>
>
> 107   7764 1 14 14:35 ?00:11:27 /usr/bin/kvm -name
> instance-000e -S -M pc-1.0 -cpu
> core2duo,+lahf_lm,+osxsave,+xsave,+sse4.1,+dca,+pdcm,+xtpr,+cx16,+tm2,+est,+vmx,+ds_cpl,+dtes64,+pbe,+tm,+ht,+ss,+acpi,+ds
> -enable-kvm -m 2048* -smp 2,sockets=2,cores=1,threads=1* -uuid
> cd6dd64c-d792-4b31-92bf-ed8ad1ea46cb -nodefconfig -nodefaults -chardev
> socket,id=charmonitor,path=/var/lib/libvirt/qemu/instance-000e.monitor,server,nowait
> -mon chardev=charmonitor,id=monitor,mode=control -rtc
> base=utc,driftfix=slew -no-kvm-pit-reinjection -no-shutdown -device
> piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive
> file=/var/lib/nova/instances/instance-000e/disk,if=none,id=drive-virtio-disk0,format=qcow2,cache=none
> -device
> virtio-blk-pci,scsi=off,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1
> -netdev tap,fd=24,id=hostnet0 -device
> virtio-net-pci,netdev=hostnet0,id=net0,mac=fa:16:3e:46:68:2e,bus=pci.0,addr=0x3
> -chardev
> file,id=charserial0,path=/var/lib/nova/instances/instance-000e/console.log
> -device isa-serial,chardev=charserial0,id=serial0 -chardev
> pty,id=charserial1 -device isa-serial,chardev=charserial1,id=serial1
> -device usb-tablet,id=input0 -vnc 0.0.0.0:3 -k en-us -vga cirrus -device
> virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5
> root@openstack-kvm1:~#
>
>
>
> Regards,
> Balu
>
>
>
>
>
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
>
>
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
>
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] [openstack-dev] [block migration] How to test kvm block migration feature?

2013-03-05 Thread John Garbutt

Just to clarify, I don't think those flags are need for the
XCP/XenServer block migration, it goes straight to the chosen SR on
the destination.

I would agree, there probably should be a block migration section under KVM too.

John

On 1 March 2013 10:24, Blair Bethwaite  wrote:
> On 1 March 2013 18:59, Qinglong.Meng  wrote:
>>
>>  I want to make testing about openstack(release F) block migration
>> based KVM. But I don't any usefully configure doc. it's only about based
>> XEN.
>> here is the org doc:
>>
>> http://docs.openstack.org/folsom/openstack-compute/admin/content/configuring-migrations.html
>
>
> I think the section headed "Block Migration" is incorrectly nested under
> "XenServer", or there should also be a "Block Migration" section under
> "KVM-Libvirt". Also missing are the nova flags you should have:
> block_migration_flag=VIR_MIGRATE_UNDEFINE_SOURCE, VIR_MIGRATE_PEER2PEER,
> VIR_MIGRATE_NON_SHARED_INC, VIR_MIGRATE_LIVE
> That, along with the other changes mentioned in the section (obviously
> excluding shared storage), should give you live block-migration.
>
> --
> Cheers,
> ~Blairo
>
> ___
> OpenStack-dev mailing list
> openstack-...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] How to create a Image which can extend the partition automatically.

2013-03-05 Thread Scott Moser

On Tue, 5 Mar 2013, Sylvain Bauza wrote:

> If you look at
> http://www.pixelbeat.org/docs/openstack_libvirt_images/#1361764412, you'll see
> that resize2fs is performed. But there is a caveat with RHEL6 which is Linux
> 2.6 (contrary to Ubuntu 12.04 which is Linux 3.0).
> If you look at "man resize2fs" :

Please don't do this, or rely on this.  Having the hypervisor do this for
your guest is simply wrong.  Hypervisors should know little to nothing
about the internals of the instances they're launching.

Please see this thread:
http://www.gossamer-threads.com/lists/openstack/dev/23572?do=post_view_threaded#23572

That describes how to do this the right way, and wont have the host OS
accidentally break your filesystem or lose your data because it didn't
realize you were running some filesystem it didn't have perfect support
for.

Other points:
 * I've just added the ability for growpart to run outside the
   initramfs and still function.  This same functionality is available in
   patched versions of parted also (resizepart), but not yet in upstream.
   https://code.launchpad.net/~psusi/ubuntu/raring/parted/resize/+merge/151401
 * Juerg added support for cloud-initramfs-utils to run in fedora/rhel and
   drakut
 * I'm adding support for cloud-init to do this rather than have it from
   cloud-initramfs-utils.  I suspect that in some point in the future, the
   requirements for "just works" will be:
* cloud-init 0.7.2
* (cloud-utils 0.27 | parted 3.2): after Philip Susi's work for
  'resizepart' lands.
* kernel > 3.8
 * for what currently works:
* cloud-initramfs-utils (0.20 or from trunk)
* cloud-init > 0.7 (cloud-init invokes resize2fs)

   You'll need cloud-utils 0.27 and sgdisk to get GPT resizing support.
   Dos partition format requires sfdisk (from util-linux).

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

[Openstack] Issues with nova x-509-

2013-03-05 Thread Razique Mahroua

Hi, I'm facing a issue with cloudpipe that is driving me crazy. My cloudpipe vpn keys used to work for a tenant, but for one another, (regular) it doesn't work.I basically create a certificate : $ nova x509-create-certWrote private key to pk.pemWrote x509 certificate to cert.pem$ nova x509-get-root-certWrote x509 root cert to cacert.pemnow if I verify both cert. and private key, they match  : $ openssl x509 -noout -modulus -in cert.pem | openssl md5(stdin)= 93259863d334911d55be20db96709e66$ openssl rsa -noout -modulus -in pk.key | openssl md5(stdin)= 93259863d334911d55be20db96709e66but if I want to verify the CA against the cert, then it doesn't match  :$ openssl verify -CAfile cacert.pem cert.pemcert.pem: C = US, ST = California, O = OpenStack, OU = NovaDev, CN = 9b1ed48626fa46b7-2c3d0e28ec564cbe-2013-03-05T13:49:04Zerror 7 at 0 depth lookup:certificate signature failure140284857550496:error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01:rsa_pk1.c:100:140284857550496:error:04067072:rsa routines:RSA_EAY_PUBLIC_DECRYPT:padding check failed:rsa_eay.c:721:140284857550496:error:0D0C5006:asn1 encoding routines:ASN1_item_verify:EVP lib:a_verify.c:221:Thus I obtain the following errors in openvpn : http://paste.openstack.org/show/32787/If I verify the CA against the certs located in /var/lib/nova/CA/projects/ it works : openssl verify -CAfile /var/lib/nova/CA/projects/$project-Id/cacert.pem  /var/lib/nova/CA/projects/$project-Id/newcerts/14.pem/var/lib/nova/CA/projects/9b1ed48626fa46b7b81f21ef21979069/newcerts/14.pem: OKand the md5 seems good as well :$ openssl x509 -noout -modulus -in /var/lib/nova/CA/projects/$project-id/newcerts/14.pem  | openssl md5But if I chose that certificate, I have the same errors...Is there any way to reset all the tenants CA, and clean a bit ?(the nova certificates tables references files that are missing (/var/lib/nova/CA/projects/9b1ed48626fa46b7b81f21ef21979069/newcerts/17.pem is an entry while the file doesn't exist)Best regards,RaziqueRazique Mahroua - Nuage & Corazique.mahr...@gmail.comTel : +33 9 72 37 94 15

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] [OpenStack] How to speed up the instance launch time?

Thanks for the responses and the link to pixelbeat. Its very helpful.

Start with QCOW, even before image is uploaded to Glance, dit help since
the image size camedown from 20Gb to 8+Gb. I even set the the
force_raw_images=False, and use_cow_images=True in nova.conf and restarted
nova services. I still see that the image is copied to _base and then
copied again to instances folder. This is probably expected and is the
caching feature. But under _base I see two files one with the underscore
suffix and one without. Does it mean that each time I launch an instance
with a diferent flavour(say disk set to 30Gb), another copy will be created
in _base?

root@openstack-kvm1:/var/lib/nova/instances# ls -l _base/ | grep
2b4a8e97317619077645de369a8f9fd63acd1f05
-rw-rw-r-- 1 nova nova  8691056640 Mar  5 19:23
2b4a8e97317619077645de369a8f9fd63acd1f05
-rw-rw-r-- 1 libvirt-qemu kvm   8691056640 Mar  5 19:23
2b4a8e97317619077645de369a8f9fd63acd1f05_20
root@openstack-kvm1:/var/lib/nova/instances#

Thanks for all the valuable suggestions. I'll explore the disk merging or
separate HDD options as well when possible.

Regards,
Balu




On Tue, Mar 5, 2013 at 6:09 PM, Sylvain Bauza wrote:

>  Another option is to merge both Glance and Nova datadirs on GlusterFS in
> distributed/replicated array.
> That way, all _base images and glance images are on the same "filesystem"
> but with distributed I/O.
>
> -Sylvain
>
>  Le 05/03/2013 13:10, Staicu Gabriel a écrit :
>
>  Hi,
>
> As a rule of thumb how I worked around this issue was to add a new hdd. I
> allocated this new hdd only to /var/lib/nova/instances/_base and the other
> hdd to /var/lib/nova/instances/ so in this manner to the first time a
> instance  is spawn on server the process use the full capacity of a hdd.
>
>  Regards,
> Gabriel
>
>
>--
> *From:* Pádraig Brady  
> *To:* Balamurugan V G  
> *Cc:* openstack@lists.launchpad.net
> *Sent:* Tuesday, March 5, 2013 1:20 PM
> *Subject:* Re: [Openstack] [OpenStack] How to speed up the instance
> launch time?
>
> On 03/05/2013 11:03 AM, Balamurugan V G wrote:
> > Hi,
> >
> > I have a Folsom 2012.2 3 nodes setup like the one specified at
> https://github.com/mseknibilel/OpenStack-Folsom-Install-guide/blob/master/OpenStack_Folsom_Install_Guide_WebVersion.rst.
> Each node has a 1Tb hard disk with no raid.
> >
> > Be it the image creation or the Instance creation, takes a long
> time(factor of the disk size of the image), about 15mins for a 20gb image.
> I can understand the slow image creation due to the http transfer of the
> file from a seperate web server hosting my images to the controller node.
> But even the instance creation takes that much or even a bit longer. I see
> that the image is copied from the Controller to Compute node and multiple
> copies are make in the compute node. So all this takes long an dis
> proportional to the image size. Is there any way to speed up this process?
> Is a SAN based backend the only way to go?
>
> It sounds like you're using raw images throughout?
> You might consider using qcow2 images in glance.
> Then you can avoid the conversion to raw in the libvirt base
> directory by setting force_raw_images=False in nova.conf
> That will avoid some of the initial caching penalty.
>
> Ensuring that you have use_cow_images=True set,
> with use CoW images for the instances and improve
> instance startup latency.
>
> Details of the operations and tradeoffs involved are at:
> http://www.pixelbeat.org/docs/openstack_libvirt_images/
>
> thanks,
> Pádraig.
>
>
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to: openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help  : https://help.launchpad.net/ListHelp
>
>
>
>
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
>
>
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
>
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

[Openstack] Fwd: Issues with nova x-509-

2013-03-05 Thread Razique Mahroua

Ok I finally resolved my issue, I have two instances of nova-cert running on my HA controllers, I created a new nova-cert primitive, restarted the cloudpipe instance, now the openvpn worksRegards,
Razique Mahroua - Nuage & Corazique.mahr...@gmail.comTel : +33 9 72 37 94 15

Début du message réexpédié :De : Razique Mahroua Objet : Issues with nova x-509-Date : 5 mars 2013 15:03:04 UTC+01:00À : "openstack@lists.launchpad.net OpenStack" Hi, I'm facing a issue with cloudpipe that is driving me crazy. My cloudpipe vpn keys used to work for a tenant, but for one another, (regular) it doesn't work.I basically create a certificate : $ nova x509-create-certWrote private key to pk.pemWrote x509 certificate to cert.pem$ nova x509-get-root-certWrote x509 root cert to cacert.pemnow if I verify both cert. and private key, they match  : $ openssl x509 -noout -modulus -in cert.pem | openssl md5(stdin)= 93259863d334911d55be20db96709e66$ openssl rsa -noout -modulus -in pk.key | openssl md5(stdin)= 93259863d334911d55be20db96709e66but if I want to verify the CA against the cert, then it doesn't match  :$ openssl verify -CAfile cacert.pem cert.pemcert.pem: C = US, ST = California, O = OpenStack, OU = NovaDev, CN = 9b1ed48626fa46b7-2c3d0e28ec564cbe-2013-03-05T13:49:04Zerror 7 at 0 depth lookup:certificate signature failure140284857550496:error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01:rsa_pk1.c:100:140284857550496:error:04067072:rsa routines:RSA_EAY_PUBLIC_DECRYPT:padding check failed:rsa_eay.c:721:140284857550496:error:0D0C5006:asn1 encoding routines:ASN1_item_verify:EVP lib:a_verify.c:221:Thus I obtain the following errors in openvpn : http://paste.openstack.org/show/32787/If I verify the CA against the certs located in /var/lib/nova/CA/projects/ it works : openssl verify -CAfile /var/lib/nova/CA/projects/$project-Id/cacert.pem  /var/lib/nova/CA/projects/$project-Id/newcerts/14.pem/var/lib/nova/CA/projects/9b1ed48626fa46b7b81f21ef21979069/newcerts/14.pem: OKand the md5 seems good as well :$ openssl x509 -noout -modulus -in /var/lib/nova/CA/projects/$project-id/newcerts/14.pem  | openssl md5But if I chose that certificate, I have the same errors...Is there any way to reset all the tenants CA, and clean a bit ?(the nova certificates tables references files that are missing (/var/lib/nova/CA/projects/9b1ed48626fa46b7b81f21ef21979069/newcerts/17.pem is an entry while the file doesn't exist)Best regards,RaziqueRazique Mahroua - Nuage & Corazique.mahr...@gmail.comTel : +33 9 72 37 94 15

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] OpenStack login page

I am getting "Invalid username or password"
Here are the contents of ketstonerc file :

export OS_USERNAME=admin
export OS_PASSWORD=verybadpass
export OS_TENANT_NAME=admin
export OS_AUTH_URL=http://127.0.0.1:5000/v2.0/

Am I suppose to pass the same username / password ?

On Tue, Mar 5, 2013 at 6:26 PM, Ashutosh Narayan  wrote:

> Hi Syed,
>
> Yes, I am able to fire up dashboard on IP ( which in my case is 127.0.0.1)
> specified at OPENSTACK_HOST in local_settings.py.
> But the dashboard login page is not allowing me to login with 'admin' user
> and password provided in script or keystonerc file.
>
> Thank you,
>
> On Tue, Mar 5, 2013 at 6:02 PM, Syed Armani wrote:
>
>>
>> These are just deprecation warnings. Could you please elaborate what you
>> mean by not able to login to dashboard page. Are you able to fire up
>> dashboard on the ip address specified at OPENSTACK_HOST in
>> local_settings.py ?
>>
>> Cheers,
>> Syed Armani
>>
>>
>> On Tuesday 05 March 2013 05:54 PM, Ashutosh Narayan wrote:
>> > Hi folks,
>> >
>> > I am following this link
>> > to
>> > setup OpenStack but am
>> > unable to login to OpenStack dashboard page.
>> >
>> > Below are few Django error messages which i get
>> >
>> > [Tue Mar 05 22:59:28 2013] [error]
>> > /usr/lib/python2.6/site-packages/django/conf/__init__.py:75:
>> > DeprecationWarning: The ADMIN_MEDIA_PREFIX setting has been removed; use
>> > STATIC_URL instead.
>> > [Tue Mar 05 22:59:28 2013] [error]   "use STATIC_URL instead.",
>> > DeprecationWarning)
>> > [Tue Mar 05 22:59:28 2013] [error]
>> > /usr/lib/python2.6/site-packages/django/conf/__init__.py:110:
>> > DeprecationWarning: The SECRET_KEY setting must not be empty.
>> > [Tue Mar 05 22:59:28 2013] [error]   warnings.warn("The SECRET_KEY
>> > setting must not be empty.", DeprecationWarning)
>> > [Tue Mar 05 22:59:28 2013] [error]
>> > /usr/lib/python2.6/site-packages/django/core/cache/__init__.py:82:
>> > DeprecationWarning: settings.CACHE_* is deprecated; use settings.CACHES
>> > instead.
>> > [Tue Mar 05 22:59:28 2013] [error]   DeprecationWarning
>> > [Tue Mar 05 22:59:28 2013] [error]
>> >
>> /usr/lib/python2.6/site-packages/django/utils/translation/__init__.py:63:
>> DeprecationWarning:
>> > Translations in the project directory aren't supported anymore. Use the
>> > LOCALE_PATHS setting instead.
>> > [Tue Mar 05 22:59:28 2013] [error]   DeprecationWarning)
>> > [Tue Mar 05 22:59:28 2013] [error]
>> > /usr/lib/python2.6/site-packages/django/contrib/auth/__init__.py:26:
>> > DeprecationWarning: Authentication backends without a
>> > `supports_inactive_user` attribute are deprecated. Please define it in
>> > .
>> > [Tue Mar 05 22:59:28 2013] [error]   DeprecationWarning)
>> > [Tue Mar 05 22:59:28 2013] [error]
>> > /usr/lib/python2.6/site-packages/django/template/defaulttags.py:1235:
>> > DeprecationWarning: The syntax for the url template tag is changing.
>> > Load the `url` tag from the `future` tag library to start using the new
>> > behavior.
>> > [Tue Mar 05 22:59:28 2013] [error]   category=DeprecationWarning)
>> >
>> > The installation happened with the help ofscript
>> > <
>> https://github.com/fedora-openstack/openstack-utils/blob/master/utils/openstack-demo-install
>> >.
>> > There were no errors when I executed the script.
>> > Relevant services were also running fine.
>> >
>> > Is the issue because of Django version embedded in script ?
>> >
>> > Support appreciated.
>> >
>> > Thank you,
>> > --
>> > Ashutosh Narayan
>> >
>> > http://ashutoshn.wordpress.com/
>> >
>> >
>> >
>> > ___
>> > Mailing list: https://launchpad.net/~openstack
>> > Post to : openstack@lists.launchpad.net
>> > Unsubscribe : https://launchpad.net/~openstack
>> > More help   : https://help.launchpad.net/ListHelp
>> >
>>
>>
>
>
> --
> Ashutosh Narayan
>
> http://ashutoshn.wordpress.com/
>
>


-- 
Ashutosh Narayan

http://ashutoshn.wordpress.com/
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Rebooted, now can't ping my guest

2013-03-05 Thread The King in Yellow

That didn't quite do it.  Rebooted 10.5.5.5/6 and they did not get IPs.
Brought one up manually and could not ping anything else.  I note that I'm
missing the "tag" statement on those recreated interfaces in "ovs-vsctl
show", so I deleted the interfaces and reran the statements you gave with
"tag=1" appended.  Now, my manually configured 10.5.5.5 COULD ping my
working 10.5.5.7, and I could ssh between the two.  However, 10.5.5.5 still
can not get a DHCP address or (with hardcoded IP) reach 10.5.5.1 on the
network node, whereas 10.5.5.7 can.  Here's how things look now:

root@os-compute-01:~# ovs-dpctl show br-int
system@br-int:
lookups: hit:236399 missed:45742 lost:0
flows: 1
port 0: br-int (internal)
port 2: qvo7dcd14b3-70
port 9: qvo0b459c65-a0
port 10: qvo4f36c3ea-5c
port 11: qvo62721ee8-08
port 12: qvocf833d2a-9e
port 13: patch-tun (patch: peer=patch-int)
root@os-compute-01:~# ovs-vsctl show
3a52a17f-9846-4b32-b309-b49faf91bfc4
Bridge br-int
Port br-int
Interface br-int
type: internal
Port "qvo0b459c65-a0"
tag: 1
Interface "qvo0b459c65-a0"
Port "qvo62721ee8-08"
tag: 1
Interface "qvo62721ee8-08"
Port "qvo4f36c3ea-5c"
tag: 1
Interface "qvo4f36c3ea-5c"
Port "qvocf833d2a-9e"
tag: 1
Interface "qvocf833d2a-9e"
Port "qvo7dcd14b3-70"
tag: 1
Interface "qvo7dcd14b3-70"
Port patch-tun
Interface patch-tun
type: patch
options: {peer=patch-int}
Bridge br-tun
Port patch-int
Interface patch-int
type: patch
options: {peer=patch-tun}
Port br-tun
Interface br-tun
type: internal
Port "gre-1"
Interface "gre-1"
type: gre
options: {in_key=flow, out_key=flow, remote_ip="10.10.10.1"}
ovs_version: "1.4.0+build0"
root@os-compute-01:~# brctl show
bridge name bridge id   STP enabled interfaces
br-int  .222603554b47   no  qvo0b459c65-a0
qvo4f36c3ea-5c
qvo62721ee8-08
qvo7dcd14b3-70
qvocf833d2a-9e
br-tun  .3abeb87cdb47   no
qbr0b459c65-a0  8000.3af05347af11   no
qvb0b459c65-a0
vnet2
qbr4f36c3ea-5c  8000.e6a5faf9a181   no
qvb4f36c3ea-5c
vnet1
qbr62721ee8-08  8000.8af675d45ed7   no
qvb62721ee8-08
vnet0
qbr7dcd14b3-70  8000.aabc605c1b2c   no
qvb7dcd14b3-70
vnet4
qbrcf833d2a-9e  8000.36e77dfc6018   no
qvbcf833d2a-9e
vnet3
root@os-compute-01:~#


On Tue, Mar 5, 2013 at 8:02 AM, Sylvain Bauza wrote:

>  You get it. This is the bug I mentioned related to compute nodes. Folks,
> anyone knowing the bug tracking numbre, btw ?
>
> 'ovs-dpctl show' shows you that only qvo7dcd14b3-70 is bridged to br-int
> (and mapped to vnet4, which I guess is the vnet device for the correct VM).
>
> Could you please try :
> sudo ovs-vsctl add-port br-int qvo0b459c65-a0
> sudo ovs-vsctl add-port br-int qvo4f36c3ea-5c
> sudo ovs-vsctl add-port br-int qvo62721ee8-08
> sudo ovs-vsctl add-port br-int qvocf833d2a-9e
> sudo service quantum-plugin-openvswitch-agent restart
>
> and check that your VMs get network back ?
>
> -Sylvain
>
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Rebooted, now can't ping my guest

You should be close to the solution. Looking at your GRE tunnels, I only 
see a one-to-one tunnel in between your compute node and your network 
node (provided your netnode is 10.10.10.1). Could you please confirm 
that your controller is either on the compute node or on the network node ?


One could suggest to restart nova-compute and check.
Also, could you please tcpdump your network node on your management IP 
and check if you see GRE packets coming from your compute node (while 
pinging or trying to get a lease) ?


-Sylvain

Le 05/03/2013 15:56, The King in Yellow a écrit :
That didn't quite do it.  Rebooted 10.5.5.5/6  and 
they did not get IPs.  Brought one up manually and could not ping 
anything else.  I note that I'm missing the "tag" statement on those 
recreated interfaces in "ovs-vsctl show", so I deleted the interfaces 
and reran the statements you gave with "tag=1" appended.  Now, my 
manually configured 10.5.5.5 COULD ping my working 10.5.5.7, and I 
could ssh between the two.  However, 10.5.5.5 still can not get a DHCP 
address or (with hardcoded IP) reach 10.5.5.1 on the network node, 
whereas 10.5.5.7 can. Here's how things look now:


root@os-compute-01:~# ovs-dpctl show br-int
system@br-int:
lookups: hit:236399 missed:45742 lost:0
flows: 1
port 0: br-int (internal)
port 2: qvo7dcd14b3-70
port 9: qvo0b459c65-a0
port 10: qvo4f36c3ea-5c
port 11: qvo62721ee8-08
port 12: qvocf833d2a-9e
port 13: patch-tun (patch: peer=patch-int)
root@os-compute-01:~# ovs-vsctl show
3a52a17f-9846-4b32-b309-b49faf91bfc4
Bridge br-int
Port br-int
Interface br-int
type: internal
Port "qvo0b459c65-a0"
tag: 1
Interface "qvo0b459c65-a0"
Port "qvo62721ee8-08"
tag: 1
Interface "qvo62721ee8-08"
Port "qvo4f36c3ea-5c"
tag: 1
Interface "qvo4f36c3ea-5c"
Port "qvocf833d2a-9e"
tag: 1
Interface "qvocf833d2a-9e"
Port "qvo7dcd14b3-70"
tag: 1
Interface "qvo7dcd14b3-70"
Port patch-tun
Interface patch-tun
type: patch
options: {peer=patch-int}
Bridge br-tun
Port patch-int
Interface patch-int
type: patch
options: {peer=patch-tun}
Port br-tun
Interface br-tun
type: internal
Port "gre-1"
Interface "gre-1"
type: gre
options: {in_key=flow, out_key=flow, 
remote_ip="10.10.10.1"}

ovs_version: "1.4.0+build0"
root@os-compute-01:~# brctl show
bridge name bridge id   STP enabled interfaces
br-int  .222603554b47   no qvo0b459c65-a0
qvo4f36c3ea-5c
qvo62721ee8-08
qvo7dcd14b3-70
qvocf833d2a-9e
br-tun  .3abeb87cdb47   no
qbr0b459c65-a0  8000.3af05347af11 no  qvb0b459c65-a0
vnet2
qbr4f36c3ea-5c  8000.e6a5faf9a181 no  qvb4f36c3ea-5c
vnet1
qbr62721ee8-08  8000.8af675d45ed7 no  qvb62721ee8-08
vnet0
qbr7dcd14b3-70  8000.aabc605c1b2c no  qvb7dcd14b3-70
vnet4
qbrcf833d2a-9e  8000.36e77dfc6018 no  qvbcf833d2a-9e
vnet3
root@os-compute-01:~#


On Tue, Mar 5, 2013 at 8:02 AM, Sylvain Bauza 
mailto:sylvain.ba...@digimind.com>> wrote:


You get it. This is the bug I mentioned related to compute nodes.
Folks, anyone knowing the bug tracking numbre, btw ?

'ovs-dpctl show' shows you that only qvo7dcd14b3-70 is bridged to
br-int (and mapped to vnet4, which I guess is the vnet device for
the correct VM).

Could you please try :
sudo ovs-vsctl add-port br-int qvo0b459c65-a0
sudo ovs-vsctl add-port br-int qvo4f36c3ea-5c
sudo ovs-vsctl add-port br-int qvo62721ee8-08
sudo ovs-vsctl add-port br-int qvocf833d2a-9e
sudo service quantum-plugin-openvswitch-agent restart

and check that your VMs get network back ?

-Sylvain



___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Rebooted, now can't ping my guest

I forgot to mention, could you please also check that 
quantum-openvswitch-agent is started ('ps -ef' ) ?



Le 05/03/2013 17:19, Sylvain Bauza a écrit :
You should be close to the solution. Looking at your GRE tunnels, I 
only see a one-to-one tunnel in between your compute node and your 
network node (provided your netnode is 10.10.10.1). Could you please 
confirm that your controller is either on the compute node or on the 
network node ?


One could suggest to restart nova-compute and check.
Also, could you please tcpdump your network node on your management IP 
and check if you see GRE packets coming from your compute node (while 
pinging or trying to get a lease) ?


-Sylvain

Le 05/03/2013 15:56, The King in Yellow a écrit :
That didn't quite do it.  Rebooted 10.5.5.5/6  and 
they did not get IPs.  Brought one up manually and could not ping 
anything else.  I note that I'm missing the "tag" statement on those 
recreated interfaces in "ovs-vsctl show", so I deleted the interfaces 
and reran the statements you gave with "tag=1" appended.  Now, my 
manually configured 10.5.5.5 COULD ping my working 10.5.5.7, and I 
could ssh between the two.  However, 10.5.5.5 still can not get a 
DHCP address or (with hardcoded IP) reach 10.5.5.1 on the network 
node, whereas 10.5.5.7 can.  Here's how things look now:


root@os-compute-01:~# ovs-dpctl show br-int
system@br-int:
lookups: hit:236399 missed:45742 lost:0
flows: 1
port 0: br-int (internal)
port 2: qvo7dcd14b3-70
port 9: qvo0b459c65-a0
port 10: qvo4f36c3ea-5c
port 11: qvo62721ee8-08
port 12: qvocf833d2a-9e
port 13: patch-tun (patch: peer=patch-int)
root@os-compute-01:~# ovs-vsctl show
3a52a17f-9846-4b32-b309-b49faf91bfc4
Bridge br-int
Port br-int
Interface br-int
type: internal
Port "qvo0b459c65-a0"
tag: 1
Interface "qvo0b459c65-a0"
Port "qvo62721ee8-08"
tag: 1
Interface "qvo62721ee8-08"
Port "qvo4f36c3ea-5c"
tag: 1
Interface "qvo4f36c3ea-5c"
Port "qvocf833d2a-9e"
tag: 1
Interface "qvocf833d2a-9e"
Port "qvo7dcd14b3-70"
tag: 1
Interface "qvo7dcd14b3-70"
Port patch-tun
Interface patch-tun
type: patch
options: {peer=patch-int}
Bridge br-tun
Port patch-int
Interface patch-int
type: patch
options: {peer=patch-tun}
Port br-tun
Interface br-tun
type: internal
Port "gre-1"
Interface "gre-1"
type: gre
options: {in_key=flow, out_key=flow, 
remote_ip="10.10.10.1"}

ovs_version: "1.4.0+build0"
root@os-compute-01:~# brctl show
bridge name bridge id   STP enabled interfaces
br-int  .222603554b47   no qvo0b459c65-a0
qvo4f36c3ea-5c
qvo62721ee8-08
qvo7dcd14b3-70
qvocf833d2a-9e
br-tun  .3abeb87cdb47   no
qbr0b459c65-a0  8000.3af05347af11 no  qvb0b459c65-a0
vnet2
qbr4f36c3ea-5c  8000.e6a5faf9a181 no  qvb4f36c3ea-5c
vnet1
qbr62721ee8-08  8000.8af675d45ed7 no  qvb62721ee8-08
vnet0
qbr7dcd14b3-70  8000.aabc605c1b2c no  qvb7dcd14b3-70
vnet4
qbrcf833d2a-9e  8000.36e77dfc6018 no  qvbcf833d2a-9e
vnet3
root@os-compute-01:~#


On Tue, Mar 5, 2013 at 8:02 AM, Sylvain Bauza 
mailto:sylvain.ba...@digimind.com>> wrote:


You get it. This is the bug I mentioned related to compute nodes.
Folks, anyone knowing the bug tracking numbre, btw ?

'ovs-dpctl show' shows you that only qvo7dcd14b3-70 is bridged to
br-int (and mapped to vnet4, which I guess is the vnet device for
the correct VM).

Could you please try :
sudo ovs-vsctl add-port br-int qvo0b459c65-a0
sudo ovs-vsctl add-port br-int qvo4f36c3ea-5c
sudo ovs-vsctl add-port br-int qvo62721ee8-08
sudo ovs-vsctl add-port br-int qvocf833d2a-9e
sudo service quantum-plugin-openvswitch-agent restart

and check that your VMs get network back ?

-Sylvain





___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

[Openstack] keystone-manage db_sync failures

2013-03-05 Thread Wyllys Ingersoll

I keep getting a failure when trying to configure keystone.  keystone-manage 
seems to have issues with sqlalchemy.

Here are my versions:

python-keystoneclient: 1:0.1.3-0ubuntu1.1~cloud0
python-sqlalchemy:  0.7.8-1ubuntu1~cloud0
python-migrate:  0.7.2-1ubuntu1

Any ideas??

$ keystone-manage db_sync
Traceback (most recent call last):
  File "/usr/bin/keystone-manage", line 28, in 
cli.main(argv=sys.argv, config_files=config_files)
  File "/usr/lib/python2.7/dist-packages/keystone/cli.py", line 164, in main
return run(cmd, (args[:1] + args[2:]))
  File "/usr/lib/python2.7/dist-packages/keystone/cli.py", line 147, in run
return CMDS[cmd](argv=args).run()
  File "/usr/lib/python2.7/dist-packages/keystone/cli.py", line 35, in run
return self.main()
  File "/usr/lib/python2.7/dist-packages/keystone/cli.py", line 54, in main
driver = importutils.import_object(getattr(CONF, k).driver)
  File 
"/usr/lib/python2.7/dist-packages/keystone/openstack/common/importutils.py", 
line 40, in import_object
return import_class(import_str)(*args, **kwargs)
  File 
"/usr/lib/python2.7/dist-packages/keystone/openstack/common/importutils.py", 
line 30, in import_class
__import__(mod_str)
  File "/usr/lib/python2.7/dist-packages/keystone/identity/backends/sql.py", 
line 22, in 
from keystone.common.sql import migration
  File "/usr/lib/python2.7/dist-packages/keystone/common/sql/migration.py", 
line 23, in 
from migrate.versioning import api as versioning_api
  File "/usr/lib/python2.7/dist-packages/migrate/versioning/api.py", line 33, 
in 
from migrate.versioning import (repository, schema, version,
  File "/usr/lib/python2.7/dist-packages/migrate/versioning/schema.py", line 
10, in 
from sqlalchemy import exceptions as sa_exceptions
ImportError: cannot import name exceptions


___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] [OpenStack] How to speed up the instance launch time?

On 03/05/2013 02:07 PM, Balamurugan V G wrote:
> Thanks for the responses and the link to pixelbeat. Its very helpful.
> 
> Start with QCOW, even before image is uploaded to Glance, dit help since the 
> image size camedown from 20Gb to 8+Gb. I even set the the 
> force_raw_images=False, and use_cow_images=True in nova.conf and restarted 
> nova services. I still see that the image is copied to _base and then copied 
> again to instances folder. This is probably expected and is the caching 
> feature. But under _base I see two files one with the underscore suffix and 
> one without. Does it mean that each time I launch an instance with a diferent 
> flavour(say disk set to 30Gb), another copy will be created in _base?
> 
> root@openstack-kvm1:/var/lib/nova/instances# ls -l _base/ | grep 
> 2b4a8e97317619077645de369a8f9fd63acd1f05
> -rw-rw-r-- 1 nova nova  8691056640 Mar  5 19:23 
> 2b4a8e97317619077645de369a8f9fd63acd1f05
> -rw-rw-r-- 1 libvirt-qemu kvm   8691056640 Mar  5 19:23 
> 2b4a8e97317619077645de369a8f9fd63acd1f05_20

These files in base are only update once per source image / size combination.
I.E. if you have 100 instances booted from a 20G flavor,
you'll only have those 2 files cached on the first boot.
Note there is a blueprint in place for precaching those too:
https://blueprints.launchpad.net/nova/+spec/nova-image-cache-management-2

thanks,
Pádraig.

p.s. those _20 files will not be there for grizzly
as the caching was adjusted there.

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Poor guest disk IO after disk usage.

2013-03-05 Thread Miller, Mark M (EB SW Cloud - R&D - Corvallis)

On 03/04/2013 07:54 PM, Pádraig Brady wrote:
> On 03/04/2013 07:19 PM, Samuel Winchenbach wrote:
>> Hi All,
>>
>> I have a cluster of three nodes set up.  Live migration is accomplished via 
>> an NFS mount over 10GigE shared by all three nodes.
>>
>> I have noticed that when a VM is brand new I am getting close to 60MB/s disk 
>> write when using "dd if=/dev/zero of=file bs=1M count=1k conv=fdatasync". 
>> after doing this 10s of times the perfomance of the disk seems to drop  to 
>> around 4 - 12 MB/s.
>>
>> I have also noticed that doing a live-migration causes a similar effect 
>> immediately.
>>
>> Here is the virsh xml output of one of my VMs:  
>> https://gist.github.com/swinchen/397fbe3bb74305064944
>>
>> I have read several "tuning" guides and most of the suggestions seems to be 
>> configured already (cache='none', virtio for network, disk and memballoon).  
>>  
>>
>> Do you think qcow2 is causing my issue and if so is there a way to boot an 
>> instance and override the disk format?
> 
> qcow may possibly be the issue.
> 
> You could use raw disk images by setting the
> use_cow_images=False nova config option.
> The tradeoff there is slower instance start and
> increased (but more guaranteed) disk usage.
> 
> Alternatively you could try to fallocate the disk
> image before running the perf test like:
>   # get virt_size
>   qemu-img info /var/lib/nova/instances/instance-002f/disk
>   fallocate -n -l $virt_size /var/lib/nova/instances/instance-002f/disk
> 
> There is also the possibility of adjusting nova
> to use preallocation=metadata on the qcow images
> (forfeiting CoW in the process), as discussed in "future work" at:
> https://blueprints.launchpad.net/nova/+spec/preallocated-images

Just did some testing here, writing in a VM backed by a local file system, 
using:
  dd if=/dev/zero of=file bs=1M count=1k conv=notrunc,fdatasync oflag=append

I didn't see a degredation after a while, but did see
quite different performance depending on the formats used:

disk performance outside VM = 120MB/s
raw in $instance_dir/ = 105MB/s
qcow copy with preallocation=metadata in $instance_dir/ = 100MB/s
qcow CoW with fallocate full size in $instance_dir/ = 55MB/s
  Note perf a bit more stable than without fallocate
  I didn't test with full host disk where improvements would be more noticeable
qcow CoW in $instance_dir/ = 52MB/s
qcow CoW in $instance_dir/ backed by qcow with preallocation=metadata in base = 
52MB/s

thanks,
Pádraig.

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Rebooted, now can't ping my guest

2013-03-05 Thread The King in Yellow

On Tue, Mar 5, 2013 at 11:19 AM, Sylvain Bauza
wrote:

>  You should be close to the solution. Looking at your GRE tunnels, I only
> see a one-to-one tunnel in between your compute node and your network node
> (provided your netnode is 10.10.10.1). Could you please confirm that your
> controller is either on the compute node or on the network node ?
>

My network node is 10.10.10.1.  My controller is an independent node, and
not on the 10.10.10.x network (following this
architecturealthough
I have changed the external subnets).


> One could suggest to restart nova-compute and check.
>

I tried, and it did nothing.

I think something else might be going on...I do seem to be getting the
correct ARP entries for 10.5.5.5 on my network node:

root@os-network:/var/log/quantum# arp -an
? (10.5.5.4) at  on tap45ffdc5f-da
? (10.5.5.3) at  on tap45ffdc5f-da
? (10.10.10.2) at 00:50:56:81:25:73 [ether] on eth1
? (192.168.0.1) at 00:50:56:81:48:02 [ether] on eth0
? (10.5.5.7) at fa:16:3e:06:17:3c [ether] on tap45ffdc5f-da
? (10.5.5.5) at fa:16:3e:8d:2c:f9 [ether] on qr-9f9041ce-65
? (10.5.5.5) at fa:16:3e:8d:2c:f9 [ether] on tap45ffdc5f-da
? (10.42.38.1) at 00:07:b4:01:b5:01 [ether] on eth3
root@os-network:/var/log/quantum# arp -i qr-9f9041ce-65 -d 10.5.5.5
root@os-network:/var/log/quantum# arp -i tap45ffdc5f-da -d 10.5.5.5
root@os-network:/var/log/quantum# arp -an
? (10.5.5.4) at  on tap45ffdc5f-da
? (10.5.5.3) at  on tap45ffdc5f-da
? (10.10.10.2) at 00:50:56:81:25:73 [ether] on eth1
? (192.168.0.1) at 00:50:56:81:48:02 [ether] on eth0
? (10.5.5.7) at fa:16:3e:06:17:3c [ether] on tap45ffdc5f-da
? (10.5.5.5) at fa:16:3e:8d:2c:f9 [ether] on tap45ffdc5f-da
? (10.42.38.1) at 00:07:b4:01:b5:01 [ether] on eth3
root@os-network:/var/log/quantum# arp -an
? (10.5.5.4) at  on tap45ffdc5f-da
? (10.5.5.3) at  on tap45ffdc5f-da
? (10.10.10.2) at 00:50:56:81:25:73 [ether] on eth1
? (192.168.0.1) at 00:50:56:81:48:02 [ether] on eth0
? (10.5.5.7) at fa:16:3e:06:17:3c [ether] on tap45ffdc5f-da
? (10.5.5.5) at fa:16:3e:8d:2c:f9 [ether] on qr-9f9041ce-65
? (10.5.5.5) at fa:16:3e:8d:2c:f9 [ether] on tap45ffdc5f-da
? (10.42.38.1) at 00:07:b4:01:b5:01 [ether] on eth3
root@os-network:/var/log/quantum#

I'm not clear on what the interfaces are, but q-9f9041ce-65 is 10.5.5.1 on
the network node, so he seems to be seeing the traffic.  tap45ffdc5f-da is
listed as 10.5.5.2, and I have no idea what function that is performing.

root@os-network:/var/log/quantum# ping 10.5.5.7
PING 10.5.5.7 (10.5.5.7) 56(84) bytes of data.
64 bytes from 10.5.5.7: icmp_req=1 ttl=64 time=1.93 ms
64 bytes from 10.5.5.7: icmp_req=2 ttl=64 time=2.08 ms
^C
--- 10.5.5.7 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 1.931/2.007/2.083/0.076 ms
root@os-network:/var/log/quantum# arp -an
? (10.5.5.4) at fa:16:3e:e0:17:f0 [ether] on tap45ffdc5f-da
? (10.5.5.3) at  on tap45ffdc5f-da
? (10.10.10.2) at 00:50:56:81:25:73 [ether] on eth1
? (192.168.0.1) at 00:50:56:81:48:02 [ether] on eth0
? (10.5.5.7) at fa:16:3e:06:17:3c [ether] on tap45ffdc5f-da
? (10.5.5.5) at fa:16:3e:8d:2c:f9 [ether] on tap45ffdc5f-da
? (10.42.38.1) at 00:07:b4:01:b5:01 [ether] on eth3
root@os-network:/var/log/quantum# ping 10.5.5.5
PING 10.5.5.5 (10.5.5.5) 56(84) bytes of data.
^C
--- 10.5.5.5 ping statistics ---
9 packets transmitted, 0 received, 100% packet loss, time 8062ms

root@os-network:/var/log/quantum#


> Also, could you please tcpdump your network node on your management IP and
> check if you see GRE packets coming from your compute node (while pinging
> or trying to get a lease) ?
>

Threw a sniff up at http://pastebin.com/giwZysxW.  There were 4 pings from
10.5.5.7 (starting line 47), followed by 4 pings from 10.5.5.5.
Interesting to see the 10.5.5.3 and .4 references...I don't have passwords
for those images (sshed in with the keys), so I rebooted them while
sniffing here: http://pastebin.com/xpbgnhxu  The network node ARP table
never populated with .3 or .4, either.

It looks like quantum-openvswitch-agent is started:

root@os-compute-01:~# ps -ef | egrep quantum | egrep -v grep
quantum  11504 1  1 09:27 ?00:01:44 python
/usr/bin/quantum-openvswitch-agent --config-file=/etc/quantum/quantum.conf
--config-file=/etc/quantum/plugins/openvswitch/ovs_quantum_plugin.ini
--log-file=/var/log/quantum/openvswitch-agent.log
root@os-compute-01:~#
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

[Openstack] error -- yum install openstack-quantum-openvswitch

2013-03-05 Thread Aru s

Hi,

I am getting the below error while trying to install antuenstack quantum.
Please help.
I am using RHEL6.3 (64bit), with EPEL
http://download.fedoraproject.org/pub/epel/6/i386/epel-release-6-8.noarch.rpm

# yum install openstack-quantum-openvswitch
Loaded plugins: product-id, security, subscription-manager
Updating certificate-based repositories.
Unable to read consumer identity
Setting up Install Process
Resolving Dependencies
--> Running transaction check
---> Package openstack-quantum-openvswitch.noarch 0:2012.2.1-1.el6 will be
installed
--> Processing Dependency: openvswitch for package:
openstack-quantum-openvswitch-2012.2.1-1.el6.noarch
--> Finished Dependency Resolution
Error: Package: openstack-quantum-openvswitch-2012.2.1-1.el6.noarch (epel)
   Requires: openvswitch
 You could try using --skip-broken to work around the problem
 You could try running: rpm -Va --nofiles --nodigest
[root@os-ctrl openvswitch]#
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] keystone-manage db_sync failures

Try adding the config file name to the command line:

> keystone-manage --config-file /etc/keystone/keystone.conf db_sync

Mark

-Original Message-
From: openstack-bounces+mark.m.miller=hp@lists.launchpad.net 
[mailto:openstack-bounces+mark.m.miller=hp@lists.launchpad.net] On Behalf 
Of Wyllys Ingersoll
Sent: Tuesday, March 05, 2013 8:27 AM
To: openstack@lists.launchpad.net
Subject: [Openstack] keystone-manage db_sync failures

I keep getting a failure when trying to configure keystone.  keystone-manage 
seems to have issues with sqlalchemy.

Here are my versions:

python-keystoneclient: 1:0.1.3-0ubuntu1.1~cloud0
python-sqlalchemy:  0.7.8-1ubuntu1~cloud0
python-migrate:  0.7.2-1ubuntu1

Any ideas??

$ keystone-manage db_sync
Traceback (most recent call last):
  File "/usr/bin/keystone-manage", line 28, in 
cli.main(argv=sys.argv, config_files=config_files)
  File "/usr/lib/python2.7/dist-packages/keystone/cli.py", line 164, in main
return run(cmd, (args[:1] + args[2:]))
  File "/usr/lib/python2.7/dist-packages/keystone/cli.py", line 147, in run
return CMDS[cmd](argv=args).run()
  File "/usr/lib/python2.7/dist-packages/keystone/cli.py", line 35, in run
return self.main()
  File "/usr/lib/python2.7/dist-packages/keystone/cli.py", line 54, in main
driver = importutils.import_object(getattr(CONF, k).driver)
  File 
"/usr/lib/python2.7/dist-packages/keystone/openstack/common/importutils.py", 
line 40, in import_object
return import_class(import_str)(*args, **kwargs)
  File 
"/usr/lib/python2.7/dist-packages/keystone/openstack/common/importutils.py", 
line 30, in import_class
__import__(mod_str)
  File "/usr/lib/python2.7/dist-packages/keystone/identity/backends/sql.py", 
line 22, in 
from keystone.common.sql import migration
  File "/usr/lib/python2.7/dist-packages/keystone/common/sql/migration.py", 
line 23, in 
from migrate.versioning import api as versioning_api
  File "/usr/lib/python2.7/dist-packages/migrate/versioning/api.py", line 33, 
in 
from migrate.versioning import (repository, schema, version,
  File "/usr/lib/python2.7/dist-packages/migrate/versioning/schema.py", line 
10, in 
from sqlalchemy import exceptions as sa_exceptions
ImportError: cannot import name exceptions


___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] keystone help! keystone stop/waiting

2013-03-05 Thread Koert van der Veer

Check /var/log/keystone or /var/log/syslog (depending on what you
configured) for any error messages. If the daemon start failed early,
you may find some hints at /var/crash/.

On 02/04/2013 11:32 AM, Mballo Cherif wrote:
>
> Hi every body!
>
> I need help for keystone service.
>
> when I try to run keystone with 'service keystone start', I get this:
>
> $ sudo service keystone start
> keystone start/running, process 15335
> $ sudo service keystone status
> keystone stop/waiting
>
> How can I fix this?
>
> Thanks you for your help.
>
>  
>
> Sherif.
>
>  
>
>
>
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp



signature.asc
Description: OpenPGP digital signature
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] keystone help! keystone stop/waiting

On Mar 5, 2013, at 12:32 PM, Koert van der Veer  quoted 
Mballo Cherif:

>> $ sudo service keystone start
>> keystone start/running, process 15335
>> $ sudo service keystone status
>> keystone stop/waiting
>> 
>> How can I fix this?

I'm having a similar problem with a grizzly front-end that I'm trying to get 
running.  Turning up the logging detail with debug and verbose in 
/etc/keystone/keystone.conf, I can see that ssl is turned off but signing is 
turned on.  Here's slices from /var/log/keystone/keystone.log:

> 2013-03-05 12:20:16DEBUG [keystone-all] ssl.ca_certs   = 
> None
> 2013-03-05 12:20:16DEBUG [keystone-all] ssl.cert_required  = 
> False
> 2013-03-05 12:20:16DEBUG [keystone-all] ssl.certfile   = 
> None
> 2013-03-05 12:20:16DEBUG [keystone-all] ssl.enable = 
> False
> 2013-03-05 12:20:16DEBUG [keystone-all] ssl.keyfile= 
> None
> 
>   [ ... deletia ... ]
> 
> 2013-03-05 12:20:16DEBUG [keystone-all] signing.ca_certs   = 
> /etc/keystone/ssl/certs/ca.pem
> 2013-03-05 12:20:16DEBUG [keystone-all] signing.ca_password= 
> None
> 2013-03-05 12:20:16DEBUG [keystone-all] signing.certfile   = 
> /etc/keystone/ssl/certs/signing_cert.pem
> 2013-03-05 12:20:16DEBUG [keystone-all] signing.key_size   = 
> 1024
> 2013-03-05 12:20:16DEBUG [keystone-all] signing.keyfile= 
> /etc/keystone/ssl/private/signing_key.pem
> 2013-03-05 12:20:16DEBUG [keystone-all] signing.token_format   = 
> PKI
> 2013-03-05 12:20:16DEBUG [keystone-all] signing.valid_days = 
> 3650


In contrast, here are the corresponding sections from 
/etc/keystone/keystone.conf:

> [ssl]
> #enable = True
> #certfile = /etc/keystone/ssl/certs/keystone.pem
> #keyfile = /etc/keystone/ssl/private/keystonekey.pem
> #ca_certs = /etc/keystone/ssl/certs/ca.pem
> #cert_required = True
> 
> [signing]
> #token_format = PKI
> #certfile = /etc/keystone/ssl/certs/signing_cert.pem
> #keyfile = /etc/keystone/ssl/private/signing_key.pem
> #ca_certs = /etc/keystone/ssl/certs/ca.pem
> #key_size = 1024
> #valid_days = 3650
> #ca_password = None

So, it looks to me like both ssl and signing are commented out (and turned off) 
in /etc/keystone/keystone.conf, but the log file is telling me that signing is 
actually turned on.

I'm sure you can imagine the problems that result from having signing turned 
on, but no /etc/keystone/ssl directory, much less anything under that hierarchy.

So, have I missed something obvious?  Is there any other debugging info that I 
can provide that would be useful?

--
Brad Knowles 
Senior Consultant


___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

[Openstack] Fwd: Rebooted, now can't ping my guest

2013-03-05 Thread The King in Yellow

Sorry, replied directly:

-- Forwarded message --
From: The King in Yellow 
Date: Tue, Mar 5, 2013 at 12:56 PM
Subject: Re: [Openstack] Rebooted, now can't ping my guest
To: Sylvain Bauza 


In fact, when I ping 10.5.5.2, tcpdump on the network node actually shows
responses...

root@os-network:/var/log/quantum# tcpdump -i tap45ffdc5f-da host 10.5.5.5
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tap45ffdc5f-da, link-type EN10MB (Ethernet), capture size
65535 bytes
:
12:50:12.936292 ARP, Request who-has os-network.local tell 10.5.5.5, length
28
12:50:12.936329 ARP, Reply os-network.local is-at fa:16:3e:36:2e:54 (oui
Unknown), length 28
12:50:14.936338 ARP, Request who-has os-network.local tell 10.5.5.5, length
28
12:50:14.936378 ARP, Reply os-network.local is-at fa:16:3e:36:2e:54 (oui
Unknown), length 28
12:50:15.936299 ARP, Request who-has os-network.local tell 10.5.5.5, length
28
12:50:15.936343 ARP, Reply os-network.local is-at fa:16:3e:36:2e:54 (oui
Unknown), length 28
12:50:16.936008 ARP, Request who-has os-network.local tell 10.5.5.5, length
28
12:50:16.936045 ARP, Reply os-network.local is-at fa:16:3e:36:2e:54 (oui
Unknown), length 28

above, pinging 10.5.5.1 ; below, pinging 10.5.5.2

12:50:17.044161 IP 10.5.5.5 > os-network.local: ICMP echo request, id
18433, seq 0, length 64
12:50:17.044222 IP os-network.local > 10.5.5.5: ICMP echo reply, id 18433,
seq 0, length 64
12:50:18.044399 IP 10.5.5.5 > os-network.local: ICMP echo request, id
18433, seq 1, length 64
12:50:18.044455 IP os-network.local > 10.5.5.5: ICMP echo reply, id 18433,
seq 1, length 64
12:50:19.044847 IP 10.5.5.5 > os-network.local: ICMP echo request, id
18433, seq 2, length 64
12:50:19.044899 IP os-network.local > 10.5.5.5: ICMP echo reply, id 18433,
seq 2, length 64
12:50:20.045370 IP 10.5.5.5 > os-network.local: ICMP echo request, id
18433, seq 3, length 64
12:50:20.045427 IP os-network.local > 10.5.5.5: ICMP echo reply, id 18433,
seq 3


Unfortunately, the CirrOS image 10.5.5.5 is using doesn't seem to have the
arp utility, nor does 'ip -n' work.  I guess it isn't getting the ARP
replies for 10.5.5.1, and somehow got an ARP entry for 10.5.5.2 and isn't
seeing the echo replies.  Seems to imply some sort of issue from the
network node back to him?

Found ARP entries via "cat /proc/1/net/arp," which seems to confirm that--
entry for 10.5.5.1 is 00:00:00:00:00:00.
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] keystone help! keystone stop/waiting

2013-03-05 Thread Miller, Mark M (EB SW Cloud - R&D - Corvallis)

On Mar 5, 2013, at 12:44 PM, Brad Knowles  wrote:

> So, have I missed something obvious?  Is there any other debugging info that 
> I can provide that would be useful?

Well, now I at least have a different problem.  I'm getting a crash, which 
seems to be related to the problem shown at 
.  From the file 
/var/crash/_usr_bin_keystone-all.107.crash:

> ProblemType: Crash
> Date: Tue Mar  5 12:20:14 2013
> ExecutablePath: /usr/bin/keystone-all
> ExecutableTimestamp: 1361901666
> InterpreterPath: /usr/bin/python2.7
> ProcCmdline: /usr/bin/python /usr/bin/keystone-all
> ProcCwd: /var/lib/keystone
> ProcEnviron:
>  PATH=(custom, no user)
>  TERM=linux
> ProcMaps:
>  0040-00671000 r-xp  fd:01 16072  
> /usr/bin/python2.7
>  0087-00871000 r--p 0027 fd:01 16072  
> /usr/bin/python2.7
>  00871000-008da000 rw-p 00271000 fd:01 16072  
> /usr/bin/python2.7
>  008da000-008ec000 rw-p  00:00 0 
>  00f56000-01b2f000 rw-p  00:00 0  
> [heap]
>  7f7005aa7000-7f7005b89000 r-xp  fd:01 566
> /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.16
>  7f7005b89000-7f7005d88000 ---p 000e2000 fd:01 566
> /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.16
>  7f7005d88000-7f7005d9 r--p 000e1000 fd:01 566
> /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.16
> 
>   [ ... deletia ... ]
> 
> PythonArgs: ['/usr/bin/keystone-all']
> Traceback:
>  Traceback (most recent call last):
>File "/usr/bin/keystone-all", line 109, in 
>  options = deploy.appconfig('config:%s' % paste_config)
>File "/usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py", line 
> 261, in appconfig
>  global_conf=global_conf)
>File "/usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py", line 
> 296, in loadcontext
>  global_conf=global_conf)
>File "/usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py", line 
> 320, in _loadconfig
>  return loader.get_context(object_type, name, global_conf)
>File "/usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py", line 
> 413, in get_context
>  defaults = self.parser.defaults()
>File "/usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py", line 68, 
> in defaults
>  defaults[key] = self.get('DEFAULT', key) or val
>File "/usr/lib/python2.7/ConfigParser.py", line 623, in get
>  return self._interpolate(section, option, value, d)
>File "/usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py", line 75, 
> in _interpolate
>  self, section, option, rawval, vars)
>File "/usr/lib/python2.7/ConfigParser.py", line 666, in _interpolate
>  value = value % vars
>  TypeError: Error in file /etc/keystone/keystone.conf: %d format: a number is 
> required, not str


I just wish it would tell me which *LINE* in /etc/keystone/keystone.conf was 
causing problems

--
Brad Knowles 
Senior Consultant


___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] keystone help! keystone stop/waiting

Brad,

The following to turn off SSL and PKI.

Mark

-

[ssl]
enable = False
#certfile = /etc/keystone/ssl/certs/keystone.pem
#keyfile = /etc/keystone/ssl/private/keystonekey.pem
#ca_certs = /etc/keystone/ssl/certs/ca.pem
#cert_required = True

[signing]
token_format = UUID
#token_format = PKI
#certfile = /etc/keystone/ssl/certs/signing_cert.pem
#keyfile = /etc/keystone/ssl/private/signing_key.pem
#ca_certs = /etc/keystone/ssl/certs/ca.pem
#key_size = 1024
#valid_days = 3650
#ca_password = None



-Original Message-
From: openstack-bounces+mark.m.miller=hp@lists.launchpad.net 
[mailto:openstack-bounces+mark.m.miller=hp@lists.launchpad.net] On Behalf 
Of Brad Knowles
Sent: Tuesday, March 05, 2013 10:45 AM
To: Koert van der Veer
Cc: 
Subject: Re: [Openstack] keystone help! keystone stop/waiting

On Mar 5, 2013, at 12:32 PM, Koert van der Veer  quoted 
Mballo Cherif:

>> $ sudo service keystone start
>> keystone start/running, process 15335
>> $ sudo service keystone status
>> keystone stop/waiting
>> 
>> How can I fix this?

I'm having a similar problem with a grizzly front-end that I'm trying to get 
running.  Turning up the logging detail with debug and verbose in 
/etc/keystone/keystone.conf, I can see that ssl is turned off but signing is 
turned on.  Here's slices from /var/log/keystone/keystone.log:

> 2013-03-05 12:20:16DEBUG [keystone-all] ssl.ca_certs   = 
> None
> 2013-03-05 12:20:16DEBUG [keystone-all] ssl.cert_required  = 
> False
> 2013-03-05 12:20:16DEBUG [keystone-all] ssl.certfile   = 
> None
> 2013-03-05 12:20:16DEBUG [keystone-all] ssl.enable = 
> False
> 2013-03-05 12:20:16DEBUG [keystone-all] ssl.keyfile= 
> None
> 
>   [ ... deletia ... ]
> 
> 2013-03-05 12:20:16DEBUG [keystone-all] signing.ca_certs   = 
> /etc/keystone/ssl/certs/ca.pem
> 2013-03-05 12:20:16DEBUG [keystone-all] signing.ca_password= 
> None
> 2013-03-05 12:20:16DEBUG [keystone-all] signing.certfile   = 
> /etc/keystone/ssl/certs/signing_cert.pem
> 2013-03-05 12:20:16DEBUG [keystone-all] signing.key_size   = 
> 1024
> 2013-03-05 12:20:16DEBUG [keystone-all] signing.keyfile= 
> /etc/keystone/ssl/private/signing_key.pem
> 2013-03-05 12:20:16DEBUG [keystone-all] signing.token_format   = 
> PKI
> 2013-03-05 12:20:16DEBUG [keystone-all] signing.valid_days = 
> 3650


In contrast, here are the corresponding sections from 
/etc/keystone/keystone.conf:

> [ssl]
> #enable = True
> #certfile = /etc/keystone/ssl/certs/keystone.pem
> #keyfile = /etc/keystone/ssl/private/keystonekey.pem
> #ca_certs = /etc/keystone/ssl/certs/ca.pem
> #cert_required = True
> 
> [signing]
> #token_format = PKI
> #certfile = /etc/keystone/ssl/certs/signing_cert.pem
> #keyfile = /etc/keystone/ssl/private/signing_key.pem
> #ca_certs = /etc/keystone/ssl/certs/ca.pem
> #key_size = 1024
> #valid_days = 3650
> #ca_password = None

So, it looks to me like both ssl and signing are commented out (and turned off) 
in /etc/keystone/keystone.conf, but the log file is telling me that signing is 
actually turned on.

I'm sure you can imagine the problems that result from having signing turned 
on, but no /etc/keystone/ssl directory, much less anything under that hierarchy.

So, have I missed something obvious?  Is there any other debugging info that I 
can provide that would be useful?

--
Brad Knowles 
Senior Consultant


___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] keystone help! keystone stop/waiting

2013-03-05 Thread Miller, Mark M (EB SW Cloud - R&D - Corvallis)

On Mar 5, 2013, at 2:47 PM, "Miller, Mark M (EB SW Cloud - R&D - Corvallis)" 

 wrote:

> The following to turn off SSL and PKI.

Did that, but unfortunately it has no effect on the crash.  The crash isn't 
being reported anymore in /var/crash/_usr_bin_keystone-all.107.crash, but I'm 
now finding exactly the same crash reported in /var/log/upstart/keystone.log:

> TypeError: Error in file /etc/keystone/keystone.conf: %d format: a number is 
> required, not str
> Traceback (most recent call last):
>   File "/usr/bin/keystone-all", line 109, in 
> options = deploy.appconfig('config:%s' % paste_config)
>   File "/usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py", line 261, 
> in appconfig
> global_conf=global_conf)
>   File "/usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py", line 296, 
> in loadcontext
> global_conf=global_conf)
>   File "/usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py", line 320, 
> in _loadconfig
> return loader.get_context(object_type, name, global_conf)
>   File "/usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py", line 413, 
> in get_context
> defaults = self.parser.defaults()
>   File "/usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py", line 68, 
> in defaults
> defaults[key] = self.get('DEFAULT', key) or val
>   File "/usr/lib/python2.7/ConfigParser.py", line 623, in get
> return self._interpolate(section, option, value, d)
>   File "/usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py", line 75, 
> in _interpolate
> self, section, option, rawval, vars)
>   File "/usr/lib/python2.7/ConfigParser.py", line 666, in _interpolate
> value = value % vars
> TypeError: Error in file /etc/keystone/keystone.conf: %d format: a number is 
> required, not str

Blargh.  I do wish it would tell me *WHERE* in the file the error is occurring, 
and not just the filename.  Blech.

Thanks for your help so far!

--
Brad Knowles 
Senior Consultant


___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Possible keystone/common/controller.py Token Bug

2013-03-05 Thread Christopher Armstrong

So I've filed a bug on launchpad[1] about the issue discussed in the 
thread[2] with this subject (sorry, I subscribed after the message went 
out, so this message isn't properly threaded).


Is it really legit? The discussion stopped abruptly. It seems like a 
pretty major bug; I can't do much with the API right now because of it 
(I think).


[1] https://bugs.launchpad.net/keystone/+bug/1145541

[2] https://lists.launchpad.net/openstack/msg21458.html

-radix

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] keystone help! keystone stop/waiting

You aren't alone. I am just glad for this email group to ask questions. Now 
change the "d/" to "s/" in the following lines in keystone.conf.

# The base endpoint URLs for keystone that are advertised to clients
# (NOTE: this does NOT affect how keystone listens for connections)
public_endpoint = http://localhost:%(public_port)s/
admin_endpoint = http://localhost:%(admin_port)s/

Mark

-Original Message-
From: Brad Knowles [mailto:bknow...@momentumsi.com] 
Sent: Tuesday, March 05, 2013 1:15 PM
To: Miller, Mark M (EB SW Cloud - R&D - Corvallis)
Cc: Brad Knowles; Koert van der Veer; 
Subject: Re: [Openstack] keystone help! keystone stop/waiting

On Mar 5, 2013, at 2:47 PM, "Miller, Mark M (EB SW Cloud - R&D - Corvallis)" 

 wrote:

> The following to turn off SSL and PKI.

Did that, but unfortunately it has no effect on the crash.  The crash isn't 
being reported anymore in /var/crash/_usr_bin_keystone-all.107.crash, but I'm 
now finding exactly the same crash reported in /var/log/upstart/keystone.log:

> TypeError: Error in file /etc/keystone/keystone.conf: %d format: a number is 
> required, not str
> Traceback (most recent call last):
>   File "/usr/bin/keystone-all", line 109, in 
> options = deploy.appconfig('config:%s' % paste_config)
>   File "/usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py", line 261, 
> in appconfig
> global_conf=global_conf)
>   File "/usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py", line 296, 
> in loadcontext
> global_conf=global_conf)
>   File "/usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py", line 320, 
> in _loadconfig
> return loader.get_context(object_type, name, global_conf)
>   File "/usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py", line 413, 
> in get_context
> defaults = self.parser.defaults()
>   File "/usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py", line 68, 
> in defaults
> defaults[key] = self.get('DEFAULT', key) or val
>   File "/usr/lib/python2.7/ConfigParser.py", line 623, in get
> return self._interpolate(section, option, value, d)
>   File "/usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py", line 75, 
> in _interpolate
> self, section, option, rawval, vars)
>   File "/usr/lib/python2.7/ConfigParser.py", line 666, in _interpolate
> value = value % vars
> TypeError: Error in file /etc/keystone/keystone.conf: %d format: a number is 
> required, not str

Blargh.  I do wish it would tell me *WHERE* in the file the error is occurring, 
and not just the filename.  Blech.

Thanks for your help so far!

--
Brad Knowles 
Senior Consultant


___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Possible keystone/common/controller.py Token Bug

2013-03-05 Thread Miller, Mark M (EB SW Cloud - R&D - Corvallis)

To run my backwards compatibility tests, I had to change file controller.py as 
follows:

#   token_data = token_ref['token_data']
token_data = token_ref

Unfortunately I don't know if this broke Keystone in some other way. So far it 
doesn't appear to have caused other problems.

Mark

-Original Message-
From: openstack-bounces+mark.m.miller=hp@lists.launchpad.net 
[mailto:openstack-bounces+mark.m.miller=hp@lists.launchpad.net] On Behalf 
Of Christopher Armstrong
Sent: Tuesday, March 05, 2013 1:18 PM
To: openstack@lists.launchpad.net
Subject: Re: [Openstack] Possible keystone/common/controller.py Token Bug

So I've filed a bug on launchpad[1] about the issue discussed in the 
thread[2] with this subject (sorry, I subscribed after the message went 
out, so this message isn't properly threaded).

Is it really legit? The discussion stopped abruptly. It seems like a 
pretty major bug; I can't do much with the API right now because of it 
(I think).

[1] https://bugs.launchpad.net/keystone/+bug/1145541

[2] https://lists.launchpad.net/openstack/msg21458.html

-radix

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] keystone help! keystone stop/waiting

On Mar 5, 2013, at 3:21 PM, "Miller, Mark M (EB SW Cloud - R&D - Corvallis)" 

 wrote:

> You aren't alone. I am just glad for this email group to ask questions.

Me too!

> Now change the "d/" to "s/" in the following lines in keystone.conf.
> 
> # The base endpoint URLs for keystone that are advertised to clients
> # (NOTE: this does NOT affect how keystone listens for connections)
> public_endpoint = http://localhost:%(public_port)s/
> admin_endpoint = http://localhost:%(admin_port)s/

Yup, that fixed the crash.  I guess now I get to contribute this change back to 
the project.

That, and debugging the next issue.  ;-)

--
Brad Knowles 
Senior Consultant


___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

[Openstack] Horizon PTL Candidacy

2013-03-05 Thread Gabriel Hurley

Hi folks!

I'm nominating myself for Horizon PTL for another term. I want to continue 
fighting for cross-service integration/standardization, better APIs for 
everyone, and the best possible user interface to introduce people to what 
OpenStack can do.

Quick recap of my qualifications: current Horizon PTL, Horizon core and 
Keystone core since Essex, Django core contributor, commits to nearly all of 
the core OpenStack projects, extremely comprehensive knowledge of OpenStack's 
APIs, and a connoisseur of both OpenStack and fine whiskeys.

Here's to a fantastic Havana release cycle!

- Gabriel


___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Horizon PTL Candidacy

2013-03-05 Thread Joshua McKenty

I'd like to nominate your alter-ego of "Terrance Dope" to this list of
qualifications, and endorse your whiskey expertise.

On Tue, Mar 5, 2013 at 1:55 PM, Gabriel Hurley wrote:

> Hi folks!
>
> I'm nominating myself for Horizon PTL for another term. I want to continue
> fighting for cross-service integration/standardization, better APIs for
> everyone, and the best possible user interface to introduce people to what
> OpenStack can do.
>
> Quick recap of my qualifications: current Horizon PTL, Horizon core and
> Keystone core since Essex, Django core contributor, commits to nearly all
> of the core OpenStack projects, extremely comprehensive knowledge of
> OpenStack's APIs, and a connoisseur of both OpenStack and fine whiskeys.
>
> Here's to a fantastic Havana release cycle!
>
> - Gabriel
>
>
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>

-- 
--
Joshua McKenty, CTO
Piston Cloud Computing, Inc.
w: (650) 24-CLOUD
m: (650) 283-6846
http://www.pistoncloud.com

"Oh, Westley, we'll never survive!"
"Nonsense. You're only saying that because no one ever has."
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

[Openstack] OpenStack Operations Guide

2013-03-05 Thread Lorin Hochstein

Hi folks:

Anne Gentle somehow managed to corral together a group of operators who
have deployed OpenStack into production and were willing to write about it.
They were locked together in a room last week and produced a book from
scratch about how to design and operate an OpenStack cloud. It is now
available at http://docs.openstack.org/ops

The license is Creative Commons (cc by), PDF, ePub and mobi formats available
for free download from the site above, with a link to purchase option if
you want the dead tree version. Any money from sales goes back to The
OpenSack Foundation, who paid travel costs for most of the authors' travel.

Like all of the content at docs.openstack.org, this is a living document
and we'd love to have more people's help and input. Details on contributing
are, of course, in the book.

We all really enjoyed the process of creating this book, and hope the
community finds this a useful resource.


Take care,

Lorin
-- 
Lorin Hochstein
Lead Architect - Cloud Services
Nimbis Services, Inc.
www.nimbisservices.com
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] keystone help! keystone stop/waiting

2013-03-05 Thread Dolph Mathews

Just opened a bug to track the public_port string vs integer issue, with a
fix in review:

  https://bugs.launchpad.net/bugs/1147842


-Dolph


On Tue, Mar 5, 2013 at 3:28 PM, Brad Knowles wrote:

> On Mar 5, 2013, at 3:21 PM, "Miller, Mark M (EB SW Cloud - R&D -
> Corvallis)" 
>  wrote:
>
> > You aren't alone. I am just glad for this email group to ask questions.
>
> Me too!
>
> > Now change the "d/" to "s/" in the following lines in keystone.conf.
> >
> > # The base endpoint URLs for keystone that are advertised to clients
> > # (NOTE: this does NOT affect how keystone listens for connections)
> > public_endpoint = http://localhost:%(public_port)s/
> > admin_endpoint = http://localhost:%(admin_port)s/
>
> Yup, that fixed the crash.  I guess now I get to contribute this change
> back to the project.
>
> That, and debugging the next issue.  ;-)
>
> --
> Brad Knowles 
> Senior Consultant
>
>
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] keystone help! keystone stop/waiting

On Mar 5, 2013, at 4:27 PM, Dolph Mathews  wrote:

> Just opened a bug to track the public_port string vs integer issue, with a 
> fix in review:
> 
>   https://bugs.launchpad.net/bugs/1147842

Cool!  Thanks!

--
Brad Knowles 
Senior Consultant


___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

[Openstack] Fun with OpenStack Grizzly install...

Folks,

So, now that keystone appears to be configured correctly and working, the next 
chapter in the saga is glance.

>From the research I've done, the problem seems similar to the one reported at 
>.  Witness:

> $ glance index
> ID   Name   Disk 
> Format  Container Format Size  
>  -- 
>   --
> Request returned failure status.
> HTTPNotFound (HTTP 404)

However, I've confirmed that the keystone user-list, service-list, tenant-list, 
and endpoint-list appear to be configured as would be expected.  Witness (with 
minor edits for security reasons, but making sure not to touch any ids):

> user@host$ keystone user-list
> +--+-+-+--+
> |id|   name  | enabled |  email   |
> +--+-+-+--+
> | 0c09c86321554c058729d4daddb1e355 |  admin  |   True  | u...@example.com |
> | 712e45d9e7944e5fa1cbd7aae3e04cbf |  cinder |   True  | u...@example.com |
> | 7c198919a566475da50619ad11847ee6 |  glance |   True  | u...@example.com |
> | b9d056823c834ca798ba6c7c2d073532 |   nova  |   True  | u...@example.com |
> | e09b7bc3fb8e47ff9b9ffda43d2292d6 | quantum |   True  | u...@example.com |
> | 9b3b4a5e6a41492d86791ceb301cbbd3 |  swift  |   True  | u...@example.com |
> +--+-+-+--+
> user@host$ keystone service-list
> +--+--+--+--+
> |id|   name   | type | 
> description  |
> +--+--+--+--+
> | e70d3f18459341df91c8946818d2774e |  cinder  |volume|Cinder 
> Service|
> | e57e65226e0d4119910446f709c81a0d |   ec2| ec2  | EC2 
> Service  |
> | 87b5286177e24f668ed9c84669e180db |  glance  |image |   OpenStack 
> Image Service|
> | df6add034f8143ddae7ac8232376d11d | keystone |   identity   |  OpenStack 
> Identity Service  |
> | 37ef9a23d24e4362ade2ad01a0592559 |   nova   |   compute|  OpenStack 
> Compute Service   |
> | 25c2b27481484e46892cd5053a96233d | quantum  |   network| OpenStack 
> Networking service |
> | 978affd06a3b4838962efaccae78b755 |  swift   | object-store |  OpenStack 
> Storage Service   |
> | fda1c38ab66843feafc97aa7b68253a4 |  volume  |volume|   OpenStack 
> Volume Service   |
> +--+--+--+--+
> user@host$ keystone tenant-list
> +--+-+-+
> |id|   name  | enabled |
> +--+-+-+
> | 4317c06847a343b9b0c547ad3b87b8ee |  admin  |   True  |
> | 9090795328d044268472abbc5a77b09e | service |   True  |
> +--+-+-+
> user@host$ keystone endpoint-list
> +--+---+---+---+---+--+
> |id|   region  |publicurl 
>  |   internalurl |
>  adminurl  |service_id|
> +--+---+---+---+---+--+
> | 0c7b0bf374ad4e4685daf0cd1600d127 | RegionOne | 
> http://host.example.com:8776/v2/%(tenant_id)s | 
> http://host.example.com:8776/v2/%(tenant_id)s | 
> http://host.example.com:8776/v2/%(tenant_id)s | 
> fda1c38ab66843feafc97aa7b68253a4 |
> | 0db3fceef82547c1bd67ce128d37ea22 | RegionOne | 
> http://host.example.com:5000/v2/%(tenant_id)s | 
> http://host.example.com:5000/v2/%(tenant_id)s | 
> http://host.example.com:5000/v2/%(tenant_id)s | 
> df6add034f8143ddae7ac8232376d11d |
> | 5268bc10fffe47c9b306252f47463360 | RegionOne | 
> http://host.example.com:9292/v2/%(tenant_id)s | 
> http://host.example.com:9292/v2/%(tenant_id)s | 
> http://host.example.com:9292/v2/%(tenant_id)s | 
> 87b5286177e24f668ed9c84669e180db |
> | 74cd0593965d4fcdb5d12c938f6a035f | RegionOne | 
> http://host.example.com:8773/v2/%(tenant_id)s | 
> http://host.example.com:8773/v2/%(tenant_id)s | 
> http://host.example.com:8773/v2/%(tenant_id)s | 
> e57e65226e0d4119910446f709c81a0d |
> | 79ae8318d8254e6f886f7b97acf05230 | Reg

Re: [Openstack] Fun with OpenStack Grizzly install...

2013-03-05 Thread Matt Joyce

check in horizon and see if you can follow inside of a stack trace there.
you can see if any of the context's from the wsgi queries is seeing a 404.

these would be queries between glance and other backend APIs.

example:

you ---  query >  glance

glance sees you token...

glance --- query -> keystone

if that query from glance to keystone fails...  it will report a 404.  BUT
that won't necessarily show up in logs as you'd expect since it's a backend
query.




related idea:

verify that your catalog service is pointing to the right API endpoints on
keystone.

-Matt

On Tue, Mar 5, 2013 at 3:14 PM, Brad Knowles wrote:

> Folks,
>
> So, now that keystone appears to be configured correctly and working, the
> next chapter in the saga is glance.
>
> >From the research I've done, the problem seems similar to the one
> reported at .
>  Witness:
>
> > $ glance index
> > ID   Name   Disk
> Format  Container Format Size
> >  --
>   --
> > Request returned failure status.
> > HTTPNotFound (HTTP 404)
>
> However, I've confirmed that the keystone user-list, service-list,
> tenant-list, and endpoint-list appear to be configured as would be
> expected.  Witness (with minor edits for security reasons, but making sure
> not to touch any ids):
>
> > user@host$ keystone user-list
> >
> +--+-+-+--+
> > |id|   name  | enabled |  email
>   |
> >
> +--+-+-+--+
> > | 0c09c86321554c058729d4daddb1e355 |  admin  |   True  |
> u...@example.com |
> > | 712e45d9e7944e5fa1cbd7aae3e04cbf |  cinder |   True  |
> u...@example.com |
> > | 7c198919a566475da50619ad11847ee6 |  glance |   True  |
> u...@example.com |
> > | b9d056823c834ca798ba6c7c2d073532 |   nova  |   True  |
> u...@example.com |
> > | e09b7bc3fb8e47ff9b9ffda43d2292d6 | quantum |   True  |
> u...@example.com |
> > | 9b3b4a5e6a41492d86791ceb301cbbd3 |  swift  |   True  |
> u...@example.com |
> >
> +--+-+-+--+
> > user@host$ keystone service-list
> >
> +--+--+--+--+
> > |id|   name   | type |
> description  |
> >
> +--+--+--+--+
> > | e70d3f18459341df91c8946818d2774e |  cinder  |volume|
>  Cinder Service|
> > | e57e65226e0d4119910446f709c81a0d |   ec2| ec2  |
> EC2 Service  |
> > | 87b5286177e24f668ed9c84669e180db |  glance  |image |
> OpenStack Image Service|
> > | df6add034f8143ddae7ac8232376d11d | keystone |   identity   |
>  OpenStack Identity Service  |
> > | 37ef9a23d24e4362ade2ad01a0592559 |   nova   |   compute|
>  OpenStack Compute Service   |
> > | 25c2b27481484e46892cd5053a96233d | quantum  |   network| OpenStack
> Networking service |
> > | 978affd06a3b4838962efaccae78b755 |  swift   | object-store |
>  OpenStack Storage Service   |
> > | fda1c38ab66843feafc97aa7b68253a4 |  volume  |volume|
> OpenStack Volume Service   |
> >
> +--+--+--+--+
> > user@host$ keystone tenant-list
> > +--+-+-+
> > |id|   name  | enabled |
> > +--+-+-+
> > | 4317c06847a343b9b0c547ad3b87b8ee |  admin  |   True  |
> > | 9090795328d044268472abbc5a77b09e | service |   True  |
> > +--+-+-+
> > user@host$ keystone endpoint-list
> >
> +--+---+---+---+---+--+
> > |id|   region  |publicurl
>|   internalurl |
>   adminurl  |service_id
>|
> >
> +--+---+---+---+---+--+
> > | 0c7b0bf374ad4e4685daf0cd1600d127 | RegionOne |
> http://host.example.com:8776/v2/%(tenant_id)s |
> http://host.example.com:8776/v2/%(tenant_id)s |
> http://host.example.com:8776/v2/%(tenant_id)s |
> fda1c38ab66843feafc97aa7b68253a4 |
> > | 0db3fceef82547c1bd67ce128d37ea22 | RegionOne |
> http://h

Re: [Openstack] Fun with OpenStack Grizzly install...

On Mar 5, 2013, at 5:20 PM, Matt Joyce  wrote:

> check in horizon and see if you can follow inside of a stack trace there.  
> you can see if any of the context's from the wsgi queries is seeing a 404.

Horizon?  That's not a service I've heard of before.  I'm basically following 
the structure at 

 for initial installation, and I've gotten hung on the glance part at 
.

> these would be queries between glance and other backend APIs.  
> 
> example:
> 
> you ---  query >  glance
> 
> glance sees you token... 
> 
> glance --- query -> keystone
> 
> if that query from glance to keystone fails...  it will report a 404.  BUT 
> that won't necessarily show up in logs as you'd expect since it's a backend 
> query.

The query from glance to keystone appears to be okay -- I'm seeing 200 status 
responses in the keystone.log.

> related idea:
> 
> verify that your catalog service is pointing to the right API endpoints on 
> keystone.

Catalog service?  That's another name that I have not heard of before, at least 
not in the context of OpenStack.

--
Brad Knowles 
Senior Consultant

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Fun with OpenStack Grizzly install...

2013-03-05 Thread Dolph Mathews

On Tue, Mar 5, 2013 at 5:28 PM, Brad Knowles wrote:

> On Mar 5, 2013, at 5:20 PM, Matt Joyce 
> wrote:
>
> > check in horizon and see if you can follow inside of a stack trace
> there.  you can see if any of the context's from the wsgi queries is seeing
> a 404.
>
> Horizon?  That's not a service I've heard of before.  I'm basically
> following the structure at <
> http://docs.openstack.org/trunk/openstack-compute/install/apt/content/ap_installinggrizzlyubuntuprecise.html>
> for initial installation, and I've gotten hung on the glance part at <
> http://docs.openstack.org/trunk/openstack-compute/install/apt/content/osfolubuntu-imageservice.html
> >.
>
> > these would be queries between glance and other backend APIs.
> >
> > example:
> >
> > you ---  query >  glance
> >
> > glance sees you token...
> >
> > glance --- query -> keystone
> >
> > if that query from glance to keystone fails...  it will report a 404.
>  BUT that won't necessarily show up in logs as you'd expect since it's a
> backend query.
>
> The query from glance to keystone appears to be okay -- I'm seeing 200
> status responses in the keystone.log.
>
> > related idea:
> >
> > verify that your catalog service is pointing to the right API endpoints
> on keystone.
>
> Catalog service?  That's another name that I have not heard of before, at
> least not in the context of OpenStack.
>

The "service catalog" refers to a subset of keystone's interface that
provides a catalog of services and endpoints to authenticated API users.
It's the computed result of your service-list and endpoint-list and it's
how those users find all the other OpenStack services, like nova and glance.

In your case, all or most of your endpoints are wrong (they all contain
/v2/ which I'm not sure is correct for any service?), so `glance index`
probably can't find glance at all. I generally refer to keystone's
sample_data.sh script for a generally idea of what the endpoints should
look like:

  https://github.com/openstack/keystone/blob/master/tools/sample_data.sh


> --
> Brad Knowles 
> Senior Consultant
>
>
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Fun with OpenStack Grizzly install...

2013-03-05 Thread Anne Gentle

Hi Brad,
It's nearly always "the configuration files were hand-typed and there's a
mistake" when doing manual installs. Scripts are fine when you understand
what they're doing, but manual installs have their place too, for learning.

You might enjoy this document to grasp some of the nomenclature. Keystone
is Cookie Monster is my favorite.
http://www.scribd.com/doc/117185088/Introduction-to-OpenStack


On Tue, Mar 5, 2013 at 5:53 PM, Dolph Mathews wrote:

>
> On Tue, Mar 5, 2013 at 5:28 PM, Brad Knowles wrote:
>
>> On Mar 5, 2013, at 5:20 PM, Matt Joyce 
>> wrote:
>>
>> > check in horizon and see if you can follow inside of a stack trace
>> there.  you can see if any of the context's from the wsgi queries is seeing
>> a 404.
>>
>> Horizon?  That's not a service I've heard of before.  I'm basically
>> following the structure at <
>> http://docs.openstack.org/trunk/openstack-compute/install/apt/content/ap_installinggrizzlyubuntuprecise.html>
>> for initial installation, and I've gotten hung on the glance part at <
>> http://docs.openstack.org/trunk/openstack-compute/install/apt/content/osfolubuntu-imageservice.html
>> >.
>>
>> > these would be queries between glance and other backend APIs.
>> >
>> > example:
>> >
>> > you ---  query >  glance
>> >
>> > glance sees you token...
>> >
>> > glance --- query -> keystone
>> >
>> > if that query from glance to keystone fails...  it will report a 404.
>>  BUT that won't necessarily show up in logs as you'd expect since it's a
>> backend query.
>>
>> The query from glance to keystone appears to be okay -- I'm seeing 200
>> status responses in the keystone.log.
>>
>> > related idea:
>> >
>> > verify that your catalog service is pointing to the right API endpoints
>> on keystone.
>>
>> Catalog service?  That's another name that I have not heard of before, at
>> least not in the context of OpenStack.
>>
>
> The "service catalog" refers to a subset of keystone's interface that
> provides a catalog of services and endpoints to authenticated API users.
> It's the computed result of your service-list and endpoint-list and it's
> how those users find all the other OpenStack services, like nova and glance.
>
> In your case, all or most of your endpoints are wrong (they all contain
> /v2/ which I'm not sure is correct for any service?), so `glance index`
> probably can't find glance at all. I generally refer to keystone's
> sample_data.sh script for a generally idea of what the endpoints should
> look like:
>
>   https://github.com/openstack/keystone/blob/master/tools/sample_data.sh
>
>
>> --
>> Brad Knowles 
>> Senior Consultant
>>
>>
>> ___
>> Mailing list: https://launchpad.net/~openstack
>> Post to : openstack@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~openstack
>> More help   : https://help.launchpad.net/ListHelp
>>
>
>
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
>
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Fun with OpenStack Grizzly install...

On Mar 5, 2013, at 5:53 PM, Dolph Mathews  wrote:

> The "service catalog" refers to a subset of keystone's interface that 
> provides a catalog of services and endpoints to authenticated API users. It's 
> the computed result of your service-list and endpoint-list and it's how those 
> users find all the other OpenStack services, like nova and glance.

Ahh, okay.  Now it makes sense.  You shouldn't expect to see the word "catalog" 
as one of the services returned by the output from "keystone service-list", the 
catalog in question is actually the data that is being returned by such 
commands.

> In your case, all or most of your endpoints are wrong (they all contain /v2/ 
> which I'm not sure is correct for any service?), so `glance index` probably 
> can't find glance at all.

Aw, crap.  I just followed the example from the page at 

 for the nova-api entry, and then re-used that same example for all the other 
endpoints that were created.  Now I see that various endpoints are slightly 
different in the way they might specify which particular version of the API is 
being used, if they specify any API version at all.

D'oh!

> I generally refer to keystone's sample_data.sh script for a generally idea of 
> what the endpoints should look like:
> 
>   https://github.com/openstack/keystone/blob/master/tools/sample_data.sh

Ahh, yes.  That would have been a good tool to know about.

I'll go delete all the keystone endpoints and re-create them, based on this 
tool.

Thanks again!

--
Brad Knowles 
Senior Consultant

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] How to create a Image which can extend the partition automatically.

On 03/05/2013 02:04 PM, Scott Moser wrote:
> On Tue, 5 Mar 2013, Sylvain Bauza wrote:
> 
>> If you look at
>> http://www.pixelbeat.org/docs/openstack_libvirt_images/#1361764412, you'll 
>> see
>> that resize2fs is performed. But there is a caveat with RHEL6 which is Linux
>> 2.6 (contrary to Ubuntu 12.04 which is Linux 3.0).
>> If you look at "man resize2fs" :
> 
> Please don't do this, or rely on this.  Having the hypervisor do this for
> your guest is simply wrong.  Hypervisors should know little to nothing
> about the internals of the instances they're launching.

Just to point out the alternative for when the VM doesn't
have the smarts to resize itself, is to use something like virt-resize:
https://blueprints.launchpad.net/nova/+spec/resize-no-raw

> Please see this thread:
> http://www.gossamer-threads.com/lists/openstack/dev/23572?do=post_view_threaded#23572
> 
> That describes how to do this the right way, and wont have the host OS
> accidentally break your filesystem or lose your data because it didn't
> realize you were running some filesystem it didn't have perfect support
> for.
> 
> Other points:
>  * I've just added the ability for growpart to run outside the
>initramfs and still function.  This same functionality is available in
>patched versions of parted also (resizepart), but not yet in upstream.
>https://code.launchpad.net/~psusi/ubuntu/raring/parted/resize/+merge/151401
>  * Juerg added support for cloud-initramfs-utils to run in fedora/rhel and
>drakut

Juerg has cloud-utils for RHEL available here:
http://kojipkgs.fedoraproject.org/packages/cloud-utils/0.27/0.2.bzr216.el6/noarch/
And cloud-initramfs-utils under dev here:
https://bugzilla.redhat.com/916087

>  * I'm adding support for cloud-init to do this rather than have it from
>cloud-initramfs-utils.  I suspect that in some point in the future, the
>requirements for "just works" will be:
> * cloud-init 0.7.2
> * (cloud-utils 0.27 | parted 3.2): after Philip Susi's work for
>   'resizepart' lands.
> * kernel > 3.8
>  * for what currently works:
> * cloud-initramfs-utils (0.20 or from trunk)
> * cloud-init > 0.7 (cloud-init invokes resize2fs)
> 
>You'll need cloud-utils 0.27 and sgdisk to get GPT resizing support.
>Dos partition format requires sfdisk (from util-linux).

thanks for the info,
Pádraig.


___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] How to create a Image which can extend the partition automatically.

2013-03-05 Thread Scott Moser

On Wed, 6 Mar 2013, Pádraig Brady wrote:

> On 03/05/2013 02:04 PM, Scott Moser wrote:
> > On Tue, 5 Mar 2013, Sylvain Bauza wrote:
> >
> >> If you look at
> >> http://www.pixelbeat.org/docs/openstack_libvirt_images/#1361764412, you'll 
> >> see
> >> that resize2fs is performed. But there is a caveat with RHEL6 which is 
> >> Linux
> >> 2.6 (contrary to Ubuntu 12.04 which is Linux 3.0).
> >> If you look at "man resize2fs" :
> >
> > Please don't do this, or rely on this.  Having the hypervisor do this for
> > your guest is simply wrong.  Hypervisors should know little to nothing
> > about the internals of the instances they're launching.
>
> Just to point out the alternative for when the VM doesn't
> have the smarts to resize itself, is to use something like virt-resize:
> https://blueprints.launchpad.net/nova/+spec/resize-no-raw

Using libguestfs is worlds better than having the host "directly" do it.
But really whats happening here is *still* something with very little
information mucking with (and possibly breaking) the inside of a disk
image.  The more we consider that a "bucket of bytes" the better.

If you are using libguestfs, chances are you're using it from your distro,
and patching it to deal with a new filesystem (or otherwise get the update
to your hostOS) is still problematic.

Just let/expect the guest do it, and we'll avoid a whole silly game of cat
and mouse that doesn't even have to be played.

When was the last time you updated your bios on your laptop so you could
use a new linux filesystem?  That sounds silly, doesn't it.  Having
openstack reach inside the contents of the disk is just as silly.

One of the major benefits of having cloud-init direct the partition resize
*and* subsequent filesystem resize is that the user can (in user-data)
disable this!  (currently the initramfs doesn't take any instruction from
user-data, so disabling it isn't really a possibility).  perhaps they
didn't want that extra instance-store space to be part of the root
filesystem.

If you put that function inside the hypervisor, you either can't do it, of
you have to expose some silly api-launch parameter of
"do_not_modify_disk".  It complicates the API and complicates the host.___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] How to create a Image which can extend the partition automatically.

2013-03-05 Thread Joshua Harlow

+1 I think cloud-init can do this all in a more correct manner and in a
manner that works across more distributions and file system types in the
long term.

On 3/5/13 5:08 PM, "Scott Moser"  wrote:

>On Wed, 6 Mar 2013, Pádraig Brady wrote:
>
>> On 03/05/2013 02:04 PM, Scott Moser wrote:
>> > On Tue, 5 Mar 2013, Sylvain Bauza wrote:
>> >
>> >> If you look at
>> >> http://www.pixelbeat.org/docs/openstack_libvirt_images/#1361764412,
>>you'll see
>> >> that resize2fs is performed. But there is a caveat with RHEL6 which
>>is Linux
>> >> 2.6 (contrary to Ubuntu 12.04 which is Linux 3.0).
>> >> If you look at "man resize2fs" :
>> >
>> > Please don't do this, or rely on this.  Having the hypervisor do this
>>for
>> > your guest is simply wrong.  Hypervisors should know little to nothing
>> > about the internals of the instances they're launching.
>>
>> Just to point out the alternative for when the VM doesn't
>> have the smarts to resize itself, is to use something like virt-resize:
>> https://blueprints.launchpad.net/nova/+spec/resize-no-raw
>
>
>Using libguestfs is worlds better than having the host "directly" do it.
>But really whats happening here is *still* something with very little
>information mucking with (and possibly breaking) the inside of a disk
>image.  The more we consider that a "bucket of bytes" the better.
>
>If you are using libguestfs, chances are you're using it from your distro,
>and patching it to deal with a new filesystem (or otherwise get the update
>to your hostOS) is still problematic.
>
>Just let/expect the guest do it, and we'll avoid a whole silly game of cat
>and mouse that doesn't even have to be played.
>
>When was the last time you updated your bios on your laptop so you could
>use a new linux filesystem?  That sounds silly, doesn't it.  Having
>openstack reach inside the contents of the disk is just as silly.
>
>One of the major benefits of having cloud-init direct the partition resize
>*and* subsequent filesystem resize is that the user can (in user-data)
>disable this!  (currently the initramfs doesn't take any instruction from
>user-data, so disabling it isn't really a possibility).  perhaps they
>didn't want that extra instance-store space to be part of the root
>filesystem.
>
>If you put that function inside the hypervisor, you either can't do it, of
>you have to expose some silly api-launch parameter of
>"do_not_modify_disk".  It complicates the API and complicates the host.


___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] How to create a Image which can extend the partition automatically.

Thanks for Scott, Padraig, Juerg. I have the whole image of this feature.
But, who knows what's the implementation in AWS cloud when using RHEL OS?


On Wed, Mar 6, 2013 at 9:15 AM, Joshua Harlow wrote:

> +1 I think cloud-init can do this all in a more correct manner and in a
> manner that works across more distributions and file system types in the
> long term.
>
> On 3/5/13 5:08 PM, "Scott Moser"  wrote:
>
> >On Wed, 6 Mar 2013, Pádraig Brady wrote:
> >
> >> On 03/05/2013 02:04 PM, Scott Moser wrote:
> >> > On Tue, 5 Mar 2013, Sylvain Bauza wrote:
> >> >
> >> >> If you look at
> >> >> http://www.pixelbeat.org/docs/openstack_libvirt_images/#1361764412,
> >>you'll see
> >> >> that resize2fs is performed. But there is a caveat with RHEL6 which
> >>is Linux
> >> >> 2.6 (contrary to Ubuntu 12.04 which is Linux 3.0).
> >> >> If you look at "man resize2fs" :
> >> >
> >> > Please don't do this, or rely on this.  Having the hypervisor do this
> >>for
> >> > your guest is simply wrong.  Hypervisors should know little to nothing
> >> > about the internals of the instances they're launching.
> >>
> >> Just to point out the alternative for when the VM doesn't
> >> have the smarts to resize itself, is to use something like virt-resize:
> >> https://blueprints.launchpad.net/nova/+spec/resize-no-raw
> >
> >
> >Using libguestfs is worlds better than having the host "directly" do it.
> >But really whats happening here is *still* something with very little
> >information mucking with (and possibly breaking) the inside of a disk
> >image.  The more we consider that a "bucket of bytes" the better.
> >
> >If you are using libguestfs, chances are you're using it from your distro,
> >and patching it to deal with a new filesystem (or otherwise get the update
> >to your hostOS) is still problematic.
> >
> >Just let/expect the guest do it, and we'll avoid a whole silly game of cat
> >and mouse that doesn't even have to be played.
> >
> >When was the last time you updated your bios on your laptop so you could
> >use a new linux filesystem?  That sounds silly, doesn't it.  Having
> >openstack reach inside the contents of the disk is just as silly.
> >
> >One of the major benefits of having cloud-init direct the partition resize
> >*and* subsequent filesystem resize is that the user can (in user-data)
> >disable this!  (currently the initramfs doesn't take any instruction from
> >user-data, so disabling it isn't really a possibility).  perhaps they
> >didn't want that extra instance-store space to be part of the root
> >filesystem.
> >
> >If you put that function inside the hypervisor, you either can't do it, of
> >you have to expose some silly api-launch parameter of
> >"do_not_modify_disk".  It complicates the API and complicates the host.
>
>
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>



-- 
Lei Zhang

Blog: http://jeffrey4l.github.com
twitter/weibo: @jeffrey4l
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] How to create a Image which can extend the partition automatically.

On Tue, Mar 5, 2013 at 10:04 PM, Scott Moser  wrote:

> cloud-init > 0.7 (cloud-init invokes resize2fs)


How this is possible to just call `resize2fs` to re-partition. As I know,
this tool will not modify the partition information. Right?


-- 
Lei Zhang

Blog: http://jeffrey4l.github.com
twitter/weibo: @jeffrey4l
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] keystone-manage db_sync failures

see https://bugs.launchpad.net/keystone/+bug/1073569 bug


On Wed, Mar 6, 2013 at 2:18 AM, Miller, Mark M (EB SW Cloud - R&D -
Corvallis)  wrote:

> Try adding the config file name to the command line:
>
> > keystone-manage --config-file /etc/keystone/keystone.conf db_sync
>
> Mark
>
> -Original Message-
> From: openstack-bounces+mark.m.miller=hp@lists.launchpad.net [mailto:
> openstack-bounces+mark.m.miller=hp@lists.launchpad.net] On Behalf Of
> Wyllys Ingersoll
> Sent: Tuesday, March 05, 2013 8:27 AM
> To: openstack@lists.launchpad.net
> Subject: [Openstack] keystone-manage db_sync failures
>
> I keep getting a failure when trying to configure keystone.
>  keystone-manage seems to have issues with sqlalchemy.
>
> Here are my versions:
>
> python-keystoneclient: 1:0.1.3-0ubuntu1.1~cloud0
> python-sqlalchemy:  0.7.8-1ubuntu1~cloud0
> python-migrate:  0.7.2-1ubuntu1
>
> Any ideas??
>
> $ keystone-manage db_sync
> Traceback (most recent call last):
>   File "/usr/bin/keystone-manage", line 28, in 
> cli.main(argv=sys.argv, config_files=config_files)
>   File "/usr/lib/python2.7/dist-packages/keystone/cli.py", line 164, in
> main
> return run(cmd, (args[:1] + args[2:]))
>   File "/usr/lib/python2.7/dist-packages/keystone/cli.py", line 147, in run
> return CMDS[cmd](argv=args).run()
>   File "/usr/lib/python2.7/dist-packages/keystone/cli.py", line 35, in run
> return self.main()
>   File "/usr/lib/python2.7/dist-packages/keystone/cli.py", line 54, in main
> driver = importutils.import_object(getattr(CONF, k).driver)
>   File
> "/usr/lib/python2.7/dist-packages/keystone/openstack/common/importutils.py",
> line 40, in import_object
> return import_class(import_str)(*args, **kwargs)
>   File
> "/usr/lib/python2.7/dist-packages/keystone/openstack/common/importutils.py",
> line 30, in import_class
> __import__(mod_str)
>   File
> "/usr/lib/python2.7/dist-packages/keystone/identity/backends/sql.py", line
> 22, in 
> from keystone.common.sql import migration
>   File
> "/usr/lib/python2.7/dist-packages/keystone/common/sql/migration.py", line
> 23, in 
> from migrate.versioning import api as versioning_api
>   File "/usr/lib/python2.7/dist-packages/migrate/versioning/api.py", line
> 33, in 
> from migrate.versioning import (repository, schema, version,
>   File "/usr/lib/python2.7/dist-packages/migrate/versioning/schema.py",
> line 10, in 
> from sqlalchemy import exceptions as sa_exceptions
> ImportError: cannot import name exceptions
>
>
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>



-- 
Lei Zhang

Blog: http://jeffrey4l.github.com
twitter/weibo: @jeffrey4l
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] error -- yum install openstack-quantum-openvswitch

now, the openvswitch package is not exist in RHEL official repository and
EPEL repository. You can build it manually. You can refer to my article
http://jeffrey4l.blogspot.com/2013/02/open-vswitch-installation-on-centos-63.html


On Wed, Mar 6, 2013 at 1:49 AM, Aru s  wrote:

> Hi,
>
> I am getting the below error while trying to install antuenstack quantum.
> Please help.
> I am using RHEL6.3 (64bit), with EPEL
> http://download.fedoraproject.org/pub/epel/6/i386/epel-release-6-8.noarch.rpm
>
> # yum install openstack-quantum-openvswitch
> Loaded plugins: product-id, security, subscription-manager
> Updating certificate-based repositories.
> Unable to read consumer identity
> Setting up Install Process
> Resolving Dependencies
> --> Running transaction check
> ---> Package openstack-quantum-openvswitch.noarch 0:2012.2.1-1.el6 will be
> installed
> --> Processing Dependency: openvswitch for package:
> openstack-quantum-openvswitch-2012.2.1-1.el6.noarch
> --> Finished Dependency Resolution
> Error: Package: openstack-quantum-openvswitch-2012.2.1-1.el6.noarch (epel)
>Requires: openvswitch
>  You could try using --skip-broken to work around the problem
>  You could try running: rpm -Va --nofiles --nodigest
> [root@os-ctrl openvswitch]#
>
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
>


-- 
Lei Zhang

Blog: http://jeffrey4l.github.com
twitter/weibo: @jeffrey4l
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] keystone-manage db_sync failures

2013-03-05 Thread Wyllys Ingersoll



I saw that bug, but that was not the problem because I had the right versions 
of all of those pieces.

The problem arose when I had to change the IP addr of my host.  I updated all 
of the config files and the endpoints in the keystone DB, but still nova was 
pulling the old IP addr from somewhere, but I could not figure out where it was 
coming from.  It wasn't in the DB and it wasn't in any of the config files.  I 
finally gave up and re-installed the whole thing from scratch.  Luckily, it was 
in a VM that I was using for testing so I didn't lose any real data or anything 
and the re-install was quick and smooth.

I still have no idea what went wrong and my lasting impression is that the 
whole thing is a house of cards that is still very fragile to the slightest 
inconsistencies.

-Wyllys


On Mar 5, 2013, at 9:42 PM, Lei Zhang 
mailto:zhang.lei@gmail.com>> wrote:

see https://bugs.launchpad.net/keystone/+bug/1073569 bug


On Wed, Mar 6, 2013 at 2:18 AM, Miller, Mark M (EB SW Cloud - R&D - Corvallis) 
mailto:mark.m.mil...@hp.com>> wrote:
Try adding the config file name to the command line:

> keystone-manage --config-file /etc/keystone/keystone.conf db_sync

Mark

-Original Message-
From: 
openstack-bounces+mark.m.miller=hp@lists.launchpad.net
 
[mailto:openstack-bounces+mark.m.miller=hp@lists.launchpad.net]
 On Behalf Of Wyllys Ingersoll
Sent: Tuesday, March 05, 2013 8:27 AM
To: openstack@lists.launchpad.net
Subject: [Openstack] keystone-manage db_sync failures

I keep getting a failure when trying to configure keystone.  keystone-manage 
seems to have issues with sqlalchemy.

Here are my versions:

python-keystoneclient: 1:0.1.3-0ubuntu1.1~cloud0
python-sqlalchemy:  0.7.8-1ubuntu1~cloud0
python-migrate:  0.7.2-1ubuntu1

Any ideas??

$ keystone-manage db_sync
Traceback (most recent call last):
  File "/usr/bin/keystone-manage", line 28, in 
cli.main(argv=sys.argv, config_files=config_files)
  File "/usr/lib/python2.7/dist-packages/keystone/cli.py", line 164, in main
return run(cmd, (args[:1] + args[2:]))
  File "/usr/lib/python2.7/dist-packages/keystone/cli.py", line 147, in run
return CMDS[cmd](argv=args).run()
  File "/usr/lib/python2.7/dist-packages/keystone/cli.py", line 35, in run
return self.main()
  File "/usr/lib/python2.7/dist-packages/keystone/cli.py", line 54, in main
driver = importutils.import_object(getattr(CONF, k).driver)
  File 
"/usr/lib/python2.7/dist-packages/keystone/openstack/common/importutils.py", 
line 40, in import_object
return import_class(import_str)(*args, **kwargs)
  File 
"/usr/lib/python2.7/dist-packages/keystone/openstack/common/importutils.py", 
line 30, in import_class
__import__(mod_str)
  File "/usr/lib/python2.7/dist-packages/keystone/identity/backends/sql.py", 
line 22, in 
from keystone.common.sql import migration
  File "/usr/lib/python2.7/dist-packages/keystone/common/sql/migration.py", 
line 23, in 
from migrate.versioning import api as versioning_api
  File "/usr/lib/python2.7/dist-packages/migrate/versioning/api.py", line 33, 
in 
from migrate.versioning import (repository, schema, version,
  File "/usr/lib/python2.7/dist-packages/migrate/versioning/schema.py", line 
10, in 
from sqlalchemy import exceptions as sa_exceptions
ImportError: cannot import name exceptions


___
Mailing list: https://launchpad.net/~openstack
Post to : 
openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~openstack
Post to : 
openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp



--
Lei Zhang

Blog: http://jeffrey4l.github.com
twitter/weibo: @jeffrey4l

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

[Openstack] Can ping guest VMs but not reachable external network

2013-03-05 Thread Sammy Fung

I tried to configure Folsom with Quantum with 2 systems, I can ping all
gust VMs and control/network node but not reachable external network and
metadata server.

What should I do or try next ?

Public IP: 10.10.0.0/24 GW: 10.10.0.1
Floating IP for allocation: 10.10.0.100-199

# ifconfig
br-ex Link encap:Ethernet  HWaddr 90:b2:1c:1d:ba:f5
  inet addr:10.10.0.5  Bcast:10.10.0.255  Mask:255.255.255.0
  inet6 addr:  Scope:Link
  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
  RX packets:1642 errors:0 dropped:0 overruns:0 frame:0
  TX packets:6 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:0
  RX bytes:111375 (111.3 KB)  TX bytes:468 (468.0 B)

eth0  Link encap:Ethernet  HWaddr 90:b2:1c:1d:ba:f5
  UP BROADCAST RUNNING PROMISC MULTICAST  MTU:1500  Metric:1
  RX packets:3889252 errors:0 dropped:9975 overruns:0 frame:0
  TX packets:405724 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000
  RX bytes:274693186 (274.6 MB)  TX bytes:57112020 (57.1 MB)
  Interrupt:35

eth2  Link encap:Ethernet  HWaddr 90:b2:1c:1d:ba:f7
  inet addr:10.43.0.5  Bcast:10.43.0.255  Mask:255.255.255.0
  inet6 addr:  Scope:Link
  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
  RX packets:468974866 errors:0 dropped:0 overruns:0 frame:0
  TX packets:333432150 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000
  RX bytes:480278132175 (480.2 GB)  TX bytes:194328821675 (194.3 GB)
  Interrupt:34

loLink encap:Local Loopback
  inet addr:127.0.0.1  Mask:255.0.0.0
  inet6 addr: ::1/128 Scope:Host
  UP LOOPBACK RUNNING  MTU:16436  Metric:1
  RX packets:459327545 errors:0 dropped:0 overruns:0 frame:0
  TX packets:459327545 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:0
  RX bytes:95368147225 (95.3 GB)  TX bytes:95368147225 (95.3 GB)

tapc4a527ec-ce Link encap:Ethernet  HWaddr fa:16:3e:ef:71:4a
  inet addr:10.10.0.100  Bcast:10.10.0.255  Mask:255.255.255.0
  inet6 addr:  Scope:Link
  UP BROADCAST RUNNING PROMISC MULTICAST  MTU:1500  Metric:1
  RX packets:349 errors:0 dropped:0 overruns:0 frame:0
  TX packets:273 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:0
  RX bytes:55285 (55.2 KB)  TX bytes:39379 (39.3 KB)

virbr0Link encap:Ethernet  HWaddr 72:98:a8:f8:ec:c5
  inet addr:192.168.122.1  Bcast:192.168.122.255  Mask:255.255.255.0
  UP BROADCAST MULTICAST  MTU:1500  Metric:1
  RX packets:0 errors:0 dropped:0 overruns:0 frame:0
  TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:0
  RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] OpenStack login page