Re: [openstack-dev] Swift3 Plugin Development

2017-06-09 Thread Nicolas Trangez
On Thu, 2017-06-08 at 17:06 +0530, Venkata R Edara wrote:
> Hello,
> 
> we  have storage product called Gluster which is file storage system,
> we 
> are looking to support S3 APIs for it.

Hello Venkata,

Did you consider using the S3 Server project [1] to implement this
functionality? S3 Server supports object and bucket ACLs since its very
first release and was designed to provide a fully compatible AWS S3 API
(including e.g. object versioning) on top of existing storage systems
like Scality RING, Docker volumes and other cloud storage providers.
It's a fully open-source project, under the Apache-2 license.

See https://github.com/Scality/S3 for code and http://s3.scality.com
for some more background.

I believe it should be easy to integrate with Gluster, as it's meant to
have plugable meta-data and data back-ends.
 
Feel free to get in touch if you have any questions or would like to
discuss how to move forward with this project, we're happy to help and
collaborate!

Cheers,

Nicolas

-- 
 


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [oslo][devstack][all] ZooKeeper vs etcd for Tooz/DLM

2017-03-15 Thread Nicolas Trangez
On Wed, 2017-03-15 at 08:33 -0400, Sean Dague wrote:
> On 03/15/2017 08:10 AM, John Garbutt wrote:
> > On 15 March 2017 at 11:58, Jay Pipes  wrote:
> > > On 03/15/2017 07:44 AM, Sean Dague wrote:
> > > > 
> > > > On 03/14/2017 11:00 PM, Monty Taylor wrote:
> > > > 
> > > > > 
> > > > > a) awesome. when the rest of this dips momentarily into words
> > > > > that might
> > > > > sound negative, please hear it all wrapped in an "awesome"
> > > > > and know that
> > > > > my personal desire is to see the thing you're working on be
> > > > > successful
> > > > > without undue burden...
> > > > > 
> > > > > b) In Tokyo, we had the big discussion about DLMs (where at
> > > > > least my
> > > > > intent going in to the room was to get us to pick one and
> > > > > only one).
> > > > > There were three camps in the room who were all vocal:
> > > > > 
> > > > > 1) YES! Let's just pick one, I don't care which one
> > > > > 2) I hate Java I don't want to run Zookeeper, so we can't
> > > > > pick that
> > > > > 3) I hate go/don't trust coreos I don't want to run etcd so
> > > > > we can't
> > > > > pick that
> > > > > 
> > > > > Because of 2 and 3 the group represented by 1 lost and we
> > > > > ended up with:
> > > > > "crap, we have to use an abstraction library"
> > > > > 
> > > > > I'd argue that unless something has changed significantly,
> > > > > having Nova
> > > > > grow a direct depend on etcd when the DLM discussion brought
> > > > > us to "the
> > > > > operators in the room have expressed a need for a pluggable
> > > > > choice
> > > > > between at least zk and etcd" should be pretty much a non-
> > > > > starter.
> > > > > 
> > > > > Now, being that I was personally in group 1, I'd be THRILLED
> > > > > if we
> > > > > could, as a community, decide to pick one and skip having an
> > > > > abstraction
> > > > > library. I still don't care which one - and you know I love
> > > > > gRPC/protobuf.
> > > > > 
> > > > > But I do think that given the anti-etcd sentiment that was
> > > > > expressed was
> > > > > equally as vehement as the anti-zk sentiment, that we need to
> > > > > circle
> > > > > back and make a legit call on this topic.
> > > > > 
> > > > > If we can pick one, I think having special-purpose libraries
> > > > > like
> > > > > os-lively for specific purposes would be neat.
> > > > > 
> > > > > If we still can't pick one, then I think adding the liveness
> > > > > check you
> > > > > implemented for os-lively as a new feature in tooz and also
> > > > > implementing
> > > > > the same thing in the zk driver would be necessary. (of
> > > > > course, that'll
> > > > > probably depend on getting etcd3 support added to tooz and
> > > > > making sure
> > > > > there is a good functional test for etcd3.
> > > > 
> > > > 
> > > > We should also make it clear that:
> > > > 
> > > > 1) Tokyo was nearly 1.5 years ago.
> > > > 2) Many stake holders in openstack with people in that room may
> > > > no
> > > > longer be part of our community
> > > > 3) Alignment with Kubernetes has become something important at
> > > > many
> > > > levels inside of OpenStack (which puts some real weight on the
> > > > etcd front)
> > > 
> > > 
> > > Yes, and even more so for etcd3 vs. etcd2, since a) k8s now uses
> > > etcd3 and
> > > b) etcd2 is no longer being worked on.
> > > 
> > > > 4) The containers ecosystem, which etcd came out of, has
> > > > matured
> > > > dramatically
> > 
> > +1 for working towards etcd3 a "base service", based on operator
> > acceptance.
> > +1 for liveness checks not causing silly DB churn.
> > 
> > While we might not need/want an abstraction layer to hide the
> > differences between different backends, but a library (tooz and/or
> > os-lively) so we all consistently use the tool seems to make sense.
> > 
> > Maybe that means get tooz using etcd3 (Julian or Jay, or both maybe
> > seemed keen?)
> > Maybe the tooz API adds bits from the os-lively POC?
> 
> I do have a concern where we immediately jump to a generic
> abstraction,
> instead of using the underlying technology to the best of our
> ability.
> It's really hard to break down and optimize the abstractions later.
> We've got all sorts of cruft (an inefficiencies) in our DB access
> layer
> because of this (UUIDs stored as UTF8 strings being a good example).
> 
> I'd definitely be more interested in etcd3 as a defined base service,
> people can use it directly. See what kind of patterns people come up
> with. Abstract late once the patterns are there.

