Sample scripts at alien4cloud-yorc-plugin/src/test/scripts using the Alien4Cloud REST API, should be updated to work with an Alien4Cloud configured to use https

2018-01-19 09:07:09 WARN LogListenerTask:51 - listenJanusLog Failed
com.mashape.unirest.http.exceptions.UnirestException: org.apache.http.conn.HttpHostConnectException: Connect to localhost:8800 [localhost/127.0.0.1] failed: Connexion refusée
at com.mashape.unirest.http.HttpClientHelper.request(HttpClientHelper.java:143) ~[unirest-java-1.4.9.jar:?]
at com.mashape.unirest.request.BaseRequest.asJson(BaseRequest.java:68) ~[unirest-java-1.4.9.jar:?]
at alien4cloud.plugin.Janus.rest.RestClient.getLogFromJanus(RestClient.java:269) ~[35034a1c-84d9-413d-b1a5-cd315a0d2520/:?]
at alien4cloud.plugin.Janus.LogListenerTask.run(LogListenerTask.java:39) [35034a1c-84d9-413d-b1a5-cd315a0d2520/:?]
at alien4cloud.plugin.Janus.TaskManager.nextWork(TaskManager.java:74) [35034a1c-84d9-413d-b1a5-cd315a0d2520/:?]
at alien4cloud.plugin.Janus.TaskManager$WorkThread.run(TaskManager.java:122) [35034a1c-84d9-413d-b1a5-cd315a0d2520/:?]
Caused by: org.apache.http.conn.HttpHostConnectException: Connect to localhost:8800 [localhost/127.0.0.1] failed: Connexion refusée
at org.apache.http.impl.conn.DefaultHttpClientConnectionOperator.connect(DefaultHttpClientConnectionOperator.java:151) ~[?:?]
at org.apache.http.impl.conn.PoolingHttpClientConnectionManager.connect(PoolingHttpClientConnectionManager.java:353) ~[httpclient-4.3.2.jar!/:4.3.2]
at org.apache.http.impl.execchain.MainClientExec.establishRoute(MainClientExec.java:380) ~[httpclient-4.3.2.jar!/:4.3.2]
at org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:236) ~[httpclient-4.3.2.jar!/:4.3.2]
at org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:184) ~[httpclient-4.3.2.jar!/:4.3.2]
at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:88) ~[httpclient-4.3.2.jar!/:4.3.2]
at org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:110) ~[httpclient-4.3.2.jar!/:4.3.2]
at org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:184) ~[httpclient-4.3.2.jar!/:4.3.2]
at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82) ~[httpclient-4.3.2.jar!/:4.3.2]
at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:107) ~[httpclient-4.3.2.jar!/:4.3.2]
at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:55) ~[httpclient-4.3.2.jar!/:4.3.2]
at com.mashape.unirest.http.HttpClientHelper.request(HttpClientHelper.java:138) ~[?:?]
... 5 more

Opened by @stebenoist on v2.0 to be checked if still relevant

Issue Type

Put an X between the brackets of the corresponding issue type

• Bug report
• Documentation issue report
• Improvement request

Description

Expected behavior

Actual behavior

Steps to reproduce the issue

1. Step1
2. Step2 ...

Additional information you deem important (e.g. issue happens only occasionally)

Additional environment details (infrastructure implied: AWS, OpenStack, etc.)

Alien4Cloud version

Output of yorc version

Yorc configuration file

Priority

High / Medium / Low

• High = We should stop anything we are doing and do this. If you're writing this calmly, you should probably choose another option. If it's really that urgent, please make sure we read this.
• Medium = It's important that we do this within a few days.
• Low = We will consider this on our next sprint planning.

