adding passwords to the node field

[Alex Polvi]

Hello,

A user emailed me this patch, which adds the adminPass to the Node
object. It is obvious why having this would be helpful, however I'm up
in the air if sticking as an attr on the node is the correct way to
go.

http://github.com/arnaudsj/libcloud/commit/7434f97d72e1d5f0d8b43a5103307fe97173d3fc

It seems like we should have a way to add arbitrary data to the node,
so that we never throw any data away from the provider. Any ideas?

-Alex

--
co-founder, cloudkick.com
twitter.com/cloudkick
541 231 0624

[Tom Davis]

Do you just want to add things at init? If that's the case, I
recommend adding **kwargs to the init, setting self.kwargs equal to it
in the base class, and overriding __getattr__ to add lookup to
self.kwargs if super() raises AttributeError. Easy peasy (unless I'm
missing something).

It seems like part of the point of subclasses is to provide such extra
arguments, but if you want a flexible way to have access to arbitrary
arguments stored on the object level, that's what I would do. Just
remember to document relevant kwargs in subclasses (as init vars,
preferably, because they are obvious) otherwise it will become a
mystery as to which nodes take which args and why anybody should care.

-- Tom

[Jeremy Orem]

I like Tom's idea, although, I'm not sure if it is better to use
**kwargs or add an extra argument (extra=None) that accepts a dict.
The "extra" argument might make it a little more obvious that the
additional arguments aren't always available.

-Jeremy

On Oct 17, 11:43 am, Tom Davis <t...@dislocatedday.com> wrote:
> Do you just want to add things at init? If that's the case, I  
> recommend adding **kwargs to the init, setting self.kwargs equal to it  
> in the base class, and overriding __getattr__ to add lookup to  
> self.kwargs if super() raises AttributeError. Easy peasy (unless I'm  
> missing something).
>
> It seems like part of the point of subclasses is to provide such extra  
> arguments, but if you want a flexible way to have access to arbitrary  
> arguments stored on the object level, that's what I would do. Just  
> remember to document relevant kwargs in subclasses (as init vars,  
> preferably, because they are obvious) otherwise it will become a  
> mystery as to which nodes take which args and why anybody should care.
>
> -- Tom
>
> On Oct 17, 2009, at 9:19 AM, Alex Polvi <po...@cloudkick.com> wrote:
>
>
>
> > Hello,
>
> > A user emailed me this patch, which adds the adminPass to the Node
> > object. It is obvious why having this would be helpful, however I'm up
> > in the air if sticking as an attr on the node is the correct way to
> > go.
>

> >http://github.com/arnaudsj/libcloud/commit/7434f97d72e1d5f0d8b43a5103...

[Alex Polvi]

On Sat, Oct 17, 2009 at 2:15 PM, Jeremy Orem <jerem...@gmail.com> wrote:
>
> I like Tom's idea, although, I'm not sure if it is better to use
> **kwargs or add an extra argument (extra=None) that accepts a dict.
> The "extra" argument might make it a little more obvious that the
> additional arguments aren't always available.

Another option would be to just add special optional kwargs with the
(adminPass=None, etc) to the node. That way it would be explicit.
However, then it would be hard to actually make a consistent
interface.

I think I'm leaning towards the extras={} kwarg, so that it is clear
that it is a libcloud convention...

-Alex

[Jeremy Orem]

On Oct 18, 1:33 pm, Alex Polvi <po...@cloudkick.com> wrote:
> Another option would be to just add special optional kwargs with the
> (adminPass=None, etc) to the node. That way it would be explicit.
> However, then it would be hard to actually make a consistent
> interface.

I'm mostly worried we'll keep tacking on more and more kwargs, but
maybe something like admin password is common enough to add it in as
an optional kwarg.

[Alex Polvi]

On Sun, Oct 18, 2009 at 1:39 PM, Jeremy Orem <jerem...@gmail.com> wrote:
>
> On Oct 18, 1:33 pm, Alex Polvi <po...@cloudkick.com> wrote:
>> Another option would be to just add special optional kwargs with the
>> (adminPass=None, etc) to the node. That way it would be explicit.
>> However, then it would be hard to actually make a consistent
>> interface.
>
> I'm mostly worried we'll keep tacking on more and more kwargs, but
> maybe something like admin password is common enough to add it in as
> an optional kwarg.

