"Free floating" does sound better than "king of nothing." ;)
On Thu, Jun 28, 2018 at 9:18 AM Suneel Marthi
wrote:
> ...u r still an Apache committer - (free floating committer now) :-)
>
> On Thu, Jun 28, 2018 at 10:14 AM, Tal Liron wrote:
>
> > On Thu,
On Thu, Jun 28, 2018 at 8:09 AM Thomas Nadeau wrote:
> I fully intend to take the ASF Committer role seriously and help out/
> contribute to other projects as time permits going forward and look
> forward to working
> and collaborating with you all in the future.
>
We are only committers on
Well, so it goes.
Many thanks to Suneel and John for their patient mentorship.
Many thanks to Cloudify for their initial seed code and funding.
On Thu, Jun 28, 2018 at 8:01 AM Suneel Marthi wrote:
> The vote ended today and here are the results.
>
> Binding +1 : 5 (Jakob Homan,
Hi Doron,
You do not have voting rights on this issue.
However, I don't think you should be too worried. The license is Apache
2.0, and you are very welcome to fork the project and continue its
development. There have been many successful forks in the history of open
source. This project may
+1
On Mon, Jun 25, 2018 at 9:40 AM Suneel Marthi wrote:
> In light of the discussion on
>
> https://lists.apache.org/thread.html/ccad17927b23573e0bef3062c98e7a72455415be959b2f5859ed6898@%3Cdev.ariatosca.apache.org%3E
>
> and given that the project has not seen any activity over the past 5
e our last meeting about the future
> of
> > AriaTosca - and wee have not heard back from Ericsson - I propose that we
> > start a [DISCUSS] to retire this project.
> >
> > Thoughts?
> >
> > On Thu, Jun 7, 2018 at 6:51 PM, Tal Liron wrote:
> >
> >>
Hello AriaTosca users,
I'm happy to introduce a new project that I've been working on the past few
months. I humbly offer it for consideration as an alternative to AriaTosca:
https://github.com/tliron/puccini
There's a lot of documentation on the site, but I thought it useful to
provide the
I actually think my work is not orthogonal... It is a complete TOSCA parser
that can do a lot of what AriaTosca does, if not more, in that respect. So,
depending on what folk think about it my project, it might make since to
move development focus there. (It's also Apache licensed.)
However, it
Hi everyone,
My new TOSCA parser will also be ready for public review in about 1 week. I
propose we delay the decision a bit longer so we can assess the situation.
On Wed, May 30, 2018 at 12:01 AM S Shenbaga Rajan <
s.shenbaga.ra...@ericsson.com> wrote:
> Hi Sunil,
>
> Give us couple of days.
The BlueJeans meeting says it's at 10AM GMT.
To clarify:
You do mean May 21 10AM EST?
On Fri, May 18, 2018 at 11:15 AM Thomas D. Nadeau <tnad...@lucidvision.com>
wrote:
> Yes typo in the subject. The BJeans is set for May 21 (see below).
>
> tom
>
>
> > On May 18, 2
Don't you mean May 21?
On Fri, May 18, 2018 at 7:11 AM Thomas Nadeau
wrote:
>
> Hi,
>
> Below is the conference info for our call on Monday regarding the
> discussion around closing down AriaTosca.
> Anyone in the community is invited to
yachand...@ericsson.com
> > > > > wrote:
> > > >
> > > > > Hi Suneel,
> > > > >
> > > > > We in Ericsson are actively working on ARIA. We want to keep the
> > > > > project on and community active.
> > > &g
I'm willing to help with this effort is someone can get it started.
What we really need is to spec this out -- can you start by documenting on
the wiki all the changes that ARIA would need to support 1.1? Once we have
that, we can turn it into JIRA tasks that individuals can handle.
On Wed, Mar
It would be wonderful if this offline meeting could result in a wiki page
explaining how the site is generated/etc... :)
On Tue, Jan 16, 2018 at 1:40 PM, Thomas Nadeau
wrote:
> Fantastic!
>
> We will need to sit down and go over a bit of a tutorial on how the site is
>
No worries, DJ. The process takes some time to learn... and it doesn't hurt
to have the ICLA on file, ready for when you are voted to be committer. :)
On Tue, Jan 9, 2018 at 8:07 AM, D Jayachandran
wrote:
> It was communicated by Ran Ziv, to submit the ICLA, so I
Hi DJ,
You do not have to submit until the ICLA until you are officially invited
to become a committer. Such an invitation would come only after the PPMC
votes to invite you. And that happens only after a member of the PPMC
nominates you. None of that has happened quite yet!
We have created a
I personally never knew how to handle this bizarre type, and never
understood why it existed in TOSCA. Since it always can ever have one and
only one value, what's the point of having "required" or "default" for it?
How should those be handled?
I will leave it up to you, or another contributor to
+1
On Thu, Jan 4, 2018 at 10:54 AM, Thomas Nadeau wrote:
> I updated the script and pushed the artifacts again. The issue is that
> test.pypi.org does not let you change artifacts once they've been pushed,
> so I cannot delete the one I pushed to replace it with the updated
We indeed need a new bug opened for the first issue.
The second issue is part of the JIRA for artifact management, I believe.
On Wed, Jan 3, 2018 at 6:11 AM, Vaishali Krishnamurthy <
v.krishnamurt...@globallogic.com.invalid> wrote:
> Hi,
>
>
>
> When trying the attribute, property and artifact
The default storage, SQLite, has certain concurrency limitations, but if
you use a more robust server (MySQL, Postresql) there should be no issues.
Maxim, any thoughts?
On Fri, Dec 29, 2017 at 12:01 AM, D Jayachandran <
d.jayachand...@ericsson.com> wrote:
> Hi,
>
> We have built a REST
+1
- I downloaded and unpacked the release.
- Version is correct.
- API docs are in "docs/html".
- All tests run with "make test".
- Installs correctly with "make install-virtual".
- Played around with Clearwater example.
On Tue, Dec 26, 2017 at 10:11 AM, Thomas Nadeau
There is currently no clear timeline. I expect it would take several weeks,
perhaps months, unless more contributors step up to assist the effort.
On Tue, Dec 12, 2017 at 5:00 AM, D Jayachandran wrote:
> Hi,
>
> When can we expect the support for substitution
present in the root directory of the CSAR.
>
> Am I right?
>
>
> Thanks,
>
> /Vaish
>
>
> From: Tal Liron <t...@cloudify.co>
> Sent: Thursday, December 7, 2017 8:51:49 PM
> To: dev@ariatosca.incubator.apache.org
> Subjec
There actually was some in-person conversation between committers about the
report. But it's a good criticism -- we should make it explicitly open and
via the mailing list.
On Mon, Dec 11, 2017 at 8:39 AM, Thomas Nadeau
wrote:
>
>
> > On Dec 11, 2017, at 9:36 AM, John D.
d/or wiki entry for a
> thumbnail sketch of how we want to do this?
>
> --Tom
>
> On Thu, Dec 7, 2017 at 2:04 PM, Tal Liron <t...@cloudify.co> wrote:
>
> > Our current idea is to support multiple ways of installing extensions.
> One
> > of them will, of cour
oing, I need to double check what can be
> done today.
> But I guess how it is done today might change as well (?)
> Based on our analysis of the latest code base, the loading of the custom
> workflows today is from CSAR only.
> Please advise.
>
> -Steve
>
> -Original M
major change in the existing way of loading plugins
> and using the same in the service template?
>
>
> Thanks,
>
> /Vaish
>
>
> From: Tal Liron <t...@cloudify.co>
> Sent: Wednesday, December 6, 2017 7:27:02 PM
> To: dev@ariatosc
Great question, and it was asked very recently on this list ...
There is a need for a unified way to dynamically load
extensions/plugins/workflows from CSAR files as well as other places. We
are trying to come with a good, forward-looking architectural design for
this loading mechanism. I will
me". I will debug into
> this and get back to you for any contribution.
>
> Thank you.
>
> -----Original Message-
> From: Tal Liron [mailto:t...@cloudify.co]
> Sent: Wednesday, December 06, 2017 2:02 PM
> To: dev@ariatosca.incubator.apache.org
> Subject: Re: get_attribute
type: my_Node_Server
>interfaces:
> Standard:
>create:
> implementation: sample > sample.sample_test.call_test
>configure:
> implementation: sample > sample.sample_test.call_name
> input
F, vmme_configuration ]}
On Tue, Dec 5, 2017 at 1:56 PM, Vaishali Krishnamurthy <
v.krishnamurt...@globallogic.com.invalid> wrote:
> I have tried the same in the latest master version. Could you please
> provide
> the service template you used ?
>
> -Original Me
etch
> the updated attribute value in another operation using the get_attribute
> function, for which it returns 'none' when I use SELF as modelable entity.
> For the same scenario if I use the node name as modelable entity, it works
> fine.
>
> -----Original Message-
> From: Tal
The bug, in case you want to follow its progress:
https://issues.apache.org/jira/browse/ARIA-424
On Tue, Dec 5, 2017 at 11:35 AM, Tal Liron <t...@cloudify.co> wrote:
> There is a bug here, but it has nothing to do with SELF.
>
> The issue is that you are using an "ad hoc&q
Standard:
>configure:
> inputs:
>payload: {
> "config": {get_attribute: [ SELF, vmme_configuration ]}}
>config: {get_attribute: [ SELF, vmme_configuration ]}
>
> Regards,
> Vaishali.
>
Thanks for the report. Do you possibly have a minimal TOSCA template we can
use to reproduce the error?
On Tue, Dec 5, 2017 at 8:29 AM, Vaishali Krishnamurthy <
v.krishnamurt...@globallogic.com.invalid> wrote:
> Hi,
>
> We have observed the attribute resolution is not proper when we use SELF as
Sorry, but I don't think we did a thorough review yet. However, feel free
to rebase on master and push it again to ensure that the CI tests pass.
On Mon, Dec 4, 2017 at 2:48 PM, Thomas Nadeau wrote:
> BTW I noticed that the Travis CI failed for your PR earlier. Tal and I
It's semantics, John. Recommending one mechanism but not the other means
that the other mechanism is less recommended or, in other words,
discouraged. This might be a mild discouragement, but it is so. The impact
of this mild discouragement would be that our potential devs will likely be
using
You *could* use those -- they are ssh with ssh keys. However, GitHub
generally recommends using HTTPS.
On Sun, Dec 3, 2017 at 4:54 PM, John D. Ament wrote:
> Any reason you wouldn't just use the github direct URLs?
>
> g...@github.com:apache/incubator-ariatosca.git
>
Hi DJ,
A lot has changed since August. :) I wonder if you can take a look at the
current state of master and see if things have improved with wagon installs?
On Fri, Dec 1, 2017 at 9:22 AM, D Jayachandran
wrote:
> Hi Ran,
>
> Sorry I had missed to answer this
> I was thinking if we had to do this, can this be included as part of ARIA
> (Atleast creation of service context object)
>
> Regards,
> DJ
> -Original Message-
> From: Tal Liron [mailto:t...@cloudify.co]
> Sent: Wednesday, November 29, 2017 1:46 PM
> To: dev
osca/
> > Could not install package: aria-extension-cloudify (Command
> > "/home/vagrant/venv/bin/python -c "import setuptools,
> > tokenize;__file__='/home/vagrant/venv/src/apache-
> > ariatosca/setup.py';f=getattr(tokenize, 'open',
> > open)(__file__);code=f.read
Sorry, hard to understand exactly what you're trying to do, what's
"failing" etc.
All I can gather from this is that you are installing something that
requires "apache-ariatosca" but that is already installed, so it's removing
it in order to upgrade. You stopped the log there.
On Wed, Nov 29,
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 <t...@cloudify.co> wrote:
>
> > OK, baseball reference. :)
> >
&g
Thanks, Steve. We don't have a JIRA for this right now, but we do intend to
have a way to include "plugins" in a CSAR and have them automatically
installed. A "plugin" is basically a Python extension to ARIA that can be
loaded at runtime and contained per service.
This is part of our current
ewa...@cloudify.co> wrote:
> bush league == amateur hour
>
> On Tue, Nov 28, 2017 at 10:49 AM, Tal Liron <t...@cloudify.co> wrote:
>
> > Sorry, I did not understand that last comment about "bush league"!
> >
> > But yes, the spec is known to be flimsy an
udify.co>
wrote:
> Wow. That is reeeaaally bad and bush league.
>
> On Tue, Nov 28, 2017 at 10:42 AM, Tal Liron <t...@cloudify.co> wrote:
>
> > "Examples" in the spec routinely break the syntax of the spec... I think
> > it's best not to trust th
ther 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 <t...@cloudify.co> wrote:
>
> > I mentioned this to you in the previous thread: the "type" field is
&g
t is there in the "type" field?
>
> On Tue, Nov 28, 2017 at 10:27 AM, Tal Liron <t...@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
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
wrote:
> Now that
rom: T1
> properties:
> n1:
> type: d2
>
>
> This produces the error:
>
> 4: override changes type from "d1" to "d2" for property "n1" in "T2
>
> On Tue, Nov 28, 2017 at 9:00 AM, Tal Liron <t...@cloudify.co> wr
You are correct that it's not entirely clear from the spec. However, I
always interpret the spirit of the spec to be object-oriented. That means
that in ARIA: yes, you can override a property, AS LONG AS the property
type is of compatible with (equal or derived from) the one in the parent.
ARIA
Victoria
> Engineering/Computer Science Building (ECS), Room 412
> Victoria, BC
> V8W 3p6 Canada
>
> On Mon, Nov 27, 2017 at 5:53 PM, Tal Liron <t...@cloudify.co> wrote:
>
> > I'm confused, Miguel. You checked out the git repository, but then
> > installed
ersity of Victoria
> Engineering/Computer Science Building (ECS), Room 412
> Victoria, BC
> V8W 3p6 Canada
>
> On Mon, Nov 27, 2017 at 3:28 PM, Vishwanath Jayaraman <
> vishwana...@hotmail.com> wrote:
>
> > Ok, got it.
> >
> >
> > Vish
>
It is a bug. I created this issue:
https://issues.apache.org/jira/browse/ARIA-411
For now, the workaround is to add a "primary" key under "implementation".
Also note that you must supply the "type" field for the interface
definition. So:
T1:
derived_from: tosca.nodes.Root
interfaces:
che-ariatosca" instead?
>
>
> --
> Miguel Jimenez, PhD student
> Department of Computer Science
> University of Victoria
> Engineering/Computer Science Building (ECS), Room 412
> Victoria, BC
> V8W 3p6 Canada
>
> On Mon, Nov 27, 2017 at 2:47 PM, Tal Liron <t...@
>
> >
> > --
> > Miguel Jimenez, PhD student
> > Department of Computer Science
> > University of Victoria
> > Engineering/Computer Science Building (ECS), Room 412
> > Victoria, BC
> > V8W 3p6 Canada
> >
> > On Mon, Nov 27, 2017 at 2:
gt;
> --
> Miguel Jimenez, PhD student
> Department of Computer Science
> University of Victoria
> Engineering/Computer Science Building (ECS), Room 412
> Victoria, BC
> V8W 3p6 Canada
>
> On Mon, Nov 27, 2017 at 2:47 PM, Tal Liron <t...@cloudify.co> wrote:
>
> > Mi
d/hello-world.yaml":9:15
>
> 4: unknown parent type "tosca:WebApplication" in "WebApp"
>
>
> @"/home/centos/incubator-ariatosca/examples/hello-
> world/hello-world.yaml":12:19
>
> Failed to parse service template
>
> Also, the gettings
Tom, the specific problems we had were not with installation, but rather in
running workflows. Have you tried to install the Hello World example?
On Mon, Nov 27, 2017 at 2:54 PM, Thomas Nadeau
wrote:
>
> I took an action during the grooming to verify the
I see no harm in giving them that permission.
On Mon, Nov 27, 2017 at 12:44 PM, John D. Ament
wrote:
> I think I see the issue. In the JIRA permission scheme, contributors can
> resolve and close issues, but not transition them. Are we in agreement
> that contributors
Hi DJ,
The question here is why use ARIA's orchestrator at all? It sounds like you
have your own orchestration engine. This is an intended use case for ARIA
(and indeed was used in the OPEN-O project).
There are a few ways to use ARIA here:
1) You can use the ARIA's Python API and access all
; On Wed, Nov 22, 2017 at 12:33 PM, Tal Liron <t...@cloudify.co> wrote:
>
> > Remember than anybody can be contributor. Becoming a committer,
> > specifically, means having privileges to move the project forward
> according
> > to the agreed-upon roadmap. I personally thi
us points
> for things in the rest of the list. If all you provide is amazing code
> contributions, that should be sufficient. Also, if it's an election that
> should be mentioned.
>
> On Wed, Nov 22, 2017 at 8:45 AM, Tal Liron <t...@cloudify.co> wrote:
>
> >
I've written up a list of requirements:
https://cwiki.apache.org/confluence/display/ARIATOSCA/Becoming+a+Committer
It's up to the committers to define this list, but would be happy to get
feedback from non-committers, too!
Less cumbersome, sure. But it also breaks the object-oriented contract.
Imagine this situation: a third party develops a powerful node type (let's
say: a virtual router) with many well-defined and polished operations on
custom interfaces (with their own types), custom workflows for various
I'm 100% sure this has nothing to do with the version of Linux in this
case...
We do have an open bug being worked on right now having to do with that
pesky ctx installation. It's expected to be fixed in time for the next
release of ARIA:
https://issues.apache.org/jira/browse/ARIA-354
On Fri,
ow functions to be values, I mean the return
> value only from the TOSCA perspective.
>
> On Thu, Nov 16, 2017 at 3:21 PM, Tal Liron <t...@cloudify.co> wrote:
>
> > Well, you can argue that attributes *vary* per node instance, while
> > properties *do not vary* per n
, DeWayne Filppi <dewa...@cloudify.co> wrote:
> Properties and attributes have no relationship. I always assumed the
> reflection was a convenience. Attributes are per instance, not per node.
>
> On Thu, Nov 16, 2017 at 2:54 PM, Tal Liron <t...@cloudify.co> wrote:
al value.
> Or are you saying the actual value will always be the same as the desired
> value and the reflected attribute is useless?
>
> -Steve
>
>
>
> -Original Message-
> From: Tal Liron [mailto:t...@cloudify.co]
> Sent: Thursday, November 16, 2017 3:49 PM
&g
think it is best if I ask further clarification from YAML Profile
> authors.
> What do you think?
> What is your preferred solution?
>
> -Steve
>
>
>
>
> -Original Message-
> From: Tal Liron [mailto:t...@cloudify.co]
> Sent: Thursday, November 16, 2017 3:15
an attribute value. This would apply to both
> context and intrinsic evaluation.
>
> On Thu, Nov 16, 2017 at 12:18 PM, Tal Liron <t...@cloudify.co> wrote:
>
> > I'm not entirely sure what you are saying here. My guess is that you mean
> > something like this:
> >
>
DeWayne Filppi <dewa...@cloudify.co> wrote:
> What I'm talking about has nothing to do with TOSCA. It only has to do
> with the orchestrator. Accessing an attribute has nothing to do with
> operations.
>
> On Thu, Nov 16, 2017 at 11:46 AM, Tal Liron <t...@cloudify.co>
ame? As far as I know it does
> not.
> What about using a better reflected attribute naming convention like
> “actual_”?
> Can I add this to the JIRA?
>
> -Steve B
>
> -Original Message-
> From: Tal Liron [mailto:t...@cloudify.co]
> Sent: Thursday, November 16, 20
Not right now, but there is an open JIRA to support it.
On Thu, Nov 16, 2017 at 1:42 PM, Steve Baillargeon <
steve.baillarg...@ericsson.com> wrote:
> Hi
> Does ARIA support "attribute and property reflection" defined in 3.5.10.1?
>
> Regards
> Steve B
>
>
g),
> skip the attribute assignment in the template and let the plugin decides
> the "value" for the attribute which can be a calculated value or any
> function implemented by the plugin? Yes I agree this is not portable.
> Did I miss something?
>
> -Steve
>
> ---
Well, this is a bit complex.
Attributes are ostensibly filled during runtime by other systems, for
example during the install workflow an ip_address would get its real value.
It's not really clear how another system would be able to insert a function
here, but it's not impossible. In ARIA's case,
created in plugins?
>
> DeWayne
>
> On Nov 14, 2017 3:04 PM, "Tal Liron" <t...@cloudify.co> wrote:
>
> Thanks, Steve. It seems that you are looking at the table at 5.8.2.2. The
> "required" column here seems poorly named: what they seem to mean is tha
Thanks, Steve. It seems that you are looking at the table at 5.8.2.2. The
"required" column here seems poorly named: what they seem to mean is that
when required is "yes" the orchestrator *must* fill in a value. Indeed all
the attributes I mentioned earlier, that ARIA fills in, are marked as
_address for
> a Compute node instance?
> If so, what method is used by ARIA to select the primary OAM IP address
> when multiple IPs are associated with the Compute node instance?
>
> -Steve
>
> -Original Message-
> From: Tal Liron [mailto:t...@cloudify.co]
ARIA exposes all defined attributes, even if they have no default value (in
which case they will be null).
Note that three attributes (tosca_id, tosca_name, state) are automatically
filled by ARIA, if they are available. Any node type inheriting from
tosca.nodes.Root will have them.
I'm not sure
There is no spec for native plugins yet, but it's something that I'm
working on. More info to come.
On Mon, Nov 13, 2017 at 12:54 PM, DeWayne Filppi
wrote:
> As opposed to using Cloudify plugins, is there an example of a native
> plugin? Or should new plugins just be
quot;my_value".
>
>
> Regards,
> DJ
> -Original Message-
> From: Tal Liron [mailto:t...@cloudify.co]
> Sent: Thursday, November 09, 2017 10:14 PM
> To: dev@ariatosca.incubator.apache.org
> Cc: Paul Doyle <paul.do...@ericsson.com>; Barry
I'll just add that you can either use a repository or just a complete URL
in the "file" section of "imports" (or short-form, which is just the URL).
Also, obviously there is a risk in using external imports: external changes
could break existing imports. But considering the complexities of cloud
-Profile-
> YAML/v1.0/os/TOSCA-Simple-Profile-YAML-v1.0-os.html#_Toc471725259>],
> The section for non-normative types used for examples throughout the spec.
> This section also exist in v1.2, with no changes to the aforementioned node
> type]
>
> On Mon, Sep 11, 2017 at 8:01 PM
I like that you called it a "bad idea". :)
Currently ARIA does not have complete namespace support, so the prefix will
not work.
On Wed, Nov 8, 2017 at 7:12 PM, Steve Baillargeon <
steve.baillarg...@ericsson.com> wrote:
> Hi
> Say I have a topology template using the following node templates:
>
can I do the same with the context object
> being passed rather than using the "ctx" tool ?
>
> Regards,
> DJ
> -Original Message-
> From: Tal Liron [mailto:t...@cloudify.co]
> Sent: Wednesday, November 08, 2017 8:06 PM
> To: dev@ariatosca.incubator
+1
On Wed, Nov 8, 2017 at 10:19 AM, Thomas Nadeau
wrote:
>
> We need to take a formal vote on whether or not to move forward
> with gitbox. Can the project committers please post their
> votes.
>
> I will tally the votes and post the conclusion by the
Yes.
My understanding is that artifacts are not an important part of the
object-oriented contract, but are instead "attachments" to nodes.
Supporting this is that the same definition format appears in both node
templates and node types. In a way, putting the artifact definition in the
node type
ARIA currently uses a special tool, called "ctx", to communicate with
implementation scripts. I imagine we will use the same tool to set return
values.
My understanding is also that these return values are quite arbitrary, and
thus un-typed. They will likely be stored as strings. So, for example,
Attendees: Tom Nadeau, Vish Jayaraman, Tal Liron, Arthur Berezin, Avia Efrat
Decisions:
- The process to release 0.2 will begin as soon as we merge ARIA-1,
ARIA-392, and ARIA-393. So: later this week.
- The big ARIA-350 epic (service composition) will be delayed for now
due to lack
This is fixed for the upcoming 0.2 release.
On Fri, Nov 3, 2017 at 11:26 AM, Thomas Nadeau
wrote:
>
> Yea that is one of the things on the list of “getting started”
> things to straighten out.
> The PR Vish is about to push starts those fixes.
>
> --Tom
The Linux images contributed to the Docker repository tend to be much more
bare than full installs, so indeed tools like this end up missing. I
imagine an Ubuntu Docker image, Fedora, etc., might have the same problems.
But it's correct this this curl/wget is a dependency and that we should
After getting some feedback from the AriaTosca community, as well as the
Cloudify user community (which has been using a similar product for years)
we have decided to stop supporting Python 2.6 in ARIA. ARIA now requires
Python 2.7.
Python 2.7 was released in 2010.
1) Does ARIA actually support namespace_uri and namespace_prefix for each
import definition as defined in YAML 1.1 spec. See multi-line grammar below:
> imports:
> - file:
> repository:
> namespace_uri:
> namespace_prefix:
>
This is in TOSCA 1.0, too. Repositories are
No, you cannot. The spec clearly defines metadata as a list of strings, and
ARIA conforms.
However, it's not hard to work around this. You can put the list of items
you want as a string with some kind of delimiter (comma?) Or, you can do a
numbering trick. You will have to parse it yourself.
My opinion is that we should keep Windows support.
Beyond the fact that Azure is a popular cloud platform, testing on Windows
keeps us honest for our Python work, making sure that we're writing
platform-neutral code.
The AppVeyor tests are broken for now, but I'm confident we will eventually
fix
on name 1 and capability definition
> name 2 must be different. Do you agree?
>
> 2) I am assuming requirement definition name 1 and capability definition
> name 1 can be the same. Do you agree?
>
> -Steve
>
> -Original Message-
> From: Tal Liron [mailto:t...@clo
Just to clarify: we currently support *both* Python 2.6 and Python 2.7. The
poll is to see if we should continue supporting 2.6.
You might ask why we supported 2.6 in the first place: this came from our
long experience working on Cloudify. Many cloud environments are still
quite old, and many
I'm not entirely sure what you mean... here's a reply according to what I
understand.
In most cases there is no ambiguity because the language is YAML-based. A
dict in YAML has unique keys, so it follows that definitions would be
unique. (We discussed the issue of importing in a previous thread,
I'm all for Docker releases as long as they don't replace the official
Python install. I guess we need to check with our mentors about how ASF
would relate to such "external" releases. For example, if we're allowed to
link to them from the project page.
On Wed, Oct 25, 2017 at 1:55 PM, DeWayne
1 - 100 of 310 matches
Mail list logo