Re: [openstack-dev] [heat] Shared code between server and client

[Jay Dobies]

On 23/10/15 05:35, Robert Collins wrote:

My 2c - if its a stable API in the client, and can be kept stable,
there's no problem.


+1


Ok, forgive me for sounding dumb here (and changing the topic of the 
thread somewhat), but what do we consider a stable client API? Is it as 
broad as any methods in heatclient that aren't prefixed with _? Or do we 
scope it only to specific areas (e.g. common, RPC client) and anything 
else is considered "use at your own risk because we may need to change it"?


My guess is that it's the former given other sentiments I've heard 
around OpenStack, but I wanted to explicitly ask anyway.


Thanks :)



-Rob

On 23 October 2015 at 08:49, Jay Dobies  wrote:

I'm working on moving the functionality for merging environments from
the
client into the server [1]. I've only superficially looked at
template_utils.py (in heatclient) but I'm guessing there is stuff in
there I
will want to use server-side.

The server has a requirement on heatclient, but I'm not sure what the
convention is for using code in it. Can I directly call into a module in
heatclient/common from the server or is the client dependency only
intended
to be used through the client-facing APIs?

[1] https://blueprints.launchpad.net/heat/+spec/multi-environments

Thanks :)

__

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: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:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [heat] Shared code between server and client

[Jay Dobies]

On 10/27/2015 11:09 AM, Jay Dobies wrote:

On 23/10/15 05:35, Robert Collins wrote:

My 2c - if its a stable API in the client, and can be kept stable,
there's no problem.


+1


Ok, forgive me for sounding dumb here (and changing the topic of the
thread somewhat), but what do we consider a stable client API? Is it as
broad as any methods in heatclient that aren't prefixed with _? Or do we




scope it only to specific areas (e.g. common, RPC client)


Sorry, I merged two concepts in there. I was referring to common in the 
client and rpc_client in the server. It's possible the same answer 
doesn't apply to both; I'm not sure if we'd want to support someone 
using the server's RPC client code.



else is considered "use at your own risk because we may need to change it"?

My guess is that it's the former given other sentiments I've heard
around OpenStack, but I wanted to explicitly ask anyway.

Thanks :)



-Rob

On 23 October 2015 at 08:49, Jay Dobies  wrote:

I'm working on moving the functionality for merging environments from
the
client into the server [1]. I've only superficially looked at
template_utils.py (in heatclient) but I'm guessing there is stuff in
there I
will want to use server-side.

The server has a requirement on heatclient, but I'm not sure what the
convention is for using code in it. Can I directly call into a
module in
heatclient/common from the server or is the client dependency only
intended
to be used through the client-facing APIs?

[1] https://blueprints.launchpad.net/heat/+spec/multi-environments

Thanks :)

__


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: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: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:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [heat] Shared code between server and client

[xuanlangjian]

I would like to see that we just need to maintain a common 
template_utils.py/template_format.py in heat client side.
But I still find some difference between client and server.
https://github.com/openstack/heat/blob/master/heat/common/template_format.py#L84-L87
 

https://github.com/openstack/python-heatclient/blob/master/heatclient/common/template_format.py#L42
 


The option max_template_size only exists on server side, how do you handle with 
that if using the same function name ‘parse’?

> On Oct 23, 2015, at 07:13, Steve Baker  wrote:
> 
> On 23/10/15 08:49, Jay Dobies wrote:
>> I'm working on moving the functionality for merging environments from the 
>> client into the server [1]. I've only superficially looked at 
>> template_utils.py (in heatclient) but I'm guessing there is stuff in there I 
>> will want to use server-side.
>> 
>> The server has a requirement on heatclient, but I'm not sure what the 
>> convention is for using code in it. Can I directly call into a module in 
>> heatclient/common from the server or is the client dependency only intended 
>> to be used through the client-facing APIs?
>> 
>> [1] https://blueprints.launchpad.net/heat/+spec/multi-environments
>> 
> heat server already depends on heatclient, which was done so that some 
> template parsing could live in heatclient and be shared by both (this isn't 
> finished, and anyone who wants to pick it up is welcome to)
> 
> So yes, this would be a valid case for heat calling heatclient functions.
> 
> As an aside, it would be preferable if heatclient can somehow discover that 
> it is interacting with a multi-env aware REST API, and fallback to local 
> merging as appropriate.
> 
> __
> 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:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [heat] Shared code between server and client