(Please be aware that your priority may not match ours, we'll use this as guidance only).

Issue Type

Put an X between the brackets of the corresponding issue type

• [X ] Bug report
• Documentation issue report
• Improvement request

Description

Uninstall workflow is not correct for Topology involving BlockStorage node.
For a basic topology with:

• Compute
• BlockStorage
• FileSystem

During the uninstall workflow, the compute is uninstalled first so the unmount FS can't be done and the wokflow is pending.
Expected behavior
The compute must be uninstalled after unmounting FS

Expected behavior

Uninstall workflow is not correct for Topology involving BlockStorage node

Actual behavior

Issue Type

• Bug report
• Documentation issue report
• Improvement request

Description

Today, to add in Alien4Cloud an Orchestrator connected to a secured Yorc Orchestrator, you need first to :

• add a certificate authority to a trustore
• add a client certificate to a keystore
• restart Alien4cloud with java options set to specify paths/passwords to trustore and keystore.

You can then configure a new Orchestrator in Alien4Cloud and open a secure connection with Yorc.

Instead of having these prerequisites on truststore/keystore, similarly to what already exists for other orchestrators as described at http://alien4cloud.github.io/#/documentation/2.1.0/orchestrators/cloudify4_driver/postdeployment_config.html, the Alien4Cloud Yorc plugin could have new configuration parameters :

• CA certificate
• Client key
• Client Certificate

provided by the user. The plugin will then use a custom trustore/keystore using these certificates to establish a secure connection with the orchestrator.

Priority

Medium

• High = We should stop anything we are doing and do this. If you're writing this calmly, you should probably choose another option. If it's really that urgent, please make sure we read this.
• Medium = It's important that we do this within a few days.
• Low = We will consider this on our next sprint planning.

(Please be aware that your priority may not match ours, we'll use this as guidance only).

Bug Report

Description

Concurrent deployment makes an invalid zip sended to Yorc.

Actual behavior

I have 2 applications A and B with a long initial state to complete (for example an artifact to download from a repository http)

I deploy A, and then I deploy B before A is still in INITIAL status (in A4C, before it is sended to Yorc)

Then, the two application failed. And you get the following stack trace:

 [2018-08-23 15:49:23][][]YorcRestException: [title: "Internal Server Error", http status code: "500", detail: "Something went wrong: [PANIC] zip: not a valid zip file"]
org.ystia.yorc.alien4cloud.plugin.rest.YorcRestException: YorcRestException: [title: "Internal Server Error", http status code: "500", detail: "Something went wrong: [PANIC] zip: not a valid zip file"]
at org.ystia.yorc.alien4cloud.plugin.rest.YorcRestException.fromYorcError(YorcRestException.java:38)
at org.ystia.yorc.alien4cloud.plugin.rest.RestClient.sendRequest(RestClient.java:170)
at org.ystia.yorc.alien4cloud.plugin.rest.RestClient.sendTopologyToYorc(RestClient.java:235)
at org.ystia.yorc.alien4cloud.plugin.DeployTask.run(DeployTask.java:138)
at org.ystia.yorc.alien4cloud.plugin.TaskManager.nextWork(TaskManager.java:89)
at org.ystia.yorc.alien4cloud.plugin.TaskManager$WorkThread.run(TaskManager.java:141)

Alien4Cloud version

2.0.0

Output of yorc version

Yorc Server v3.1.0-M1
Revision: "7b4a65ee36cf213fea07333e94aa09ec396f2fdd"

Priority

Medium

Bug Report

Description

A 'Scale Down' operation started from Alien4Cloud never ends.
The final status of the deleted instance in the Scale Down case is Initial as well.
This will confuse next 'Scale Up' operation as well.

Looking at statuses on Yorc sever, everything is fine, the issue appears only in Alien4Cloud.

Output of yorc version

Current develop version

Priority

Medium

• High = We should stop anything we are doing and do this. If you're writing this calmly, you should probably choose another option. If it's really that urgent, please make sure we read this.
• Medium = It's important that we do this within a few days.
• Low = We will consider this on our next sprint planning.

(Please be aware that your priority may not match ours, we'll use this as guidance only).

As: Yorc Dev Team
I want to: Have TOSCA sample accessibles
So that: We can now archive plugin repo

AC1: Check if we need to tag samples version

Issue Type

• Bug report
• Documentation issue report
• Improvement request

Description

When an artifact is a folder from the a4c appllication workspace, it isn't copied well in the topology.zip

Expected behavior

This folder and its content should be added to the topology.zip file sent to Yorc

Actual behavior

Folder is missing.

Steps to reproduce the issue

1. Create a Mock TOSCA type with a file artifact
2. Create an app in alien
3. Create a folder and files into the app's archive content
4. Select this folder as the artifact
5. Save deploy and check that the folder is missing

As: A user
I want to: deploy an application on several locations of a given orchestrator
So that: I can deploy on hybrid infrastructures

AC1: Enrich Alien to allow selection of several locations
AC2: If it is simpler limit to locations on the same orchestrator

Issue Type

Put an X between the brackets of the corresponding issue type

• Bug report
• Documentation issue report
• Improvement request

Description

Add the link to distrib files: https://bintray.com/ystia/yorc-a4c-plugin/distributions

So that we can easily download yorc a4c plugin.

When configuring a new yorc orchestrator, even if you put a wrong url and enable it, it displays that it is connected.
But actually it is not and they are lots of errors logs in alien4cloud.

On some OpenStack setups configured to not use local disks on the hypervisor, the orchestrator fails to create a Compute Instance as Yorc today doesn't allow to create a Compute Instance with a non-local bootable Volume.

This issue tracks the need to modify TOSCA types on the plugin side.

On the orchestrator side, the corresponding issue is ystia/yorc#461

On Alien4Cloud Yorc provider side, the corresponding issue is alien4cloud/alien4cloud-yorc-provider#5

As: An app designer
I want to: transform automatically a Docker Job into Slurm + Singularity
So that: be able to deploy the same application to K8S and Slurm + Singularity

AC1: A4C Topo modifier
AC2: Support only volumes mounted from filesystem

Issue Type

• Bug report
• Documentation issue report
• Improvement request

Description

Upgrading test sample component dependencies with known vulnerabilities:

• cryptography lib needs to be >= 2.3
• paramiko needs to be >= 2.1

Priority

High

Issue Type

Put an X between the brackets of the corresponding issue type

• Bug report
• Documentation issue report
• Improvement request

Description

The tosca-samples for Kubernets deployment have dependency on docker-types v2.1.0 (provided by Alien).
As the current plugin version is ment to be used with Alien 2.1.1, the dependency needs to be updated to docker-types v2.1.1

Steps to reproduce the issue

Upload to the Alien Catalog tosca-samples from https://github.com/ystia/yorc-a4c-plugin/tree/develop/tosca-samples

Alien4Cloud version

2.1.1

Output of yorc version

3.2.0

Yorc configuration file

Priority

Low

• High = We should stop anything we are doing and do this. If you're writing this calmly, you should probably choose another option. If it's really that urgent, please make sure we read this.
• Medium = It's important that we do this within a few days.
• Low = We will consider this on our next sprint planning.

(Please be aware that your priority may not match ours, we'll use this as guidance only).

Bug Report

Description

After the fix for issue #131 it is seen that when running a custom workflow, Alien4Cloud consumes 100% of one CPU.
This is because the Alien4Cloud yorc plugin thread waiting for the workflow to end is actively checking the status of the latest event,
without never doing any wait to be awaken on new event received.

Output of yorc version

3.2.1 and 4.0.0-SNAPSHOT

Yorc configuration file

Priority

High

• High = We should stop anything we are doing and do this. If you're writing this calmly, you should probably choose another option. If it's really that urgent, please make sure we read this.
• Medium = It's important that we do this within a few days.
• Low = We will consider this on our next sprint planning.

(Please be aware that your priority may not match ours, we'll use this as guidance only).

As: Yorc team
I want: to upgrade to Alien4Cloud 2.1
So that: I can benefit from newest features, bug fixes & enhancements

As: Yorc team
I want to: upgrade to a4c Kubernetes plugin 2.1
So that: I can benefit from newest features like jobs support we introduced recently

Issue Type

• Bug report
• Documentation issue report
• Improvement request

Description

When undeploying applications from Alien4Cloud, the application is expected to be undeployed, then purged from Yorc Server.

In some cases, it happens that the application is undeployed but not purged on Yorc Server side.

Looking at Alien4Cloud logs, a Yorc server error is reported : Task with id "xxx" and status "INITIAL" already exists for target "Deployment PAAS ID"

As a consequence, next attempt to deploy the application from Alien4Cloud will fail as Yorc has already an application unpurged with the same name.

Looking at the code, in a loop in UndeployTask, it can happen that this task will try twice to change the status to UNDEPLOYED,
first here: https://github.com/ystia/yorc-a4c-plugin/blob/develop/alien4cloud-yorc-plugin/src/main/java/org/ystia/yorc/alien4cloud/plugin/UndeployTask.java#L118
Then here: https://github.com/ystia/yorc-a4c-plugin/blob/develop/alien4cloud-yorc-plugin/src/main/java/org/ystia/yorc/alien4cloud/plugin/UndeployTask.java#L163
As the call changing the status to UNDEPLOYED is attempting to perform a purge, we can have two attempts to purge a deployment. And the second attempt will fail.

Other issue to fix at the same time : a null pointer exception can happen at:
https://github.com/ystia/yorc-a4c-plugin/blob/develop/alien4cloud-yorc-plugin/src/main/java/org/ystia/yorc/alien4cloud/plugin/EventListenerTask.java#L74
because the call to jrdi.getInstanceInformations() is done before (instead of after) checking if jrdi is null

Priority

Medium

• High = We should stop anything we are doing and do this. If you're writing this calmly, you should probably choose another option. If it's really that urgent, please make sure we read this.
• Medium = It's important that we do this within a few days.
• Low = We will consider this on our next sprint planning.

(Please be aware that your priority may not match ours, we'll use this as guidance only).

Issue Type

• Bug report
• Documentation issue report
• Improvement request

Description

Pull request #75 has changed the org.ystia.yorc.samples.vision.linux.ansible component version to 1.0.0-SNAPSHOT.
The topology provided in tosca samples should be changed to use this version.

Priority

Medium

• High = We should stop anything we are doing and do this. If you're writing this calmly, you should probably choose another option. If it's really that urgent, please make sure we read this.
• Medium = It's important that we do this within a few days.
• Low = We will consider this on our next sprint planning.

(Please be aware that your priority may not match ours, we'll use this as guidance only).

Issue Type

• Bug report
• Documentation issue report
• Improvement request

Description

Attempting to have the Alien4Cloud Yorc plugin to connect to Yorc in secure mode by:

• creating a keystore and trustore with required client certificate and certificate authority
• specifying a keystore and trustore using javax.net.ssl.trustStore and javax.net.ssl.keyStore java options at Alien4Cloud launch
• providing an https URL in Yorc plugin configuration

the plugin fails to connect to Yorc with this error :

2019-01-08 16:34:10.933 WARN  [qtp1131592118-15] RestClient:131 - Unable to retrieve deployments due to: An error occurred while calling GET https://127.0.0.1:8800/deployments
2019-01-08 16:34:10.937 ERROR [qtp1131592118-15] OrchestratorController:127 - Failed to instantiate orchestrator because of invalid configuration.
alien4cloud.paas.exception.PluginConfigurationException: Failed to connect to yorc
        at org.ystia.yorc.alien4cloud.plugin.rest.RestClient.setProviderConfiguration(RestClient.java:133) ~[?:?]
        at org.ystia.yorc.alien4cloud.plugin.YorcPaaSProvider.setConfiguration(YorcPaaSProvider.java:449) ~[?:?]
        at org.ystia.yorc.alien4cloud.plugin.YorcPaaSProvider.setConfiguration(YorcPaaSProvider.java:62) 
...[Redacted]...
Caused by: org.springframework.web.client.ResourceAccessException: I/O error on GET request for "https://127.0.0.1:8800/deployments": Received fatal alert: bad_certificate; nested exception is javax.net.ssl.SSLHandshakeException: Received fatal alert: bad_certificate

Java SSL debug logs shows no certificate is found on the client during the SSL handshake:

*** CertificateRequest
Cert Types: RSA, ECDSA
Supported Signature Algorithms: SHA256withRSA, SHA256withECDSA, SHA384withRSA, SHA384withECDSA, SHA512withRSA, SHA512withECDSA, SHA1withRSA, SHA1withECDSA
Cert Authorities:
<CN=yorc, OU=yorc, O=ystia, L=Default City, C=FR>
qtp1131592118-15, READ: TLSv1.2 Handshake, length = 4
*** ServerHelloDone
Warning: no suitable certificate found - continuing without client authentication
*** Certificate chain
<Empty>
***

System settings for keystore don't seem to be used here.
While some java code using the same truststore and keystore, creating a socket from a socket factory using a system defaut SSL context, is able to perform a handshake with the secured Yorc server.

Alien4Cloud version

2.1.0

Output of yorc version

3.2.0-SNAPSHOT (develop) or 3.1.0

Priority

Medium

• High = We should stop anything we are doing and do this. If you're writing this calmly, you should probably choose another option. If it's really that urgent, please make sure we read this.
• Medium = It's important that we do this within a few days.
• Low = We will consider this on our next sprint planning.

(Please be aware that your priority may not match ours, we'll use this as guidance only).

Bug Report

Description

Plugin version : 3.2.0-M3
Having K8's JOB and K8's deployment on demand ressources makes matching phase crashing and return an error 500
A workaround is deleting job ressource and keep only deployment one

Expected behavior

Having K8's JOB AND K8's deployment on demand ressources should not return errors at matching step

Actual behavior

Having the both return error

Steps to reproduce the issue

1. Upload yorc plugin
2. Configure k8s location with Container, Job, Deployment, and Service
3. Upload or create a k8's app. You can use simpleApache for example
4. Click on "matching" button

Additional information you deem important (e.g. issue happens only occasionally)

Additional environment details (infrastructure implied: AWS, OpenStack, etc.)

Output of yorc version

Yorc Server v3.2.0-M3
Database schema version: 1.0.0
Revision: "34e008d0db595b0e5756afbe5b2d87f39eb4bcb4"

Yorc configuration file

Priority

Medium

Issue Type

Put an X between the brackets of the corresponding issue type

• Bug report
• Documentation issue report
• Improvement request

Description

Its not clear enough how to configure in the slurm.Compute resources, the credentials property values of the endpoint capability.
The credentials are the one used to create the resource, or the one used to connect to it once created ? Or both ?
Specify that if the user property is set, the token_type must be set to "password" or to "private_key".

Expected behavior

Priority

Low

• High = We should stop anything we are doing and do this. If you're writing this calmly, you should probably choose another option. If it's really that urgent, please make sure we read this.
• Medium = It's important that we do this within a few days.
• Low = We will consider this on our next sprint planning.

(Please be aware that your priority may not match ours, we'll use this as guidance only).

@loicalbertin commented on Mon Jan 07 2019

@loicalbertin commented on Thu Feb 14 2019

Starting with Alien 2.1.1 and #84 Alien now provide a way to get the original RFC-3339 timestamp at the nanosecond precision. This can be used to order logs properly.

As: An app manager
I want to: Update a deployed topology
So that: I add or remove workflows

AC1: Use Yorc premium REST API endpoint for deployment updates
AC2: ability to add a new workflows
AC3: ability to remove an existing workflows

AC4: ability to change an existing workflow

Related to ystia/yorc#209

Issue Type

• Bug report
• Documentation issue report
• Improvement request

Description

From time to time, an application being undeployed can stay in the state UNDEPLOYMENT_IN_PROGRESS for 30 minute in Alien4Cloud, while the application has been undeployed and purged on Yorc in less than 1 minute.

Finally after 30 minutes, the application appears as being UNDEPLOYED in Alien4Cloud.
Logs show a timeout occured in the Alien4Cloud Yorc plugin task UndeployTask:

2019-03-18 16:33:13.871 WARN  [WorkThread-9] UndeployTask:159 - Timeout occured
2019-03-18 16:33:13.886 INFO  [WorkThread-9] UndeployService:88 - Un-deployed deployment [a7d002be-e8ca-421b-92de-574705067f0f] on orchestrator [77ec2a2e-444f-403c-

Output of yorc version

Happens with yorc 3.1.1, 3.1.2 and 3.2.0 since latest snapshot.

Priority

Medium

• High = We should stop anything we are doing and do this. If you're writing this calmly, you should probably choose another option. If it's really that urgent, please make sure we read this.
• Medium = It's important that we do this within a few days.
• Low = We will consider this on our next sprint planning.

(Please be aware that your priority may not match ours, we'll use this as guidance only).

Issue Type

Put an X between the brackets of the corresponding issue type

• Bug report
• Documentation issue report
• Improvement request

Description

Hi,

When I deploy an application, if I restart Alien4Cloud during the deployment and the app finishes to deploy succesffuly before Alien4Cloud finishes to restart, the deployment will always stay in progress in Alien4Cloud and will never finish.

Expected behavior

The deployment status (finished) is properly updated when Alien4Cloud has restarted.

Actual behavior

The deployment status stay in progress when Alien4Cloud has restarted and will never change.

Steps to reproduce the issue

• Deploy an application in Alien4Cloud
• Wait just before the end of the deployment to restart Alien4Cloud
• Restart Alien4Cloud

Additional information you deem important (e.g. issue happens only occasionally)

Additional environment details (infrastructure implied: AWS, OpenStack, etc.)

Alien4Cloud version

Alien4Cloud 2.1.0

Output of yorc version

Yorc 3.1.0-RC2

Yorc configuration file

Priority

High (may have some status inconsistency that may cause us some troubles).

• High = We should stop anything we are doing and do this. If you're writing this calmly, you should probably choose another option. If it's really that urgent, please make sure we read this.
• Medium = It's important that we do this within a few days.
• Low = We will consider this on our next sprint planning.

(Please be aware that your priority may not match ours, we'll use this as guidance only).

As: An app designer
I want to: visualy identify Yorc's components with icons (specially true when they are coming from topology modifiers)
So that: I can identify, at a glance, components in runtime or workflows views

AC1: Check all types provided by Yorc

Already identified

• GCP Addresses
• Slurm Jobs
• Kubernetes resources

• Specify in README that this project is no more under active dev.
• Keep it as long as 3.2 is supported.
• Migrate ZenHub Backlog for this repo

Issue Type

Put an X between the brackets of the corresponding issue type

• Bug report
• Documentation issue report
• Improvement request

Description

Initiate a Blog for Ystia opensource project with the GCP demo

• create a site at https://ystia.github.io/
• create a blog at https://ystia.github.io/blog/
• Rework GCP sample to:
  • minimize prerequisites
  • provide scripts automating the setup
• Add a blog entry describing how to use the sample

When deploying a topolgy for kubernetes connecting two deployments (Grafana for example), get attribute from target is working for port but for IP, it results in a "${SERVICE_IP_LOOKUP0}" which is not working for the pod

Bug Report

Description

TOSCA samples are still importing alien-base-types:2.1.1, they should be updated to import version 2.2

Priority

Medium

• High = We should stop anything we are doing and do this. If you're writing this calmly, you should probably choose another option. If it's really that urgent, please make sure we read this.
• Medium = It's important that we do this within a few days.
• Low = We will consider this on our next sprint planning.

(Please be aware that your priority may not match ours, we'll use this as guidance only).

Bug Report

Description

Workflow ends with timeout after 4 hours and application is undeployed

Expected behavior

No timeout

Actual behavior

Workflow ends with timeout after 4 hours and application is undeployed

Priority

High

Add as a TOSCA sample a basic implementation of Job allowing to spawn shell commands,
that could be used on infrastructures without a default job scheduler, like Hosts Pools or OpenStack.

As: an app designer
I want to: Design a portable Job and choose to deploy it on a Slurm location
So that: I can build portable jobs workloads

AC1: Use a4c modifier

@loicalbertin commented on Thu Aug 29 2019

As: Yorc Dev Team / User
I want to: Have the Yorc plugin documentation online on A4C website
So that: I can consult it easily

AC1: Migrate documentation, adapt it if needed

Issue Type

• Bug report

Description

This is problematic for specific node lifecycle as Job by instance.
Ex: https://github.com/alien4cloud/samples/blob/develop/org/alien4cloud/mock/jobs/types.yml

Priority

High

Issue Type

• Bug report

Description

Usage of abstract components is broken

Expected behavior

I would like to deploy an application using abstract components using A4C matching.

Actual behavior

I create an application in A4C, I create the associated resource in the corresponding location, the matching is working very well. In the topology sended to Yorc, the topology is good. Indeed in the node_template: section, I have my concrete component inserted by the matching. But in the workflow I have something very strange.

I was expecting to have approximately the same workflow using an abstract component or using a concrete component. But it is not. With the abstract component I have this workflow :

  workflows:
    install:
      steps:
        Compute_install:
          target: Compute
          activities:
            - delegate: install
          on_success:
            - ConsulServer_install
        ConsulServer_install:
          target: ConsulServer
          activities:
            - delegate: install

Wich causes this error in Yorc :

[2018-08-01T09:23:52.919112565+02:00][DEBUG][test-Environment][install][72018f83-69b5-4412-b239-71b84eb18b1c][ConsulServer][][][][]Step "ConsulServer_install": error details: Unsupported node type "org.ystia.yorc.samples.consul.linux.ansible.nodes.ConsulServer" for a delegate operation

Here is the complete topology sended to yorc :

tosca_definitions_version: alien_dsl_2_0_0

metadata:
  template_name: Test
  template_version: 0.1.0-SNAPSHOT
  template_author: ${template_author}

description: ""

imports:
  - org.ystia.yorc.pub/1.0.0-SNAPSHOT/types.yaml
  - org.ystia.ansible.pub/1.0.0-SNAPSHOT/types.yaml
  - <yorc-openstack-types.yml>
  - org.ystia.yorc.linux.ansible/1.0.0-SNAPSHOT/types.yaml
  - org.ystia.yorc.samples.consul.linux.ansible/1.0.0-SNAPSHOT/types.yaml
  - org.ystia.yorc.samples.consul.pub/1.0.0-SNAPSHOT/types.yaml
  - <yorc-types.yml>

topology_template:
  node_templates:
    Compute:
      metadata:
        a4c_edit_x: 103
        a4c_edit_y: "-47"
      type: yorc.nodes.openstack.Compute
      properties:
        image: "7d9bd308-d9c1-4952-a410-95b761672499"
        flavor: 4
        key_pair: yorc
      capabilities:
        endpoint:
          properties:
            credentials: 
              user: root
            secure: true
            protocol: tcp
            network_name: PRIVATE
            initiator: source
        scalable:
          properties:
            min_instances: 1
            max_instances: 1
            default_instances: 1
    ConsulServer:
      type: org.ystia.yorc.samples.consul.linux.ansible.nodes.ConsulServer
      properties:
        install_dnsmasq: true
        mode: server
        download_url: "https://releases.hashicorp.com/consul/1.0.2/consul_1.0.2_linux_amd64.zip"
        install_dir: "/usr/local/bin"
        data_dir: "/var/consul"
        config_dir: "/etc/consul.d"
        datacenter: dc1
        domain: consul
      requirements:
        - hostedOnComputeHost:
            type_requirement: host
            node: Compute
            capability: tosca.capabilities.Container
            relationship: tosca.relationships.HostedOn
      capabilities:
        consul_agent:
          properties:
            api_port: 8500
            protocol: tcp
            secure: false
            network_name: PRIVATE
            initiator: source
  workflows:
    install:
      steps:
        Compute_install:
          target: Compute
          activities:
            - delegate: install
          on_success:
            - ConsulServer_install
        ConsulServer_install:
          target: ConsulServer
          activities:
            - delegate: install
    uninstall:
      steps:
        Compute_uninstall:
          target: Compute
          activities:
            - delegate: uninstall
        ConsulServer_uninstall:
          target: ConsulServer
          activities:
            - delegate: uninstall
          on_success:
            - Compute_uninstall
    start:
      steps:
        ConsulServer_start:
          target: ConsulServer
          activities:
            - delegate: start
        Compute_start:
          target: Compute
          activities:
            - delegate: start
          on_success:
            - ConsulServer_start
    stop:
      steps:
        ConsulServer_stop:
          target: ConsulServer
          activities:
            - delegate: stop
          on_success:
            - Compute_stop
        Compute_stop:
          target: Compute
          activities:
            - delegate: stop

Steps to reproduce the issue

1. Create an application on your A4C with an component that is abstact (but not a compute). You can use the org.ystia.yorc.samples.consul.pub.nodes.ConsulServer component

topology_template:
  node_templates:
    Compute:
      metadata:
        a4c_edit_x: 103
        a4c_edit_y: "-47"
      type: tosca.nodes.Compute
      capabilities:
        scalable:
          properties:
            min_instances: 1
            max_instances: 1
            default_instances: 1
        endpoint:
          properties:
            secure: true
            protocol: tcp
            network_name: PRIVATE
            initiator: source
    ConsulServer:
      type: org.ystia.yorc.samples.consul.pub.nodes.ConsulServer
      properties:
        mode: server
        download_url: "https://releases.hashicorp.com/consul/1.0.2/consul_1.0.2_linux_amd64.zip"
        install_dir: "/usr/local/bin"
        data_dir: "/var/consul"
        config_dir: "/etc/consul.d"
        datacenter: dc1
        domain: consul
      requirements:
        - hostedOnComputeHost:
            type_requirement: host
            node: Compute
            capability: tosca.capabilities.Container
            relationship: tosca.relationships.HostedOn
      capabilities:
        consul_agent:
          properties:
            api_port: 8500
            protocol: tcp
            secure: false
            network_name: PRIVATE
            initiator: source

2. Create the resource in the location

3. Deploy the application, and see how it failes

Alien4Cloud version

2.0.0

Output of yorc version

Yorc Server v3.1.0-SNAPSHOT
Revision: "9fd36012fd2a8e93071f958c5e65c7e79a84353d"

Priority

Medium

Bug report

Description

When we disable-enable the orchestrator we get an error in the logs of a4C:

2018-08-24 09:59:56 INFO  YorcPaaSProvider:159 - Starting Yorc events & logs listeners
2018-08-24 09:59:56 ERROR EventListenerTask:167 - listenDeploymentEvent Failed
java.lang.NullPointerException: null
	at org.ystia.yorc.alien4cloud.plugin.rest.RestClient.getEventFromYorc(RestClient.java:343) ~[305711ce-542f-4e21-9140-567d6fcd554d/:?]
	at org.ystia.yorc.alien4cloud.plugin.EventListenerTask.run(EventListenerTask.java:60) [305711ce-542f-4e21-9140-567d6fcd554d/:?]
	at org.ystia.yorc.alien4cloud.plugin.TaskManager.nextWork(TaskManager.java:89) [305711ce-542f-4e21-9140-567d6fcd554d/:?]
	at org.ystia.yorc.alien4cloud.plugin.TaskManager$WorkThread.run(TaskManager.java:141) [305711ce-542f-4e21-9140-567d6fcd554d/:?]
2018-08-24 09:59:56 WARN  LogListenerTask:72 - listen Yorc Logs Failed
java.lang.NullPointerException: null
	at org.ystia.yorc.alien4cloud.plugin.rest.RestClient.getLogFromYorc(RestClient.java:333) ~[305711ce-542f-4e21-9140-567d6fcd554d/:?]
	at org.ystia.yorc.alien4cloud.plugin.LogListenerTask.run(LogListenerTask.java:50) [305711ce-542f-4e21-9140-567d6fcd554d/:?]
	at org.ystia.yorc.alien4cloud.plugin.TaskManager.nextWork(TaskManager.java:89) [305711ce-542f-4e21-9140-567d6fcd554d/:?]
	at org.ystia.yorc.alien4cloud.plugin.TaskManager$WorkThread.run(TaskManager.java:141) [305711ce-542f-4e21-9140-567d6fcd554d/:?]

This cause no trouble, but an error stack trace in A4C logs

Alien4Cloud version

2.0.0

Priority

High

As: Yorc Dev team
I want to: upgrade to Alien4Cloud 2.2
So that: I can benefit of bugfixes & enhancements

AC1: Migrate yorc-a4c-plugin
AC2: Check for DSL updates or incompatibilities
AC3: Upgrade csar-public-library & ystia forge