Re: Condor Cloud Provider Project

[David Lutterkort]

On Wed, 2011-03-16 at 10:28 -0400, Greg Blomquist wrote:
>  +++ John R. Dunning [16/03/11 09:01 -0400]:
>  >
>  >Oops, I probably misspoke.  I thought when you and I talked on the
>  >phone, we said that you were going to think about what the components
>  >would need to be for the stateful chunk of code, interfacing between
>  >DC API and the buzzard^H^H^H^H^H^H^Hcondor backend.  If you've already
>  >got enough on your plate that's fine.
>  >
>  >Perhaps it will make sense for Greg to look at that?
>  
>  I'll probably need a little more insight into what needs looking into here.  
>  I'm currently working on a "config server", but I'm not sure of the
> overlap 
>  with what's being discussed here.  The config server I'm working on is specific
>  to Audrey wrt cross-pollinating instance configs for post-boot configurations 
>  of deployables. 
That is very much needed, but very different from what Falcon needs; it
should be possible to stand up a Falcon instance, without using
Conductor, Audrey or any of the other higher-level services we are
working on. That should give you a private cloud that lets you run your
own homegrown images and talk to it via Deltacloud.

There are really two 'config servers' in play here:

     1. The server to which an instance posts its IP address; for all
        intents and purposes this could be the Deltacloud server itself.
        To make this scheme moderately secure, we should inject 3 pieces
        of data into an instance: the IP of that server, some sort of
        UUID for the instance, and a secret token that only the instance
        and this config server know. The instance then posts its IP, its
        UUID and hte secret token to update the instance/IP mapping.
     2. The post-boot config server that is part of Audrey II - a
        completely separate animal.

David

Condor Cloud Provider Project

[Michal Fojtik]

On Mar 16, 2011, at 7:04 PM, David Lutterkort wrote:

>  On Wed, 2011-03-16 at 10:28 -0400, Greg Blomquist wrote:
> > +++ John R. Dunning [16/03/11 09:01 -0400]:
> >> 
> >> Oops, I probably misspoke.  I thought when you and I talked on the
> >> phone, we said that you were going to think about what the components
> >> would need to be for the stateful chunk of code, interfacing between
> >> DC API and the buzzard^H^H^H^H^H^H^Hcondor backend.  If you've already
> >> got enough on your plate that's fine.
> >> 
> >> Perhaps it will make sense for Greg to look at that?
> > 
> > I'll probably need a little more insight into what needs looking into here.  
> > I'm currently working on a "config server", but I'm not sure of the
> overlap 
> > with what's being discussed here.  The config server I'm working on is
> specific
> > to Audrey wrt cross-pollinating instance configs for post-boot configurations 
> > of deployables.
>  
>  That is very much needed, but very different from what Falcon needs; it
>  should be possible to stand up a Falcon instance, without using
>  Conductor, Audrey or any of the other higher-level services we are
>  working on. That should give you a private cloud that lets you run your
>  own homegrown images and talk to it via Deltacloud.
>  
>  There are really two 'config servers' in play here:
>  
>      1. The server to which an instance posts its IP address; for all
>         intents and purposes this could be the Deltacloud server itself.
>         To make this scheme moderately secure, we should inject 3 pieces
>         of data into an instance: the IP of that server, some sort of
>         UUID for the instance, and a secret token that only the instance
>         and this config server know. The instance then posts its IP, its
>         UUID and hte secret token to update the instance/IP mapping. 
Actually we was thinking about using Sinatra app which talks to Condor and translate
queries for Deltacloud API to handle this IP managment.

So for Deltacloud API this communication will be more transparent (DC API driver will
just talk to this Sinatra app which add proper IP address to instance on backend site).

See here:
http://git.fedorahosted.org/git/?p=condor-cloud.git;a=summary

  -- Michal

>      2. The post-boot config server that is part of Audrey II - a
>         completely separate animal.
>  
>  David
>  
>  
>  
>   
------------------------------------------------------
Michal Fojtik, mfojtik(a)redhat.com
Deltacloud API: http://deltacloud.org

Condor Cloud Provider Project

[David Lutterkort]

