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
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
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
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?
-
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
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
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.
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
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
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
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
, 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
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
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
-
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
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:
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
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
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?
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
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.
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
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
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
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
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
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
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
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.
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
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
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
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
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
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
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
49 matches
Mail list logo