If we go with extra={}, do you think it would work like this?

def __init__(self, foo, bar, extra={}):
self.foo = foo
self.bar = bar
self.extra = extra

Then app code would go: adminpass = node.extra.get('adminPass', None)

Or would it be like this?

def __init__(self, foo, bar, extra={}):
self.foo = foo
self.bar = bar
self.adminpass = extra.get('adminPass', None)

Another option would be to add an "attributes" field, which has all
the data that came back from the provider. It would be up to the
to_node implementation to take all the extra data out of the providers
response and shove it in there. The advantage of this is that we would
never lose any data that came back from the provider. The downside is
that it would be a random grab bag of stuff.

-Alex

>
>> I think I'm leaning towards the extras={} kwarg, so that it is clear
>> that it is a libcloud convention...
>>
>> -Alex
> >
>

[Jeremy Orem]

On Oct 18, 1:49 pm, Alex Polvi <po...@cloudkick.com> wrote:
> If we go with extra={}, do you think it would work like this?
>
> def __init__(self, foo, bar, extra={}):
>   self.foo = foo
>   self.bar = bar
>   self.extra = extra
>
> Then app code would go: adminpass = node.extra.get('adminPass', None)

I envisioned it like the above or another option is to override
__getattr__ so we can look for extra attributes in self.extra if they
don't already exist in the object.

[Sébastien]

Hi,

Alex invited me to join the fun, since I am the user who submitted
this patch over the week-end ;)

I have gone through more of the API Doc for Rackspace and there are a
lot of new things to integrate which are not, I believe to be merged
with the base Node class unless they are common to more than just
Rackspace.

I actually have modified my patch since I submitted it, and pushed all
the new customizations into the Rackspace driver itself. I invite you
to look at this commit: http://github.com/arnaudsj/libcloud/commit/8eff3419bfbeb8f477cd83ab16b5a41274438a20

After submitting this, I felt bad about the verbose form of some of
the code I committed, so I went and introduced more 2.6+ pythonic
expressions to simplify the code:
http://github.com/arnaudsj/libcloud/commit/ee585323f390d04c178a2dddf86996bb719e5a9c
However, I am not sure if you guys have any guidelines regarding which
version of python you want to support with libcloud.

Finally, my next to-do is to crack open the return code dilemma with
Rackspace, as right now the error handling is pretty much inexistent.
Is this something that is just particular to Rackspace again, or are
there other APIs that only response through HTTP return code instead
of actual content?

Thank you for helping guide my work so that it can be most fruitful
for the libcloud project.

Cheers!

[Ivan]

> I have gone through more of the API Doc for Rackspace and there are a
> lot of new things to integrate which are not, I believe to be merged
> with the base Node class unless they are common to more than just
> Rackspace.
>
> I actually have modified my patch since I submitted it, and pushed all
> the new customizations into the Rackspace driver itself. I invite you

> to look at this commit:http://github.com/arnaudsj/libcloud/commit/8eff3419bfbeb8f477cd83ab16...

>
> After submitting this, I felt bad about the verbose form of some of
> the code I committed, so I went and introduced more 2.6+ pythonic

> expressions to simplify the code:http://github.com/arnaudsj/libcloud/commit/ee585323f390d04c178a2dddf8...

> However, I am not sure if you guys have any guidelines regarding which
> version of python you want to support with libcloud.
>

What parts are 2.6+?
[i for i in self.list_images() if i.id == image] should work in 2.4.

I do think that at least python 2.4+ should be supported. Debian Lenny
is on 2.5, there will still be a good amout of etch boxes out there I
would image with 2.4. Centos4/RHEL4 had 2.3 I think. (You have to draw
the line somewhere though)

> Finally, my next to-do is to crack open the return code dilemma with
> Rackspace, as right now the error handling is pretty much inexistent.
> Is this something that is just particular to Rackspace again, or are
> there other APIs that only response through HTTP return code instead
> of actual content?

There seems to be a lot of different ways heh. We went down the route
of returning non 2xx on error, but then we have a json response object
with error messages in it.