On Wed, 2011-03-16 at 20:23 +0100, Michal Fojtik wrote:
>  Actually we was thinking about using Sinatra app which talks to Condor and translate
>  queries for Deltacloud API to handle this IP managment. 
To make sure I get this right: the flow then is

                                      *
        client -> deltacloud-core server -> new sinatra app -> condor

Which raises the same question I asked yesterday about vSphere: why does
the interface marked with (*) need to be REST ? Wouldn't it make more
sense to collapse all that into the deltacloud-falcon driver so that the
interface (*) is just normal in-process calls within the driver ?

I am all for abstracting the deltacloud driver/condor interaction a
little bit, but that can also be done by putting that code into a
separate gem or similar.

David

Condor Cloud Provider Project

[Michal Fojtik]

On Mar 17, 2011, at 12:43 AM, David Lutterkort wrote:

>  On Wed, 2011-03-16 at 20:23 +0100, Michal Fojtik wrote:
> > 
> > Actually we was thinking about using Sinatra app which talks to Condor and translate
> > queries for Deltacloud API to handle this IP managment.
>  
>  To make sure I get this right: the flow then is
>  
>                                       *
>         client -> deltacloud-core server -> new sinatra app -> condor 
Yes this is right.

>  Which raises the same question I asked yesterday about vSphere: why
> does
>  the interface marked with (*) need to be REST ? Wouldn't it make more
>  sense to collapse all that into the deltacloud-falcon driver so that the
>  interface (*) is just normal in-process calls within the driver ? 
This application will do an IP management for Condor cloud, so:

1) Will held configuration file used by DHCP server to assign IP from MAC address
2) Will do a POST service for in-guest-agent inside Condor VMs 

Another benefit is that you don't need to install Deltacloud API on the same machine
where Condor is installed / or install Condor just for doing calls to remote Condor...

My thoughts are to use this app to 'simulate' 'real' public cloud behavior
which obviously
expose some sort of API. In this case it will be *very* simple API. Then in DC driver we
can
just use RestClient + Nokogiri to parse XML.

  -- Michal

>  I am all for abstracting the deltacloud driver/condor interaction a
>  little bit, but that can also be done by putting that code into a
>  separate gem or similar.
>  
>  David
>  
>   
------------------------------------------------------
Michal Fojtik, mfojtik(a)redhat.com
Deltacloud API: http://deltacloud.org

Condor Cloud Provider Project

[David Lutterkort]

On Thu, 2011-03-17 at 09:05 +0100, Michal Fojtik wrote:
>  On Mar 17, 2011, at 12:43 AM, David Lutterkort wrote:
>  
>  > On Wed, 2011-03-16 at 20:23 +0100, Michal Fojtik wrote:
>  >> 
>  >> Actually we was thinking about using Sinatra app which talks to Condor and
> translate
>  >> queries for Deltacloud API to handle this IP managment.
>  > 
>  > To make sure I get this right: the flow then is
>  > 
>  >                                      *
>  >        client -> deltacloud-core server -> new sinatra app -> condor
>  
>  Yes this is right.
>  
>  > Which raises the same question I asked yesterday about vSphere: why does
>  > the interface marked with (*) need to be REST ? Wouldn't it make more
>  > sense to collapse all that into the deltacloud-falcon driver so that the
>  > interface (*) is just normal in-process calls within the driver ?
>  
>  This application will do an IP management for Condor cloud, so:
>  
>  1) Will held configuration file used by DHCP server to assign IP from MAC address
>
>  2) Will do a POST service for in-guest-agent inside Condor VMs  
That can be achieved by adding one more POST handler to the Deltacloud
application.

Will Falcon then support both modes of operation, explicit IP assignment
controlled by a Falcon-supplied DHCP server, and scraping IP's out of
running instances via an agent ?

>  Another benefit is that you don't need to install Deltacloud API
> on the same machine
>  where Condor is installed / or install Condor just for doing calls to remote Condor...
Is that a real deployment concern ? I would hope that Condor already
gives us all the deployment flexibility we'd need, so we can always
pretend that condor is running local to the server. Are there actual
requirements that make it impossible for us to run the Deltacloud server
and Condor on the same machine ?