I'm not involved in Oslo or Devstack, so not really a say in this, but:

Yes! A 1000 times yes! An 'abstraction' with only a single
implementation is (1) almost by definition not an abstraction, and (2)
in 99% of the cases just exposing a crippled version of the underlying
system's features.
Furthermore, adding a second implementation of the interface backed by
another system at some later point in time turns out to be difficult
(or impossible) because the 'abstraction' 

Re: [openstack-dev] [Cinder] Pending removal of Scality volume driver

2016-08-10 Thread Nicolas Trangez
Sean and team,

On Wed, 2016-08-03 at 08:55 -0300, Erlon Cruz wrote:
> Hi sean, I think it would worth to CC the contact info informed in
> the CI
> Wiki (openstack...@scality.com).
> 
> On Tue, Aug 2, 2016 at 4:26 PM, Sean McGinnis 
> wrote:
> 
> > 
> > Tomorrow is the one week grace period. I just ran the last comment
> > script and it still shows it's been 112 days since the Scality CI
> > has
> > reported on a patch.
> > 
> > Please let me know the status of the CI.

Sadly enough, we have been unable to resolve the recent issues in the
system/lab backing our CI server (originally caused by some hardware
migrations), and it's unclear when this would be back in a stable
state. We consider moving to a different service, which would require a
re-install of the CI system (which, given the development on Zuul and
related services since we set it up, may be a healthy thing to do
anyway).

In order to play by the rules of the Cinder community, we propose our
driver to be temporarily removed from the tree, until we get this CI
situation resolved. We are confident the Scality volume driver is in
working shape and is not to be removed for bug/technical reasons. As
such we'll aim for re-inclusion as soon as we get a stable Cinder CI
environment up and running again.

I filed https://review.openstack.org/#/c/353739/ to handle all of this.

Thank you,

Nicolas

-- 
 

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Cinder] Pending removal of Scality volume driver

2016-08-03 Thread Nicolas Trangez
Sean,

Jordan, who's managing this, is currently in holidays. Furthermore
we're experiencing some hardware issues with the lab used by the CI
system to run the tests complicating things.

Any chance we could get some more time for Jordan to look into this?

Thanks,

Nicolas

On Wed, 2016-08-03 at 08:55 -0300, Erlon Cruz wrote:
> Hi sean, I think it would worth to CC the contact info informed in
> the CI
> Wiki (openstack...@scality.com).
> 
> On Tue, Aug 2, 2016 at 4:26 PM, Sean McGinnis 
> wrote:
> 
> > 
> > Tomorrow is the one week grace period. I just ran the last comment
> > script and it still shows it's been 112 days since the Scality CI
> > has
> > reported on a patch.
> > 
> > Please let me know the status of the CI.
> > 
> > On Thu, Jul 28, 2016 at 07:28:26AM -0500, Sean McGinnis wrote:
> > > 
> > > On Thu, Jul 28, 2016 at 11:28:42AM +0200, Jordan Pittier wrote:
> > > > 
> > > > Hi Sean,
> > > > 
> > > > Thanks for the heads up.
> > > > 
> > > > On Wed, Jul 27, 2016 at 11:13 PM, Sean McGinnis  > > > gmx.com
> > > 
> > > > 
> > > > wrote:
> > > > 
> > > > > 
> > > > > The Cinder policy for driver CI requires that all volume
> > > > > drivers
> > > > > have a CI reporting on any new patchset. CI's may have some
> > > > > down
> > > > > time, but if they do not report within a two week period they
> > > > > are
> > > > > considered out of compliance with our policy.
> > > > > 
> > > > > This is a notification that the Scality OpenStack CI is out
> > > > > of
> > compliance.
> > > 
> > > > 
> > > > > 
> > > > > It has not reported since April 12th, 2016.
> > > > > 
> > > > Our CI is still running for every patchset, just that it
> > > > doesn't report
> > > > back to Gerrit. I'll see what I can do about it.
> > > 
> > > Great! I'll watch for it to start reporting again. Thanks for
> > > being
> > > responsive and looking into it.
> > > 
> > > > 
> > > > 
> > > > > 
> > > > > 
> > > > > The patch for driver removal has been posted here:
> > > > > 
> > > > > https://review.openstack.org/348032/
> > > > 
> > > > That link is about the Tegile driver, not ours.
> > > 
> > > Oops, copy/paste error. Here is the correct one:
> > > 
> > > https://review.openstack.org/#/c/348042/
> > > 
> > > > 
> > > > 
> > > 
> > > 
> > ___
> > ___
> > > 
> > > OpenStack Development Mailing List (not for usage questions)
> > > Unsubscribe:
> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > > 
> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > 
> > ___
> > ___
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsu
> > bscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > 
> _
> _
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubs
> cribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-- 
 

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Glance] glance_store and glance

