[openstack-dev] [monasca] Anomaly & Prediction Engine

2016-01-22 Thread Osanai, Hisashi
Monasca folks, We discussed about Anomaly & Prediction Engine in this week's irc meeting and decided we would exchange info using this list. I'm really interested in having this functionality but the status is prototype now. We know that there are a lot of related tech around it and the tech

[openstack-dev] info in paste will be removed?

2015-08-28 Thread Osanai, Hisashi
Folks, I would like to know whether info in http://paste.openstack.org will be removed or not. If it will be removed, I also would like to know a condition. Thanks in advance, Hisashi Osanai __ OpenStack Development

Re: [openstack-dev] info in paste will be removed?

2015-08-28 Thread Osanai, Hisashi
On Friday, August 28, 2015 8:49 PM, Jeremy Stanley wrote: We (the project infrastructure root sysadmins) don't expire/purge the content on paste.openstack.org, though have deleted individual pastes on request if someone reports material which is abusive or potentially illegal in many

Re: [openstack-dev] [cross-project] RBAC Policy Basics

2015-06-23 Thread Osanai, Hisashi
On Tuesday, June 23, 2015 10:30 PM, Adam Young wrote: OK, I think I get it; you want to make a check specific to the roles on the service token. The term Service roles confused me. You can do this check with oslo.messaging today. Don't uyse the role check, just a generic check. It

Re: [openstack-dev] [cross-project] RBAC Policy Basics

2015-06-23 Thread Osanai, Hisashi
On Tuesday, June 23, 2015 12:14 AM, Adam Young wrote: It is not an issue if you keep each of the policy files completely separate, but it means that each service has its own meaning for the same name, and that confuses operators; owner in Nova means a user that has a role on this project

Re: [openstack-dev] [cross-project] RBAC Policy Basics

2015-06-21 Thread Osanai, Hisashi
On Saturday, June 20, 2015 11:16 AM, Adam Young wrote: What situations does a shared policy file require? For example, there are policy files for Nova and Cinder and they have same targets such as context_is_admin, admin_or_owner and default. A lot of these internal rules most likely

Re: [openstack-dev] [cross-project] RBAC Policy Basics

2015-06-18 Thread Osanai, Hisashi
Adam, Thank you for the information RBAC Policy Basics. Thursday, June 18, 2015 1:47 AM, Adam Young wrote: However, we have found a need to have a global override. This is a way a cloud admin that can go into any API anywhere and fix things. This means that Glance, Neutron, Nova, and

[openstack-dev] [oslo.policy] service_roles checks in oslo.policy

2015-05-12 Thread Osanai, Hisashi
Oslo.policy folks, I have been developing Swift's RBAC using oslo.policy[1]. It is necessary to check for service_roles(HTTP_X_SERVICE_ROLES)[2] in this patch. Current implementation looks if rule string starts with 'role', check the string whether the string is in 'roles' of the credential.

Re: [openstack-dev] [oslo.policy] guraduation status

2015-03-04 Thread Osanai, Hisashi
Doug, Thank you for the response and sorry to respond you late. Recently I could not receive e-mails from this list and your e-mail was one of them. I don't know the reason but I found out your response in archive. On Mon, 02 Mar 2015 12:28:06 -0800, Doug Hellmann wrote: We're making good

Re: [openstack-dev] [oslo.policy] guraduation status

2015-03-03 Thread Osanai, Hisashi
Jordan, Thank you for providing the info. On Monday, March 02, 2015 7:41 PM, Jordan Pittier wrote; The project is abandoned but the initial goal was to have the code somehow proposed to be merged in Openstack Swift. Feel free to have a look a continue this effort. I have been developing

[openstack-dev] [oslo.policy] guraduation status

2015-03-02 Thread Osanai, Hisashi
oslo.policy folks, I'm thinking about realization of policy-based access control in swift using oslo.policy [1] so I would like to know oslo.policy's status for graduation. [1] https://github.com/openstack/oslo-specs/blob/master/specs/kilo/graduate-policy.rst Thanks in advance, Hisashi

Re: [openstack-dev] [swift] a way of checking replicate completion on swift cluster

2014-12-04 Thread Osanai, Hisashi
Thank you for the response. I updated the following patch with the idea. https://review.openstack.org/#/c/138342/ On Friday, December 05, 2014 5:50 AM, Clay Gerrard wrote: more fidelity in the recon's seems fine, statsd emissions are also a popular target for telemetry radiation. Thanks

Re: [openstack-dev] [swift] a way of checking replicate completion on swift cluster

2014-11-27 Thread Osanai, Hisashi
Hi, I think it is a good idea to have the object-replicator's failure info in recon like the other replicators. I think the following info can be added in object-replicator in addition to object_replication_last and object_replication_time. If there is any technical reason to not add them, I

Re: [openstack-dev] [swift] Allow hostname for nodes in Ring

2014-10-15 Thread Osanai, Hisashi
Thanks for your advice. On Thursday, October 16, 2014 2:25 AM, Pete Zaitcev wrote: I don't know if the bug report is all that necessary or useful. The scope of the problem is well defined without, IMHO. I really want to have clear rules for this but your thought looks pretty nice for me

Re: [openstack-dev] [swift] Allow hostname for nodes in Ring

2014-10-14 Thread Osanai, Hisashi
Swift folks, Could you please advise me about the following email? Thanks in advance, Hisashi Osanai -Original Message- From: Osanai, Hisashi [mailto:osanai.hisa...@jp.fujitsu.com] Sent: Friday, October 10, 2014 1:57 PM To: openstack-dev@lists.openstack.org Subject: [openstack-dev

Re: [openstack-dev] [swift] Allow hostname for nodes in Ring

2014-10-14 Thread Osanai, Hisashi
Hi Matthew, Thanks for the quick response. On Wednesday, October 15, 2014 2:31 PM, Matthew Oliver wrote: - Continue where this one left off, in which case pull down the change from gerrit and start working on it. But if you do this make sure you add a 'Co-Authored-By: name

[openstack-dev] [swift] Allow hostname for nodes in Ring

2014-10-09 Thread Osanai, Hisashi
Hi Swift folks, Today the following patch was abandoned and I contacted with the author, so I would like to take it over if nobody else is chafing to take it. Is it OK? https://review.openstack.org/#/c/80421/ If it is OK, I will proceed it with following procedure. (1) Open new bug report

[openstack-dev] [doc][swift] improvement for selinux related procedure

2014-10-06 Thread Osanai, Hisashi
Hi, I think that the document OPENSTACK INSTALLATION GUIDE FOR RED HAT ENTERPRISE LINUX, ... has been written based on selinux because the openstack-selinux package is installed along with the in following procedure.

[openstack-dev] [all] minimum python support version for juno

2014-10-01 Thread Osanai, Hisashi
Hi, I would like to know the minimum python support version for juno. I checked the following memo. My understanding is python 2.6 support will be supported in juno and also dropped before kilo so it will be dropped in one of stable releases in juno. Is this correct understanding?

Re: [openstack-dev] [all] minimum python support version for juno

2014-10-01 Thread Osanai, Hisashi
Thank you for the quick responses. On 10/1/2014 4:24 AM, Ihar Hrachyshka wrote: All stable Juno releases will support Python 2.6. All Kilo releases are expected to drop Python 2.6 support. On Wednesday, October 01, 2014 11:28 PM, Matt Riedemann wrote: Right, and backports could be

[openstack-dev] [ceilometer] step ahead regarding swift middleware related topic

2014-09-25 Thread Osanai, Hisashi
Hi Ceilometer Folks, I would like to step ahead regarding the following two topic. (1) Backporting an important fix to Icehouse I think that this fix is really important and works OK. Could you please review and approve it? https://review.openstack.org/#/c/112806/ (2) Repackage the

Re: [openstack-dev] [ceilometer] repackage ceilometer and ceilometerclient

2014-08-22 Thread Osanai, Hisashi
On Friday, August 22, 2014 2:55 PM, Dean Troyer wrote: As one data point, the keystone middleware (auth_token) was just recently moved out of keystoneclient and into its own repo, partially because it had dependencies that otherwise were not required for pure client installations. 

Re: [openstack-dev] [ceilometer] repackage ceilometer and ceilometerclient

2014-08-22 Thread Osanai, Hisashi
On Friday, August 22, 2014 4:15 PM, Nejc Saje wrote: The modules you are talking about are part of Ceilometer's core functionality, we can't move them to a completely separate code-tree that is meant only for client functionality. Thank you for the explanation! I understand your point of the

Re: [openstack-dev] [ceilometer] repackage ceilometer and ceilometerclient

2014-08-21 Thread Osanai, Hisashi
Thank you for your quick response. On Thursday, August 21, 2014 3:12 PM, Nejc Saje wrote: I don't think there's any way the modules you mention in the BP can be moved into ceilometerclient. I think the best approach to resolve this would be to rewrite swift middleware to use oslo.messaging

Re: [openstack-dev] [ceilometer] repackage ceilometer and ceilometerclient

2014-08-21 Thread Osanai, Hisashi
, 2014 3:59 PM, Osanai, Hisashi wrote: I understand your point that solve almost unnecessary dependencies. I would like to make sure that remained the dependencies of context and timeutils after rewriting. Does the rewriting include removing the dependencies? On Thursday, August 21, 2014 3:12

Re: [openstack-dev] [ceilometer] repackage ceilometer and ceilometerclient

2014-08-21 Thread Osanai, Hisashi
On Friday, August 22, 2014 1:14 PM, Gordon chung wrote: could you create a spec[1] and we can maybe hash out idea there. [1]https://github.com/openstack/ceilometer-specs Thank you for your response. I will create a spec for this. Thank you very much! Hisashi Osanai

[openstack-dev] [ceilometer] repackage ceilometer and ceilometerclient

2014-08-20 Thread Osanai, Hisashi
Folks, I wrote the following BP regarding repackaging ceilometer and ceilometerclient. https://blueprints.launchpad.net/ceilometer/+spec/repackaging-ceilometerclient I need to install the ceilometer package when the swift_middlware middleware uses. And the ceilometer package has dependencies

Re: [openstack-dev] backport fixes to old branches

2014-08-17 Thread Osanai, Hisashi
On Friday, August 15, 2014 8:48 PM, Ihar Hrachyshka wrote: There was an issue with jenkins running py33 checks for stable ceilometer branches, which is wrong. Should be fixed now. Thank you for your response. I couldn't solve this by myself but Dina Belova and Julien Danjou solved this issue

Re: [openstack-dev] [ceilometer] gate-ceilometer-python33 failed because of wrong setup.py in happybase

2014-08-13 Thread Osanai, Hisashi
On Wednesday, August 13, 2014 5:03 PM, Julien Danjou wrote: This is not a problem in tox.ini, this is a problem in the infrastructure config. Removing py33 from the envlist in tox.ini isn't going to fix anything unforunately. Thank you for your quick response. I may misunderstand this topic.

Re: [openstack-dev] [ceilometer] gate-ceilometer-python33 failed because of wrong setup.py in happybase

2014-08-13 Thread Osanai, Hisashi
On Wed, Aug 13, 2014 at 2:35 PM, Julien Danjou wrote: Means the py33 needs to execute on stable/icehouse. Here I misunderstand something... Not it does not, that line in tox.ini is not use by the gate. this is a problem in the infrastructure config. Means execfile function calls on

[openstack-dev] [ceilometer] tox -epy26 failed because of insufficient test environment

2014-08-12 Thread Osanai, Hisashi
Hi, I got an error message when Jenkins executed tox -epy26 in the following fix. https://review.openstack.org/#/c/112771/ I think that the reason of the error message is a mongod isn't installed in test environment. (it works in my test env) Do you have any idea to solve this? -

Re: [openstack-dev] [ceilometer] tox -epy26 failed because of insufficient test environment

2014-08-12 Thread Osanai, Hisashi
On Tuesday, August 12, 2014 7:05 PM, Dina Belova wrote: that is blocking the Ceilometer gate at all for now. Thank you for your quick response. I understand current situation. Thanks again! Hisashi Osanai ___ OpenStack-dev mailing list

Re: [openstack-dev] [ceilometer] gate-ceilometer-python33 failed because of wrong setup.py in happybase

2014-08-12 Thread Osanai, Hisashi
On Tuesday, August 12, 2014 10:14 PM, Julien Danjou wrote: The py33 gate shouldn't be activated for the stable/icehouse. I'm no infra-config expert, but we should be able to patch it for that (hint?). Thank you for the response. Now we have two choices: (1) deter to activate the py33 gate

Re: [openstack-dev] ceilometer] [ft] Improving ceil.objectstore.swift_middleware