Just as a reminder: the fact that all deltacloud-core drivers talk HTTP
out the back is not because it's an elegant design choice - it's by
necessity, since the only API's we can talk to are via HTTP. For Falcon,
there is absolutely no reason why we'd need to have the same sort of
split, and where the other DC drivers use HTTP to talk to the backend
cloud, we can use in-process calls to talk to Condor. That's an order of
magnitude easier to design and test.

>  My thoughts are to use this app to 'simulate' 'real'
> public cloud behavior which obviously
>  expose some sort of API. In this case it will be *very* simple API. Then in DC driver we
> can
>  just use RestClient + Nokogiri to parse XML. 
There's no need really to have an internal remote API for Falcon at this
point. I would assume that that internal API will closely mirror DC
anyway, and most of the work that needs to be done in the DC driver will
be fairly artificial and redundant. It would mostly amount to
deserializing one format and then serializing back into an almost
identical format.

As for deployment/scalability flexibility, I would _definitely_ not use
a REST based API for that - if needed, AMQP would give us much more
flexibility and scalability.

But those concerns are premature: for now, it's way enough to have the
Deltacloud driver interact with condor directly, not over a remote API.

David

Condor Cloud Provider Project

[Ian Main]

On Thu, Mar 17, 2011 at 11:04:28AM -0700, David Lutterkort wrote:
>  On Thu, 2011-03-17 at 09:05 +0100, Michal Fojtik wrote:
>  > On Mar 17, 2011, at 12:43 AM, David Lutterkort wrote:
>  > 
>  > > On Wed, 2011-03-16 at 20:23 +0100, Michal Fojtik wrote:
>  > >> 
>  > >> Actually we was thinking about using Sinatra app which talks to Condor and
> translate
>  > >> queries for Deltacloud API to handle this IP managment.
>  > > 
>  > > To make sure I get this right: the flow then is
>  > > 
>  > >                                      *
>  > >        client -> deltacloud-core server -> new sinatra app -> condor
>  > 
>  > Yes this is right.
>  > 
>  > > Which raises the same question I asked yesterday about vSphere: why does
>  > > the interface marked with (*) need to be REST ? Wouldn't it make more
>  > > sense to collapse all that into the deltacloud-falcon driver so that the
>  > > interface (*) is just normal in-process calls within the driver ?
>  > 
>  > This application will do an IP management for Condor cloud, so:
>  > 
>  > 1) Will held configuration file used by DHCP server to assign IP from MAC address
>  >
>  > 2) Will do a POST service for in-guest-agent inside Condor VMs 
>  
>  That can be achieved by adding one more POST handler to the Deltacloud
>  application.
>  
>  Will Falcon then support both modes of operation, explicit IP assignment
>  controlled by a Falcon-supplied DHCP server, and scraping IP's out of
>  running instances via an agent ? 
Yes.  The other thing is authentication.  Basically there will be
configuration required on the condor-cloud side that I'm not sure
belongs in a driver.

You are correct that this could be done with a gem or even just a script
(almost) but to have a running process will be useful for eg the dhcpd
case etc.  I was a bit torn on this too and decided I would run with the
REST api.  In the end both will work.

>  > Another benefit is that you don't need to install Deltacloud
> API on the same machine
>  > where Condor is installed / or install Condor just for doing calls to remote
> Condor...
>  
>  Is that a real deployment concern ? I would hope that Condor already
>  gives us all the deployment flexibility we'd need, so we can always
>  pretend that condor is running local to the server. Are there actual
>  requirements that make it impossible for us to run the Deltacloud server
>  and Condor on the same machine ? 
Condor can do remote calls.  Also I don't think it's an issue generally
to have the driver on the same machine as there's already the REST api
there making it network capable of course.  That is not why we went this
route.

>  Just as a reminder: the fact that all deltacloud-core drivers talk
> HTTP
>  out the back is not because it's an elegant design choice - it's by
>  necessity, since the only API's we can talk to are via HTTP. For Falcon,
>  there is absolutely no reason why we'd need to have the same sort of
>  split, and where the other DC drivers use HTTP to talk to the backend
>  cloud, we can use in-process calls to talk to Condor. That's an order of
>  magnitude easier to design and test. 
There is a logical split here.  I also want to be able to develop the
condor-cloud side without having to modify the driver all the time, so
some kind of logical separation is required.