[Zane Bitter]

On 28/10/15 00:09, Jay Dobies wrote:

On 23/10/15 05:35, Robert Collins wrote:

My 2c - if its a stable API in the client, and can be kept stable,
there's no problem.


+1


Ok, forgive me for sounding dumb here (and changing the topic of the
thread somewhat), but what do we consider a stable client API?


Anything we need to call from outside ;)

__
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] [heat] Shared code between server and client

[Dean Troyer]

On Thu, Oct 22, 2015 at 6:13 PM, Steve Baker  wrote:

> heat server already depends on heatclient, which was done so that some
> template parsing could live in heatclient and be shared by both (this isn't
> finished, and anyone who wants to pick it up is welcome to)
>

I don't know the details here, but this sounds similar to keystoneclient's
auth plugins which were recently moved out of keystoneclient into
keystoneauth for a couple of reasons.

Consider a similar path if possible to reduce the potential dependency
collisions as clients and servers have different needs.  It sounds like you
have been able to avoid that so far though...

dt

-- 

Dean Troyer
dtro...@gmail.com
__
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] [heat] Shared code between server and client

[Zane Bitter]

On 23/10/15 05:35, Robert Collins wrote:

My 2c - if its a stable API in the client, and can be kept stable,
there's no problem.


+1


-Rob

On 23 October 2015 at 08:49, Jay Dobies  wrote:

I'm working on moving the functionality for merging environments from the
client into the server [1]. I've only superficially looked at
template_utils.py (in heatclient) but I'm guessing there is stuff in there I
will want to use server-side.

The server has a requirement on heatclient, but I'm not sure what the
convention is for using code in it. Can I directly call into a module in
heatclient/common from the server or is the client dependency only intended
to be used through the client-facing APIs?

[1] https://blueprints.launchpad.net/heat/+spec/multi-environments

Thanks :)

__
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:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [heat] Shared code between server and client

[Jay Dobies]

I'm working on moving the functionality for merging environments from 
the client into the server [1]. I've only superficially looked at 
template_utils.py (in heatclient) but I'm guessing there is stuff in 
there I will want to use server-side.


The server has a requirement on heatclient, but I'm not sure what the 
convention is for using code in it. Can I directly call into a module in 
heatclient/common from the server or is the client dependency only 
intended to be used through the client-facing APIs?


[1] https://blueprints.launchpad.net/heat/+spec/multi-environments

Thanks :)

__
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] [heat] Shared code between server and client

[Robert Collins]

My 2c - if its a stable API in the client, and can be kept stable,
there's no problem.

-Rob

On 23 October 2015 at 08:49, Jay Dobies  wrote:
> I'm working on moving the functionality for merging environments from the
> client into the server [1]. I've only superficially looked at
> template_utils.py (in heatclient) but I'm guessing there is stuff in there I
> will want to use server-side.
>
> The server has a requirement on heatclient, but I'm not sure what the
> convention is for using code in it. Can I directly call into a module in
> heatclient/common from the server or is the client dependency only intended
> to be used through the client-facing APIs?
>
> [1] https://blueprints.launchpad.net/heat/+spec/multi-environments
>
> Thanks :)
>
> __
> 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



-- 
Robert Collins 
Distinguished Technologist
HP Converged Cloud

__
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] [heat] Shared code between server and client

[Steve Baker]

On 23/10/15 08:49, Jay Dobies wrote:
I'm working on moving the functionality for merging environments from 
the client into the server [1]. I've only superficially looked at 
template_utils.py (in heatclient) but I'm guessing there is stuff in 
there I will want to use server-side.


The server has a requirement on heatclient, but I'm not sure what the 
convention is for using code in it. Can I directly call into a module 
in heatclient/common from the server or is the client dependency only 
intended to be used through the client-facing APIs?


[1] https://blueprints.launchpad.net/heat/+spec/multi-environments

heat server already depends on heatclient, which was done so that some 
template parsing could live in heatclient and be shared by both (this 
isn't finished, and anyone who wants to pick it up is welcome to)


So yes, this would be a valid case for heat calling heatclient functions.

As an aside, it would be preferable if heatclient can somehow discover 
that it is interacting with a multi-env aware REST API, and fallback to 
local merging as appropriate.


__
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