Mailing-List: contact dev-help@deltacloud.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@deltacloud.apache.org
Received-SPF: pass (nike.apache.org: local policy)
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: feedback request regarding FGCP driver patch
Date: Fri, 13 Apr 2012 00:29:53 +1000
Message-ID: <434A0ECB689CAF49A3A2321F30F2AB831FE34053@FALEX03.au.fjanz.com>
In-Reply-To: <1334194765.2597.65.camel@avon.watzmann.net>
Thread-Topic: feedback request regarding FGCP driver patch
Thread-Index: Ac0YTTV7/6W4xdIgQGaYtEzr4IyJqwAAknbw
References: <434A0ECB689CAF49A3A2321F30F2AB831FE33850@FALEX03.au.fjanz.com>
 <1334194765.2597.65.camel@avon.watzmann.net>
From: "Koper, Dies" <diesk@fast.au.fujitsu.com>
To: <dev@deltacloud.apache.org>

Hi David,

Thanks for the detailed reply.

> Maybe it is time that we assume the existence of /var/lib/deltacloud
and
> store everything there ? This would require that we at the very least
> also change the mock driver and have it store its data
> in /var/lib/deltacloud/mock

Where would that be on Windows?
So the full path would be something like
/var/lib/deltacloud/fgcp/certs/lutter/UserCert.p12 and
/var/lib/deltacloud/cacerts? (Or /etc/... as Justin suggested?)

> I think mapping from OS to username is icky, but should be fine.

OK, I'll add that.

> > 3. 'feature :instances, :hardware_profiles', what does it do?
>=20
> It allows overriding HWP propeties on instance creation - that only
> makes sense with HWP that use ranges or enums for some of their
> parameters. E.g., if a HWP says 'memory must be between 2GB and 8GB

Okay, sounds like it doesn't apply to FGCP.

> > 4. hardware_profiles.storage: storage is defined as part of the
image in
> Good question - omitting it would be cleaner to me, though API users
> might trip over themselves; would be good to check at least the Ruby
> client to see if it will be happy with HWP w/o storage.
>=20
> Otherwise, we could also set it to 0.

I only tried the GUI so far and under /hardware_profiles it shows
Storage: 0 (actually, it looks more like a circle with a slash through
it) and under /hardware_profiles/economy it is omitted - so that looks
good.

> > 5. Is there an easy way to sort the hardware_profiles before
returning
> No, there's nothing built in; you'll get to have some fun with
> Array#sort - don't be shy to implement a '<=3D>' in
> Deltacloud::HardwareProfile to make that simple. I think sorting
> ascending by [cpu, memory] is very sane.

I may try this when the driver is completed. I'm not skilled enough yet
;)

> > 6. FGCP's create image from instance API does not return the new
image
> > id straight away. In fact, it is not known until the creation
process
> > completes. What do you think of my solution to return a dummy id?
Shall
> > I add a check for that ID in create_instance to raise an error?
>=20
> You can't just return a dummy id, since that will become part of the
URL
> for the image (it will be /images/:id) - and that URL needs to stay
> fixed for as long as the image stays around.

Speaking of dummy ids, detached storage shows 'unknown' (as hyperlink!)
in the 'Attached to' field of the UI. Why not just leave it empty?

> How does the FGCP API deal with somebody creating 5 images from 5
> different instances ? How would a user know which image comes from
what
> instance ?

You specify a name and description for the instance when you create it.
So when it's completed and you list the images, a new image with that
name and description appear in that list. And at that time it will have
an id.

> > 10. Images' hardware profiles: In FGCP images can be used with any
> > hardware profile, so I'm saving a call (to retrieve the hardware
profile
> > list) and return an empty array. Should I return the hwps anyway?
>=20
> How often can HWP change in FGPC ? If they don't change, just retrieve
> them once and then stick them into a class variable.

Very rarely (once every few years?), so I suppose I could do that.
How do you feel about caching other data?
To obtain the realms, I need 1+N requests (1 list of virtual systems + N
list of network segments per virtual system). The number of network
segments in a virtual system cannot change once the system has been
created, so I could cache the network segments per system, only
reloading the list of virtual systems every time realms() is called and
then take the network segments from the cache. Would be much faster.

Today I implemented storage volumes and updated my code according to
some of the things we discussed here. Tomorrow I'll try to implement
another function and maybe upload a new patch.

Cheers,
Dies Koper


> -----Original Message-----
> From: David Lutterkort [mailto:lutter@redhat.com]
> Sent: Thursday, 12 April 2012 11:39 AM
> To: dev@deltacloud.apache.org
> Subject: Re: feedback request regarding FGCP driver patch
>=20
> Hi Dies,
>=20
> great to see this much progress on the driver - from glancing at it,
it
> looks very promising.
>=20
> On Thu, 2012-04-12 at 00:15 +1000, Koper, Dies wrote:
> > 1. The default storage paths for the user and CA certificates and
the
> > environment variables to override them with.
>=20
> I wouldn't store the certs in a path relative to __FILE__ - in a lot
of
> cases that will be under /usr, and writing there from code is pretty
> unfriendly. If FGCP_CERT_DIR is not set, I would try looking either
for
> something in $HOME/.deltacloud or in /var/tmp/deltacloud/fgcp ...
since
> these are certs, I wonder if the latter is really that great. Since
> deltacloudd often runs as a system daemon, I don't really like storing
> in $HOME either.
>=20
> Maybe it is time that we assume the existence of /var/lib/deltacloud
and
> store everything there ? This would require that we at the very least
> also change the mock driver and have it store its data
> in /var/lib/deltacloud/mock
>=20
> > 2. Instance :username is hardcoded to 'root' in some drivers. In
FGCP it
> > depends on the image's OS: 'root' for Linux and 'Administrator' for
> > Windows. There is no API to get the username but I could check the
OS
> > from the instance's image and return the right username that way. I
> > couldn't find any other drivers doing this. What would you
recommend?
> > Add the call or just not set :username?
>=20
> I think mapping from OS to username is icky, but should be fine.
>=20
> > 3. 'feature :instances, :hardware_profiles', what does it do?
>=20
> It allows overriding HWP propeties on instance creation - that only
> makes sense with HWP that use ranges or enums for some of their
> parameters. E.g., if a HWP says 'memory must be between 2GB and 8GB
> with
> a default of 4GB', the presence of this feature allows users to pass
in
> hwp_memory=3D3 when they create an instance.
>=20
> > 4. hardware_profiles.storage: storage is defined as part of the
image in
> > FGCP, not the hwp. Should I just not set this variable, or set it to
a
> > particular value (like 'N/A')?
>=20
> Good question - omitting it would be cleaner to me, though API users
> might trip over themselves; would be good to check at least the Ruby
> client to see if it will be happy with HWP w/o storage.
>=20
> Otherwise, we could also set it to 0.
>=20
> > 5. Is there an easy way to sort the hardware_profiles before
returning
> > them? Especially if hwp setting is optional when creating a new
instance
> > I'd like to default to the lowest spec one, but that is currently
not
> > the first one returned by hardware_profiles. So I'd like to sort its
> > profiles by memory and cpu before returning them.
>=20
> No, there's nothing built in; you'll get to have some fun with
> Array#sort - don't be shy to implement a '<=3D>' in
> Deltacloud::HardwareProfile to make that simple. I think sorting
> ascending by [cpu, memory] is very sane.
>=20
> > 6. FGCP's create image from instance API does not return the new
image
> > id straight away. In fact, it is not known until the creation
process
> > completes. What do you think of my solution to return a dummy id?
Shall
> > I add a check for that ID in create_instance to raise an error?
>=20
> You can't just return a dummy id, since that will become part of the
URL
> for the image (it will be /images/:id) - and that URL needs to stay
> fixed for as long as the image stays around.
>=20
> How does the FGCP API deal with somebody creating 5 images from 5
> different instances ? How would a user know which image comes from
what
> instance ?
>=20
> > 8. I had browser timeouts with the instances method so I reduced the
> > amount of detail given when no :id is specified. What do you think
of
> > the rules I use decide whether to add detail? OK like that or make
it
> > more predictable and return more detail only for the case where id
is
> > given?
>=20
> It's fine to return only some detail about instances for /instances
(as
> long as each instance has a URL from which you can retrieve all
details)
>=20
> > 10. Images' hardware profiles: In FGCP images can be used with any
> > hardware profile, so I'm saving a call (to retrieve the hardware
profile
> > list) and return an empty array. Should I return the hwps anyway?
>=20
> How often can HWP change in FGPC ? If they don't change, just retrieve
> them once and then stick them into a class variable.
>=20
> > Storage is defined by the image so I could return the list of
profiles
> > with the storage specified too.
>=20
> Hmmm ... I am not sure what the effect would be if the same HWP
> sometimes has storage=3D0 and sometimes storage=3D200. I wouldn't =
return
> anything different for the HWP's on an image.
>=20
> > 11. valid_credentials?: I only noticed about this method when I was
> > looking at some of the other drivers' unit tests. It's not in the
online
> > API documentation. How/why would a client use it?
>=20
> It's meant to allow quickly checking that you have the right
> credentials, before you do actual work.
>=20
> David
>=20
>=20