>  > My thoughts are to use this app to 'simulate'
> 'real' public cloud behavior which obviously
>  > expose some sort of API. In this case it will be *very* simple API. Then in DC
> driver we can
>  > just use RestClient + Nokogiri to parse XML.
>  
>  There's no need really to have an internal remote API for Falcon at this
>  point. I would assume that that internal API will closely mirror DC
>  anyway, and most of the work that needs to be done in the DC driver will
>  be fairly artificial and redundant. It would mostly amount to
>  deserializing one format and then serializing back into an almost
>  identical format.
>  
>  As for deployment/scalability flexibility, I would _definitely_ not use
>  a REST based API for that - if needed, AMQP would give us much more
>  flexibility and scalability.
>  
>  But those concerns are premature: for now, it's way enough to have the
>  Deltacloud driver interact with condor directly, not over a remote API. 
OK, to summarize, basically by doing the REST API we can:

- Develop the condor-cloud portion outside of the driver, eg add new IP
  snarfing techniques etc. without changing the driver.
- Have configuration of the condor-cloud portion without it being part
  of the driver, it will feel like its own piece of software, which it
  should be.
- Things to configure include authentication, IP management techniques,
  various limits on CPU/memory etc., location of image repository, 
  and specific VM configurations.
- Having an agent, eg daemon type process, lets us accept callbacks 
  from whatever IP management system we use, watch dhcpd logs or what
  have you.

The downside being it may be a bit slower, maybe a little harder to
develop?  Although seeing how it works I don't see it being much harder
to develop than any other API.  Michal already has the groundwork up
and running.  Again I don't think it's a make or break thing here..

I'll see how Michal is making out and if we need to strip this back
some for time reasons.

    Ian

Condor Cloud Provider Project

[Michal Fojtik]

On Mar 18, 2011, at 9:46 PM, Ian Main wrote:

>  On Thu, Mar 17, 2011 at 11:04:28AM -0700, David Lutterkort wrote:
> > On Thu, 2011-03-17 at 09:05 +0100, Michal Fojtik wrote:
> >> On Mar 17, 2011, at 12:43 AM, David Lutterkort wrote:
> >> 
> >>> On Wed, 2011-03-16 at 20:23 +0100, Michal Fojtik wrote:
> >>>> 
> >>>> Actually we was thinking about using Sinatra app which talks to Condor
> and translate
> >>>> queries for Deltacloud API to handle this IP managment.
> >>> 
> >>> To make sure I get this right: the flow then is
> >>> 
> >>>                                     *
> >>>       client -> deltacloud-core server -> new sinatra app -> condor
> >> 
> >> Yes this is right.
> >> 
> >>> Which raises the same question I asked yesterday about vSphere: why does
> >>> the interface marked with (*) need to be REST ? Wouldn't it make more
> >>> sense to collapse all that into the deltacloud-falcon driver so that the
> >>> interface (*) is just normal in-process calls within the driver ?
> >> 
> >> This application will do an IP management for Condor cloud, so:
> >> 
> >> 1) Will held configuration file used by DHCP server to assign IP from MAC
> address
> >> 
> >> 2) Will do a POST service for in-guest-agent inside Condor VMs 
> > 
> > That can be achieved by adding one more POST handler to the Deltacloud
> > application.
> > 
> > Will Falcon then support both modes of operation, explicit IP assignment
> > controlled by a Falcon-supplied DHCP server, and scraping IP's out of
> > running instances via an agent ?
>  
>  Yes.  The other thing is authentication.  Basically there will be
>  configuration required on the condor-cloud side that I'm not sure
>  belongs in a driver. 
What sort of authentication you mean? I can use LDAP/Kerberos auth for Condor.

>  
>  You are correct that this could be done with a gem or even just a script
>  (almost) but to have a running process will be useful for eg the dhcpd
>  case etc.  I was a bit torn on this too and decided I would run with the
>  REST api.  In the end both will work. 
Yes, after brief talk with David I agree to create a gem instead of writing a new
REST API. Even code I wrote in Sinatra perfectly replicate DC API structure, so this
redudancy
is not needed.