2014-08-10 Thread Osanai, Hisashi
On Friday, August 08, 2014 9:20 PM, Chris Dent wrote: These may not be directly what you want, but are something worth tracking as you explore and think. Thank you for your help. I will brush up my thought (shift to pollster) with the fixes which you pointed out. Thanks again! Hisashi

Re: [openstack-dev] backport fixes to old branches

2014-08-08 Thread Osanai, Hisashi
Hi, On Tuesday, August 05, 2014 8:57 PM, Ihar Hrachyshka wrote: Thanks. To facilitate quicker backport, you may also propose the patch for review yourself. It may take time before stable maintainers or other interested parties get to the bug and do cherry-pick. I did cherry-pick for

Re: [openstack-dev] [ceilometer] [swift] Improving ceilometer.objectstore.swift_middleware

2014-08-08 Thread Osanai, Hisashi
Hi, Is there any way to proceed ahead the following topic? Best Regards, Hisashi Osanai On Friday, August 01, 2014 7:32 PM, Hisashi Osanai wrote: I would like to follow this discussion so I picked up points. - There are two way to collect info from swift, one is pollster and the other

Re: [openstack-dev] backport fixes to old branches

2014-08-06 Thread Osanai, Hisashi
On Tuesday, August 05, 2014 8:57 PM, Ihar Hrachyshka wrote: Thanks. To facilitate quicker backport, you may also propose the patch for review yourself. It may take time before stable maintainers or other interested parties get to the bug and do cherry-pick. Thank you for your advice. I

