I have no idea if its a bug. Just seeing if it looked familiar to anyone.
Thought that error message might ring a bell.
On Sep 5, 2017 10:33 PM, "Tal Liron" wrote:
> Are you reporting a bug here? It would really help to get a complete
> example with instructions to reproduce.
>
> On Tue, Sep 5,
Are you reporting a bug here? It would really help to get a complete
example with instructions to reproduce.
On Tue, Sep 5, 2017 at 7:07 PM, DeWayne Filppi wrote:
> After adding the highlighted content to the ARIA openstack plugin.yaml,
>
> aria.openstack.datatypes.Server:
> description: >
Dear podling,
This email was sent by an automated system on behalf of the Apache
Incubator PMC. It is an initial reminder to give you plenty of time to
prepare your quarterly board report.
The board meeting is scheduled for Wed, 20 September 2017, 10:30 am PDT.
The report for your podling will fo
After adding the highlighted content to the ARIA openstack plugin.yaml,
aria.openstack.datatypes.Server:
description: >-
openstack Server args.
properties:
server:
type: map
required: false
entry_schema:
type: string
I get the following erro
Yes, I believe you've got the idea. The original "server" arg is defined
as a map/dict. TOSCA of course requires something somewhat more explicit.
I'm working around it by adding the following to Server datatype:
aria.openstack.datatypes.Server:
description: >-
openstack Server args.
On Sun, Sep 3, 2017 at 4:06 AM, Ran Ziv wrote:
> I too agree with the notion that picking a substituting service template
> explicitly is against the spirit of this feature, for the reasons Avia has
> explained.
> If a specific template is needed, why not import it directly, or require a
> more s
On Tue, Sep 5, 2017 at 5:33 AM, D Jayachandran
wrote:
> Hence I wanted to know if there is any possibility of identifying an
> abstract type (during parsing )so that we need not import or define the
> custom node type in my service template.
>
In my opinion, the import of the abstract type is n
We already have utility code to generate all kinds of UUIDs, so it's
trivial to make the change. I guess it's just a matter of making a
decision...
On Tue, Sep 5, 2017 at 3:57 AM, Vaishnavi K.R
wrote:
>
> Hi,
>
> I agree that with the CLI based usage in ARIA, the requirement of the UUID
> based
Hi All,
Thanks for the comments on handling substitution when multiple service
templates matches for the abstract node type.
My 2nd point was on importing the non-normative node types in the top level
service template. Let me explain this with an example.
1) Normative type (tosca.nodes.Databa
Hi,
I agree that with the CLI based usage in ARIA, the requirement of the UUID
based identification of the node and service instance elements is an overhead.
>From the discussions so far, it seems like UUID is important in handling the
>multi-user and multi-tenant scenarios.
Do you have any u
10 matches
Mail list logo