[Openstack] grizzly swift keystone, http to 8080/8888 wont work
Dear List,
i got stuck with a setup of openstack grizzly. This setup consists of:
- swift proxy 1.0.8.1
- swift storage nodes 1.0.8.1
- keystone
- ceilometer
I kept browsing the web and reading openstack docs for days now and
can't just get it working right. Because of openstacks diversity a
wasn't able to find something really similar to my situation.
The thing is, i changed swift-proxy from using swauth to keystone.
Keystone and swift-proxy do interact all right as fare as i can say.
What i can't get working is that simple webpage which gave the ability
to log in as superuser, adding new user and so on. It is that webpart
that connects to the proxy on port 8080, respectively port .
Thx o lot for taking a look into this.
Axel
Theses are the browser urls i try:
(delay_auth_decision = 1)
http://the.swift.proxy:/auth/
bad url
Apr 16 11:49:31 ns-proxy01 swift-proxy Calling Swift3 Middleware (txn:
txcfde073b9ffe4f379da392056e2176de)
Apr 16 11:49:31 ns-proxy01 swift-proxy {'headers': {'Accept-Language':
'de-de,de;q=0.8,en-us;q=0.5,en;q=0.3', 'Accept-Encoding': 'gzip,
deflate', 'Host': 'backend', 'Accept':
'text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8',
'User-Agent': 'Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:20.0)
Gecko/20100101 Firefox/20.0', 'Connection': 'close', 'Content-Type':
None}, 'environ': {'SCRIPT_NAME': '', 'REQUEST_METHOD': 'GET',
'PATH_INFO': '/auth/', 'SERVER_PROTOCOL': 'HTTP/1.0', 'HTTP_USER_AGENT':
'Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:20.0) Gecko/20100101
Firefox/20.0', 'HTTP_CONNECTION': 'close', 'eventlet.posthooks': [],
'SERVER_NAME': '10.42.44.101', 'REMOTE_ADDR': '10.42.44.5',
'eventlet.input': ,
'wsgi.url_scheme': 'http', 'SERVER_PORT': '', 'wsgi.input':
, 'HTTP_HOST':
'backend', 'swift.cache': , 'wsgi.multithread': True, 'HTTP_ACCEPT':
'text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8',
'wsgi.version': (1, 0), 'GATEWAY_INTERFACE': 'CGI/1.1', 'wsgi.run_once':
False, 'wsgi.errors': , 'wsgi.multiprocess': False, 'HTTP_ACCEPT_LANGUAGE':
'de-de,de;q=0.8,en-us;q=0.5,en;q=0.3', 'swift.trans_id':
'txcfde073b9ffe4f379da392056e2176de', 'CONTENT_TYPE': None,
'HTTP_ACCEPT_ENCODING': 'gzip, deflate'}}
Apr 16 11:49:31 ns-proxy01 swift-proxy Authorizing as anonymous (txn:
txcfde073b9ffe4f379da392056e2176de)
Apr 16 11:49:31 ns-proxy01 swift-proxy 10.42.44.5 10.42.44.5
16/Apr/2013/09/49/31 GET /auth/ HTTP/1.0 412 -
Mozilla/5.0%20%28Macintosh%3B%20Intel%20Mac%20OS%20X%2010.8%3B%20rv%3A20.0%29%20Gecko/20100101%20Firefox/20.0
- - 7 - txcfde073b9ffe4f379da392056e2176de - 0.0003 -
(delay_auth_decision = 0)
http://the.swift.proxy:/auth/
401 Unauthorized
Apr 16 11:56:35 ns-proxy01 swift-proxy Calling Swift3 Middleware (txn:
tx508b08866bbc410399543d98cafa2856)
Apr 16 11:56:35 ns-proxy01 swift-proxy {'headers': {'Accept-Language':
'de-de,de;q=0.8,en-us;q=0.5,en;q=0.3', 'Accept-Encoding': 'gzip,
deflate', 'Host': 'backend', 'Accept':
'text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8',
'User-Agent': 'Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:20.0)
Gecko/20100101 Firefox/20.0', 'Connection': 'close', 'Cache-Control':
'max-age=0', 'Content-Type': None}, 'environ': {'SCRIPT_NAME': '',
'REQUEST_METHOD': 'GET', 'PATH_INFO': '/auth/', 'SERVER_PROTOCOL':
'HTTP/1.0', 'HTTP_USER_AGENT': 'Mozilla/5.0 (Macintosh; Intel Mac OS X
10.8; rv:20.0) Gecko/20100101 Firefox/20.0', 'HTTP_CONNECTION': 'close',
'eventlet.posthooks': [], 'SERVER_NAME': '10.42.44.101', 'REMOTE_ADDR':
'10.42.44.5', 'eventlet.input': , 'wsgi.url_scheme': 'http', 'SERVER_PORT': '',
'wsgi.input': ,
'HTTP_HOST': 'backend', 'swift.cache':
,
'wsgi.multithread': True, 'HTTP_CACHE_CONTROL': 'max-age=0',
'HTTP_ACCEPT':
'text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8',
'wsgi.version': (1, 0), 'GATEWAY_INTERFACE': 'CGI/1.1', 'wsgi.run_once':
False, 'wsgi.errors': , 'wsgi.multiprocess': False, 'HTTP_ACCEPT_LANGUAGE':
'de-de,de;q=0.8,en-us;q=0.5,en;q=0.3', 'swift.trans_id':
'tx508b08866bbc410399543d98cafa2856', 'CONTENT_TYPE': None,
'HTTP_ACCEPT_ENCODING': 'gzip, deflate'}}
export OS_SERVICE_TOKEN=XXX
export OS_SERVICE_ENDPOINT=http://10.42.44.101:35357/v2.0
root@ns-proxy01:/etc/swift# swift -V 2.0 -A
http://10.42.44.101:5000/v2.0 -U admin -K XXX stat
Account: AUTH_c2dc53651a73430db9e0551fca4200de
Containers: 4354
Objects: 2622
Bytes: 114207
Accept-Ranges: bytes
X-Timestamp: 1365601461.87732
X-Trans-Id: txa6273bb374d5468da6e4b6ad48929762
Content-Type: text/plain; charset=utf-8
root@ns-proxy01:/etc/swift# keystone --debug user-list
REQ: curl -i http://10.42.44.101:35357/v2.0/users -X GET -H "User-Agent:
python-keystoneclient" -H "X-Auth-Token: 6IHBKKwfVnHZf5ifGiQaRQL5u3hdYtPe"
RESP: [200] {'date': 'Tue, 16 Apr 2013 09:39:37 GMT', 'content-type':
'application/json', 'content-length': '860', 'vary': 'X-Auth-Token'}
RESP BODY: {"users": [{"name": "glance", "id":
"03c928bae5ad4a9f90be425c1ff554dd", "tenantId":
"054ca85bca2e44c2
Re: [Openstack] grizzly swift keystone, http to 8080/8888 wont work
Thanks for your quick reply, Simon,
The role ResellerAdmin does exists and looks good, does it?
root@ns-proxy01:/etc/swift# keystone user-get ceilometer
+--+--+
| Property | Value |
+--+--+
| email | |
| enabled | True |
|id| cde44fe9c6d446da99ea370b88ec7d63 |
| name |ceilometer|
| tenantId | 054ca85bca2e44c29cf4730e1450517f |
+--+--+
root@ns-proxy01:/etc/swift# keystone user-role-list --user-id
cde44fe9c6d446da99ea370b88ec7d63 --tenant-id
054ca85bca2e44c29cf4730e1450517f
+--+---+--+--+
|id| name | user_id
|tenant_id |
+--+---+--+--+
| c2df2bc0fd6f404794565f10cc0e5e7a | ResellerAdmin |
cde44fe9c6d446da99ea370b88ec7d63 | 054ca85bca2e44c29cf4730e1450517f |
| 9fe2ff9ee4384b1894a90878d3e92bab |_member_ |
cde44fe9c6d446da99ea370b88ec7d63 | 054ca85bca2e44c29cf4730e1450517f |
+--+---+--+--+
And i can see ceilometer log entrys, counting bytes. So that looks good.
My issue it, that with the old swauth setup there was a real simple web
based user manager.
surfing to "http://my.swift.proxy:/auth/"; was the entry url to this
sort of user manager. But now, after the change to keystone, i get http
result codes like 412 or 401.
Since i inherit this setup i even do not know for sure if this
swift-user-manager it actually a part of swift. i believe so.
Can please one confirm which urls do work on swift-proxy http port
8080/ (proxy-server.conf -> [DEFAULT] -> bind_port). Should "/auth/"
return a page?
Thank you. Axel
Am 16.04.13 12:41, schrieb Simon Pasquier:
> Hi,
> I'm not sure to understand exactly your issue but since your setup
> includes ceilometer, I can just give you a hint for the ceilometer/swift
> integration.
> You have to create a 'ResellerAdmin' role and assign that role to your
> ceilometer user. Alternatively you can define the 'reseller_admin_role'
> parameter (default value=ResellerAdmin) in the [filter:authtoken]
> section of /etc/swift/proxy-server.conf.
> Cheers,
> Simon
>
> Le 16/04/2013 12:04, Axel Christiansen a écrit :
>> Dear List,
>>
>>
>> i got stuck with a setup of openstack grizzly. This setup consists of:
>>
>> - swift proxy 1.0.8.1
>> - swift storage nodes 1.0.8.1
>> - keystone
>> - ceilometer
>>
>>
>> I kept browsing the web and reading openstack docs for days now and
>> can't just get it working right. Because of openstacks diversity a
>> wasn't able to find something really similar to my situation.
>>
>>
>> The thing is, i changed swift-proxy from using swauth to keystone.
>> Keystone and swift-proxy do interact all right as fare as i can say.
>> What i can't get working is that simple webpage which gave the ability
>> to log in as superuser, adding new user and so on. It is that webpart
>> that connects to the proxy on port 8080, respectively port .
>>
>>
>> Thx o lot for taking a look into this.
>> Axel
>>
>>
>>
>>
>> Theses are the browser urls i try:
>>
>> (delay_auth_decision = 1)
>> http://the.swift.proxy:/auth/
>> bad url
>> Apr 16 11:49:31 ns-proxy01 swift-proxy Calling Swift3 Middleware (txn:
>> txcfde073b9ffe4f379da392056e2176de)
>> Apr 16 11:49:31 ns-proxy01 swift-proxy {'headers': {'Accept-Language':
>> 'de-de,de;q=0.8,en-us;q=0.5,en;q=0.3', 'Accept-Encoding': 'gzip,
>> deflate', 'Host': 'backend', 'Accept':
>> 'text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8',
>> 'User-Agent': 'Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:20.0)
>> Gecko/20100101 Firefox/20.0', 'Connection': 'close', 'Content-Type':
>> None}, 'environ': {'SCRIPT_NAME': '', 'REQUEST_METHOD': 'GET',
>> 'PATH_INFO': '/auth/', 'SERVER_PROTOCOL': 'HTTP/1.0', 'HTTP_USER_AGENT':
>> 'Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:20.0) Gecko/20100101
>> Firefox/20.0', 'HTTP_CONNE
Re: [Openstack] grizzly swift keystone, http to 8080/8888 wont work
The mystery seems solved. There it a webadmin for swauth.
https://github.com/gholt/swauth#web-admin-install
Does there exists is similar thing for keystone?
Regards, Axel
Am 16.04.13 14:53, schrieb Axel Christiansen:
>
>
> Thanks for your quick reply, Simon,
>
>
> The role ResellerAdmin does exists and looks good, does it?
>
> root@ns-proxy01:/etc/swift# keystone user-get ceilometer
> +--+--+
> | Property | Value |
> +--+--+
> | email | |
> | enabled | True |
> |id| cde44fe9c6d446da99ea370b88ec7d63 |
> | name |ceilometer|
> | tenantId | 054ca85bca2e44c29cf4730e1450517f |
> +--+--+
> root@ns-proxy01:/etc/swift# keystone user-role-list --user-id
> cde44fe9c6d446da99ea370b88ec7d63 --tenant-id
> 054ca85bca2e44c29cf4730e1450517f
> +--+---+--+--+
> |id| name | user_id
> |tenant_id |
> +--+---+--+--+
> | c2df2bc0fd6f404794565f10cc0e5e7a | ResellerAdmin |
> cde44fe9c6d446da99ea370b88ec7d63 | 054ca85bca2e44c29cf4730e1450517f |
> | 9fe2ff9ee4384b1894a90878d3e92bab |_member_ |
> cde44fe9c6d446da99ea370b88ec7d63 | 054ca85bca2e44c29cf4730e1450517f |
> +--+---+--+--+
>
> And i can see ceilometer log entrys, counting bytes. So that looks good.
>
>
>
>
> My issue it, that with the old swauth setup there was a real simple web
> based user manager.
>
> surfing to "http://my.swift.proxy:/auth/"; was the entry url to this
> sort of user manager. But now, after the change to keystone, i get http
> result codes like 412 or 401.
>
>
> Since i inherit this setup i even do not know for sure if this
> swift-user-manager it actually a part of swift. i believe so.
>
>
> Can please one confirm which urls do work on swift-proxy http port
> 8080/ (proxy-server.conf -> [DEFAULT] -> bind_port). Should "/auth/"
> return a page?
>
>
> Thank you. Axel
>
>
>
>
> Am 16.04.13 12:41, schrieb Simon Pasquier:
>> Hi,
>> I'm not sure to understand exactly your issue but since your setup
>> includes ceilometer, I can just give you a hint for the ceilometer/swift
>> integration.
>> You have to create a 'ResellerAdmin' role and assign that role to your
>> ceilometer user. Alternatively you can define the 'reseller_admin_role'
>> parameter (default value=ResellerAdmin) in the [filter:authtoken]
>> section of /etc/swift/proxy-server.conf.
>> Cheers,
>> Simon
>>
>> Le 16/04/2013 12:04, Axel Christiansen a écrit :
>>> Dear List,
>>>
>>>
>>> i got stuck with a setup of openstack grizzly. This setup consists of:
>>>
>>> - swift proxy 1.0.8.1
>>> - swift storage nodes 1.0.8.1
>>> - keystone
>>> - ceilometer
>>>
>>>
>>> I kept browsing the web and reading openstack docs for days now and
>>> can't just get it working right. Because of openstacks diversity a
>>> wasn't able to find something really similar to my situation.
>>>
>>>
>>> The thing is, i changed swift-proxy from using swauth to keystone.
>>> Keystone and swift-proxy do interact all right as fare as i can say.
>>> What i can't get working is that simple webpage which gave the ability
>>> to log in as superuser, adding new user and so on. It is that webpart
>>> that connects to the proxy on port 8080, respectively port .
>>>
>>>
>>> Thx o lot for taking a look into this.
>>> Axel
>>>
>>>
>>>
>>>
>>> Theses are the browser urls i try:
>>>
>>> (delay_auth_decision = 1)
>>> http://the.swift.proxy:/auth/
>>> bad url
>>> Apr 16 11:49:31 ns-proxy01 swift-proxy Calling Swift3 Middleware (txn:
>>> txcfde073b9ffe4f379da392056e2176de)
>>> Apr 16 11:49:31 ns-proxy01 swift-proxy {'headers': {'Accept-Language':
>>> 'de-de,de;q=0.8,en-us;q=0.5,en;q=0.3', 'Accept-Encoding': 'gzip,
>>> deflate', 'Host&
[Openstack] grizzly swift-proxy, swift-recon -d: HTTP Error 400: Bad Request
Dear List, after upgrading to grizzly, swift-recon returns this. Could not find out to much in the logs. Can one give me a hint? root@ns-proxy01:~# swift-recon -d -v === --> Starting reconnaissance on 6 hosts === [2013-04-17 13:07:51] Checking disk usage now -> http://10.42.45.13:6000/recon/diskusage: HTTP Error 400: Bad Request -> http://10.42.45.12:6000/recon/diskusage: HTTP Error 400: Bad Request -> http://10.42.45.15:6000/recon/diskusage: HTTP Error 400: Bad Request -> http://10.42.45.11:6000/recon/diskusage: HTTP Error 400: Bad Request -> http://10.42.45.14:6000/recon/diskusage: HTTP Error 400: Bad Request -> http://10.42.45.16:6000/recon/diskusage: HTTP Error 400: Bad Request On one of the storage-nodes this does show up in the log: Apr 17 13:07:51 sn02 object-server 10.42.45.1 - - [17/Apr/2013:11:07:51 +] "GET /recon/diskusage" 400 30 "-" "-" "Python-urllib/2.7" 0.0001 Cheers Axel ___ 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] grizzly swift-proxy, swift-recon -d: HTTP Error 400: Bad Request
Hello Coleman, Great. That fixed it. Thank you. Axel Am 17.04.13 16:22, schrieb Corrigan, Coleman: > Hello Christiansen, have you made sure to set up recon in the pipeline of > your object node ? > > e.g on 10.42.45.13 does /etc/swift/object-server.conf have > >pipeline = recon object-server > > and a [filter:recon] stanza ? > > Regards, > Coleman > > -Original Message- > From: Openstack > [mailto:openstack-bounces+coleman.corrigan=hp....@lists.launchpad.net] On > Behalf Of Axel Christiansen > Sent: 17 April 2013 13:37 > To: openstack@lists.launchpad.net > Subject: [Openstack] grizzly swift-proxy, swift-recon -d: HTTP Error 400: Bad > Request > > Dear List, > > > after upgrading to grizzly, swift-recon returns this. Could not find out > to much in the logs. > Can one give me a hint? > > root@ns-proxy01:~# swift-recon -d -v > === > --> Starting reconnaissance on 6 hosts > === > [2013-04-17 13:07:51] Checking disk usage now > -> http://10.42.45.13:6000/recon/diskusage: HTTP Error 400: Bad Request > -> http://10.42.45.12:6000/recon/diskusage: HTTP Error 400: Bad Request > -> http://10.42.45.15:6000/recon/diskusage: HTTP Error 400: Bad Request > -> http://10.42.45.11:6000/recon/diskusage: HTTP Error 400: Bad Request > -> http://10.42.45.14:6000/recon/diskusage: HTTP Error 400: Bad Request > -> http://10.42.45.16:6000/recon/diskusage: HTTP Error 400: Bad Request > > > > On one of the storage-nodes this does show up in the log: > > Apr 17 13:07:51 sn02 object-server 10.42.45.1 - - [17/Apr/2013:11:07:51 > +] "GET /recon/diskusage" 400 30 "-" "-" "Python-urllib/2.7" 0.0001 > > > > Cheers > Axel > > ___ > 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] grizzly swift/keystone clients
Hello List, what GUI-Clients like Cyberduck do exist, wich can talk the v2.0 API? Thank you Axel ___ 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] grizzly keystone with v1.0 API
Hello List again, on the zmanda-blog is a description to make a swift/keystone setup work again via the v1.0 API. Had anyone success doing this on grizzly? I sadly did not. Regards, Axel ___ 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] grizzly keystone with v1.0 API
Thank you Matthieu, that sounds very interesting. The grizzly i am using comes with an "all in one keystone.conf". I think that is fine and should work. Would you be so kind and send me your "/etc/keystone/keystone.conf" and "/etc/keystone/keystone-paste.ini". I would like to compare these to mine and hope it brings me a lot closer. Yes, thats what i ment on the zmanda-blog. Thnak you! Axel Am 05.06.13 11:30, schrieb Matthieu Huin: > Hello Axel, > > If you refer to this post : http://www.zmanda.com/blogs/?p=1002 , I managed > to set it up successfully on a devstack ( that's the trunk version, though, > not grizzly ). There is a mistake in the instructions; the config file to > modify is not /etc/keystone/keystone.conf but > /etc/keystone/keystone-paste.ini . > > Hope that helps. > > Matthieu Huin > > m...@enovance.com > > - Original Message - > From: "Axel Christiansen" > To: openstack@lists.launchpad.net > Sent: Wednesday, June 5, 2013 11:23:13 AM > Subject: [Openstack] grizzly keystone with v1.0 API > > Hello List again, > > > on the zmanda-blog is a description to make a swift/keystone setup work > again via the v1.0 API. Had anyone success doing this on grizzly? > > I sadly did not. > > > Regards, Axel > > ___ > 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] grizzly keystone with v1.0 API
yes, i added these files and they do get compiled and invoked. (added some more debug code). At least an object of ProtocolConverter gets created, but the converter methods never get called. The grizzly keystone tar archive does not come with a keystone-paste.ini. What i can tell so fare, the contents of keystone-paste.ini is included in keytone.conf. And that should be fine. I got myself a devstack now, adopted keystone and its configs into the grizzly openstack and still have no luck. Axel Am 05.06.13 12:23, schrieb Matthieu Huin: > Did you add these files to your keystone installation ? > https://github.com/AlexYangYu/StackLab-Ketystone/commit/9e126d6716912e8822de3884c32f5b9509ef0994 > (you only need the first two files) > Then you have to modify keystone-paste.ini and restart keystone. > > Matthieu Huin > > m...@enovance.com > > - Original Message ----- > From: "Axel Christiansen" > To: "Matthieu Huin" > Cc: openstack@lists.launchpad.net > Sent: Wednesday, June 5, 2013 12:14:32 PM > Subject: Re: [Openstack] grizzly keystone with v1.0 API > > Thank you Matthieu, > > > that sounds very interesting. The grizzly i am using comes with an "all > in one keystone.conf". I think that is fine and should work. > > Would you be so kind and send me your "/etc/keystone/keystone.conf" and > "/etc/keystone/keystone-paste.ini". I would like to compare these to > mine and hope it brings me a lot closer. > > > Yes, thats what i ment on the zmanda-blog. > > > Thnak you! > > > Axel > > > > Am 05.06.13 11:30, schrieb Matthieu Huin: >> Hello Axel, >> >> If you refer to this post : http://www.zmanda.com/blogs/?p=1002 , I managed >> to set it up successfully on a devstack ( that's the trunk version, though, >> not grizzly ). There is a mistake in the instructions; the config file to >> modify is not /etc/keystone/keystone.conf but >> /etc/keystone/keystone-paste.ini . >> >> Hope that helps. >> >> Matthieu Huin >> >> m...@enovance.com >> >> - Original Message - >> From: "Axel Christiansen" >> To: openstack@lists.launchpad.net >> Sent: Wednesday, June 5, 2013 11:23:13 AM >> Subject: [Openstack] grizzly keystone with v1.0 API >> >> Hello List again, >> >> >> on the zmanda-blog is a description to make a swift/keystone setup work >> again via the v1.0 API. Had anyone success doing this on grizzly? >> >> I sadly did not. >> >> >> Regards, Axel >> >> ___ >> 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] grizzly keystone with v1.0 API
Thanks for your configs!
Am 05.06.13 15:20, schrieb Matthieu Huin:
> With the config I've sent, the v1 API is accessible at a URL looking like
> this: http://endpoint:5000/v1.0
>
> What do you get in the keystone logs when you send a cURL request like
>
> curl -H "x-auth-user: tenant:user" -H "x-auth-key: password"
> http://endpoint:5000/v1.0
>
> ?
When using valid credentials the promt just appears again. No output.
2013-06-05 15:39:54,114 INFO sqlalchemy.engine.base.Engine INSERT INTO
token (id, expires, extr ..
When using invalid credentials:
{"error": {"message": "Invalid user / password", "code": 401, "title":
"Not Authorized"}}
When using Cyberduck the keystone seems not to get touched at all.
This ist what appears in the proxy.log wehen trying to login via Cyberduck:
Jun 5 15:47:03 ns-proxy01 swift-proxy Calling Swift3 Middleware (txn:
tx439bd9050f054697b722c4b0db5a4219)
Jun 5 15:47:03 ns-proxy01 swift-proxy {'headers': {'Accept-Encoding':
'gzip,deflate', 'Host': 'backend', 'X-Auth-User': 'demo:admin',
'User-Agent': 'Cyberduck/4.3 (Mac OS X/10.8.3) (i386)', 'Connection':
'close', 'X-Auth-Key': 'XZ5OOQSKWSNJ', 'Content-Type': None}, 'environ':
{'SCRIPT_NAME': '', 'HTTP_X_AUTH_KEY': 'XZ5OOQSKWSNJ', 'REQUEST_METHOD':
'GET', 'PATH_INFO': '/auth/v1.0', 'SERVER_PROTOCOL': 'HTTP/1.0',
'wsgi.url_scheme': 'http', 'HTTP_USER_AGENT': 'Cyberduck/4.3 (Mac OS
X/10.8.3) (i386)', 'HTTP_CONNECTION': 'close', 'REMOTE_PORT': '41624',
'SERVER_NAME': '10.42.44.101', 'REMOTE_ADDR': '10.42.44.5',
'eventlet.input': ,
'HTTP_X_AUTH_USER': 'demo:admin', 'SERVER_PORT': '', 'wsgi.input':
, 'HTTP_HOST':
'backend', 'swift.cache': , 'wsgi.multithread': True, 'eventlet.posthooks': [],
'wsgi.version': (1, 0), 'RAW_PATH_INFO': '/auth/v1.0',
'GATEWAY_INTERFACE': 'CGI/1.1', 'wsgi.run_once': False, 'wsgi.errors':
,
'wsgi.multiprocess': False, 'swift.trans_id':
'tx439bd9050f054697b722c4b0db5a4219', 'CONTENT_TYPE': None,
'HTTP_ACCEPT_ENCODING': 'gzip,deflate'}}
Jun 5 15:47:03 ns-proxy01 swift-proxy Authorizing as anonymous (txn:
tx439bd9050f054697b722c4b0db5a4219)
Jun 5 15:47:03 ns-proxy01 swift-proxy 10.42.44.5 10.42.44.5
05/Jun/2013/13/47/03 GET /auth/v1.0 HTTP/1.0 401 -
Cyberduck/4.3%20%28Mac%20OS%20X/10.8.3%29%20%28i386%29 - - 131 -
tx439bd9050f054697b722c4b0db5a4219 - 0.0008 -
>
>
> Matthieu Huin
>
> m...@enovance.com
>
> - Original Message -
> From: "Axel Christiansen"
> To: "Matthieu Huin"
> Cc: openstack@lists.launchpad.net
> Sent: Wednesday, June 5, 2013 3:10:22 PM
> Subject: Re: [Openstack] grizzly keystone with v1.0 API
>
>
> yes, i added these files and they do get compiled and invoked. (added
> some more debug code). At least an object of ProtocolConverter gets
> created, but the converter methods never get called.
>
>
> The grizzly keystone tar archive does not come with a
> keystone-paste.ini. What i can tell so fare, the contents of
> keystone-paste.ini is included in keytone.conf. And that should be fine.
>
> I got myself a devstack now, adopted keystone and its configs into the
> grizzly openstack and still have no luck.
>
> Axel
>
>
>
> Am 05.06.13 12:23, schrieb Matthieu Huin:
>> Did you add these files to your keystone installation ?
>> https://github.com/AlexYangYu/StackLab-Ketystone/commit/9e126d6716912e8822de3884c32f5b9509ef0994
>> (you only need the first two files)
>> Then you have to modify keystone-paste.ini and restart keystone.
>>
>> Matthieu Huin
>>
>> m...@enovance.com
>>
>> - Original Message -
>> From: "Axel Christiansen"
>> To: "Matthieu Huin"
>> Cc: openstack@lists.launchpad.net
>> Sent: Wednesday, June 5, 2013 12:14:32 PM
>> Subject: Re: [Openstack] grizzly keystone with v1.0 API
>>
>> Thank you Matthieu,
>>
>>
>> that sounds very interesting. The grizzly i am using comes with an "all
>> in one keystone.conf". I think that is fine and should work.
>>
>> Would you be so kind and send me your "/etc/keystone/keystone.conf" and
>> &qu
Re: [Openstack] grizzly keystone with v1.0 API
Hello Matthieu,
hello List,
thank a lot for your contributions.
In the process of tracking this donw with you i came to an enlightenment.
My openstack setup is just fine. The load balancer needed a little
adjustment to have the v1.0 API request send to keystone.
Thank you :)
Axel
Am 05.06.13 15:51, schrieb Axel Christiansen:
>
> Thanks for your configs!
>
>
> Am 05.06.13 15:20, schrieb Matthieu Huin:
>> With the config I've sent, the v1 API is accessible at a URL looking like
>> this: http://endpoint:5000/v1.0
>>
>> What do you get in the keystone logs when you send a cURL request like
>>
>> curl -H "x-auth-user: tenant:user" -H "x-auth-key: password"
>> http://endpoint:5000/v1.0
>>
>> ?
>
>
> When using valid credentials the promt just appears again. No output.
> 2013-06-05 15:39:54,114 INFO sqlalchemy.engine.base.Engine INSERT INTO
> token (id, expires, extr ..
>
> When using invalid credentials:
> {"error": {"message": "Invalid user / password", "code": 401, "title":
> "Not Authorized"}}
>
>
>
>
> When using Cyberduck the keystone seems not to get touched at all.
>
> This ist what appears in the proxy.log wehen trying to login via Cyberduck:
>
> Jun 5 15:47:03 ns-proxy01 swift-proxy Calling Swift3 Middleware (txn:
> tx439bd9050f054697b722c4b0db5a4219)
> Jun 5 15:47:03 ns-proxy01 swift-proxy {'headers': {'Accept-Encoding':
> 'gzip,deflate', 'Host': 'backend', 'X-Auth-User': 'demo:admin',
> 'User-Agent': 'Cyberduck/4.3 (Mac OS X/10.8.3) (i386)', 'Connection':
> 'close', 'X-Auth-Key': 'XZ5OOQSKWSNJ', 'Content-Type': None}, 'environ':
> {'SCRIPT_NAME': '', 'HTTP_X_AUTH_KEY': 'XZ5OOQSKWSNJ', 'REQUEST_METHOD':
> 'GET', 'PATH_INFO': '/auth/v1.0', 'SERVER_PROTOCOL': 'HTTP/1.0',
> 'wsgi.url_scheme': 'http', 'HTTP_USER_AGENT': 'Cyberduck/4.3 (Mac OS
> X/10.8.3) (i386)', 'HTTP_CONNECTION': 'close', 'REMOTE_PORT': '41624',
> 'SERVER_NAME': '10.42.44.101', 'REMOTE_ADDR': '10.42.44.5',
> 'eventlet.input': ,
> 'HTTP_X_AUTH_USER': 'demo:admin', 'SERVER_PORT': '', 'wsgi.input':
> , 'HTTP_HOST':
> 'backend', 'swift.cache': 0x28c30d0>, 'wsgi.multithread': True, 'eventlet.posthooks': [],
> 'wsgi.version': (1, 0), 'RAW_PATH_INFO': '/auth/v1.0',
> 'GATEWAY_INTERFACE': 'CGI/1.1', 'wsgi.run_once': False, 'wsgi.errors':
> ,
> 'wsgi.multiprocess': False, 'swift.trans_id':
> 'tx439bd9050f054697b722c4b0db5a4219', 'CONTENT_TYPE': None,
> 'HTTP_ACCEPT_ENCODING': 'gzip,deflate'}}
> Jun 5 15:47:03 ns-proxy01 swift-proxy Authorizing as anonymous (txn:
> tx439bd9050f054697b722c4b0db5a4219)
> Jun 5 15:47:03 ns-proxy01 swift-proxy 10.42.44.5 10.42.44.5
> 05/Jun/2013/13/47/03 GET /auth/v1.0 HTTP/1.0 401 -
> Cyberduck/4.3%20%28Mac%20OS%20X/10.8.3%29%20%28i386%29 - - 131 -
> tx439bd9050f054697b722c4b0db5a4219 - 0.0008 -
>
>
>
>>
>>
>> Matthieu Huin
>>
>> m...@enovance.com
>>
>> - Original Message -
>> From: "Axel Christiansen"
>> To: "Matthieu Huin"
>> Cc: openstack@lists.launchpad.net
>> Sent: Wednesday, June 5, 2013 3:10:22 PM
>> Subject: Re: [Openstack] grizzly keystone with v1.0 API
>>
>>
>> yes, i added these files and they do get compiled and invoked. (added
>> some more debug code). At least an object of ProtocolConverter gets
>> created, but the converter methods never get called.
>>
>>
>> The grizzly keystone tar archive does not come with a
>> keystone-paste.ini. What i can tell so fare, the contents of
>> keystone-paste.ini is included in keytone.conf. And that should be fine.
>>
>> I got myself a devstack now, adopted keystone and its configs into the
>> grizzly openstack and still have no luck.
>>
>> Axel
>>
>>
>>
>> Am 05.06.13 12:23, schrieb Matthieu Huin:
>>> Did you add these files to your keystone installation ?
>>> https://github.com/AlexYangYu/StackLab-Ketystone/commit/9e126d6716912e8822de3884c32f5b9509ef0994
>>> (you only need the first two file
[Openstack] Ceilometer with swift
Dear List, i am trying to retrieve measurements from swift via ceilometer. ceilometer stores its measurements in db and so. looks good. The ceilometer V2 Web API is expecting resource_id as UUID value, for example. I can not find a UUID anywere. When listing resources (GET /v2/resources/) the result contains a lot of ids for various things but non in UUID format. What am i doing wrong? Thank you and nice day. Axel ___ 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] Ceilometer with swift
Its working now. Must have made a mistake :) Greets Axel Am 01.07.13 16:42, schrieb Axel Christiansen: > Dear List, > > > i am trying to retrieve measurements from swift via ceilometer. > ceilometer stores its measurements in db and so. looks good. > > > The ceilometer V2 Web API is expecting resource_id as UUID value, for > example. I can not find a UUID anywere. When listing resources (GET > /v2/resources/) the result contains a lot of ids for various things but > non in UUID format. > > What am i doing wrong? > > > Thank you and nice day. > > Axel > > ___ > 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] ring building absolut drive names
Hello List, does one has to use the real device names in ring-building, like: swift-ring-builder account.builder add z5-10.0.6.204:6002/sda4 100 Here it is sda4. Can one use the partition UUID value or the mount point? What if a drive has a fialure and a reboot of the system is done with this failing drive. The subsequente drives after the failing drive will move up with there drive letters, right? Won't this get the relations between ring and drives mixed up? Thank you for hints, Axel ___ 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] ring building absolut drive names
Thanks. Thats nice. So mounting via UUID ensures right drive<->mount-point mapping. Am 10.07.13 18:23, schrieb Samuel Merritt: > On 7/10/13 2:25 AM, Axel Christiansen wrote: >> Hello List, >> >> >> does one has to use the real device names in ring-building, like: >> swift-ring-builder account.builder add z5-10.0.6.204:6002/sda4 100 >> Here it is sda4. >> >> Can one use the partition UUID value or the mount point? > > It's really a mount point, not a device name. You can use whatever thing > you want, so long as /srv/node/<$thing> is where the filesystem is mounted. > > ___ > 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] nova-api-os-compute missing in archive.gplhost.com/debian
Hi. I am using these repos to setup nova on a debian 7. Looks like the grizzly package nova-api-os-compute is missing and therefore breaks dependency. deb http://archive.gplhost.com/debian grizzly main deb http://archive.gplhost.com/debian grizzly-backports main Was looking a little around. Does someone know another grizzly repo for debian7? Thx, Axel ___ 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] swift storage, getting it working
Hello List, i got stock getting a swift store running. the base components, a proxy some storage nodes are prepared. The keystone service is up and seems working ok. Authentication works. wehn trying to create a container this happens: swift -v -s -V 2.0 -A http://10.42.44.206:5000/v2.0 -U demo:admin -K XZ5OOQSKWSNJ post tesadfdsafds Container PUT failed: https://cs1.internet4you.com:443/v1/AUTH_adb1bcba4b2548589b67c8aee6be09fb/tesadfdsafds 404 Not Found [first 60 chars of response] Not FoundThe resource could not be found.< On the storage nodes: Jul 12 10:33:55 sn04 object-server 10.42.45.203 - - [12/Jul/2013:08:33:55 +] "HEAD /sdz1/80228/AUTH_adb1bcba4b2548589b67c8aee6be09fb" 400 63 "-" "tx169c1f37bcee47e083eff0f6916f9392" "-" 0.0002 a log snippet. http://paste.openstack.org/show/40211/ It would be really nice if one could point me in the rigth direction. Where should i dig. Thx, Axel ___ 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] swift storage, getting it working
Thank you. That looks all right. Switching to user swift on a storage node, cd-ing to a mountpoint (/srv/node/sdb1/) and creating a file works. I checked the mount points and rights twice. Here is a little larger snippet from the log server: http://paste.openstack.org/show/40222/ someone with another hint? What should i check next? Thx List. Axel Am 12.07.13 10:58, schrieb Kuo Hugo: > Agree with Jonathan +1 > > Change the owner of disk mount point to the relevant user which you set > in /etc/swift/*. > > +Hugo Kuo+ > h...@swiftstack.com <mailto:h...@swiftstack.com> > tonyt...@gmail.com > <mailto:tonyt...@gmail.com> > +886 935004793 > > > 2013/7/12 Jonathan Lu mailto:jojokur...@gmail.com>> > > Hi, > I once met such problem because I forget to change the own of > the directory of the mounted device to swift:swift. > > > On 2013/7/12 16:44, Axel Christiansen wrote: > > Hello List, > > > i got stock getting a swift store running. the base components, > a proxy > some storage nodes are prepared. The keystone service is up and > seems > working ok. Authentication works. > > > wehn trying to create a container this happens: > > swift -v -s -V 2.0 -A http://10.42.44.206:5000/v2.0 -U demo:admin -K > XZ5OOQSKWSNJ post tesadfdsafds > Container PUT failed: > > https://cs1.internet4you.com:__443/v1/AUTH___adb1bcba4b2548589b67c8aee6be09__fb/tesadfdsafds > > <https://cs1.internet4you.com:443/v1/AUTH_adb1bcba4b2548589b67c8aee6be09fb/tesadfdsafds> > 404 Not Found [first 60 chars of response] Not > FoundThe resource could not be found.< > > > On the storage nodes: > Jul 12 10:33:55 sn04 object-server 10.42.45.203 - - > [12/Jul/2013:08:33:55 +] "HEAD > /sdz1/80228/AUTH___adb1bcba4b2548589b67c8aee6be09__fb" 400 63 "-" > "__tx169c1f37bcee47e083eff0f6916f__9392" "-" 0.0002 > > a log snippet. > http://paste.openstack.org/__show/40211/ > <http://paste.openstack.org/show/40211/> > > > It would be really nice if one could point me in the rigth > direction. > Where should i dig. > > Thx, Axel > > > _ > Mailing list: https://launchpad.net/~__openstack > <https://launchpad.net/~openstack> > Post to : openstack@lists.launchpad.net > <mailto:openstack@lists.launchpad.net> > Unsubscribe : https://launchpad.net/~__openstack > <https://launchpad.net/~openstack> > More help : https://help.launchpad.net/__ListHelp > <https://help.launchpad.net/ListHelp> > > > > _ > Mailing list: https://launchpad.net/~__openstack > <https://launchpad.net/~openstack> > Post to : openstack@lists.launchpad.net > <mailto:openstack@lists.launchpad.net> > Unsubscribe : https://launchpad.net/~__openstack > <https://launchpad.net/~openstack> > More help : https://help.launchpad.net/__ListHelp > <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] swift storage, getting it working
Hello. my issue is solved. What did i do wrong, got wrong from google ;) I mixed up the default ports for the ring building. The proxy-server option "allow_account_management = true" and "account_autocreate = true" where set to false. All the best. Axel Am 12.07.13 12:50, schrieb Axel Christiansen: > > > Thank you. That looks all right. Switching to user swift on a storage > node, cd-ing to a mountpoint (/srv/node/sdb1/) and creating a file > works. I checked the mount points and rights twice. > > > Here is a little larger snippet from the log server: > http://paste.openstack.org/show/40222/ > > > someone with another hint? What should i check next? > > > Thx List. Axel > > > > > Am 12.07.13 10:58, schrieb Kuo Hugo: >> Agree with Jonathan +1 >> >> Change the owner of disk mount point to the relevant user which you set >> in /etc/swift/*. >> >> +Hugo Kuo+ >> h...@swiftstack.com <mailto:h...@swiftstack.com> >> tonyt...@gmail.com >> <mailto:tonyt...@gmail.com> >> +886 935004793 >> >> >> 2013/7/12 Jonathan Lu mailto:jojokur...@gmail.com>> >> >> Hi, >> I once met such problem because I forget to change the own of >> the directory of the mounted device to swift:swift. >> >> >> On 2013/7/12 16:44, Axel Christiansen wrote: >> >> Hello List, >> >> >> i got stock getting a swift store running. the base components, >> a proxy >> some storage nodes are prepared. The keystone service is up and >> seems >> working ok. Authentication works. >> >> >> wehn trying to create a container this happens: >> >> swift -v -s -V 2.0 -A http://10.42.44.206:5000/v2.0 -U demo:admin -K >> XZ5OOQSKWSNJ post tesadfdsafds >> Container PUT failed: >> >> https://cs1.internet4you.com:__443/v1/AUTH___adb1bcba4b2548589b67c8aee6be09__fb/tesadfdsafds >> >> <https://cs1.internet4you.com:443/v1/AUTH_adb1bcba4b2548589b67c8aee6be09fb/tesadfdsafds> >> 404 Not Found [first 60 chars of response] Not >> FoundThe resource could not be found.< >> >> >> On the storage nodes: >> Jul 12 10:33:55 sn04 object-server 10.42.45.203 - - >> [12/Jul/2013:08:33:55 +] "HEAD >> /sdz1/80228/AUTH___adb1bcba4b2548589b67c8aee6be09__fb" 400 63 "-" >> "__tx169c1f37bcee47e083eff0f6916f__9392" "-" 0.0002 >> >> a log snippet. >> http://paste.openstack.org/__show/40211/ >> <http://paste.openstack.org/show/40211/> >> >> >> It would be really nice if one could point me in the rigth >> direction. >> Where should i dig. >> >> Thx, Axel >> >> >> _ >> Mailing list: https://launchpad.net/~__openstack >> <https://launchpad.net/~openstack> >> Post to : openstack@lists.launchpad.net >> <mailto:openstack@lists.launchpad.net> >> Unsubscribe : https://launchpad.net/~__openstack >> <https://launchpad.net/~openstack> >> More help : https://help.launchpad.net/__ListHelp >> <https://help.launchpad.net/ListHelp> >> >> >> >> _ >> Mailing list: https://launchpad.net/~__openstack >> <https://launchpad.net/~openstack> >> Post to : openstack@lists.launchpad.net >> <mailto:openstack@lists.launchpad.net> >> Unsubscribe : https://launchpad.net/~__openstack >> <https://launchpad.net/~openstack> >> More help : https://help.launchpad.net/__ListHelp >> <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] swift storage, getting it working
Hi Hugo, as i mentioned, my ring was wrong. At least i beleve using the wrong ports for the ring services(account, container, object) breaks the ring, right? Thats what broke my setup, i beleve. Axel Am 12.07.13 14:09, schrieb Kuo Hugo: > Hi Alex , > > Did you re-check the drives information in the ring? > Would you like to show it? > > +Hugo Kuo+ > h...@swiftstack.com <mailto:h...@swiftstack.com> > tonyt...@gmail.com > <mailto:tonyt...@gmail.com> > +886 935004793 > > > 2013/7/12 Axel Christiansen <mailto:axel.christian...@softreset.de>> > > Hello. > > > my issue is solved. What did i do wrong, got wrong from google ;) > > I mixed up the default ports for the ring building. > The proxy-server option "allow_account_management = true" and > "account_autocreate = true" where set to false. > > > All the best. > Axel > > > > > Am 12.07.13 12:50, schrieb Axel Christiansen: > > > > > > Thank you. That looks all right. Switching to user swift on a storage > > node, cd-ing to a mountpoint (/srv/node/sdb1/) and creating a file > > works. I checked the mount points and rights twice. > > > > > > Here is a little larger snippet from the log server: > > http://paste.openstack.org/show/40222/ > > > > > > someone with another hint? What should i check next? > > > > > > Thx List. Axel > > > > > > > > > > Am 12.07.13 10:58, schrieb Kuo Hugo: > >> Agree with Jonathan +1 > >> > >> Change the owner of disk mount point to the relevant user which > you set > >> in /etc/swift/*. > >> > >> +Hugo Kuo+ > >> h...@swiftstack.com <mailto:h...@swiftstack.com> > <mailto:h...@swiftstack.com <mailto:h...@swiftstack.com>> > >> tonyt...@gmail.com <mailto:tonyt...@gmail.com> > >> <mailto:tonyt...@gmail.com <mailto:tonyt...@gmail.com>> > >> +886 935004793 > >> > >> > >> 2013/7/12 Jonathan Lu <mailto:jojokur...@gmail.com> <mailto:jojokur...@gmail.com > <mailto:jojokur...@gmail.com>>> > >> > >> Hi, > >> I once met such problem because I forget to change the own of > >> the directory of the mounted device to swift:swift. > >> > >> > >> On 2013/7/12 16:44, Axel Christiansen wrote: > >> > >> Hello List, > >> > >> > >> i got stock getting a swift store running. the base > components, > >> a proxy > >> some storage nodes are prepared. The keystone service is > up and > >> seems > >> working ok. Authentication works. > >> > >> > >> wehn trying to create a container this happens: > >> > >> swift -v -s -V 2.0 -A http://10.42.44.206:5000/v2.0 -U > demo:admin -K > >> XZ5OOQSKWSNJ post tesadfdsafds > >> Container PUT failed: > >> > > https://cs1.internet4you.com:__443/v1/AUTH___adb1bcba4b2548589b67c8aee6be09__fb/tesadfdsafds > >> > > <https://cs1.internet4you.com:443/v1/AUTH_adb1bcba4b2548589b67c8aee6be09fb/tesadfdsafds> > >> 404 Not Found [first 60 chars of response] Not > >> FoundThe resource could not be found.< > >> > >> > >> On the storage nodes: > >> Jul 12 10:33:55 sn04 object-server 10.42.45.203 - - > >> [12/Jul/2013:08:33:55 +] "HEAD > >> /sdz1/80228/AUTH___adb1bcba4b2548589b67c8aee6be09__fb" > 400 63 "-" > >> "__tx169c1f37bcee47e083eff0f6916f__9392" "-" 0.0002 > >> > >> a log snippet. > >> http://paste.openstack.org/__show/40211/ > >> <http://paste.openstack.org/show/40211/> > >> > >> > >> It would be really nice if one could point me in the rigth > >> direction. > >> Where should i dig. > >> > >> Thx, Axel > >> > >> > >> _
[Openstack] swift proxys and dedecated ceilometer
Dear List, i am trying to figure out what ceilometer components nedds to bo installed an what nodes. I have 2 swift-proxy-hosts and 1 ceiloemeter-host These are the packages debian7 respectively the grizzly repo offers: ceilometer-agent-central - OpenStack efficient metering counters system - central agent ceilometer-agent-compute - OpenStack efficient metering counters system - compute agent ceilometer-api - OpenStack efficient metering counters system (API service) ceilometer-collector - OpenStack efficient metering counters system - collector service ceilometer-common - OpenStack efficient metering counters system - common files python-ceilometer - OpenStack efficient metering counters system - Python libraries python-ceilometerclient - Client library for Openstack Ceilometer API server Thank you, Axel ___ 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] swift proxys and dedecated ceilometer
Hi Julien, thx a lot for the real quick help. Yes, only swift. These meters: storage.objects storage.objects.size storage.objects.containers storage.objects.incoming.bytes storage.objects.outgoing.bytes To be sure, the ceilometer-agent-central and ceilometer-collector do go on the proxys. And just the ceilometer-api ist for the dedecated ceilometer-host? Axel Am 24.07.13 15:33, schrieb Julien Danjou: > On Wed, Jul 24 2013, Axel Christiansen wrote: > > Hi Axel, > > If you want to only meter Swift, you just need: > >> ceilometer-agent-central ceilometer-collector > > And to retrieve your data: >> ceilometer-api > ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