I removed Sinatra application today and finished with 'launch_instance' and
hardware profiles.

> >> Another benefit is that you don't need to install
> Deltacloud API on the same machine
> >> where Condor is installed / or install Condor just for doing calls to remote
> Condor...
> > 
> > Is that a real deployment concern ? I would hope that Condor already
> > gives us all the deployment flexibility we'd need, so we can always
> > pretend that condor is running local to the server. Are there actual
> > requirements that make it impossible for us to run the Deltacloud server
> > and Condor on the same machine ?
>  
>  Condor can do remote calls.  Also I don't think it's an issue generally
>  to have the driver on the same machine as there's already the REST api
>  there making it network capable of course.  That is not why we went this
>  route. 
Agree.

> > Just as a reminder: the fact that all deltacloud-core drivers
> talk HTTP
> > out the back is not because it's an elegant design choice - it's by
> > necessity, since the only API's we can talk to are via HTTP. For Falcon,
> > there is absolutely no reason why we'd need to have the same sort of
> > split, and where the other DC drivers use HTTP to talk to the backend
> > cloud, we can use in-process calls to talk to Condor. That's an order of
> > magnitude easier to design and test.
>  
>  There is a logical split here.  I also want to be able to develop the
>  condor-cloud side without having to modify the driver all the time, so
>  some kind of logical separation is required.
>  
> >> My thoughts are to use this app to 'simulate' 'real' public cloud
> behavior which obviously
> >> expose some sort of API. In this case it will be *very* simple API. Then in DC
> driver we can
> >> just use RestClient + Nokogiri to parse XML.
> > 
> > There's no need really to have an internal remote API for Falcon at this
> > point. I would assume that that internal API will closely mirror DC
> > anyway, and most of the work that needs to be done in the DC driver will
> > be fairly artificial and redundant. It would mostly amount to
> > deserializing one format and then serializing back into an almost
> > identical format.
> > 
> > As for deployment/scalability flexibility, I would _definitely_ not use
> > a REST based API for that - if needed, AMQP would give us much more
> > flexibility and scalability.
> > 
> > But those concerns are premature: for now, it's way enough to have the
> > Deltacloud driver interact with condor directly, not over a remote API.
>  
>  OK, to summarize, basically by doing the REST API we can:
>  
>  - Develop the condor-cloud portion outside of the driver, eg add new IP
>   snarfing techniques etc. without changing the driver. 
IP management could be also done on configuration server side. Deltacloud API
driver can connect to this server and retrieve IP informations for instance.

>  - Have configuration of the condor-cloud portion without it being
> part
>   of the driver, it will feel like its own piece of software, which it
>   should be.
>  - Things to configure include authentication, IP management techniques,
>   various limits on CPU/memory etc., location of image repository, 
>   and specific VM configurations.
>  - Having an agent, eg daemon type process, lets us accept callbacks 
>   from whatever IP management system we use, watch dhcpd logs or what
>   have you.
>  
>  The downside being it may be a bit slower, maybe a little harder to
>  develop?  Although seeing how it works I don't see it being much harder
>  to develop than any other API.  Michal already has the groundwork up
>  and running.  Again I don't think it's a make or break thing here.. 
It was *very* simple Sinatra app, but now it's removed and replaced by gem code.
We can still do a Sinatra app build on top of this gem.

>  I'll see how Michal is making out and if we need to strip this
> back
>  some for time reasons. 
I'm happy with this solution:


deltacloud-client -> deltacloud-condor-driver -> condor-cloud-gem -> Condor

condor-cloud-gem will be interface between Ruby and Condor.

  -- Michal

------------------------------------------------------
Michal Fojtik, mfojtik(a)redhat.com
Deltacloud API: http://deltacloud.org

Condor Cloud Provider Project

[Ian Main]

On Fri, Mar 18, 2011 at 09:55:21PM +0100, Michal Fojtik wrote:
>  On Mar 18, 2011, at 9:46 PM, Ian Main wrote:
>   
[snip]

