Re: [Openstack] Failed to get metadata for ip x.x.x.x
I was fairly sure trunk has been fixed now, just about the sametime his patch was uploaded, that had other issues. Are you still seeing the problem? I will double check the bug has been updated when I get online. Thanks, John Robert Collins robe...@robertcollins.net wrote: On Tue, Oct 9, 2012 at 3:56 AM, John Garbutt john.garb...@citrix.com wrote: I think Mate has just spotted this bug on trunk this morning. He should be raising the bug and uploading a patch for that ASAP. Clearly some unit tests are missing in this bit of code. It's been nearly three weeks now - can we revert the broken patch (which looks like it will break for everyone) and get back to a good state? If thats acceptable, I'll propose a patch to do that. -Rob ___ 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] Failed to get metadata for ip x.x.x.x
Hi, The folsom release solves the problem! However, I noticed that the url used by devstack to download xe-guest-utilities ( http://images.ansolabs.com/xen/xe-guest-utilities_5.6.100-651_amd64.deb) does not work any more. For me, I just used my last downloads. But, a new devstack user will not be able to install openstack with XCP, without this deb file. Please try to fix this problem as soon as possible. Thank you Regards, Afef 2012/10/29 John Garbutt john.garb...@citrix.com I was fairly sure trunk has been fixed now, just about the sametime his patch was uploaded, that had other issues. Are you still seeing the problem? I will double check the bug has been updated when I get online. Thanks, John Robert Collins robe...@robertcollins.net wrote: On Tue, Oct 9, 2012 at 3:56 AM, John Garbutt john.garb...@citrix.com wrote: I think Mate has just spotted this bug on trunk this morning. He should be raising the bug and uploading a patch for that ASAP. Clearly some unit tests are missing in this bit of code. It's been nearly three weeks now - can we revert the broken patch (which looks like it will break for everyone) and get back to a good state? If thats acceptable, I'll propose a patch to do that. -Rob ___ 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] new mailing list for bare-metal provisioning
On 10/29/2012 02:59 AM, Asher Newcomer wrote: +1 On Sun, Oct 28, 2012 at 8:39 PM, Russell Bryant rbry...@redhat.com mailto:rbry...@redhat.com wrote: On 10/28/2012 08:19 PM, David Kang wrote: I agree that subject prefix is a way. There are pros and cons of either approach. However, when I asked a few of the people who showed interest in bare-metal discussion, a new mailing list was preferred by them. And we thought a separate mailing list makes people easier to participate and to manage the discussion. We can discuss this issue again among the people who signed up the new mailing list. There are quite a few people, like myself, who are interested in *all* nova development. Signing up for a new mailing list for every new development effort would be a nightmare to keep up with. I *really, really* think the list should be dropped and all discussions should be on openstack-dev. I agree. -- Russell Bryant ___ Mailing list: https://launchpad.net/~openstack https://launchpad.net/%7Eopenstack Post to : openstack@lists.launchpad.net mailto:openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack https://launchpad.net/%7Eopenstack 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] Failed to get metadata for ip x.x.x.x
On Mon, Oct 29, 2012 at 8:34 PM, John Garbutt john.garb...@citrix.com wrote: I was fairly sure trunk has been fixed now, just about the sametime his patch was uploaded, that had other issues. Are you still seeing the problem? I reproduced it on the baremetal branch we've been hacking on, which isn't completely up to date with trunk, reverting the patch identified by Thierry fixed it for me, so we're working with that reverted locally for now. It's my EOD but I'm sure we can try to reproduce with tip itself easily enough. I will double check the bug has been updated when I get online. It hasn't :) -Rob ___ 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] new mailing list for bare-metal provisioning
If mailing list gets separated, it would be good to have an aggregate mailing list we can subscribe to which has all nova related mailing lists. On Mon, Oct 29, 2012 at 3:53 PM, Gary Kotton gkot...@redhat.com wrote: On 10/29/2012 02:59 AM, Asher Newcomer wrote: +1 On Sun, Oct 28, 2012 at 8:39 PM, Russell Bryant rbry...@redhat.comwrote: On 10/28/2012 08:19 PM, David Kang wrote: I agree that subject prefix is a way. There are pros and cons of either approach. However, when I asked a few of the people who showed interest in bare-metal discussion, a new mailing list was preferred by them. And we thought a separate mailing list makes people easier to participate and to manage the discussion. We can discuss this issue again among the people who signed up the new mailing list. There are quite a few people, like myself, who are interested in *all* nova development. Signing up for a new mailing list for every new development effort would be a nightmare to keep up with. I *really, really* think the list should be dropped and all discussions should be on openstack-dev. I agree. -- Russell Bryant ___ 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
Re: [Openstack] new mailing list for bare-metal provisioning
Sam Stoelinga wrote: If mailing list gets separated, it would be good to have an aggregate mailing list we can subscribe to which has all nova related mailing lists. We really shouldn't go in that direction: the openstack-dev list is already an aggregator of topics, since we use mailman topics on it. I see a lot of drawbacks in having the ML separate. The only drawback I can think of in having the baremetal discussions on the main openstack-dev list is that some people might only want to receive baremetal stuff. Those (hopefully rare) people can use client-side filtering on the subject... or we also can setup a baremetal mailman topic so that you can directly filter using your ML preferences. -- Thierry Carrez (ttx) Release Manager, OpenStack ___ 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] Failed to get metadata for ip x.x.x.x
If you are using XenServer I automatically install the tools shipped with the product. It is a free download, so that might be your best bet for getting started right now. I will follow up with the XCP guys to see what we should be doing long term. Thank you for the heads up! John From: Afef MDHAFFAR [mailto:afef.mdhaf...@gmail.com] Sent: Monday, October 29, 2012 7:53 AM To: John Garbutt Cc: openstack@lists.launchpad.net Subject: Re: [Openstack] Failed to get metadata for ip x.x.x.x Hi, The folsom release solves the problem! However, I noticed that the url used by devstack to download xe-guest-utilities (http://images.ansolabs.com/xen/xe-guest-utilities_5.6.100-651_amd64.deb) does not work any more. For me, I just used my last downloads. But, a new devstack user will not be able to install openstack with XCP, without this deb file. Please try to fix this problem as soon as possible. Thank you Regards, Afef 2012/10/29 John Garbutt john.garb...@citrix.commailto:john.garb...@citrix.com I was fairly sure trunk has been fixed now, just about the sametime his patch was uploaded, that had other issues. Are you still seeing the problem? I will double check the bug has been updated when I get online. Thanks, John Robert Collins robe...@robertcollins.netmailto:robe...@robertcollins.net wrote: On Tue, Oct 9, 2012 at 3:56 AM, John Garbutt john.garb...@citrix.commailto:john.garb...@citrix.com wrote: I think Mate has just spotted this bug on trunk this morning. He should be raising the bug and uploading a patch for that ASAP. Clearly some unit tests are missing in this bit of code. It's been nearly three weeks now - can we revert the broken patch (which looks like it will break for everyone) and get back to a good state? If thats acceptable, I'll propose a patch to do that. -Rob ___ 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] How can I specify which filesystem to use for ephemeral storage per image?
Hi! I'm running a nova cloud (essex) with both linux and windows instances. I want the windows images to boot with an ephemeral pre-formatted ntfs drive. I've tried setting: virt_mkfs=windows=mkfs.ntfs --force --fast --label %(fs_label)s %(target)s in nova.conf and I've also set the os_type metadata on the windows image, but nova still uses ext4: 2012-10-29 12:41:24 DEBUG nova.utils [req-33b476e7-6412-4caa-ba51-839c36ab35b0 ec731931e03544d89e46468a3a268d9b 526fedd9083647fbbbc167261f10ecfc] Running cmd (subprocess): mkfs.ext4 -L ephemeral0 -F /var/lib/nova/instances/_base/ephemeral_0_20_windows from (pid=10597) execute /usr/lib/python2.7/dist-packages/nova/utils.py:219 Cheers, Erik ___ 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] new mailing list for bare-metal provisioning
On 10/29/2012 12:32 PM, Thierry Carrez wrote: We really shouldn't go in that direction: the openstack-dev list is already an aggregator of topics, since we use mailman topics on it. Indeed, mailman topics are very powerful. The current topics for openstack-dev are listed on each subscriber's personal page: http://lists.openstack.org/cgi-bin/mailman/options/openstack-dev As a subscriber of openstack-dev I can decide to receive only messages tagged for a topic by selecting the ones I'm interested in. As a writer of a message I can tag it by adding the topic to the subject line of the message. For example, if I want to receive only messages for Nova, I can subscribe to the Nova topic at the link above. When I write a message about nova I have to add '[Nova]' (or 'Nova') anywhere in the subject. Creating a topic of bare-metal is easy, using topics is a matter of habit. I believe that we should not create more lists unless strictly necessary. I also understood from David that the baremetal group felt very strongly against using any of the existing list, even when I suggested to use topics. I'm glad we're having this conversation now and I'm open to any outcome. /stef ___ 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] new mailing list for bare-metal provisioning
On 10/28/2012 08:19 PM, David Kang wrote: I agree that subject prefix is a way. There are pros and cons of either approach. However, when I asked a few of the people who showed interest in bare-metal discussion, a new mailing list was preferred by them. And we thought a separate mailing list makes people easier to participate and to manage the discussion. We can discuss this issue again among the people who signed up the new mailing list. I think the more general concern is that part of the challenges of getting the current bare-metal approach in has been that it's largely been developed on the side. I think the path for successful evolution of bare-metal in nova is to stop thinking about it as a side effort, and more a part of normal nova development, as other changes in nova will have implications for bare-metal for sure. So driving the discussion back onto the main list would be really beneficial. -Sean -- Sean Dague IBM Linux Technology Center email: sda...@linux.vnet.ibm.com alt-email: slda...@us.ibm.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] Instrumentation Monitoring Next Step - quick meet up
Reminder: Time: Monday (10/29/2012) 2200 UTC – 2300 UTC (2pm PDT if you are in California) Location: IRC #openstack-meeting Thanks! Annie From: Annie Cheng ann...@yahoo-inc.commailto:ann...@yahoo-inc.com Date: Thu, 25 Oct 2012 14:17:09 -0700 To: openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net Subject: [Openstack] Instrumentation Monitoring Next Step - quick meet up Hi all, Couple of us chat in the summit design sessions and and after summit on #openstack irc regarding topic of Monitoring. We think it's best to do a quick meeting to get everyone on the same page, split works, and get at least a prototype going in Grizzly. Time: Monday (10/29/2012) 2200 UTC – 2300 UTC Location: IRC #openstack-meeting I checked http://wiki.openstack.org/Meetings, this tme slot seems to be empty Top level agenda would be 1. Get everyone on the same page on high level direction 2. Discuss different design/implementation possibility 3. Split up works Before the meeting, if you want to read up, here are some links I know. Please jump in with others I missed: Blueprint: https://blueprints.launchpad.net/nova/+spec/nova-instrumentation-metrics-monitoring Etherpad: https://etherpad.openstack.org/grizzly-common-instrumentation Different code samples: https://github.com/asalkeld/statgen Looking forward, some of those conversation probably will fold into the regular Metering meeting. Just like to do a one off for now so we can go deeper on monitoring specific topics. Thanks! Annie ___ 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] Instrumentation Monitoring Next Step - quick meet up
Apologize .. Correction Time: Monday (10/29/2012) 2200 UTC – 2300 UTC (3pm PDT if you are in California) Location: IRC #openstack-meeting From: Annie Cheng ann...@yahoo-inc.commailto:ann...@yahoo-inc.com Date: Mon, 29 Oct 2012 07:14:08 -0700 To: openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net Subject: Re: [Openstack] Instrumentation Monitoring Next Step - quick meet up Reminder: Time: Monday (10/29/2012) 2200 UTC – 2300 UTC (2pm PDT if you are in California) Location: IRC #openstack-meeting Thanks! Annie From: Annie Cheng ann...@yahoo-inc.commailto:ann...@yahoo-inc.com Date: Thu, 25 Oct 2012 14:17:09 -0700 To: openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net Subject: [Openstack] Instrumentation Monitoring Next Step - quick meet up Hi all, Couple of us chat in the summit design sessions and and after summit on #openstack irc regarding topic of Monitoring. We think it's best to do a quick meeting to get everyone on the same page, split works, and get at least a prototype going in Grizzly. Time: Monday (10/29/2012) 2200 UTC – 2300 UTC Location: IRC #openstack-meeting I checked http://wiki.openstack.org/Meetings, this tme slot seems to be empty Top level agenda would be 1. Get everyone on the same page on high level direction 2. Discuss different design/implementation possibility 3. Split up works Before the meeting, if you want to read up, here are some links I know. Please jump in with others I missed: Blueprint: https://blueprints.launchpad.net/nova/+spec/nova-instrumentation-metrics-monitoring Etherpad: https://etherpad.openstack.org/grizzly-common-instrumentation Different code samples: https://github.com/asalkeld/statgen Looking forward, some of those conversation probably will fold into the regular Metering meeting. Just like to do a one off for now so we can go deeper on monitoring specific topics. Thanks! Annie ___ 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] Instrumentation Monitoring Next Step - quick meet up
Ugh, I just realized I have a conflict. Can we push it an hour later? (sorry!) -S From: openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net [openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net] on behalf of Annie Cheng [ann...@yahoo-inc.com] Sent: Monday, October 29, 2012 11:18 AM To: openstack@lists.launchpad.net Subject: Re: [Openstack] Instrumentation Monitoring Next Step - quick meet up Apologize .. Correction Time: Monday (10/29/2012) 2200 UTC – 2300 UTC (3pm PDT if you are in California) Location: IRC #openstack-meeting From: Annie Cheng ann...@yahoo-inc.commailto:ann...@yahoo-inc.com Date: Mon, 29 Oct 2012 07:14:08 -0700 To: openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net Subject: Re: [Openstack] Instrumentation Monitoring Next Step - quick meet up Reminder: Time: Monday (10/29/2012) 2200 UTC – 2300 UTC (2pm PDT if you are in California) Location: IRC #openstack-meeting Thanks! Annie From: Annie Cheng ann...@yahoo-inc.commailto:ann...@yahoo-inc.com Date: Thu, 25 Oct 2012 14:17:09 -0700 To: openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net Subject: [Openstack] Instrumentation Monitoring Next Step - quick meet up Hi all, Couple of us chat in the summit design sessions and and after summit on #openstack irc regarding topic of Monitoring. We think it's best to do a quick meeting to get everyone on the same page, split works, and get at least a prototype going in Grizzly. Time: Monday (10/29/2012) 2200 UTC – 2300 UTC Location: IRC #openstack-meeting I checked http://wiki.openstack.org/Meetings, this tme slot seems to be empty Top level agenda would be 1. Get everyone on the same page on high level direction 2. Discuss different design/implementation possibility 3. Split up works Before the meeting, if you want to read up, here are some links I know. Please jump in with others I missed: Blueprint: https://blueprints.launchpad.net/nova/+spec/nova-instrumentation-metrics-monitoring Etherpad: https://etherpad.openstack.org/grizzly-common-instrumentation Different code samples: https://github.com/asalkeld/statgen Looking forward, some of those conversation probably will fold into the regular Metering meeting. Just like to do a one off for now so we can go deeper on monitoring specific topics. Thanks! Annie ___ 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] Quotas in folsom
I'm running into quota problems trying to increase the number of security groups and rules within security groups per tenant. Setting quota_security_groups and quota_security_group_rules in nova.conf seem to have no effect. There also doesn't seem to be any way to change the quota limits for security groups through the nova client or horizon. How do I go about changing these quotas or is there a way to disable all quotas all together? ___ 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] Nova different sr
Good afternoon, Is it possible for Nova to deploy vm in different storages?? rather than just use the storage which matches sr_matching_filter parameter?? Best regards, ___ 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] Retrieve Endpoints
It's hard to say without docs, as the openstack.identity.endpoint shown
there is just throwing errors for me, and the openstack.endpoint is raising
401.
However, the port used for the identity endpoint is typically used for the
administrative/management identity endpoint (keystone), and the
openstack.endpoint refers to specifically to compute in the hostname
(nova).
-Dolph
On Sun, Oct 28, 2012 at 11:21 PM, Tummala Pradeep
pradeep.tumm...@ericsson.com wrote:
Hi Joe,
I am actually trying to integrate cloudify with Openstack. To accomplish
this, I have to configure openstack.groovy file in cloudify.
There are two fields here - openstack.endpoint
openstack.identity.endpoint. I have an example for cloudify integration
with HP Openstack cloud. Hope, it will help you to understand what exactly
these two fields (Last 4 lines) require.
cloud {
// Mandatory. The name of the cloud, as it will appear in the Cloudify
UI.
name = Openstack
configuration {
// Mandatory - openstack Diablo cloud driver.
className
org.cloudifysource.esc.driver.provisioning.openstack.OpenstackCloudDriver
// Optional. The template name for the management machines.
Defaults to the first template in the templates section below.
managementMachineTemplate SMALL_LINUX
**// Optional. Indicates whether internal cluster
communications should use the machine private IP. Defaults to true.
connectToPrivateIp true
remoteUsername REPLACE_WITH_THE_SSH_USER_NAME
remotePassword REPLACE_WITH_THE_SS_USER_PASSWORD
}
provider {
// optional
provider openstack
localDirectory tools/cli/plugins/esc/hp/upload
remoteDirectory /root/gs-files
cloudifyUrl
http://s3.amazonaws.com/gigaspaces-cloudify/cloudify/hp/gigaspaces-hp.zip;
http://s3.amazonaws.com/gigaspaces-cloudify/cloudify/hp/gigaspaces-hp.zip
machineNamePrefix agent
dedicatedManagementMachines true
managementOnlyFiles ([])
managementGroup management
numberOfManagementMachines 1
zones ([agent])
reservedMemoryCapacityPerMachineInMB 1024
}
user {
user ENTER_USER
apiKey ENTER_KEY
keyFile ENTER_KEY_FILE
}
templates ([
SMALL_LINUX : template{
imageId 221
machineMemoryMB 1600
hardwareId 102
//locationId us-east-1
options ([
openstack.securityGroup :
test,
openstack.keyPair :
hp-cloud-demo,
// indicates if a floating IP
should be assigned to this machine. Defaults to true.
openstack.allocate-floating-ip : true
])
}
])
custom ([
*openstack.endpoint :
https://az-2.region-a.geo-1.compute.hpcloudsvc.com/;
https://az-2.region-a.geo-1.compute.hpcloudsvc.com/,*
* openstack.identity.endpoint:
https://region-a.geo-1.identity.hpcloudsvc.com:35357/;
https://region-a.geo-1.identity.hpcloudsvc.com:35357/,*
openstack.tenant : ENTER_TENANT,
openstack.wireLog: false
])
}
Now, I am trying the integration with OpenStack deployed on my server. Do
let me know if you get any idea from the above example.
Thanks
Pradeep
On 10/26/2012 01:36 AM, heckj wrote:
Hi Pradeep,
I'm not sure what the context is for these values, so it's a little hard to
assert a clear answer.
For most openstack projects, (all but keystone), there's generally a single
API endpoints, and the keystone service catalog is configured on deployment
to point to those. The service catalog supports exposing internal and public
endpoints.
Keystone (quirky thing that it is) has two endpoints - one for general public
authorization with a very limited API - in the docs and on the CLI, this is
referred to as the auth_url. In a devstack setup, this auth_url is
http://localhost:5000/v2.0; http://localhost:5000/v2.0 - your deployment
I'd expect to be different.
There's also an administrative endpoint for Keystone where a Keystone admin
(or associated scripts) can configure services, endpoints, users, etc
depending on the keystone deployment configuration. The CLI refers to this as
the management_url, and in a devstack setup, it would be
http://localhost:35357/v2.0; http://localhost:35357/v2.0
This help?
-joe
Re: [Openstack] Troubleshooting Swift 1.7.4 on mini servers
Yeah, I read about the 507 error.However, when the error occurs on my I can see with 'df' that the drive is only 1% full and is definitely not unmounted. I can write files to the mounted filesystem directly before, during, and after the Swift error occurs. So the problem must be some kind of timeout that is causing the object server to think that something is wrong with the disk. I'll keep digging... On Fri, Oct 26, 2012 at 11:21 PM, John Dickinson m...@not.mn wrote: A 507 is returned by the object servers in 2 situations: 1) the drives are full or 2) the drives have been unmounted because of disk error. It's highly likely that you simply have full drives. Remember that the usable space in your cluster is 1/N where N = replica count. As an example, with 3 replicas and 5 nodes with a single 1TB drive each, you only have about 1.6TB available for data. As Pete suggested in his response, how big are your drives, and what does `df` tell you? --John On Oct 26, 2012, at 5:26 PM, Nathan Trueblood nat...@truebloodllc.com wrote: Hey folks- I'm trying to figure out what's going wrong with my Swift deployment on a small cluster of mini servers. I have a small test cluster (5 storage nodes, 1 proxy) of mini-servers that are ARM-based. The proxy is a regular, Intel-based server with plenty of RAM. The object/account/container servers are relatively small, with 2GB of RAM per node. Everything starts up fine, but now I'm trying to troubleshoot a strange problem. After I successfully upload a few test files, it seems like the storage system stops responding and the proxy gives me a 503 error. Here's the test sequence I run on my proxy: lab@proxy01:~/bin$ ./swiftcl.sh stat swift -A http://proxy01:8080/auth/v1.0 -U system:root -K testpass stat Account: AUTH_system Containers: 5 Objects: 4 Bytes: 47804968 Accept-Ranges: bytes X-Timestamp: 1351294912.72119 lab@proxy01:~/bin$ ./swiftcl.sh upload myfiles1 /home/lab/bigfile1 swift -A http://proxy01:8080/auth/v1.0 -U system:root -K testpass upload myfiles1 /home/lab/bigfile1 home/lab/bigfile1 lab@proxy01:~/bin$ ./swiftcl.sh upload myfiles2 /home/lab/bigfile1 swift -A http://proxy01:8080/auth/v1.0 -U system:root -K testpass upload myfiles2 /home/lab/bigfile1 home/lab/bigfile1 lab@proxy01:~/bin$ ./swiftcl.sh upload myfiles3 /home/lab/bigfile1 swift -A http://proxy01:8080/auth/v1.0 -U system:root -K testpass upload myfiles3 /home/lab/bigfile1 home/lab/bigfile1 lab@proxy01:~/bin$ ./swiftcl.sh upload myfiles4 /home/lab/bigfile1 swift -A http://proxy01:8080/auth/v1.0 -U system:root -K testpass upload myfiles4 /home/lab/bigfile1 home/lab/bigfile1 lab@proxy01:~/bin$ ./swiftcl.sh upload myfiles5 /home/lab/bigfile1 swift -A http://proxy01:8080/auth/v1.0 -U system:root -K testpass upload myfiles5 /home/lab/bigfile1 Object PUT failed: http://172.16.1.111:8080/v1/AUTH_system/myfiles5/home/lab/bigfile1 503 Service Unavailable [first 60 chars of response] 503 Service Unavailable The server is currently unavailable lab@proxy01:~/bin$ ./swiftcl.sh stat swift -A http://proxy01:8080/auth/v1.0 -U system:root -K testpass stat Account: AUTH_system Containers: 6 Objects: 5 Bytes: 59756210 Accept-Ranges: bytes X-Timestamp: 1351294912.72119 Here's the corresponding log on the Proxy: Oct 26 17:06:52 proxy01 proxy-server - 127.0.0.1 27/Oct/2012/00/06/52 GET /auth/v1.0/ HTTP/1.0 200 - - - - - - - - 0.0010 Oct 26 17:07:13 proxy01 proxy-server - 127.0.0.1 27/Oct/2012/00/07/13 GET /auth/v1.0/ HTTP/1.0 200 - - - - - - - - 0.0017 Oct 26 17:07:13 proxy01 proxy-server - 127.0.0.1 27/Oct/2012/00/07/13 GET /auth/v1.0/ HTTP/1.0 200 - - - - - - - - 0.0016 Oct 26 17:07:22 proxy01 proxy-server - 127.0.0.1 27/Oct/2012/00/07/22 GET /auth/v1.0/ HTTP/1.0 200 - - - - - - - - 0.0010 Oct 26 17:07:22 proxy01 proxy-server - 127.0.0.1 27/Oct/2012/00/07/22 GET /auth/v1.0/ HTTP/1.0 200 - - - - - - - - 0.0016 Oct 26 17:07:27 proxy01 proxy-server - 127.0.0.1 27/Oct/2012/00/07/27 GET /auth/v1.0/ HTTP/1.0 200 - - - - - - - - 0.0010 Oct 26 17:07:27 proxy01 proxy-server - 127.0.0.1 27/Oct/2012/00/07/27 GET /auth/v1.0/ HTTP/1.0 200 - - - - - - - - 0.0016 Oct 26 17:07:27 proxy01 proxy-server Handoff requested (1) (txn: tx6946419daba54efe9c2878f8a2a78f88) (client_ip: 172.16.1.111) Oct 26 17:07:27 proxy01 proxy-server Handoff requested (2) (txn: tx6946419daba54efe9c2878f8a2a78f88) (client_ip: 172.16.1.111) Oct 26 17:07:33 proxy01 proxy-server - 127.0.0.1 27/Oct/2012/00/07/33 GET /auth/v1.0/ HTTP/1.0 200 - - - - - - - - 0.0010 Oct 26 17:07:33 proxy01 proxy-server - 127.0.0.1 27/Oct/2012/00/07/33 GET /auth/v1.0/ HTTP/1.0 200 - - - - - - - - 0.0016 Oct 26 17:07:33 proxy01 proxy-server Handoff requested (1) (txn: tx5f9659f74cb2491f9a63cbb84f680c5c) (client_ip: 172.16.1.111) Oct 26 17:07:33 proxy01 proxy-server Handoff requested (2) (txn:
Re: [Openstack] Troubleshooting Swift 1.7.4 on mini servers
Also check the number of inodes used: `df -i` --John On Oct 29, 2012, at 8:31 AM, Nathan Trueblood nat...@truebloodllc.com wrote: Yeah, I read about the 507 error.However, when the error occurs on my I can see with 'df' that the drive is only 1% full and is definitely not unmounted. I can write files to the mounted filesystem directly before, during, and after the Swift error occurs. So the problem must be some kind of timeout that is causing the object server to think that something is wrong with the disk. I'll keep digging... On Fri, Oct 26, 2012 at 11:21 PM, John Dickinson m...@not.mn wrote: A 507 is returned by the object servers in 2 situations: 1) the drives are full or 2) the drives have been unmounted because of disk error. It's highly likely that you simply have full drives. Remember that the usable space in your cluster is 1/N where N = replica count. As an example, with 3 replicas and 5 nodes with a single 1TB drive each, you only have about 1.6TB available for data. As Pete suggested in his response, how big are your drives, and what does `df` tell you? --John On Oct 26, 2012, at 5:26 PM, Nathan Trueblood nat...@truebloodllc.com wrote: Hey folks- I'm trying to figure out what's going wrong with my Swift deployment on a small cluster of mini servers. I have a small test cluster (5 storage nodes, 1 proxy) of mini-servers that are ARM-based. The proxy is a regular, Intel-based server with plenty of RAM. The object/account/container servers are relatively small, with 2GB of RAM per node. Everything starts up fine, but now I'm trying to troubleshoot a strange problem. After I successfully upload a few test files, it seems like the storage system stops responding and the proxy gives me a 503 error. Here's the test sequence I run on my proxy: lab@proxy01:~/bin$ ./swiftcl.sh stat swift -A http://proxy01:8080/auth/v1.0 -U system:root -K testpass stat Account: AUTH_system Containers: 5 Objects: 4 Bytes: 47804968 Accept-Ranges: bytes X-Timestamp: 1351294912.72119 lab@proxy01:~/bin$ ./swiftcl.sh upload myfiles1 /home/lab/bigfile1 swift -A http://proxy01:8080/auth/v1.0 -U system:root -K testpass upload myfiles1 /home/lab/bigfile1 home/lab/bigfile1 lab@proxy01:~/bin$ ./swiftcl.sh upload myfiles2 /home/lab/bigfile1 swift -A http://proxy01:8080/auth/v1.0 -U system:root -K testpass upload myfiles2 /home/lab/bigfile1 home/lab/bigfile1 lab@proxy01:~/bin$ ./swiftcl.sh upload myfiles3 /home/lab/bigfile1 swift -A http://proxy01:8080/auth/v1.0 -U system:root -K testpass upload myfiles3 /home/lab/bigfile1 home/lab/bigfile1 lab@proxy01:~/bin$ ./swiftcl.sh upload myfiles4 /home/lab/bigfile1 swift -A http://proxy01:8080/auth/v1.0 -U system:root -K testpass upload myfiles4 /home/lab/bigfile1 home/lab/bigfile1 lab@proxy01:~/bin$ ./swiftcl.sh upload myfiles5 /home/lab/bigfile1 swift -A http://proxy01:8080/auth/v1.0 -U system:root -K testpass upload myfiles5 /home/lab/bigfile1 Object PUT failed: http://172.16.1.111:8080/v1/AUTH_system/myfiles5/home/lab/bigfile1 503 Service Unavailable [first 60 chars of response] 503 Service Unavailable The server is currently unavailable lab@proxy01:~/bin$ ./swiftcl.sh stat swift -A http://proxy01:8080/auth/v1.0 -U system:root -K testpass stat Account: AUTH_system Containers: 6 Objects: 5 Bytes: 59756210 Accept-Ranges: bytes X-Timestamp: 1351294912.72119 Here's the corresponding log on the Proxy: Oct 26 17:06:52 proxy01 proxy-server - 127.0.0.1 27/Oct/2012/00/06/52 GET /auth/v1.0/ HTTP/1.0 200 - - - - - - - - 0.0010 Oct 26 17:07:13 proxy01 proxy-server - 127.0.0.1 27/Oct/2012/00/07/13 GET /auth/v1.0/ HTTP/1.0 200 - - - - - - - - 0.0017 Oct 26 17:07:13 proxy01 proxy-server - 127.0.0.1 27/Oct/2012/00/07/13 GET /auth/v1.0/ HTTP/1.0 200 - - - - - - - - 0.0016 Oct 26 17:07:22 proxy01 proxy-server - 127.0.0.1 27/Oct/2012/00/07/22 GET /auth/v1.0/ HTTP/1.0 200 - - - - - - - - 0.0010 Oct 26 17:07:22 proxy01 proxy-server - 127.0.0.1 27/Oct/2012/00/07/22 GET /auth/v1.0/ HTTP/1.0 200 - - - - - - - - 0.0016 Oct 26 17:07:27 proxy01 proxy-server - 127.0.0.1 27/Oct/2012/00/07/27 GET /auth/v1.0/ HTTP/1.0 200 - - - - - - - - 0.0010 Oct 26 17:07:27 proxy01 proxy-server - 127.0.0.1 27/Oct/2012/00/07/27 GET /auth/v1.0/ HTTP/1.0 200 - - - - - - - - 0.0016 Oct 26 17:07:27 proxy01 proxy-server Handoff requested (1) (txn: tx6946419daba54efe9c2878f8a2a78f88) (client_ip: 172.16.1.111) Oct 26 17:07:27 proxy01 proxy-server Handoff requested (2) (txn: tx6946419daba54efe9c2878f8a2a78f88) (client_ip: 172.16.1.111) Oct 26 17:07:33 proxy01 proxy-server - 127.0.0.1 27/Oct/2012/00/07/33 GET /auth/v1.0/ HTTP/1.0 200 - - - - - - - - 0.0010 Oct 26 17:07:33 proxy01 proxy-server - 127.0.0.1 27/Oct/2012/00/07/33 GET /auth/v1.0/ HTTP/1.0 200 - - - - - - - -
[Openstack] Allocate specific floating IP to an instance
Hi Stacker, I know OpenStack is not designed that way and I don't think it's possible (or maybe I misses something :)) but I was wondering if there is any simple workaround to choose a specific floating IP to allocate. In other words, don't give me a random or N+1 next floating IP available but let me decide which floating IP I want to assign to my instance. It doesn't make sense in a public cloud but it does for a corporate/private cloud. It would be nice to have :) Thanks in advance. Cheers! ___ 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] Quotas in folsom
On Mon, 2012-10-29 at 10:53 -0400, Mitchell Broome wrote: I'm running into quota problems trying to increase the number of security groups and rules within security groups per tenant. Setting quota_security_groups and quota_security_group_rules in nova.conf seem to have no effect. There also doesn't seem to be any way to change the quota limits for security groups through the nova client or horizon. The quotas system checks the database for quotas specific to the tenant, then for quotas for the tenant's quota class (if you're using quota classes). Only if it can't find any such quotas will it go to the values defined in nova.conf. You're right that these particular quotas are not among the quotas recognized by the nova shell command, but you can access them through the pythonic API; I'm guessing that the new quotas were added to nova itself during the folsom release cycle, but nobody remembered to update novaclient to recognize them. Could you log a bug against folsom for that, please? How do I go about changing these quotas or is there a way to disable all quotas all together? Check the database itself for quota records for your tenants; you can revert to defaults (drawn from nova.conf) by deleting any 'quotas' table rows for the resources you're interested in. If it still doesn't take the values you set in nova.conf, then there's likely some other bug that needs to be looked into… -- Kevin L. Mitchell kevin.mitch...@rackspace.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] Instrumentation Monitoring Next Step - quick meet up
I can't meet later than that tonight. Doug On Mon, Oct 29, 2012 at 10:21 AM, Sandy Walsh sandy.wa...@rackspace.comwrote: Ugh, I just realized I have a conflict. Can we push it an hour later? (sorry!) -S -- *From:* openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net[openstack-bounces+sandy.walsh= rackspace@lists.launchpad.net] on behalf of Annie Cheng [ ann...@yahoo-inc.com] *Sent:* Monday, October 29, 2012 11:18 AM *To:* openstack@lists.launchpad.net *Subject:* Re: [Openstack] Instrumentation Monitoring Next Step - quick meet up Apologize .. Correction Time: Monday (10/29/2012) 2200 UTC – 2300 UTC (*3pm PDT *if you are in California) Location: IRC #openstack-meeting From: Annie Cheng ann...@yahoo-inc.com Date: Mon, 29 Oct 2012 07:14:08 -0700 To: openstack@lists.launchpad.net openstack@lists.launchpad.net Subject: Re: [Openstack] Instrumentation Monitoring Next Step - quick meet up Reminder: Time: Monday (10/29/2012) 2200 UTC – 2300 UTC (2pm PDT if you are in California) Location: IRC #openstack-meeting Thanks! Annie From: Annie Cheng ann...@yahoo-inc.com Date: Thu, 25 Oct 2012 14:17:09 -0700 To: openstack@lists.launchpad.net openstack@lists.launchpad.net Subject: [Openstack] Instrumentation Monitoring Next Step - quick meet up Hi all, Couple of us chat in the summit design sessions and and after summit on #openstack irc regarding topic of Monitoring. We think it's best to do a quick meeting to get everyone on the same page, split works, and get at least a prototype going in Grizzly. Time: Monday (10/29/2012) 2200 UTC – 2300 UTC Location: IRC #openstack-meeting I checked http://wiki.openstack.org/Meetings, this tme slot seems to be empty Top level agenda would be 1. Get everyone on the same page on high level direction 2. Discuss different design/implementation possibility 3. Split up works Before the meeting, if you want to read up, here are some links I know. Please jump in with others I missed: Blueprint: https://blueprints.launchpad.net/nova/+spec/nova-instrumentation-metrics-monitoring Etherpad: https://etherpad.openstack.org/grizzly-common-instrumentation Different code samples: https://github.com/asalkeld/statgen Looking forward, some of those conversation probably will fold into the regular Metering meeting. Just like to do a one off for now so we can go deeper on monitoring specific topics. Thanks! Annie ___ 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] Instrumentation Monitoring Next Step - quick meet up
We also have to stick with the schedule on our end. Sandy, all discussion will be tracked in IRC log. We can also have follow up discussion via mailing list or more meetings. Annie From: Doug Hellmann [mailto:doug.hellm...@dreamhost.com] Sent: Monday, October 29, 2012 09:37 AM To: Sandy Walsh sandy.wa...@rackspace.com Cc: Annie Cheng; openstack@lists.launchpad.net openstack@lists.launchpad.net Subject: Re: [Openstack] Instrumentation Monitoring Next Step - quick meet up I can't meet later than that tonight. Doug On Mon, Oct 29, 2012 at 10:21 AM, Sandy Walsh sandy.wa...@rackspace.commailto:sandy.wa...@rackspace.com wrote: Ugh, I just realized I have a conflict. Can we push it an hour later? (sorry!) -S From: openstack-bounces+sandy.walsh=rackspace@lists.launchpad.netmailto:rackspace@lists.launchpad.net [openstack-bounces+sandy.walsh=rackspace@lists.launchpad.netmailto:rackspace@lists.launchpad.net] on behalf of Annie Cheng [ann...@yahoo-inc.commailto:ann...@yahoo-inc.com] Sent: Monday, October 29, 2012 11:18 AM To: openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net Subject: Re: [Openstack] Instrumentation Monitoring Next Step - quick meet up Apologize .. Correction Time: Monday (10/29/2012) 2200 UTC – 2300 UTC (3pm PDT if you are in California) Location: IRC #openstack-meeting From: Annie Cheng ann...@yahoo-inc.commailto:ann...@yahoo-inc.com Date: Mon, 29 Oct 2012 07:14:08 -0700 To: openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net Subject: Re: [Openstack] Instrumentation Monitoring Next Step - quick meet up Reminder: Time: Monday (10/29/2012) 2200 UTC – 2300 UTC (2pm PDT if you are in California) Location: IRC #openstack-meeting Thanks! Annie From: Annie Cheng ann...@yahoo-inc.commailto:ann...@yahoo-inc.com Date: Thu, 25 Oct 2012 14:17:09 -0700 To: openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net Subject: [Openstack] Instrumentation Monitoring Next Step - quick meet up Hi all, Couple of us chat in the summit design sessions and and after summit on #openstack irc regarding topic of Monitoring. We think it's best to do a quick meeting to get everyone on the same page, split works, and get at least a prototype going in Grizzly. Time: Monday (10/29/2012) 2200 UTC – 2300 UTC Location: IRC #openstack-meeting I checked http://wiki.openstack.org/Meetings, this tme slot seems to be empty Top level agenda would be 1. Get everyone on the same page on high level direction 2. Discuss different design/implementation possibility 3. Split up works Before the meeting, if you want to read up, here are some links I know. Please jump in with others I missed: Blueprint: https://blueprints.launchpad.net/nova/+spec/nova-instrumentation-metrics-monitoring Etherpad: https://etherpad.openstack.org/grizzly-common-instrumentation Different code samples: https://github.com/asalkeld/statgen Looking forward, some of those conversation probably will fold into the regular Metering meeting. Just like to do a one off for now so we can go deeper on monitoring specific topics. Thanks! Annie ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.netmailto: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] Instrumentation Monitoring Next Step - quick meet up
np ... I realize it's tricky to change this stuff. I'll see if I can jump on remote. -S From: Annie Cheng [ann...@yahoo-inc.com] Sent: Monday, October 29, 2012 1:44 PM To: 'doug.hellm...@dreamhost.com'; Sandy Walsh Cc: 'openstack@lists.launchpad.net' Subject: Re: [Openstack] Instrumentation Monitoring Next Step - quick meet up We also have to stick with the schedule on our end. Sandy, all discussion will be tracked in IRC log. We can also have follow up discussion via mailing list or more meetings. Annie From: Doug Hellmann [mailto:doug.hellm...@dreamhost.com] Sent: Monday, October 29, 2012 09:37 AM To: Sandy Walsh sandy.wa...@rackspace.com Cc: Annie Cheng; openstack@lists.launchpad.net openstack@lists.launchpad.net Subject: Re: [Openstack] Instrumentation Monitoring Next Step - quick meet up I can't meet later than that tonight. Doug On Mon, Oct 29, 2012 at 10:21 AM, Sandy Walsh sandy.wa...@rackspace.commailto:sandy.wa...@rackspace.com wrote: Ugh, I just realized I have a conflict. Can we push it an hour later? (sorry!) -S From: openstack-bounces+sandy.walsh=rackspace@lists.launchpad.netmailto:rackspace@lists.launchpad.net [openstack-bounces+sandy.walsh=rackspace@lists.launchpad.netmailto:rackspace@lists.launchpad.net] on behalf of Annie Cheng [ann...@yahoo-inc.commailto:ann...@yahoo-inc.com] Sent: Monday, October 29, 2012 11:18 AM To: openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net Subject: Re: [Openstack] Instrumentation Monitoring Next Step - quick meet up Apologize .. Correction Time: Monday (10/29/2012) 2200 UTC – 2300 UTC (3pm PDT if you are in California) Location: IRC #openstack-meeting From: Annie Cheng ann...@yahoo-inc.commailto:ann...@yahoo-inc.com Date: Mon, 29 Oct 2012 07:14:08 -0700 To: openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net Subject: Re: [Openstack] Instrumentation Monitoring Next Step - quick meet up Reminder: Time: Monday (10/29/2012) 2200 UTC – 2300 UTC (2pm PDT if you are in California) Location: IRC #openstack-meeting Thanks! Annie From: Annie Cheng ann...@yahoo-inc.commailto:ann...@yahoo-inc.com Date: Thu, 25 Oct 2012 14:17:09 -0700 To: openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net Subject: [Openstack] Instrumentation Monitoring Next Step - quick meet up Hi all, Couple of us chat in the summit design sessions and and after summit on #openstack irc regarding topic of Monitoring. We think it's best to do a quick meeting to get everyone on the same page, split works, and get at least a prototype going in Grizzly. Time: Monday (10/29/2012) 2200 UTC – 2300 UTC Location: IRC #openstack-meeting I checked http://wiki.openstack.org/Meetings, this tme slot seems to be empty Top level agenda would be 1. Get everyone on the same page on high level direction 2. Discuss different design/implementation possibility 3. Split up works Before the meeting, if you want to read up, here are some links I know. Please jump in with others I missed: Blueprint: https://blueprints.launchpad.net/nova/+spec/nova-instrumentation-metrics-monitoring Etherpad: https://etherpad.openstack.org/grizzly-common-instrumentation Different code samples: https://github.com/asalkeld/statgen Looking forward, some of those conversation probably will fold into the regular Metering meeting. Just like to do a one off for now so we can go deeper on monitoring specific topics. Thanks! Annie ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.netmailto: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] Local vlan id number is less than virtual network numbers
this was answered in LP questions: https://answers.launchpad.net/quantum/+question/212613 dan On Thu, Oct 25, 2012 at 2:45 AM, 吉海 thesea1...@gmail.com wrote: Hello, i am a new quantum fun. I have a question about provision local vlan of ovs plugin. Plugin ovs agent can provide 4094 local vlan for local vlan mapping on integration bridge 'br-int'. But each physical network can have a vlan range, it may be 1-4094. If compute node has two physical network. Each physical network vlan range is 1 - 4094. The node supports 4094 * 2 network. Now plugin agent of this node can only provide 4094 local vlan id for mapping physical network segmentation id(physical vlan id). If i create other network more than 4094, it will log error No local VLAN availabel for net-id= . Is it right? ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- ~~~ Dan Wendlandt Nicira, Inc: www.nicira.com twitter: danwendlandt ~~~ ___ 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] Quotas in folsom
It's also worth noting that we are now in territory where quotas are controlled by multiple projects: volumes and gigabytes have quotas in both Nova and Cinder; network quotas are in both Nova and Quantum... While I don't think it makes sense to try and centralize these things, I think the projects could coordinate more to understand who should be managing a given quota and to try and make the end-user experience less baffling. - Gabriel -Original Message- From: openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net [mailto:openstack- bounces+gabriel.hurley=nebula@lists.launchpad.net] On Behalf Of Kevin L. Mitchell Sent: Monday, October 29, 2012 9:28 AM To: openstack@lists.launchpad.net Subject: Re: [Openstack] Quotas in folsom On Mon, 2012-10-29 at 10:53 -0400, Mitchell Broome wrote: I'm running into quota problems trying to increase the number of security groups and rules within security groups per tenant. Setting quota_security_groups and quota_security_group_rules in nova.conf seem to have no effect. There also doesn't seem to be any way to change the quota limits for security groups through the nova client or horizon. The quotas system checks the database for quotas specific to the tenant, then for quotas for the tenant's quota class (if you're using quota classes). Only if it can't find any such quotas will it go to the values defined in nova.conf. You're right that these particular quotas are not among the quotas recognized by the nova shell command, but you can access them through the pythonic API; I'm guessing that the new quotas were added to nova itself during the folsom release cycle, but nobody remembered to update novaclient to recognize them. Could you log a bug against folsom for that, please? How do I go about changing these quotas or is there a way to disable all quotas all together? Check the database itself for quota records for your tenants; you can revert to defaults (drawn from nova.conf) by deleting any 'quotas' table rows for the resources you're interested in. If it still doesn't take the values you set in nova.conf, then there's likely some other bug that needs to be looked into… -- Kevin L. Mitchell kevin.mitch...@rackspace.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] new mailing list for bare-metal provisioning
subscribe to the Nova topic at the link above. When I write a message about nova I have to add '[Nova]' (or 'Nova') anywhere in the subject (Sidenote: does 'Nova' actually work? Looks to me like the regex in mailman requires the square braces...) Personally I'm fine with either model, but just to call out the common complaint I hear about topics: I think a lot of folks feel that what you just pointed out is actually a major weakness. The topic functionality requires that *each individual sender* be aware of that functionality and format his subject lines accordingly. That often doesn't happen even with folks who've been active in the community for some time, let alone folks who are new. When someone doesn't format his subject properly, it either causes clutter when email sorting filters break or causes folks to miss messages about things they care about if they've subscribed only to particular topics. I know there have been at least a couple of threads about Quantum in the past couple of weeks (one pertaining to Ceilometer integration, one pertaining to the Folsom stable branch come to mind) that didn't have [Quantum] (or [Ceilometer] for that matter) in the subject line. Thus, I'd have missed those messages if I were only subscribed to the Quantum topic. Personally I like to see everything so it doesn't much matter to me other than in how I set up my email filters, but I think perhaps this is one reason why we've had the discussion about more vs fewer mailing lists more than once. At Your Service, Mark T. Voelker On 10/29/2012 09:01 AM, Stefano Maffulli wrote: On 10/29/2012 12:32 PM, Thierry Carrez wrote: We really shouldn't go in that direction: the openstack-dev list is already an aggregator of topics, since we use mailman topics on it. Indeed, mailman topics are very powerful. The current topics for openstack-dev are listed on each subscriber's personal page: http://lists.openstack.org/cgi-bin/mailman/options/openstack-dev As a subscriber of openstack-dev I can decide to receive only messages tagged for a topic by selecting the ones I'm interested in. As a writer of a message I can tag it by adding the topic to the subject line of the message. For example, if I want to receive only messages for Nova, I can subscribe to the Nova topic at the link above. When I write a message about nova I have to add '[Nova]' (or 'Nova') anywhere in the subject. Creating a topic of bare-metal is easy, using topics is a matter of habit. I believe that we should not create more lists unless strictly necessary. I also understood from David that the baremetal group felt very strongly against using any of the existing list, even when I suggested to use topics. I'm glad we're having this conversation now and I'm open to any outcome. /stef ___ 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] quantum: two ips one vif
On Fri, Oct 26, 2012 at 4:12 PM, Carl Bolterstein cbolterst...@blackmesh.com wrote: For the curiosity sake - After some trial and error. It appears we have solved one half of our conundrum. Using the driver below, there is no ip data inserted into libvirt.xml which allows any ip to be used. It works for our uses (HA vip services, secondary addresses). libvirt_vif_driver=nova.virt.libvirt.vif.LibvirtOpenVswitchVirtualPortDriver yes, the docs here (http://docs.openstack.org/trunk/openstack-network/admin/content/nova_with_quantum_vifplugging_ovs.html) talk about using the hybrid driver if you care about security groups. We should expand it to also mention that this applies for spoof-prevention as well. This however does not prevent quantum from assigning a used IP to a new port, but working on that. Would be great if you can provide more detail there. Dan Carl Bolterstein -Original Message- From: openstack-bounces+cbolterstein=blackmesh@lists.launchpad.net [mailto:openstack-bounces+cbolterstein=blackmesh@lists.launchpad.net] On Behalf Of Jason Kölker Sent: Tuesday, October 23, 2012 6:38 PM To: openstack@lists.launchpad.net Subject: Re: [Openstack] quantum: two ips one vif On Tue, 2012-10-23 at 15:14 -0700, Dan Wendlandt wrote: can you post your libvirt xml for the VM? It maybe well be libvirt filtering if you are using the OVS Hybrid vif driver: for example, a VM would have xml like: filterref filter='nova-instance-instance-0001-fa163e0569ba' parameter name='DHCPSERVER' value='10.0.0.2'/ parameter name='IP' value='10.0.0.3'/ parameter name='PROJMASK' value='255.255.0.0'/ parameter name='PROJNET' value='10.0.0.0'/ /filterref I'm not sure what the nova code would generate for multiple IPs. Libvirt's driver only supports 1 ip per interface. It needs to be updated to use the newer network models and not depend on the code in nova.virt.netutils.get_injected_network_template. Happy Hacking! 7-11 ___ 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 -- ~~~ Dan Wendlandt Nicira, Inc: www.nicira.com twitter: danwendlandt ~~~ ___ 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] Looking for a mailman administrator
Hello folks, We need a new administrator for the mailman installation on lists.openstack.org. Duncan McGreggor has helped the community a lot in the past months, setting up the new machine, configuring and testing mailman's upgrades from the old servers and running the setup since June. I'm very grateful to him for this. He just communicated to me that he can't take care of lists.openstack.org anymore. The person should be familiar with mailman and have time to help migrate the General list from Launchpad to lists.openstack.org, as we agreed. If you (know somebody that) want to do it please contact me offlist. Thank you, Stefano ___ 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] Quotas in folsom
On Mon, 2012-10-29 at 18:01 +, Gabriel Hurley wrote: It's also worth noting that we are now in territory where quotas are controlled by multiple projects: volumes and gigabytes have quotas in both Nova and Cinder; network quotas are in both Nova and Quantum... While I don't think it makes sense to try and centralize these things, I think the projects could coordinate more to understand who should be managing a given quota and to try and make the end-user experience less baffling. It's also worth noting that I've finally been able to start working on Boson, which may help with that… -- Kevin L. Mitchell kevin.mitch...@rackspace.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] Finding/Making Windows 7 Images for OpenStack
On Wed, Oct 24, 2012 at 3:05 PM, Mark Lehrer m...@knm.org wrote: for OpenStack? I know it's supposed to be as easy as using kvm to install it initially (as per the OpenStack docs) then importing that image into glance, but there are some subtle things that I might be Nope, it is indeed that simple. Make sure you use the same hardware settings as Openstack for the nic and disk and configure DHCP. It certainly might be that simple for a single instance, but I had trouble reusing that instance without using sysprep and generalize. Thanks, Curtis. However, activation and licensing can be annoying. We are considering using the datacenter edition here for this reason. Mark -- Twitter: @serverascode Blog: serverascode.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] Quotas in folsom
+1 for Boson ... this is a key area for CERN too. When you have a fixed budget and no credit cards, quota management is a strong requirement! Tim -Original Message- From: openstack-bounces+tim.bell=cern...@lists.launchpad.net [mailto:openstack-bounces+tim.bell=cern...@lists.launchpad.net] On Behalf Of Kevin L. Mitchell Sent: 29 October 2012 20:26 To: openstack@lists.launchpad.net Subject: Re: [Openstack] Quotas in folsom On Mon, 2012-10-29 at 18:01 +, Gabriel Hurley wrote: It's also worth noting that we are now in territory where quotas are controlled by multiple projects: volumes and gigabytes have quotas in both Nova and Cinder; network quotas are in both Nova and Quantum... While I don't think it makes sense to try and centralize these things, I think the projects could coordinate more to understand who should be managing a given quota and to try and make the end-user experience less baffling. It's also worth noting that I've finally been able to start working on Boson, which may help with that… -- Kevin L. Mitchell kevin.mitch...@rackspace.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 smime.p7s Description: S/MIME cryptographic 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] Instance provisioning taking more time for all the instances
Hi Nagaraju, apologies for long delay in replying. Answer inline. On 09/29/2012 05:40 AM, Nagaraju Bingi wrote: Hi, We have deployed Openstack on VMware and we could able to provision Instances but image is not getting cached on compute/ESX server and for every provisioning of instances the image is getting downloaded from glance. Please provide steps to cache VMDK images on compute. I've cc'd Mikal Still, who wrote the original image cache in the libvirt driver. I'm not sure but I think work was done in Folsom to make the image cache more generic, but I'm not totally sure. Hoping Mikal has an answer to that. All the best, -jay ___ 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] Troubleshooting Swift 1.7.4 on mini servers
Still no further clues. I re-created all the volumes I'm using for Swift. Plenty of Inodes free: lab@data02:~$ df -i FilesystemInodes IUsed IFree IUse% Mounted on /dev/sda2 12214272 39290 121749821% / none 107979 4821074971% /dev none 107979 2681077111% /run none 107979 21079771% /run/lock none 107979 11079781% /run/shm /dev/sda1 4915223 491291% /boot /dev/sda4 13404640037 1340463631% /srv/node/sda4 I successfully upload a small object to container cont1, then cont2. When I upload to cont3, I see the following in the object-server log (data02) This seems to be the problematic sequence: Data02 has ip 192.168.1.202 Data03 has ip 192.168.1.203 1. First the account server reports an HTTP 201 on the container from a different object server in a different zone. 2. Then the object server reports a 404 trying to HEAD the new object. 3. Then the object server reports a 507 trying to PUT the new object. From this point the operation eventually fails and the proxy reports a 503. Oct 29 17:58:20 data02 account-server 192.168.1.203 - - [30/Oct/2012:00:58:20 +] PUT /sda4/116021/AUTH_system/cont3 201 - tx5a3ca6c845af41928e0ba6b7bc58d2da - - 0.0082 Oct 29 17:58:20 data02 object-server 192.168.1.111 - - [30/Oct/2012:00:58:20 +] HEAD /sda4/257613/AUTH_system/cont3/home/lab/bigfile3 404 - - tx5f21503ff12e45e39a80eb52f6757261 - 0.0011 Oct 29 17:58:20 data02 object-server 192.168.1.111 - - [30/Oct/2012:00:58:20 +] PUT /sda4/257613/AUTH_system/cont3/home/lab/bigfile3 507 - - tx425494dc372740e28d043a07d3a08b9a - 0.0031 In an earlier, successful transaction I noticed that between Steps 1 and 2 above, there is a response from the container-server: Oct 29 17:57:59 data02 account-server 192.168.1.204 - - [30/Oct/2012:00:57:59 +] PUT /sda4/116021/AUTH_system/cont2 201 - txb10d75886bf14e4eba14fcc52d81c5d9 - - 0.0182 Oct 29 17:57:59 data02 container-server 192.168.1.111 - - [30/Oct/2012:00:57:59 +] PUT /sda4/122355/AUTH_system/cont2 201 - txb10d75886bf14e4eba14fcc52d81c5d9 - - 0.1554 Oct 29 17:57:59 data02 object-server 192.168.1.111 - - [30/Oct/2012:00:57:59 +] HEAD /sda4/226151/AUTH_system/cont2/home/lab/bigfile3 404 - - tx1c514850530849d1bfbfa716d9039b87 - 0.0012 Oct 29 17:57:59 data02 container-server 192.168.1.204 - - [30/Oct/2012:00:57:59 +] PUT /sda4/122355/AUTH_system/cont2/home/lab/bigfile3 201 - tx8130af5cae484e5f9c5a25541d1c87aa - - 0.0041 Oct 29 17:57:59 data02 object-server 192.168.1.111 - - [30/Oct/2012:00:57:59 +] PUT /sda4/226151/AUTH_system/cont2/home/lab/bigfile3 201 - - tx8130af5cae484e5f9c5a25541d1c87aa - 0.1716 So maybe the container server is failing to create the new container? Maybe a bug in auto-create of containers? Definitely NOT a problem with the filesystem, but something is causing the object-server to think there is a problem with the filesystem. I suspect a bug in one of the underlying libraries. Any further suggestions on how to troubleshoot? Thanks. When I finally find the solution, I'll post my results. -N On Fri, Oct 26, 2012 at 11:21 PM, John Dickinson m...@not.mn wrote: A 507 is returned by the object servers in 2 situations: 1) the drives are full or 2) the drives have been unmounted because of disk error. It's highly likely that you simply have full drives. Remember that the usable space in your cluster is 1/N where N = replica count. As an example, with 3 replicas and 5 nodes with a single 1TB drive each, you only have about 1.6TB available for data. As Pete suggested in his response, how big are your drives, and what does `df` tell you? --John On Oct 26, 2012, at 5:26 PM, Nathan Trueblood nat...@truebloodllc.com wrote: Hey folks- I'm trying to figure out what's going wrong with my Swift deployment on a small cluster of mini servers. I have a small test cluster (5 storage nodes, 1 proxy) of mini-servers that are ARM-based. The proxy is a regular, Intel-based server with plenty of RAM. The object/account/container servers are relatively small, with 2GB of RAM per node. Everything starts up fine, but now I'm trying to troubleshoot a strange problem. After I successfully upload a few test files, it seems like the storage system stops responding and the proxy gives me a 503 error. Here's the test sequence I run on my proxy: lab@proxy01:~/bin$ ./swiftcl.sh stat swift -A http://proxy01:8080/auth/v1.0 -U system:root -K testpass stat Account: AUTH_system Containers: 5 Objects: 4 Bytes: 47804968 Accept-Ranges: bytes X-Timestamp: 1351294912.72119 lab@proxy01:~/bin$ ./swiftcl.sh upload myfiles1 /home/lab/bigfile1 swift -A http://proxy01:8080/auth/v1.0 -U system:root -K testpass upload myfiles1 /home/lab/bigfile1 home/lab/bigfile1 lab@proxy01:~/bin$ ./swiftcl.sh upload myfiles2 /home/lab/bigfile1 swift -A
[Openstack] Action Required: Use DocImpact flag when commits might impact docs
TL;DR - If anything you submit could have an impact on documentation, just add DocImpact to a line in your commit message. Developers, We need your help. In the face of the 500 contributors to the code base, those small handful of us working on documentation are losing the war. One of the worst pains we have right now is that we're not getting information from you about the changes you make. We just don't have the people to review every single commit on every single project for its impact on documentation. This is where you can make a difference. If your commit could have an impact on documentation - be it an added/altered/removed commandline option, a deprecated or new feature, a caveat, if you've written docs in the patch, or if you're just not sure - there's a way to let us know. = Just add DocImpact to a line in your commit message. This sends us an email so we can triage. It doesn't guarantee docs will be written, but at least it gives us visibility of the changes. Thanks for reading. As always - if you have any time to write/fix docs, we've more than one hundred bugs waiting for your contribution . . . Regards, Tom, on behalf of the docs team. ___ 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] Troubleshooting Swift 1.7.4 on mini servers
There are any error about disk in the kern.log? 2012/10/30 Nathan Trueblood nat...@truebloodllc.com Still no further clues. I re-created all the volumes I'm using for Swift. Plenty of Inodes free: lab@data02:~$ df -i FilesystemInodes IUsed IFree IUse% Mounted on /dev/sda2 12214272 39290 121749821% / none 107979 4821074971% /dev none 107979 2681077111% /run none 107979 21079771% /run/lock none 107979 11079781% /run/shm /dev/sda1 4915223 491291% /boot /dev/sda4 13404640037 1340463631% /srv/node/sda4 I successfully upload a small object to container cont1, then cont2. When I upload to cont3, I see the following in the object-server log (data02) This seems to be the problematic sequence: Data02 has ip 192.168.1.202 Data03 has ip 192.168.1.203 1. First the account server reports an HTTP 201 on the container from a different object server in a different zone. 2. Then the object server reports a 404 trying to HEAD the new object. 3. Then the object server reports a 507 trying to PUT the new object. From this point the operation eventually fails and the proxy reports a 503. Oct 29 17:58:20 data02 account-server 192.168.1.203 - - [30/Oct/2012:00:58:20 +] PUT /sda4/116021/AUTH_system/cont3 201 - tx5a3ca6c845af41928e0ba6b7bc58d2da - - 0.0082 Oct 29 17:58:20 data02 object-server 192.168.1.111 - - [30/Oct/2012:00:58:20 +] HEAD /sda4/257613/AUTH_system/cont3/home/lab/bigfile3 404 - - tx5f21503ff12e45e39a80eb52f6757261 - 0.0011 Oct 29 17:58:20 data02 object-server 192.168.1.111 - - [30/Oct/2012:00:58:20 +] PUT /sda4/257613/AUTH_system/cont3/home/lab/bigfile3 507 - - tx425494dc372740e28d043a07d3a08b9a - 0.0031 In an earlier, successful transaction I noticed that between Steps 1 and 2 above, there is a response from the container-server: Oct 29 17:57:59 data02 account-server 192.168.1.204 - - [30/Oct/2012:00:57:59 +] PUT /sda4/116021/AUTH_system/cont2 201 - txb10d75886bf14e4eba14fcc52d81c5d9 - - 0.0182 Oct 29 17:57:59 data02 container-server 192.168.1.111 - - [30/Oct/2012:00:57:59 +] PUT /sda4/122355/AUTH_system/cont2 201 - txb10d75886bf14e4eba14fcc52d81c5d9 - - 0.1554 Oct 29 17:57:59 data02 object-server 192.168.1.111 - - [30/Oct/2012:00:57:59 +] HEAD /sda4/226151/AUTH_system/cont2/home/lab/bigfile3 404 - - tx1c514850530849d1bfbfa716d9039b87 - 0.0012 Oct 29 17:57:59 data02 container-server 192.168.1.204 - - [30/Oct/2012:00:57:59 +] PUT /sda4/122355/AUTH_system/cont2/home/lab/bigfile3 201 - tx8130af5cae484e5f9c5a25541d1c87aa - - 0.0041 Oct 29 17:57:59 data02 object-server 192.168.1.111 - - [30/Oct/2012:00:57:59 +] PUT /sda4/226151/AUTH_system/cont2/home/lab/bigfile3 201 - - tx8130af5cae484e5f9c5a25541d1c87aa - 0.1716 So maybe the container server is failing to create the new container? Maybe a bug in auto-create of containers? Definitely NOT a problem with the filesystem, but something is causing the object-server to think there is a problem with the filesystem. I suspect a bug in one of the underlying libraries. Any further suggestions on how to troubleshoot? Thanks. When I finally find the solution, I'll post my results. -N On Fri, Oct 26, 2012 at 11:21 PM, John Dickinson m...@not.mn wrote: A 507 is returned by the object servers in 2 situations: 1) the drives are full or 2) the drives have been unmounted because of disk error. It's highly likely that you simply have full drives. Remember that the usable space in your cluster is 1/N where N = replica count. As an example, with 3 replicas and 5 nodes with a single 1TB drive each, you only have about 1.6TB available for data. As Pete suggested in his response, how big are your drives, and what does `df` tell you? --John On Oct 26, 2012, at 5:26 PM, Nathan Trueblood nat...@truebloodllc.com wrote: Hey folks- I'm trying to figure out what's going wrong with my Swift deployment on a small cluster of mini servers. I have a small test cluster (5 storage nodes, 1 proxy) of mini-servers that are ARM-based. The proxy is a regular, Intel-based server with plenty of RAM. The object/account/container servers are relatively small, with 2GB of RAM per node. Everything starts up fine, but now I'm trying to troubleshoot a strange problem. After I successfully upload a few test files, it seems like the storage system stops responding and the proxy gives me a 503 error. Here's the test sequence I run on my proxy: lab@proxy01:~/bin$ ./swiftcl.sh stat swift -A http://proxy01:8080/auth/v1.0 -U system:root -K testpass stat Account: AUTH_system Containers: 5 Objects: 4 Bytes: 47804968 Accept-Ranges: bytes X-Timestamp: 1351294912.72119 lab@proxy01:~/bin$ ./swiftcl.sh upload myfiles1 /home/lab/bigfile1 swift -A http://proxy01:8080/auth/v1.0 -U
Re: [Openstack] Troubleshooting Swift 1.7.4 on mini servers
On Mon, 29 Oct 2012 18:16:52 -0700 Nathan Trueblood nat...@truebloodllc.com wrote: Definitely NOT a problem with the filesystem, but something is causing the object-server to think there is a problem with the filesystem. If you are willing to go all-out, you can probably catch the error with strace, if it works on ARM. Failing that, find all places where 507 is generated and see if any exceptions are caught, by modifying the source, I'm afraid to say. I suspect a bug in one of the underlying libraries. That's a possibility. Or, it could be a kernel bug. You are using XFS, right? If it were something other than XFS or ext4, I would suspect ARM blowing over the 2GB barrier somewhere, since your object is called bigfile3. As it is, you have little option than to divide the layers until you identify the one that's broken. BTW, make sure to disable the fallocate, since we're at it. -- Pete ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
