Re: server create problem

[DeWayne Filppi]

I dug down quite a bit, and see that in openstack_plugin_common.__init__ in
the cosmo_list method of the NovaClientWithSugar class, I wrapped a call to
getattr with a try:except and see.

02:22:47 | I | nova_plugin.server.create | {u'args': OrderedDict(),
u'openstack_config': {'username': 'dewayne', 'tenant_name':
'dewayne-tenant', 'password': 'viBKwW4E', 'auth_url': '
https://rackspace-api.gigaspaces.com:5000/v3'}} | COSMO_EXCEPTION='Client'
object has no attribute 'images'

Maybe somebody who wrote this logic can help. Basically, the logic take the
'image' property, makes it plural, and then tries to find it in the client
class.  It doesn't find it and it blows up.  Maybe I've got a bad version
of the openstack plugin:  2.2.0


On Thu, Aug 31, 2017 at 12:53 AM, Ran Ziv  wrote:

> Is this everything?
> It seems like this never reached the actual API call telling Nova to create
> a server, but rather failed in the section where image/flavor, keypair,
> security groups and nics are configured for the server
> ( see
> https://github.com/cloudify-cosmo/cloudify-openstack-
> plugin/blob/master/nova_plugin/server.py#L282
> )
>
> Unfortunately it seems like the trace from the plugin code hasn't reached
> the execution logs somehow (possibly something we've missed in the plugin
> adapter?), so I can't really say what's the exact problem.
> It should be fairly simple to debug though - the plugin code should be
> extracted inside your ~/.aria/plugins dir, so you can easily debug the
> plugin code while it's running and find the real problem as it happens.
>
>
> On Wed, Aug 30, 2017 at 7:28 PM, DeWayne Filppi 
> wrote:
>
> > The log:
> >
> > Starting execution. Press Ctrl+C cancel
> > 16:13:43 | I | neutron_plugin.router.create | {u'args': OrderedDict(),
> > u'openstack_config': {'username': 'dewayne', 'tenant_name':
> > 'dewayne-tenant', 'password': 'xxx', 'auth_url': '
> > https://rackspace-api.gigaspaces.com:5000/v3'}} | router_1
> Standard.create
> > started...
> > 16:13:44 | I | neutron_plugin.network.create | {u'args': OrderedDict(),
> > u'openstack_config': {'username': 'dewayne', 'tenant_name':
> > 'dewayne-tenant', 'password': 'xxx', 'auth_url': '
> > https://rackspace-api.gigaspaces.com:5000/v3'}} | network_1
> > Standard.create
> > started...
> > 16:13:44 | I | nova_plugin.keypair.create | {u'args': OrderedDict(),
> > u'openstack_config': {'username': 'dewayne', 'tenant_name':
> > 'dewayne-tenant', 'password': 'xxx', 'auth_url': '
> > https://rackspace-api.gigaspaces.com:5000/v3'}} | keypair_1
> > Standard.create
> > started...
> > 16:13:51 | I | neutron_plugin.network.create | {u'args': OrderedDict(),
> > u'openstack_config': {'username': 'dewayne', 'tenant_name':
> > 'dewayne-tenant', 'password': 'xxx', 'auth_url': '
> > https://rackspace-api.gigaspaces.com:5000/v3'}} | network_1
> > Standard.create
> > successful
> > 16:13:51 | D | None | {} | network_1 Standard.configure has no
> > implementation
> > 16:13:51 | D | None | {} | network_1 Standard.start has no implementation
> > 16:13:52 | I | nova_plugin.keypair.create | {u'args': OrderedDict(),
> > u'openstack_config': {'username': 'dewayne', 'tenant_name':
> > 'dewayne-tenant', 'password': 'xxx', 'auth_url': '
> > https://rackspace-api.gigaspaces.com:5000/v3'}} | Using external
> resource
> > keypair: dfilppi-rs
> > 16:13:52 | I | nova_plugin.keypair.create | {u'args': OrderedDict(),
> > u'openstack_config': {'username': 'dewayne', 'tenant_name':
> > 'dewayne-tenant', 'password': 'xxx', 'auth_url': '
> > https://rackspace-api.gigaspaces.com:5000/v3'}} | keypair_1
> > Standard.create
> > successful
> > 16:13:52 | I | neutron_plugin.router.create | {u'args': OrderedDict(),
> > u'openstack_config': {'username': 'dewayne', 'tenant_name':
> > 'dewayne-tenant', 'password': 'xxx', 'auth_url': '
> > https://rackspace-api.gigaspaces.com:5000/v3'}} | router_1
> Standard.create
> > successful
> > 16:13:53 | D | None | {} | router_1 Standard.configure has no
> > implementation
> > 16:13:53 | D | None | {} | keypair_1 Standard.configure has no
> > implementation
> > 16:13:53 | D | None | {} | router_1 Standard.start has no implementation
> > 16:13:54 | D | None | {} | keypair_1 Standard.start has no implementation
> > 16:13:57 | I | neutron_plugin.subnet.create | {u'args':
> > OrderedDict([('cidr', u'172.16.0.0/16'), ('ip_version', 4)]),
> > u'openstack_config': {'username': 'dewayne', 'tenant_name':
> > 'dewayne-tenant', 'password': 'xxx', 'auth_url': '
> > https://rackspace-api.gigaspaces.com:5000/v3'}} | subnet_1
> Standard.create
> > started...
> > 16:14:02 | I | neutron_plugin.subnet.create | {u'args':
> > OrderedDict([('cidr', u'172.16.0.0/16'), ('ip_version', 4)]),
> > u'openstack_config': {'username': 'dewayne', 'tenant_name':
> > 'dewayne-tenant', 'password': 'xxx', 'auth_url': '
> > https://rackspace-api.gigaspaces.com:5000/v3'}} | subnet_1
> Standard.create
> > successful
> > 

Podling Report Reminder - September 2017

[johndament]

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 form a part of the Incubator PMC
report. The Incubator PMC requires your report to be submitted 2 weeks
before the board meeting, to allow sufficient time for review and
submission (Wed, September 06).

Please submit your report with sufficient time to allow the Incubator
PMC, and subsequently board members to review and digest. Again, the
very latest you should submit your report is 2 weeks prior to the board
meeting.

Thanks,

The Apache Incubator PMC

Submitting your Report

--

Your report should contain the following:

*   Your project name
*   A brief description of your project, which assumes no knowledge of
the project or necessarily of its field
*   A list of the three most important issues to address in the move
towards graduation.
*   Any issues that the Incubator PMC or ASF Board might wish/need to be
aware of
*   How has the community developed since the last report
*   How has the project developed since the last report.
*   How does the podling rate their own maturity.

This should be appended to the Incubator Wiki page at:

https://wiki.apache.org/incubator/September2017

Note: This is manually populated. You may need to wait a little before
this page is created from a template.

Mentors
---

Mentors should review reports for their project(s) and sign them off on
the Incubator wiki page. Signing off reports shows that you are
following the project - projects that are not signed may raise alarms
for the Incubator PMC.

Incubator PMC

Re: Service Composition / Substitution Mapping

[Tal Liron]

Regarding #1, I agree with Avia here. Substitution mapping is intended as
an extension of requirements-matching-capabilities. As you know, a
requirement can be as minimal as just specifying a capability type, but
could optionally additionally specify a node and even include a node filter
with more constraints. Unfortunately the substitution mapping grammar is
still not very sophisticated in TOSCA 1.0, and while you can require a
node, you can't specifically require it to be a substituted service
template. That's why I'm thinking we may need to introduce a policy to fill
in this gap for now. But indeed, if there is no such policy, available
service templates could be tried arbitrarily one at a time until one
satisfies the requirement (as Avia points out, this would require the
composite service to be *entirely* successfully satisfied).

On Thu, Aug 31, 2017 at 10:23 AM, Avia Efrat  wrote:

> 1) Substitutable nodes (abstract nodes) are defined by their type. And a
> node type should represent specific node/subsystem characteristics. Having
> two node types ( with the same name) that represent different logical
> entities seems odd, and indicates a possible bug in the design. That is
> another reason why using so-called namespaces while creating type
> hierarchies is a good practice.
>
> You could argue that if you have multiple sources for templates (e.g. your
> own storage and a external catalog), there could be unexpected name
> collisions of node types names. Having said that, we need to remember the
> entire process of the substitution mapping.
>
> First, as you said, we are trying to locate a service template that has a
> substitution mapping definition of the same type of the abstract node in
> the top level template. But choosing the service template is only the first
> step. The second step is instantiating the top level template along with
> the substitution template. During the instantiation, requirements and
> capabilities are matched. If not all requirements are satisfied
> (considering both top level and substituting template), the substitution
> mapping is not considered successful, and the instantiation fails.
>
> If that is the case, it makes sense to go ahead and try the next
> substitution template that fits the type, and continue like so until we
> find a substitution where all the requirements are satisfied during
> instantiation.
>
> At this point you may be wondering, "what if the instantiation was
> successful, but the source of the substitution template wasn't the one that
> *I* wanted?". Well, You have to think about this issue in substitution
> mapping terms. that is, when you use an abstract node, actually what you
> are saying is "I want something of type t, the has the capabilities c, and
> requires r. regarding the internals, I don't care, I just want it to work".
> So actually, selecting a specific substituting template (as long as the
> type, the requirements and the capabilities are as expected, of course), is
> somewhat against the spirit of the substitution mapping feature.
>
> 2) I'm sorry, but I didn't get to the bottom of your question. Could you
> elaborate a bit more, and include a small example?
>
>
>
>
> On Thu, Aug 31, 2017 at 11:35 AM, D Jayachandran <
> d.jayachand...@ericsson.com> wrote:
>
> > Hi,
> >
> > With respect to substituting stored service templates, I have few things
> > to be clarified
> >
> > 1) Handling substitution when multiple service templates matches for the
> > abstract node type .
> > Would the 1st match would be used for substitution  or Are we
> > looking at policy to enable user to select particular service templates
> for
> > substitution with multiple service templates ?
> > 2) Custom node types as abstract node type.
> > With custom node types as abstract node type, there seems to be a
> > need to implicitly import that custom node type in our top level service
> > template so that the parser recognizes this custom type.
> > Assuming the abstract node type would be substituted from a
> stored
> > substituting service template, we need to at least import the custom node
> > types and have it part of the same CSAR package.
> > Would this be a challenge for the top-level service template
> > author in including and importing the custom node types as abstraction ?
> or
> > Is this how we are looking at custom node types ?
> > Is it possible to identify an abstract node during parsing , such
> > as if it does not contain any implementation ( The SPEC does not say
> > anything on this )?
> >
> > Regards,
> > DJ
> > -Original Message-
> > From: Ran Ziv [mailto:r...@cloudify.co]
> > Sent: Wednesday, August 16, 2017 6:19 PM
> > To: dev@ariatosca.incubator.apache.org
> > Subject: Re: Service Composition / Substitution Mapping
> >
> > I agree, especially when the benefit of being able to use an existing
> > service - yet only one which hasn't been deployed via a workflow -
> doesn't

Re: Service Composition / Substitution Mapping

[Avia Efrat]

1) Substitutable nodes (abstract nodes) are defined by their type. And a
node type should represent specific node/subsystem characteristics. Having
two node types ( with the same name) that represent different logical
entities seems odd, and indicates a possible bug in the design. That is
another reason why using so-called namespaces while creating type
hierarchies is a good practice.

You could argue that if you have multiple sources for templates (e.g. your
own storage and a external catalog), there could be unexpected name
collisions of node types names. Having said that, we need to remember the
entire process of the substitution mapping.

First, as you said, we are trying to locate a service template that has a
substitution mapping definition of the same type of the abstract node in
the top level template. But choosing the service template is only the first
step. The second step is instantiating the top level template along with
the substitution template. During the instantiation, requirements and
capabilities are matched. If not all requirements are satisfied
(considering both top level and substituting template), the substitution
mapping is not considered successful, and the instantiation fails.

If that is the case, it makes sense to go ahead and try the next
substitution template that fits the type, and continue like so until we
find a substitution where all the requirements are satisfied during
instantiation.

At this point you may be wondering, "what if the instantiation was
successful, but the source of the substitution template wasn't the one that
*I* wanted?". Well, You have to think about this issue in substitution
mapping terms. that is, when you use an abstract node, actually what you
are saying is "I want something of type t, the has the capabilities c, and
requires r. regarding the internals, I don't care, I just want it to work".
So actually, selecting a specific substituting template (as long as the
type, the requirements and the capabilities are as expected, of course), is
somewhat against the spirit of the substitution mapping feature.

2) I'm sorry, but I didn't get to the bottom of your question. Could you
elaborate a bit more, and include a small example?




On Thu, Aug 31, 2017 at 11:35 AM, D Jayachandran <
d.jayachand...@ericsson.com> wrote:

> Hi,
>
> With respect to substituting stored service templates, I have few things
> to be clarified
>
> 1) Handling substitution when multiple service templates matches for the
> abstract node type .
> Would the 1st match would be used for substitution  or Are we
> looking at policy to enable user to select particular service templates for
> substitution with multiple service templates ?
> 2) Custom node types as abstract node type.
> With custom node types as abstract node type, there seems to be a
> need to implicitly import that custom node type in our top level service
> template so that the parser recognizes this custom type.
> Assuming the abstract node type would be substituted from a stored
> substituting service template, we need to at least import the custom node
> types and have it part of the same CSAR package.
> Would this be a challenge for the top-level service template
> author in including and importing the custom node types as abstraction ? or
> Is this how we are looking at custom node types ?
> Is it possible to identify an abstract node during parsing , such
> as if it does not contain any implementation ( The SPEC does not say
> anything on this )?
>
> Regards,
> DJ
> -Original Message-
> From: Ran Ziv [mailto:r...@cloudify.co]
> Sent: Wednesday, August 16, 2017 6:19 PM
> To: dev@ariatosca.incubator.apache.org
> Subject: Re: Service Composition / Substitution Mapping
>
> I agree, especially when the benefit of being able to use an existing
> service - yet only one which hasn't been deployed via a workflow - doesn't
> seem all that interesting IMO.
>
> Another concern I could add to the ones you've mentioned is the service's
> inputs - the substituting template's inputs should be received via the
> properties of the abstract node in the top level service template. If the
> service already exists, these inputs would not be passed as expected.
>
> Ran
>
> On Wed, Aug 16, 2017 at 3:25 PM, D Jayachandran <
> d.jayachand...@ericsson.com
> > wrote:
>
> > Hi Ran,
> >
> > When Tal mentioned about "substituting service", I thought it was
> > about the services which dint have any associated executions/workflows
> triggered.
> > Am also in favor of  "substituting service templates" rather than
> > "substituting service".
> > With "substituting service" approach (when the service is not
> > instantiated), I see some open points
> > - In a multi-user scenario, what will happen when a service is
> > composed using the substituting service and at the sametime a
> > workflow is triggered for the substituting service. ?
> > - Is it okay to delete(dissolve) the 

RE: Service Composition / Substitution Mapping

[D Jayachandran]

Hi,

With respect to substituting stored service templates, I have few things to be 
clarified

1) Handling substitution when multiple service templates matches for the 
abstract node type .
Would the 1st match would be used for substitution  or Are we looking 
at policy to enable user to select particular service templates for 
substitution with multiple service templates ?
2) Custom node types as abstract node type. 
With custom node types as abstract node type, there seems to be a need 
to implicitly import that custom node type in our top level service template so 
that the parser recognizes this custom type. 
Assuming the abstract node type would be substituted from a stored 
substituting service template, we need to at least import the custom node types 
and have it part of the same CSAR package. 
Would this be a challenge for the top-level service template author in 
including and importing the custom node types as abstraction ? or Is this how 
we are looking at custom node types ?
Is it possible to identify an abstract node during parsing , such as if 
it does not contain any implementation ( The SPEC does not say anything on this 
)? 

Regards,
DJ
-Original Message-
From: Ran Ziv [mailto:r...@cloudify.co] 
Sent: Wednesday, August 16, 2017 6:19 PM
To: dev@ariatosca.incubator.apache.org
Subject: Re: Service Composition / Substitution Mapping

I agree, especially when the benefit of being able to use an existing service - 
yet only one which hasn't been deployed via a workflow - doesn't seem all that 
interesting IMO.

Another concern I could add to the ones you've mentioned is the service's 
inputs - the substituting template's inputs should be received via the 
properties of the abstract node in the top level service template. If the 
service already exists, these inputs would not be passed as expected.

Ran

On Wed, Aug 16, 2017 at 3:25 PM, D Jayachandran  wrote:

> Hi Ran,
>
> When Tal mentioned about "substituting service", I thought it was 
> about the services which dint have any associated executions/workflows 
> triggered.
> Am also in favor of  "substituting service templates" rather than 
> "substituting service".
> With "substituting service" approach (when the service is not 
> instantiated), I see some open points
> - In a multi-user scenario, what will happen when a service is 
> composed using the substituting service and at the sametime a  
> workflow is triggered for the substituting service. ?
> - Is it okay to delete(dissolve) the substituting service 
> after it is used to create the composed service. ?
>
> Starting with it might be a good idea to only have "substituting 
> service templates" approach.
>
> Regards,
> DJ
> -Original Message-
> From: Ran Ziv [mailto:r...@cloudify.co]
> Sent: Wednesday, August 16, 2017 4:29 PM
> To: dev@ariatosca.incubator.apache.org
> Subject: Re: Service Composition / Substitution Mapping
>
> I'd say right now we're looking at "static service composition" which 
> is only about "substituting service templates", not "substituting 
> service". If a service is already running, it will not be used.
>
> I think what Tal meant was that each service template - whether the 
> top level one or one of the substituting templates - needs to resolve 
> its inner reqs internally first, and then resolve substitution 
> reqs across service templates.
>
>
> On Wed, Aug 16, 2017 at 12:00 PM, D Jayachandran < 
> d.jayachand...@ericsson.com> wrote:
>
> > Hi Tal,
> >
> > Thanks for organizing the points.
> > So if I understand correctly we are looking only at "Static service 
> > composition" which includes "substituting service template" and 
> > "substituting service".
> >
> > As you said with "substituting service template" approach ,we will 
> > have all the nodes aggregated from other service templates and a 
> > single workflow would be triggered to perform life-cycle operation 
> > on
> all the nodes.
> > Am not sure why the workflows needs to be "boundary aware" for nodes 
> > being substituted ? I see nodes are already part of the composed 
> > service, Could you please help me understand this ?
> >
> >
> > Regards,
> > DJ
> > -Original Message-
> > From: Tal Liron [mailto:t...@cloudify.co]
> > Sent: Saturday, August 12, 2017 4:52 AM
> > To: dev@ariatosca.incubator.apache.org
> > Subject: Re: Service Composition / Substitution Mapping
> >
> > You are correct -- to participate in this "multi-VIM" scenario, the 
> > Openstack plugin would have to know how to translate the TOSCA 
> > properties to a flavor ID. This could all be done in 100% TOSCA via 
> > policies (say, an aria.Openstack).
> >
> > Doing this automatically might not be a good idea, or even necessary.
> > Worst case is you get a validation error if the ARIA plugin can't 
> > find a flavor in the table to match your requirements, in which you 
> > case you can go and manually find the 

Re: server create problem

[Ran Ziv]

Is this everything?
It seems like this never reached the actual API call telling Nova to create
a server, but rather failed in the section where image/flavor, keypair,
security groups and nics are configured for the server
( see
https://github.com/cloudify-cosmo/cloudify-openstack-plugin/blob/master/nova_plugin/server.py#L282
)

Unfortunately it seems like the trace from the plugin code hasn't reached
the execution logs somehow (possibly something we've missed in the plugin
adapter?), so I can't really say what's the exact problem.
It should be fairly simple to debug though - the plugin code should be
extracted inside your ~/.aria/plugins dir, so you can easily debug the
plugin code while it's running and find the real problem as it happens.


On Wed, Aug 30, 2017 at 7:28 PM, DeWayne Filppi  wrote:

> The log:
>
> Starting execution. Press Ctrl+C cancel
> 16:13:43 | I | neutron_plugin.router.create | {u'args': OrderedDict(),
> u'openstack_config': {'username': 'dewayne', 'tenant_name':
> 'dewayne-tenant', 'password': 'xxx', 'auth_url': '
> https://rackspace-api.gigaspaces.com:5000/v3'}} | router_1 Standard.create
> started...
> 16:13:44 | I | neutron_plugin.network.create | {u'args': OrderedDict(),
> u'openstack_config': {'username': 'dewayne', 'tenant_name':
> 'dewayne-tenant', 'password': 'xxx', 'auth_url': '
> https://rackspace-api.gigaspaces.com:5000/v3'}} | network_1
> Standard.create
> started...
> 16:13:44 | I | nova_plugin.keypair.create | {u'args': OrderedDict(),
> u'openstack_config': {'username': 'dewayne', 'tenant_name':
> 'dewayne-tenant', 'password': 'xxx', 'auth_url': '
> https://rackspace-api.gigaspaces.com:5000/v3'}} | keypair_1
> Standard.create
> started...
> 16:13:51 | I | neutron_plugin.network.create | {u'args': OrderedDict(),
> u'openstack_config': {'username': 'dewayne', 'tenant_name':
> 'dewayne-tenant', 'password': 'xxx', 'auth_url': '
> https://rackspace-api.gigaspaces.com:5000/v3'}} | network_1
> Standard.create
> successful
> 16:13:51 | D | None | {} | network_1 Standard.configure has no
> implementation
> 16:13:51 | D | None | {} | network_1 Standard.start has no implementation
> 16:13:52 | I | nova_plugin.keypair.create | {u'args': OrderedDict(),
> u'openstack_config': {'username': 'dewayne', 'tenant_name':
> 'dewayne-tenant', 'password': 'xxx', 'auth_url': '
> https://rackspace-api.gigaspaces.com:5000/v3'}} | Using external resource
> keypair: dfilppi-rs
> 16:13:52 | I | nova_plugin.keypair.create | {u'args': OrderedDict(),
> u'openstack_config': {'username': 'dewayne', 'tenant_name':
> 'dewayne-tenant', 'password': 'xxx', 'auth_url': '
> https://rackspace-api.gigaspaces.com:5000/v3'}} | keypair_1
> Standard.create
> successful
> 16:13:52 | I | neutron_plugin.router.create | {u'args': OrderedDict(),
> u'openstack_config': {'username': 'dewayne', 'tenant_name':
> 'dewayne-tenant', 'password': 'xxx', 'auth_url': '
> https://rackspace-api.gigaspaces.com:5000/v3'}} | router_1 Standard.create
> successful
> 16:13:53 | D | None | {} | router_1 Standard.configure has no
> implementation
> 16:13:53 | D | None | {} | keypair_1 Standard.configure has no
> implementation
> 16:13:53 | D | None | {} | router_1 Standard.start has no implementation
> 16:13:54 | D | None | {} | keypair_1 Standard.start has no implementation
> 16:13:57 | I | neutron_plugin.subnet.create | {u'args':
> OrderedDict([('cidr', u'172.16.0.0/16'), ('ip_version', 4)]),
> u'openstack_config': {'username': 'dewayne', 'tenant_name':
> 'dewayne-tenant', 'password': 'xxx', 'auth_url': '
> https://rackspace-api.gigaspaces.com:5000/v3'}} | subnet_1 Standard.create
> started...
> 16:14:02 | I | neutron_plugin.subnet.create | {u'args':
> OrderedDict([('cidr', u'172.16.0.0/16'), ('ip_version', 4)]),
> u'openstack_config': {'username': 'dewayne', 'tenant_name':
> 'dewayne-tenant', 'password': 'xxx', 'auth_url': '
> https://rackspace-api.gigaspaces.com:5000/v3'}} | subnet_1 Standard.create
> successful
> 16:14:02 | D | None | {} | subnet_1->router_1
> Configure.pre_configure_target has no implementation
> 16:14:02 | D | None | {} | subnet_1->router_1
> Configure.pre_configure_source has no implementation
> 16:14:03 | D | None | {} | subnet_1 Standard.configure has no
> implementation
> 16:14:04 | D | None | {} | subnet_1->router_1
> Configure.post_configure_source has no implementation
> 16:14:04 | D | None | {} | subnet_1->router_1
> Configure.post_configure_target has no implementation
> 16:14:04 | D | None | {} | subnet_1 Standard.start has no implementation
> 16:14:05 | D | None | {} | subnet_1->router_1 Configure.add_source has no
> implementation
> 16:14:07 | I | neutron_plugin.router.connect_subnet |
> {u'openstack_config':
> {'username': 'dewayne', 'tenant_name': 'dewayne-tenant', 'password':
> 'xxx', 'auth_url': 'https://rackspace-api.gigaspaces.com:5000/v3'}} |
> subnet_1->router_1 Configure.add_target started...
> 16:14:12 | I |