>  > 
>  > OK, to summarize, basically by doing the REST API we can:
>  > 
>  > - Develop the condor-cloud portion outside of the driver, eg add new IP
>  >  snarfing techniques etc. without changing the driver.
>  
>  IP management could be also done on configuration server side. Deltacloud API
>  driver can connect to this server and retrieve IP informations for instance.
>  
>  > - Have configuration of the condor-cloud portion without it being part
>  >  of the driver, it will feel like its own piece of software, which it
>  >  should be.
>  > - Things to configure include authentication, IP management techniques,
>  >  various limits on CPU/memory etc., location of image repository, 
>  >  and specific VM configurations.
>  > - Having an agent, eg daemon type process, lets us accept callbacks 
>  >  from whatever IP management system we use, watch dhcpd logs or what
>  >  have you.
>  > 
>  > The downside being it may be a bit slower, maybe a little harder to
>  > develop?  Although seeing how it works I don't see it being much harder
>  > to develop than any other API.  Michal already has the groundwork up
>  > and running.  Again I don't think it's a make or break thing here..
>  
>  It was *very* simple Sinatra app, but now it's removed and replaced by gem code.
>  We can still do a Sinatra app build on top of this gem.
>  
>  > I'll see how Michal is making out and if we need to strip this back
>  > some for time reasons.
>  
>  I'm happy with this solution:
>  
>  
>  deltacloud-client -> deltacloud-condor-driver -> condor-cloud-gem -> Condor
>  
>  condor-cloud-gem will be interface between Ruby and Condor. 
Yes, I'm happy with it too, thanks for the work Michal! :)  Either way
is a good start, if it gets bigger we can look at more options.

    Ian

Condor Cloud Provider Project

[David Lutterkort]

On Fri, 2011-03-18 at 16:46 -0400, Ian Main wrote:
>  On Thu, Mar 17, 2011 at 11:04:28AM -0700, David Lutterkort wrote:
>  > On Thu, 2011-03-17 at 09:05 +0100, Michal Fojtik wrote:
>  > > On Mar 17, 2011, at 12:43 AM, David Lutterkort wrote:
>  > > 
>  > > > On Wed, 2011-03-16 at 20:23 +0100, Michal Fojtik wrote:
>  > > >> 
>  > > >> Actually we was thinking about using Sinatra app which talks to Condor
> and translate
>  > > >> queries for Deltacloud API to handle this IP managment.
>  > > > 
>  > > > To make sure I get this right: the flow then is
>  > > > 
>  > > >                                      *
>  > > >        client -> deltacloud-core server -> new sinatra app ->
> condor
>  > > 
>  > > Yes this is right.
>  > > 
>  > > > Which raises the same question I asked yesterday about vSphere: why does
>  > > > the interface marked with (*) need to be REST ? Wouldn't it make more
>  > > > sense to collapse all that into the deltacloud-falcon driver so that the
>  > > > interface (*) is just normal in-process calls within the driver ?
>  > > 
>  > > This application will do an IP management for Condor cloud, so:
>  > > 
>  > > 1) Will held configuration file used by DHCP server to assign IP from MAC
> address
>  > >
>  > > 2) Will do a POST service for in-guest-agent inside Condor VMs 
>  > 
>  > That can be achieved by adding one more POST handler to the Deltacloud
>  > application.
>  > 
>  > Will Falcon then support both modes of operation, explicit IP assignment
>  > controlled by a Falcon-supplied DHCP server, and scraping IP's out of
>  > running instances via an agent ?
>  
>  Yes.  The other thing is authentication.  Basically there will be
>  configuration required on the condor-cloud side that I'm not sure
>  belongs in a driver. 
For purposes of Falcon, let's just forget about drivers as we know them
- they are really an artifact of the way Deltacloud has to work when it
is adapting existing public cloud API's.

What the Falcon frontend should be is a Deltacloud server, modified such
that it maintains state, handles auth etc. In terms of how the code is
structured, that will look a lot like an existing driver, but the Falcon
'driver' will be a full-fledged webapp.