2015-08-07 Thread Nicolas Trangez
On Fri, 2015-08-07 at 01:21 -0400, Nikhil Komawar wrote:
 3. ease of addition of newer drivers for the developers -- drivers 
 are
 only being removed since.

The OpenStack team at Scality developed a Glance Store driver for RING,
currently out-of-tree to get to a first fully-working version (
https://github.com/scality/scality-glance-store), but with the
intention from day 1 to propose this driver for inclusion in the
upstream glance-store project, following the standard OpenStack
processes.

Whilst as you say new drivers haven't been proposed since the split,
this could be explained by the fact the way Glance is designed now
explicitly supports out-of-tree drivers (in glance-store or elsewhere)?

We have a couple of questions related to this proposal:

- Would folding glance-store back into glance have any impact on the
process (or reluctance) to include new third-party drivers?

- Will the glance-store core reviewer team be merged back into glance,
focusing on the store drivers?

Nicolas

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [nova][cinder][neutron][security] Rootwrap on root-intensive nodes

2015-02-05 Thread Nicolas Trangez
On Thu, 2015-02-05 at 08:27 -0500, Tristan Cacqueray wrote:
 Thus if we want to emulate OpenSSH design, the rpc call would also
 need to
 carry authentication data in order to prevent unwanted activity. And
 the
 rpc daemon would then need to enforce some kind of acl/policy.

Sounds a lot like what the DBus system bus implements/provides to me...
And it took quite some time to get that done.

(Note: I'm not proposing its usage in any way)

Nicolas


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Swift] Swift GUI (free or open source)?

2015-01-29 Thread Nicolas Trangez
On Wed, 2015-01-28 at 17:35 -0800, Adam Lawson wrote:
 Okay cool beans. Incidentally, are there any efforts out there going
 through the motions that you know about (even abandoned)? I'd be willing to
 prop them a bit if they're low on development resources..

I don't know of any such project(s), but I'd be very interested in this
as well.

Nicolas


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] People of OpenStack (and their IRC nicks)

2014-12-09 Thread Nicolas Trangez
On Tue, 2014-12-09 at 10:46 +, Matthew Gilliard wrote:
 can we autogenerate it somehow?

Maybe some 'irc_nick' field in Stackalytic's default_data.json could be
added and used to populate such page?

Nicolas


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [nova] Proposal new hacking rules

2014-11-26 Thread Nicolas Trangez
On Mon, 2014-11-24 at 13:19 -0500, Jay Pipes wrote:
 I think pointing out that the default failure 
 message for testtools.TestCase.assertEqual() uses the terms
 reference 
 (expected) and actual is a reason why reviewers *should* ask patch 
 submitters to use (expected, actual) ordering.

Is there any reason for this specific ordering? Not sure about others,
but I tend to write equality comparisons like this

if var == 1:

instead of

if 1 == var:

(although I've seen the latter in C code before).

This gives rise to

assert var == 1

or, moving into `unittest` domain

assertEqual(var, 1)

reading it as 'Assert `var` equals 1', which makes me wonder why the
`assertEqual` API is defined the other way around (unlike how I'd write
any other equality check).

Nicolas


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [nova] Proposal new hacking rules

2014-11-26 Thread Nicolas Trangez
On Wed, 2014-11-26 at 08:54 -0500, Jay Pipes wrote:
 On 11/26/2014 06:20 AM, Nicolas Trangez wrote:
  On Mon, 2014-11-24 at 13:19 -0500, Jay Pipes wrote:
  I think pointing out that the default failure
  message for testtools.TestCase.assertEqual() uses the terms
  reference
  (expected) and actual is a reason why reviewers *should* ask patch
  submitters to use (expected, actual) ordering.
 
  Is there any reason for this specific ordering? Not sure about others,
  but I tend to write equality comparisons like this
 
   if var == 1:
 
  instead of
 
   if 1 == var:
 
  (although I've seen the latter in C code before).
 
  This gives rise to
 
   assert var == 1
 
  or, moving into `unittest` domain
 
   assertEqual(var, 1)
 
  reading it as 'Assert `var` equals 1', which makes me wonder why the
  `assertEqual` API is defined the other way around (unlike how I'd write
  any other equality check).
 
 It's not about an equality condition.
 
 It's about the message that is produced by 
 testtools.TestCase.assertEqual(), and the helpfulness of that message 
 when the order of the arguments is reversed.

I'm aware of that. I was just wondering whether there's a particular
reason the ordering (and as a result of that the error message) was
chosen as it is.

I'd rather design the API as `assertEqual(value, expected)`, and let the
message indeed say 'Expected ..., but got ...' (and using the argument
values accordingly).

Nicolas


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev