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 Osa
Hi,
# I'm sending same content email again because previous subject is not suitable.
I did cherry-pick for "https://bugs.launchpad.net/ceilometer/+bug/1326250"; and
executed git review (https://review.openstack.org/#/c/112806/).
In review phase I got the error message from Jenkins.
The reason
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?
- setup-tes
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
OpenStack-dev
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 topi
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 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 w
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,
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 th
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
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 a
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?
https://ethe
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 in
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.
http://docs.openstack.org/icehouse/install-guide/install/yum/content/basi
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 (the
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.o
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
> ' to att
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 (go
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
r using xfs on devices
On Tue, Jul 1, 2014 at 6:21 AM, Osanai, Hisashi
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-and-configur
02, 2014 1:06 PM
> 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" wrote:
>
> > So I think i
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
check
nformation about the health of the cluster.
>
> If you've got some other ideas on checks to add to recon or ways to make
> it better or perhaps even some different ways to integrate monitoring
> systems, let us know!
>
> --John
>
>
>
> On Jul 7, 2014, at 7:33
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 migra
John,
Thank you for your quick response.
On Friday, July 11, 2014 12:33 PM John Dickinson 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 again,
Hisash
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 addresses
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 cl
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
- stora
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:
> https://wiki.openstack.org/wiki/StableBr
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 wo
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 othe
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
has
On Thursday, July 09, 2015 2:18 AM, Clint Byrum wrote:
> We can't change the past, but we can certainly influence the future. I
> think we should probably reconsider this name, and honor our Japanese
> hosts with a name that is pleasing to the entire community.
I completely agree with the current
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 Maili
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 juri
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 Key
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 rul
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 projec
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.
> I
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 Osanai
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
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 pro
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.
h
53 matches
Mail list logo