[openstack-dev] backport fixes to old branches

2014-08-05 Thread Osanai, Hisashi
Hi, I would like to have the following fix for IceHouse branch because the problem happens on it but the fix was committed on Juno-2 only. Is there any process to backport fixes to old branches? https://bugs.launchpad.net/ceilometer/+bug/1326250 Best Regards, Hisashi Osanai

Re: [openstack-dev] backport fixes to old branches

2014-08-05 Thread Osanai, Hisashi
Thank you for your quick response. I don't have enough rights for nominating the bug so I put the tag icehouse-backport-potential instead. https://bugs.launchpad.net/ceilometer/+bug/1326250 On Tuesday, August 05, 2014 6:35 PM, Ihar Hrachyshka wrote:

Re: [openstack-dev] [ceilometer] [swift] Improving ceilometer.objectstore.swift_middleware

2014-08-01 Thread Osanai, Hisashi
I would like to follow this discussion so I picked up points. - There are two way to collect info from swift, one is pollster and the other is notification. And we discussed about how to solve the performance degradation of swift_middleware here. pollster: - storage.objects -

Re: [openstack-dev] [swift] Use FQDN in Ring files instead of ip

2014-07-23 Thread Osanai, Hisashi
I would like to discuss this topic more deeply. I understand we need to prepare DNS systems and add a lot of operational complexity and burden to use the DNS system when we use FQDN in Ring files. However I think most datacenter have DNS systems to manage network resources such as ip