>  You are correct that this could be done with a gem or even just a
> script
>  (almost) but to have a running process will be useful for eg the dhcpd
>  case etc. 
How so ? We can easily add handlers in deltacloud-falcon that
deltacloud-core does not have, e.g.
http://localhost:3001/let-me-give-you-my-ip

>  > Just as a reminder: the fact that all deltacloud-core drivers
> talk HTTP
>  > out the back is not because it's an elegant design choice - it's by
>  > necessity, since the only API's we can talk to are via HTTP. For Falcon,
>  > there is absolutely no reason why we'd need to have the same sort of
>  > split, and where the other DC drivers use HTTP to talk to the backend
>  > cloud, we can use in-process calls to talk to Condor. That's an order of
>  > magnitude easier to design and test.
>  
>  There is a logical split here.  I also want to be able to develop the
>  condor-cloud side without having to modify the driver all the time, so
>  some kind of logical separation is required. 
I agree that there is a logical split _somewhere_ - though in terms of
dev and getting stuff done, a fairly monolithic code base will
definitely be faster than a separate gem, or even a seperate web
service.

>  OK, to summarize, basically by doing the REST API we can:
>  
>  - Develop the condor-cloud portion outside of the driver, eg add new IP
>    snarfing techniques etc. without changing the driver.
>  - Have configuration of the condor-cloud portion without it being part
>    of the driver, it will feel like its own piece of software, which it
>    should be.
>  - Things to configure include authentication, IP management techniques,
>    various limits on CPU/memory etc., location of image repository, 
>    and specific VM configurations.
>  - Having an agent, eg daemon type process, lets us accept callbacks 
>    from whatever IP management system we use, watch dhcpd logs or what
>    have you. 
All of this can also be achieved with a 'driver'. In terms of decoupling
Falcon and Deltacloud development, you can just work off a clone of
deltacloud-core somewhere.

>  The downside being it may be a bit slower, maybe a little harder to
>  develop? 
It will also be _a lot_ harder to faithfully replicate the Deltacloud
API. By hooking into the existing infrastructure, you'll get a lot of
API behavior for free.

David

Condor Cloud Provider Project

[Ian Main]

On Fri, Mar 18, 2011 at 02:34:48PM -0700, David Lutterkort wrote:
>  On Fri, 2011-03-18 at 16:46 -0400, Ian Main wrote:
>  > On Thu, Mar 17, 2011 at 11:04:28AM -0700, David Lutterkort wrote:
>  > > On Thu, 2011-03-17 at 09:05 +0100, Michal Fojtik wrote:
>  > > > On Mar 17, 2011, at 12:43 AM, David Lutterkort wrote:
>  > > > 
>  > > > > On Wed, 2011-03-16 at 20:23 +0100, Michal Fojtik wrote:
>  > > > >> 
>  > > > >> Actually we was thinking about using Sinatra app which talks to
> Condor and translate
>  > > > >> queries for Deltacloud API to handle this IP managment.
>  > > > > 
>  > > > > To make sure I get this right: the flow then is
>  > > > > 
>  > > > >                                      *
>  > > > >        client -> deltacloud-core server -> new sinatra app
> -> condor
>  > > > 
>  > > > Yes this is right.
>  > > > 
>  > > > > Which raises the same question I asked yesterday about vSphere: why
> does
>  > > > > the interface marked with (*) need to be REST ? Wouldn't it make
> more
>  > > > > sense to collapse all that into the deltacloud-falcon driver so that
> the
>  > > > > interface (*) is just normal in-process calls within the driver ?
>  > > > 
>  > > > This application will do an IP management for Condor cloud, so:
>  > > > 
>  > > > 1) Will held configuration file used by DHCP server to assign IP from MAC
> address
>  > > >
>  > > > 2) Will do a POST service for in-guest-agent inside Condor VMs 
>  > > 
>  > > That can be achieved by adding one more POST handler to the Deltacloud
>  > > application.
>  > > 
>  > > Will Falcon then support both modes of operation, explicit IP assignment
>  > > controlled by a Falcon-supplied DHCP server, and scraping IP's out of
>  > > running instances via an agent ?
>  > 
>  > Yes.  The other thing is authentication.  Basically there will be
>  > configuration required on the condor-cloud side that I'm not sure
>  > belongs in a driver.
>  
>  For purposes of Falcon, let's just forget about drivers as we know them
>  - they are really an artifact of the way Deltacloud has to work when it
>  is adapting existing public cloud API's.
>  
>  What the Falcon frontend should be is a Deltacloud server, modified such
>  that it maintains state, handles auth etc. In terms of how the code is
>  structured, that will look a lot like an existing driver, but the Falcon
>  'driver' will be a full-fledged webapp.
>  
>  > You are correct that this could be done with a gem or even just a script
>  > (almost) but to have a running process will be useful for eg the dhcpd
>  > case etc.
>  
>  How so ? We can easily add handlers in deltacloud-falcon that
>  deltacloud-core does not have, e.g.
>  http://localhost:3001/let-me-give-you-my-ip 
Really it would be best for the IP information to end up in the condor
job, but that's a side point.  In order to facilitate some of the IP
schemes you would need a long-running stateful process is all I'm
saying.

