You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ariatosca.apache.org by DeWayne Filppi <de...@cloudify.co> on 2017/11/28 18:04:46 UTC
back to the future
Now that the 'subclassing' problem has been resolved, overriding interface
methods is breaking. Simple example:
tosca_definitions_version: tosca_simple_yaml_1_0
imports:
- aria-1.0
node_types:
T1:
derived_from: tosca.nodes.Root
interfaces:
Standard:
create:
implementation:
primary: i1.sh
delete:
implementation:
primary: i1.sh
The error, using Aria in the ARIA-1 branch:
Validation issues:
2: required field "type" in
"aria_extension_tosca.simple_v1_0.definitions.InterfaceDefinition" does not
have a value
Re: back to the future
Posted by DeWayne Filppi <de...@cloudify.co>.
Interesting. Then how does this example from the spec function?:
mysql_database:
type: Database
<http://docs.oasis-open.org/tosca/TOSCA-Simple-Profile-YAML/v1.0/csprd01/TOSCA-Simple-Profile-YAML-v1.0-csprd01.html#DEFN_TYPE_NODES_DATABASE>
properties:
name: { get_input: db_name }
user: { get_input: db_user }
password: { get_input: db_pwd }
port: { get_input: db_port }
capabilities:
database_endpoint:
properties:
port: { get_input: db_port }
requirements:
- host: mysql_dbms
interfaces:
Standard:
configure: mysql_database_configure.sh
<http://docs.oasis-open.org/tosca/TOSCA-Simple-Profile-YAML/v1.0/csprd01/TOSCA-Simple-Profile-YAML-v1.0-csprd01.html#UC_2_MYSQL_DATABASE_CONFIGURE_SH>
On Tue, Nov 28, 2017 at 10:40 AM, Tal Liron <ta...@cloudify.co> wrote:
> I agree that ideally it could be inherited from the parent node type if not
> specified. That would indeed be my opinion.
>
> Small quibble: the fact that it's called "Standard" is arbitrary. The
> interface name does *not* have to conform to the interface type, it's just
> what they decided for the normative Root node type. The name does *not*
> contain type information. For example, in your own node type you can
> override the interface named "Standard" to be of a different interface
> type, which does not have "Standard" in its name. (ARIA will insist that
> your overriding type inherits from the Standard node type -- see our other
> discussion about type inheritance.)
>
> On Tue, Nov 28, 2017 at 12:32 PM, DeWayne Filppi <de...@cloudify.co>
> wrote:
>
> > Seems rather ugly. Do you have an opinion? If I specify that I'm using
> > the Standard interface, what point is there in the "type" field?
> >
> > On Tue, Nov 28, 2017 at 10:27 AM, Tal Liron <ta...@cloudify.co> wrote:
> >
> > > I mentioned this to you in the previous thread: the "type" field is
> > > required for interface definitions according to TOSCA syntax. So, even
> if
> > > it's the same as what you are inheriting, you must specify it.
> > >
> > > On Tue, Nov 28, 2017 at 12:04 PM, DeWayne Filppi <de...@cloudify.co>
> > > wrote:
> > >
> > > > Now that the 'subclassing' problem has been resolved, overriding
> > > interface
> > > > methods is breaking. Simple example:
> > > >
> > > > tosca_definitions_version: tosca_simple_yaml_1_0
> > > >
> > > > imports:
> > > >
> > > > - aria-1.0
> > > >
> > > > node_types:
> > > >
> > > > T1:
> > > > derived_from: tosca.nodes.Root
> > > > interfaces:
> > > > Standard:
> > > > create:
> > > > implementation:
> > > > primary: i1.sh
> > > > delete:
> > > > implementation:
> > > > primary: i1.sh
> > > >
> > > > The error, using Aria in the ARIA-1 branch:
> > > >
> > > > Validation issues:
> > > > 2: required field "type" in
> > > > "aria_extension_tosca.simple_v1_0.definitions.InterfaceDefinition"
> > does
> > > > not
> > > > have a value
> > > >
> > >
> >
>
Re: back to the future
Posted by Tal Liron <ta...@cloudify.co>.
I agree that ideally it could be inherited from the parent node type if not
specified. That would indeed be my opinion.
Small quibble: the fact that it's called "Standard" is arbitrary. The
interface name does *not* have to conform to the interface type, it's just
what they decided for the normative Root node type. The name does *not*
contain type information. For example, in your own node type you can
override the interface named "Standard" to be of a different interface
type, which does not have "Standard" in its name. (ARIA will insist that
your overriding type inherits from the Standard node type -- see our other
discussion about type inheritance.)
On Tue, Nov 28, 2017 at 12:32 PM, DeWayne Filppi <de...@cloudify.co>
wrote:
> Seems rather ugly. Do you have an opinion? If I specify that I'm using
> the Standard interface, what point is there in the "type" field?
>
> On Tue, Nov 28, 2017 at 10:27 AM, Tal Liron <ta...@cloudify.co> wrote:
>
> > I mentioned this to you in the previous thread: the "type" field is
> > required for interface definitions according to TOSCA syntax. So, even if
> > it's the same as what you are inheriting, you must specify it.
> >
> > On Tue, Nov 28, 2017 at 12:04 PM, DeWayne Filppi <de...@cloudify.co>
> > wrote:
> >
> > > Now that the 'subclassing' problem has been resolved, overriding
> > interface
> > > methods is breaking. Simple example:
> > >
> > > tosca_definitions_version: tosca_simple_yaml_1_0
> > >
> > > imports:
> > >
> > > - aria-1.0
> > >
> > > node_types:
> > >
> > > T1:
> > > derived_from: tosca.nodes.Root
> > > interfaces:
> > > Standard:
> > > create:
> > > implementation:
> > > primary: i1.sh
> > > delete:
> > > implementation:
> > > primary: i1.sh
> > >
> > > The error, using Aria in the ARIA-1 branch:
> > >
> > > Validation issues:
> > > 2: required field "type" in
> > > "aria_extension_tosca.simple_v1_0.definitions.InterfaceDefinition"
> does
> > > not
> > > have a value
> > >
> >
>
Re: back to the future
Posted by DeWayne Filppi <de...@cloudify.co>.
Seems rather ugly. Do you have an opinion? If I specify that I'm using
the Standard interface, what point is there in the "type" field?
On Tue, Nov 28, 2017 at 10:27 AM, Tal Liron <ta...@cloudify.co> wrote:
> I mentioned this to you in the previous thread: the "type" field is
> required for interface definitions according to TOSCA syntax. So, even if
> it's the same as what you are inheriting, you must specify it.
>
> On Tue, Nov 28, 2017 at 12:04 PM, DeWayne Filppi <de...@cloudify.co>
> wrote:
>
> > Now that the 'subclassing' problem has been resolved, overriding
> interface
> > methods is breaking. Simple example:
> >
> > tosca_definitions_version: tosca_simple_yaml_1_0
> >
> > imports:
> >
> > - aria-1.0
> >
> > node_types:
> >
> > T1:
> > derived_from: tosca.nodes.Root
> > interfaces:
> > Standard:
> > create:
> > implementation:
> > primary: i1.sh
> > delete:
> > implementation:
> > primary: i1.sh
> >
> > The error, using Aria in the ARIA-1 branch:
> >
> > Validation issues:
> > 2: required field "type" in
> > "aria_extension_tosca.simple_v1_0.definitions.InterfaceDefinition" does
> > not
> > have a value
> >
>
Re: back to the future
Posted by Tal Liron <ta...@cloudify.co>.
Absolutely. Let's also remember that TOSCA was first developed "on paper"
at first without any implementation. There wasn't even any way to validate
the examples other than by hand.
Things are better now that ARIA exists (and a few other TOSCA parsers), so
excuses are running out...
On Tue, Nov 28, 2017 at 1:48 PM, DeWayne Filppi <de...@cloudify.co> wrote:
> Yeah, well in a big spec like TOSCA, I tend to go for the examples rather
> than reading it cover to cover, which actually makes them more important
> than the spec in a practical sense. But maybe that's just me. On the
> other hand, it validates the raison d'etre of ARIA: to discover such issues
> with the spec and serve as a feedback mechanism.
>
> On Tue, Nov 28, 2017 at 11:02 AM, Tal Liron <ta...@cloudify.co> wrote:
>
> > OK, baseball reference. :)
> >
> > Well, it's always easy to criticize. :) If we want TOSCA to be better, we
> > need to better participate in the process. There is an open JIRA for ARIA
> > to consolidate all our errata into a single proposal for OASIS.
> >
> > On Tue, Nov 28, 2017 at 1:00 PM, DeWayne Filppi <de...@cloudify.co>
> > wrote:
> >
> > > bush league == amateur hour
> > >
> > > On Tue, Nov 28, 2017 at 10:49 AM, Tal Liron <ta...@cloudify.co> wrote:
> > >
> > > > Sorry, I did not understand that last comment about "bush league"!
> > > >
> > > > But yes, the spec is known to be flimsy and self-contradictory. In
> the
> > > end,
> > > > we must make a choice on how to implement things in ARIA, while
> taking
> > > into
> > > > account that other TOSCA implementations might interpret the spec
> > > > differently. (Even more ideally: provide configuration options for
> > ARIA's
> > > > parser, so that it could better work with YAML files created for
> other
> > > > TOSCA implementations. We have a few of these configuration options
> > > > already.)
> > > >
> > > > This is exactly why the current PR for ARIA-1 is important: it
> > > introduces a
> > > > broad test suite for TOSCA syntax and grammar, which obviously
> follows
> > > the
> > > > interpretations we made for ARIA. But it can be run on other TOSCA
> > > parsers,
> > > > too, at least giving us information as to where other parsers differ
> in
> > > > their interpretations of the spec.
> > > >
> > > > I will say that our rules of thumb has generally been: 1) if a strict
> > and
> > > > loose interpretation are possible, choose the stricter one, and 2)
> keep
> > > the
> > > > "spirit of the spec" in mind: object-orientation and enforcement of
> the
> > > > parent type contract.
> > > >
> > > > On Tue, Nov 28, 2017 at 12:44 PM, DeWayne Filppi <
> dewayne@cloudify.co>
> > > > wrote:
> > > >
> > > > > Wow. That is reeeeeeeeeeeaaaaaaaaaaaaaaaaaaaaaaally bad and bush
> > > > league.
> > > > >
> > > > > On Tue, Nov 28, 2017 at 10:42 AM, Tal Liron <ta...@cloudify.co>
> wrote:
> > > > >
> > > > > > "Examples" in the spec routinely break the syntax of the spec...
> I
> > > > think
> > > > > > it's best not to trust them.
> > > > > >
> > > > > > On Tue, Nov 28, 2017 at 12:40 PM, DeWayne Filppi <
> > > dewayne@cloudify.co>
> > > > > > wrote:
> > > > > >
> > > > > > > I suppose it lets you name interfaces whatever you want, which
> is
> > > > > > confusing
> > > > > > > because of other areas of the spec. Note that there are tons
> of
> > > > > examples
> > > > > > > in the spec without the "type" specified.
> > > > > > >
> > > > > > > On Tue, Nov 28, 2017 at 10:27 AM, Tal Liron <ta...@cloudify.co>
> > > wrote:
> > > > > > >
> > > > > > > > I mentioned this to you in the previous thread: the "type"
> > field
> > > is
> > > > > > > > required for interface definitions according to TOSCA syntax.
> > So,
> > > > > even
> > > > > > if
> > > > > > > > it's the same as what you are inheriting, you must specify
> it.
> > > > > > > >
> > > > > > > > On Tue, Nov 28, 2017 at 12:04 PM, DeWayne Filppi <
> > > > > dewayne@cloudify.co>
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > Now that the 'subclassing' problem has been resolved,
> > > overriding
> > > > > > > > interface
> > > > > > > > > methods is breaking. Simple example:
> > > > > > > > >
> > > > > > > > > tosca_definitions_version: tosca_simple_yaml_1_0
> > > > > > > > >
> > > > > > > > > imports:
> > > > > > > > >
> > > > > > > > > - aria-1.0
> > > > > > > > >
> > > > > > > > > node_types:
> > > > > > > > >
> > > > > > > > > T1:
> > > > > > > > > derived_from: tosca.nodes.Root
> > > > > > > > > interfaces:
> > > > > > > > > Standard:
> > > > > > > > > create:
> > > > > > > > > implementation:
> > > > > > > > > primary: i1.sh
> > > > > > > > > delete:
> > > > > > > > > implementation:
> > > > > > > > > primary: i1.sh
> > > > > > > > >
> > > > > > > > > The error, using Aria in the ARIA-1 branch:
> > > > > > > > >
> > > > > > > > > Validation issues:
> > > > > > > > > 2: required field "type" in
> > > > > > > > > "aria_extension_tosca.simple_v1_0.definitions.
> > > > InterfaceDefinition"
> > > > > > > does
> > > > > > > > > not
> > > > > > > > > have a value
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: back to the future
Posted by DeWayne Filppi <de...@cloudify.co>.
Yeah, well in a big spec like TOSCA, I tend to go for the examples rather
than reading it cover to cover, which actually makes them more important
than the spec in a practical sense. But maybe that's just me. On the
other hand, it validates the raison d'etre of ARIA: to discover such issues
with the spec and serve as a feedback mechanism.
On Tue, Nov 28, 2017 at 11:02 AM, Tal Liron <ta...@cloudify.co> wrote:
> OK, baseball reference. :)
>
> Well, it's always easy to criticize. :) If we want TOSCA to be better, we
> need to better participate in the process. There is an open JIRA for ARIA
> to consolidate all our errata into a single proposal for OASIS.
>
> On Tue, Nov 28, 2017 at 1:00 PM, DeWayne Filppi <de...@cloudify.co>
> wrote:
>
> > bush league == amateur hour
> >
> > On Tue, Nov 28, 2017 at 10:49 AM, Tal Liron <ta...@cloudify.co> wrote:
> >
> > > Sorry, I did not understand that last comment about "bush league"!
> > >
> > > But yes, the spec is known to be flimsy and self-contradictory. In the
> > end,
> > > we must make a choice on how to implement things in ARIA, while taking
> > into
> > > account that other TOSCA implementations might interpret the spec
> > > differently. (Even more ideally: provide configuration options for
> ARIA's
> > > parser, so that it could better work with YAML files created for other
> > > TOSCA implementations. We have a few of these configuration options
> > > already.)
> > >
> > > This is exactly why the current PR for ARIA-1 is important: it
> > introduces a
> > > broad test suite for TOSCA syntax and grammar, which obviously follows
> > the
> > > interpretations we made for ARIA. But it can be run on other TOSCA
> > parsers,
> > > too, at least giving us information as to where other parsers differ in
> > > their interpretations of the spec.
> > >
> > > I will say that our rules of thumb has generally been: 1) if a strict
> and
> > > loose interpretation are possible, choose the stricter one, and 2) keep
> > the
> > > "spirit of the spec" in mind: object-orientation and enforcement of the
> > > parent type contract.
> > >
> > > On Tue, Nov 28, 2017 at 12:44 PM, DeWayne Filppi <de...@cloudify.co>
> > > wrote:
> > >
> > > > Wow. That is reeeeeeeeeeeaaaaaaaaaaaaaaaaaaaaaaally bad and bush
> > > league.
> > > >
> > > > On Tue, Nov 28, 2017 at 10:42 AM, Tal Liron <ta...@cloudify.co> wrote:
> > > >
> > > > > "Examples" in the spec routinely break the syntax of the spec... I
> > > think
> > > > > it's best not to trust them.
> > > > >
> > > > > On Tue, Nov 28, 2017 at 12:40 PM, DeWayne Filppi <
> > dewayne@cloudify.co>
> > > > > wrote:
> > > > >
> > > > > > I suppose it lets you name interfaces whatever you want, which is
> > > > > confusing
> > > > > > because of other areas of the spec. Note that there are tons of
> > > > examples
> > > > > > in the spec without the "type" specified.
> > > > > >
> > > > > > On Tue, Nov 28, 2017 at 10:27 AM, Tal Liron <ta...@cloudify.co>
> > wrote:
> > > > > >
> > > > > > > I mentioned this to you in the previous thread: the "type"
> field
> > is
> > > > > > > required for interface definitions according to TOSCA syntax.
> So,
> > > > even
> > > > > if
> > > > > > > it's the same as what you are inheriting, you must specify it.
> > > > > > >
> > > > > > > On Tue, Nov 28, 2017 at 12:04 PM, DeWayne Filppi <
> > > > dewayne@cloudify.co>
> > > > > > > wrote:
> > > > > > >
> > > > > > > > Now that the 'subclassing' problem has been resolved,
> > overriding
> > > > > > > interface
> > > > > > > > methods is breaking. Simple example:
> > > > > > > >
> > > > > > > > tosca_definitions_version: tosca_simple_yaml_1_0
> > > > > > > >
> > > > > > > > imports:
> > > > > > > >
> > > > > > > > - aria-1.0
> > > > > > > >
> > > > > > > > node_types:
> > > > > > > >
> > > > > > > > T1:
> > > > > > > > derived_from: tosca.nodes.Root
> > > > > > > > interfaces:
> > > > > > > > Standard:
> > > > > > > > create:
> > > > > > > > implementation:
> > > > > > > > primary: i1.sh
> > > > > > > > delete:
> > > > > > > > implementation:
> > > > > > > > primary: i1.sh
> > > > > > > >
> > > > > > > > The error, using Aria in the ARIA-1 branch:
> > > > > > > >
> > > > > > > > Validation issues:
> > > > > > > > 2: required field "type" in
> > > > > > > > "aria_extension_tosca.simple_v1_0.definitions.
> > > InterfaceDefinition"
> > > > > > does
> > > > > > > > not
> > > > > > > > have a value
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: back to the future
Posted by Tal Liron <ta...@cloudify.co>.
OK, baseball reference. :)
Well, it's always easy to criticize. :) If we want TOSCA to be better, we
need to better participate in the process. There is an open JIRA for ARIA
to consolidate all our errata into a single proposal for OASIS.
On Tue, Nov 28, 2017 at 1:00 PM, DeWayne Filppi <de...@cloudify.co> wrote:
> bush league == amateur hour
>
> On Tue, Nov 28, 2017 at 10:49 AM, Tal Liron <ta...@cloudify.co> wrote:
>
> > Sorry, I did not understand that last comment about "bush league"!
> >
> > But yes, the spec is known to be flimsy and self-contradictory. In the
> end,
> > we must make a choice on how to implement things in ARIA, while taking
> into
> > account that other TOSCA implementations might interpret the spec
> > differently. (Even more ideally: provide configuration options for ARIA's
> > parser, so that it could better work with YAML files created for other
> > TOSCA implementations. We have a few of these configuration options
> > already.)
> >
> > This is exactly why the current PR for ARIA-1 is important: it
> introduces a
> > broad test suite for TOSCA syntax and grammar, which obviously follows
> the
> > interpretations we made for ARIA. But it can be run on other TOSCA
> parsers,
> > too, at least giving us information as to where other parsers differ in
> > their interpretations of the spec.
> >
> > I will say that our rules of thumb has generally been: 1) if a strict and
> > loose interpretation are possible, choose the stricter one, and 2) keep
> the
> > "spirit of the spec" in mind: object-orientation and enforcement of the
> > parent type contract.
> >
> > On Tue, Nov 28, 2017 at 12:44 PM, DeWayne Filppi <de...@cloudify.co>
> > wrote:
> >
> > > Wow. That is reeeeeeeeeeeaaaaaaaaaaaaaaaaaaaaaaally bad and bush
> > league.
> > >
> > > On Tue, Nov 28, 2017 at 10:42 AM, Tal Liron <ta...@cloudify.co> wrote:
> > >
> > > > "Examples" in the spec routinely break the syntax of the spec... I
> > think
> > > > it's best not to trust them.
> > > >
> > > > On Tue, Nov 28, 2017 at 12:40 PM, DeWayne Filppi <
> dewayne@cloudify.co>
> > > > wrote:
> > > >
> > > > > I suppose it lets you name interfaces whatever you want, which is
> > > > confusing
> > > > > because of other areas of the spec. Note that there are tons of
> > > examples
> > > > > in the spec without the "type" specified.
> > > > >
> > > > > On Tue, Nov 28, 2017 at 10:27 AM, Tal Liron <ta...@cloudify.co>
> wrote:
> > > > >
> > > > > > I mentioned this to you in the previous thread: the "type" field
> is
> > > > > > required for interface definitions according to TOSCA syntax. So,
> > > even
> > > > if
> > > > > > it's the same as what you are inheriting, you must specify it.
> > > > > >
> > > > > > On Tue, Nov 28, 2017 at 12:04 PM, DeWayne Filppi <
> > > dewayne@cloudify.co>
> > > > > > wrote:
> > > > > >
> > > > > > > Now that the 'subclassing' problem has been resolved,
> overriding
> > > > > > interface
> > > > > > > methods is breaking. Simple example:
> > > > > > >
> > > > > > > tosca_definitions_version: tosca_simple_yaml_1_0
> > > > > > >
> > > > > > > imports:
> > > > > > >
> > > > > > > - aria-1.0
> > > > > > >
> > > > > > > node_types:
> > > > > > >
> > > > > > > T1:
> > > > > > > derived_from: tosca.nodes.Root
> > > > > > > interfaces:
> > > > > > > Standard:
> > > > > > > create:
> > > > > > > implementation:
> > > > > > > primary: i1.sh
> > > > > > > delete:
> > > > > > > implementation:
> > > > > > > primary: i1.sh
> > > > > > >
> > > > > > > The error, using Aria in the ARIA-1 branch:
> > > > > > >
> > > > > > > Validation issues:
> > > > > > > 2: required field "type" in
> > > > > > > "aria_extension_tosca.simple_v1_0.definitions.
> > InterfaceDefinition"
> > > > > does
> > > > > > > not
> > > > > > > have a value
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: back to the future
Posted by DeWayne Filppi <de...@cloudify.co>.
bush league == amateur hour
On Tue, Nov 28, 2017 at 10:49 AM, Tal Liron <ta...@cloudify.co> wrote:
> Sorry, I did not understand that last comment about "bush league"!
>
> But yes, the spec is known to be flimsy and self-contradictory. In the end,
> we must make a choice on how to implement things in ARIA, while taking into
> account that other TOSCA implementations might interpret the spec
> differently. (Even more ideally: provide configuration options for ARIA's
> parser, so that it could better work with YAML files created for other
> TOSCA implementations. We have a few of these configuration options
> already.)
>
> This is exactly why the current PR for ARIA-1 is important: it introduces a
> broad test suite for TOSCA syntax and grammar, which obviously follows the
> interpretations we made for ARIA. But it can be run on other TOSCA parsers,
> too, at least giving us information as to where other parsers differ in
> their interpretations of the spec.
>
> I will say that our rules of thumb has generally been: 1) if a strict and
> loose interpretation are possible, choose the stricter one, and 2) keep the
> "spirit of the spec" in mind: object-orientation and enforcement of the
> parent type contract.
>
> On Tue, Nov 28, 2017 at 12:44 PM, DeWayne Filppi <de...@cloudify.co>
> wrote:
>
> > Wow. That is reeeeeeeeeeeaaaaaaaaaaaaaaaaaaaaaaally bad and bush
> league.
> >
> > On Tue, Nov 28, 2017 at 10:42 AM, Tal Liron <ta...@cloudify.co> wrote:
> >
> > > "Examples" in the spec routinely break the syntax of the spec... I
> think
> > > it's best not to trust them.
> > >
> > > On Tue, Nov 28, 2017 at 12:40 PM, DeWayne Filppi <de...@cloudify.co>
> > > wrote:
> > >
> > > > I suppose it lets you name interfaces whatever you want, which is
> > > confusing
> > > > because of other areas of the spec. Note that there are tons of
> > examples
> > > > in the spec without the "type" specified.
> > > >
> > > > On Tue, Nov 28, 2017 at 10:27 AM, Tal Liron <ta...@cloudify.co> wrote:
> > > >
> > > > > I mentioned this to you in the previous thread: the "type" field is
> > > > > required for interface definitions according to TOSCA syntax. So,
> > even
> > > if
> > > > > it's the same as what you are inheriting, you must specify it.
> > > > >
> > > > > On Tue, Nov 28, 2017 at 12:04 PM, DeWayne Filppi <
> > dewayne@cloudify.co>
> > > > > wrote:
> > > > >
> > > > > > Now that the 'subclassing' problem has been resolved, overriding
> > > > > interface
> > > > > > methods is breaking. Simple example:
> > > > > >
> > > > > > tosca_definitions_version: tosca_simple_yaml_1_0
> > > > > >
> > > > > > imports:
> > > > > >
> > > > > > - aria-1.0
> > > > > >
> > > > > > node_types:
> > > > > >
> > > > > > T1:
> > > > > > derived_from: tosca.nodes.Root
> > > > > > interfaces:
> > > > > > Standard:
> > > > > > create:
> > > > > > implementation:
> > > > > > primary: i1.sh
> > > > > > delete:
> > > > > > implementation:
> > > > > > primary: i1.sh
> > > > > >
> > > > > > The error, using Aria in the ARIA-1 branch:
> > > > > >
> > > > > > Validation issues:
> > > > > > 2: required field "type" in
> > > > > > "aria_extension_tosca.simple_v1_0.definitions.
> InterfaceDefinition"
> > > > does
> > > > > > not
> > > > > > have a value
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: back to the future
Posted by Tal Liron <ta...@cloudify.co>.
Sorry, I did not understand that last comment about "bush league"!
But yes, the spec is known to be flimsy and self-contradictory. In the end,
we must make a choice on how to implement things in ARIA, while taking into
account that other TOSCA implementations might interpret the spec
differently. (Even more ideally: provide configuration options for ARIA's
parser, so that it could better work with YAML files created for other
TOSCA implementations. We have a few of these configuration options
already.)
This is exactly why the current PR for ARIA-1 is important: it introduces a
broad test suite for TOSCA syntax and grammar, which obviously follows the
interpretations we made for ARIA. But it can be run on other TOSCA parsers,
too, at least giving us information as to where other parsers differ in
their interpretations of the spec.
I will say that our rules of thumb has generally been: 1) if a strict and
loose interpretation are possible, choose the stricter one, and 2) keep the
"spirit of the spec" in mind: object-orientation and enforcement of the
parent type contract.
On Tue, Nov 28, 2017 at 12:44 PM, DeWayne Filppi <de...@cloudify.co>
wrote:
> Wow. That is reeeeeeeeeeeaaaaaaaaaaaaaaaaaaaaaaally bad and bush league.
>
> On Tue, Nov 28, 2017 at 10:42 AM, Tal Liron <ta...@cloudify.co> wrote:
>
> > "Examples" in the spec routinely break the syntax of the spec... I think
> > it's best not to trust them.
> >
> > On Tue, Nov 28, 2017 at 12:40 PM, DeWayne Filppi <de...@cloudify.co>
> > wrote:
> >
> > > I suppose it lets you name interfaces whatever you want, which is
> > confusing
> > > because of other areas of the spec. Note that there are tons of
> examples
> > > in the spec without the "type" specified.
> > >
> > > On Tue, Nov 28, 2017 at 10:27 AM, Tal Liron <ta...@cloudify.co> wrote:
> > >
> > > > I mentioned this to you in the previous thread: the "type" field is
> > > > required for interface definitions according to TOSCA syntax. So,
> even
> > if
> > > > it's the same as what you are inheriting, you must specify it.
> > > >
> > > > On Tue, Nov 28, 2017 at 12:04 PM, DeWayne Filppi <
> dewayne@cloudify.co>
> > > > wrote:
> > > >
> > > > > Now that the 'subclassing' problem has been resolved, overriding
> > > > interface
> > > > > methods is breaking. Simple example:
> > > > >
> > > > > tosca_definitions_version: tosca_simple_yaml_1_0
> > > > >
> > > > > imports:
> > > > >
> > > > > - aria-1.0
> > > > >
> > > > > node_types:
> > > > >
> > > > > T1:
> > > > > derived_from: tosca.nodes.Root
> > > > > interfaces:
> > > > > Standard:
> > > > > create:
> > > > > implementation:
> > > > > primary: i1.sh
> > > > > delete:
> > > > > implementation:
> > > > > primary: i1.sh
> > > > >
> > > > > The error, using Aria in the ARIA-1 branch:
> > > > >
> > > > > Validation issues:
> > > > > 2: required field "type" in
> > > > > "aria_extension_tosca.simple_v1_0.definitions.InterfaceDefinition"
> > > does
> > > > > not
> > > > > have a value
> > > > >
> > > >
> > >
> >
>
Re: back to the future
Posted by DeWayne Filppi <de...@cloudify.co>.
Wow. That is reeeeeeeeeeeaaaaaaaaaaaaaaaaaaaaaaally bad and bush league.
On Tue, Nov 28, 2017 at 10:42 AM, Tal Liron <ta...@cloudify.co> wrote:
> "Examples" in the spec routinely break the syntax of the spec... I think
> it's best not to trust them.
>
> On Tue, Nov 28, 2017 at 12:40 PM, DeWayne Filppi <de...@cloudify.co>
> wrote:
>
> > I suppose it lets you name interfaces whatever you want, which is
> confusing
> > because of other areas of the spec. Note that there are tons of examples
> > in the spec without the "type" specified.
> >
> > On Tue, Nov 28, 2017 at 10:27 AM, Tal Liron <ta...@cloudify.co> wrote:
> >
> > > I mentioned this to you in the previous thread: the "type" field is
> > > required for interface definitions according to TOSCA syntax. So, even
> if
> > > it's the same as what you are inheriting, you must specify it.
> > >
> > > On Tue, Nov 28, 2017 at 12:04 PM, DeWayne Filppi <de...@cloudify.co>
> > > wrote:
> > >
> > > > Now that the 'subclassing' problem has been resolved, overriding
> > > interface
> > > > methods is breaking. Simple example:
> > > >
> > > > tosca_definitions_version: tosca_simple_yaml_1_0
> > > >
> > > > imports:
> > > >
> > > > - aria-1.0
> > > >
> > > > node_types:
> > > >
> > > > T1:
> > > > derived_from: tosca.nodes.Root
> > > > interfaces:
> > > > Standard:
> > > > create:
> > > > implementation:
> > > > primary: i1.sh
> > > > delete:
> > > > implementation:
> > > > primary: i1.sh
> > > >
> > > > The error, using Aria in the ARIA-1 branch:
> > > >
> > > > Validation issues:
> > > > 2: required field "type" in
> > > > "aria_extension_tosca.simple_v1_0.definitions.InterfaceDefinition"
> > does
> > > > not
> > > > have a value
> > > >
> > >
> >
>
Re: back to the future
Posted by Tal Liron <ta...@cloudify.co>.
"Examples" in the spec routinely break the syntax of the spec... I think
it's best not to trust them.
On Tue, Nov 28, 2017 at 12:40 PM, DeWayne Filppi <de...@cloudify.co>
wrote:
> I suppose it lets you name interfaces whatever you want, which is confusing
> because of other areas of the spec. Note that there are tons of examples
> in the spec without the "type" specified.
>
> On Tue, Nov 28, 2017 at 10:27 AM, Tal Liron <ta...@cloudify.co> wrote:
>
> > I mentioned this to you in the previous thread: the "type" field is
> > required for interface definitions according to TOSCA syntax. So, even if
> > it's the same as what you are inheriting, you must specify it.
> >
> > On Tue, Nov 28, 2017 at 12:04 PM, DeWayne Filppi <de...@cloudify.co>
> > wrote:
> >
> > > Now that the 'subclassing' problem has been resolved, overriding
> > interface
> > > methods is breaking. Simple example:
> > >
> > > tosca_definitions_version: tosca_simple_yaml_1_0
> > >
> > > imports:
> > >
> > > - aria-1.0
> > >
> > > node_types:
> > >
> > > T1:
> > > derived_from: tosca.nodes.Root
> > > interfaces:
> > > Standard:
> > > create:
> > > implementation:
> > > primary: i1.sh
> > > delete:
> > > implementation:
> > > primary: i1.sh
> > >
> > > The error, using Aria in the ARIA-1 branch:
> > >
> > > Validation issues:
> > > 2: required field "type" in
> > > "aria_extension_tosca.simple_v1_0.definitions.InterfaceDefinition"
> does
> > > not
> > > have a value
> > >
> >
>
Re: back to the future
Posted by DeWayne Filppi <de...@cloudify.co>.
I suppose it lets you name interfaces whatever you want, which is confusing
because of other areas of the spec. Note that there are tons of examples
in the spec without the "type" specified.
On Tue, Nov 28, 2017 at 10:27 AM, Tal Liron <ta...@cloudify.co> wrote:
> I mentioned this to you in the previous thread: the "type" field is
> required for interface definitions according to TOSCA syntax. So, even if
> it's the same as what you are inheriting, you must specify it.
>
> On Tue, Nov 28, 2017 at 12:04 PM, DeWayne Filppi <de...@cloudify.co>
> wrote:
>
> > Now that the 'subclassing' problem has been resolved, overriding
> interface
> > methods is breaking. Simple example:
> >
> > tosca_definitions_version: tosca_simple_yaml_1_0
> >
> > imports:
> >
> > - aria-1.0
> >
> > node_types:
> >
> > T1:
> > derived_from: tosca.nodes.Root
> > interfaces:
> > Standard:
> > create:
> > implementation:
> > primary: i1.sh
> > delete:
> > implementation:
> > primary: i1.sh
> >
> > The error, using Aria in the ARIA-1 branch:
> >
> > Validation issues:
> > 2: required field "type" in
> > "aria_extension_tosca.simple_v1_0.definitions.InterfaceDefinition" does
> > not
> > have a value
> >
>
Re: back to the future
Posted by Tal Liron <ta...@cloudify.co>.
I mentioned this to you in the previous thread: the "type" field is
required for interface definitions according to TOSCA syntax. So, even if
it's the same as what you are inheriting, you must specify it.
On Tue, Nov 28, 2017 at 12:04 PM, DeWayne Filppi <de...@cloudify.co>
wrote:
> Now that the 'subclassing' problem has been resolved, overriding interface
> methods is breaking. Simple example:
>
> tosca_definitions_version: tosca_simple_yaml_1_0
>
> imports:
>
> - aria-1.0
>
> node_types:
>
> T1:
> derived_from: tosca.nodes.Root
> interfaces:
> Standard:
> create:
> implementation:
> primary: i1.sh
> delete:
> implementation:
> primary: i1.sh
>
> The error, using Aria in the ARIA-1 branch:
>
> Validation issues:
> 2: required field "type" in
> "aria_extension_tosca.simple_v1_0.definitions.InterfaceDefinition" does
> not
> have a value
>