Re: [openstack-dev] [swift] Use FQDN in Ring files instead of ip

2014-07-23 Thread Osanai, Hisashi
Thank you for the quick response. On Thursday, July 24, 2014 12:51 PM, John Dickinson wrote: you can actually do the same today with the IP-based system. You can use the set_info command of swift-ring-builder to change the IP for existing devices and this avoids any rebalancing in the

Re: [openstack-dev] [swift] Use FQDN in Ring files instead of ip

2014-07-23 Thread Osanai, Hisashi
Thank you for the clarification. I understand and agree with your thought it's clear enough. Thank you for your time and I highly appreciate your responses. Best Regards, Hisashi Osanai On Thursday, July 24, 2014 2:16 PM, John Dickinson wrote: Oh I totally agree with what you are saying. A

Re: [openstack-dev] [keystone/swift] role-based access cotrol in swift

2014-07-21 Thread Osanai, Hisashi
Hi, Thank you for the info. On Monday, July 21, 2014 10:19 PM, Nassim Babaci wrote: * Adding policy engine support to Swift https://review.openstack.org/#/c/89568/ With the commit message in 89568, you have developed same function except supporting policy.json file format. My answer is

Re: [openstack-dev] [keystone/swift] role-based access cotrol in swift

2014-07-11 Thread Osanai, Hisashi
John, Thank you for your quick response. On Friday, July 11, 2014 12:33 PM John Dickinson m...@not.mn wrote: Some of the above may be in line with what you're looking for. They are the one what I'm looking for. First I will look at the codes of policy engine whether I can use it. Thanks

[openstack-dev] [keystone/swift] role-based access cotrol in swift

2014-07-10 Thread Osanai, Hisashi
Hi, I looked for info about role-based access control in swift because I would like to prohibit PUT operations to containers like create containers and set ACLs. Other services like Nova, Cinder have policy.json file but Swift doesn't. And I found out the following info. - Swift ACL's

[openstack-dev] [swift] add checking daemons existence in Healthcheck middleware

2014-07-07 Thread Osanai, Hisashi
Hi, Current Healthcheck middleware provides the functionality of monitoring Servers such as Proxy Server, Object Server, Container Server, Container Server and Account Server. The middleware checks whether each Servers can handle request/response. My idea to enhance this middleware is

Re: [openstack-dev] [swift] add checking daemons existence in Healthcheck middleware

2014-07-07 Thread Osanai, Hisashi
it better or perhaps even some different ways to integrate monitoring systems, let us know! --John On Jul 7, 2014, at 7:33 PM, Osanai, Hisashi osanai.hisa...@jp.fujitsu.com wrote: Hi, Current Healthcheck middleware provides the functionality of monitoring Servers

Re: [openstack-dev] Swift: reason for using xfs on devices

2014-07-02 Thread Osanai, Hisashi
To: Osanai, Hisashi/小山内 尚 Cc: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] Swift: reason for using xfs on devices On Wed, 2 Jul 2014 00:16:42 + Osanai, Hisashi osanai.hisa...@jp.fujitsu.com wrote: So I think if performance of swift is more

[openstack-dev] Swift: reason for using xfs on devices

2014-07-01 Thread Osanai, Hisashi
Hi, In the following document, there is a setup up procedure for storage and it seems that swift recommends to use xfs. http://docs.openstack.org/icehouse/install-guide/install/yum/content/installing-and-configuring-storage-nodes.html === 2. For each device on the node that you want to use for

Re: [openstack-dev] Swift: reason for using xfs on devices

2014-07-01 Thread Osanai, Hisashi
On Tue, Jul 1, 2014 at 6:21 AM, Osanai, Hisashi osanai.hisa...@jp.fujitsu.com wrote: Hi, In the following document, there is a setup up procedure for storage and it seems that swift recommends to use xfs. http://docs.openstack.org/icehouse/install-guide/install/yum/content/installing