>  > > Just as a reminder: the fact that all deltacloud-core
> drivers talk HTTP
>  > > out the back is not because it's an elegant design choice - it's by
>  > > necessity, since the only API's we can talk to are via HTTP. For Falcon,
>  > > there is absolutely no reason why we'd need to have the same sort of
>  > > split, and where the other DC drivers use HTTP to talk to the backend
>  > > cloud, we can use in-process calls to talk to Condor. That's an order of
>  > > magnitude easier to design and test.
>  > 
>  > There is a logical split here.  I also want to be able to develop the
>  > condor-cloud side without having to modify the driver all the time, so
>  > some kind of logical separation is required.
>  
>  I agree that there is a logical split _somewhere_ - though in terms of
>  dev and getting stuff done, a fairly monolithic code base will
>  definitely be faster than a separate gem, or even a seperate web
>  service. 
Well I hadn't considered that as an option.  I didn't think a fork of
deltacloud would be viable.  I should chat with you about this idea.

>  > OK, to summarize, basically by doing the REST API we can:
>  > 
>  > - Develop the condor-cloud portion outside of the driver, eg add new IP
>  >   snarfing techniques etc. without changing the driver.
>  > - Have configuration of the condor-cloud portion without it being part
>  >   of the driver, it will feel like its own piece of software, which it
>  >   should be.
>  > - Things to configure include authentication, IP management techniques,
>  >   various limits on CPU/memory etc., location of image repository, 
>  >   and specific VM configurations.
>  > - Having an agent, eg daemon type process, lets us accept callbacks 
>  >   from whatever IP management system we use, watch dhcpd logs or what
>  >   have you.
>  
>  All of this can also be achieved with a 'driver'. In terms of decoupling
>  Falcon and Deltacloud development, you can just work off a clone of
>  deltacloud-core somewhere. 
Yes they can I just thought you wouldn't want those things in a driver.
Again I hadn't considered the standalone-deltacloud case.  I like that
idea even more than the gem though.. I don't really want to carry a gem.
I'll chat you up about this soon.

    Ian

Condor Cloud Provider Project

>     From: Ian Main <imain(a)redhat.com&gt;
>     Date: Fri, 18 Mar 2011 19:08:43 -0400
>     
>     Really it would be best for the IP information to end up in the condor
>     job, but that's a side point.  In order to facilitate some of the IP
>     schemes you would need a long-running stateful process is all I'm
>     saying. 
Please keep in mind (everybody) that the only known use case for this
backend is in support of cloud engine.  In that scenario, there will,
by definition, be a config server.  Part of the job of the config
server is to communicate IP addresses of clients back to cloud
engine.  Therefore any other work which we introduce for retrieving IP
addresses etc is, by definition, gratuitous.

Similar statements apply to authentication of clients.  There's
already a scheme in place for getting IPA integrated into the mix,
OTPs handed out and coordinated etc.  

At such time as we identify a use case for condor backend which
involves running outside cloud engine, it will become more interesting
to deal with some of those other things.  

>     
>     Yes they can I just thought you wouldn't want those things in a driver.
>     Again I hadn't considered the standalone-deltacloud case.   
Good.  Because that's not the use case that's on the table.