nifi-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <>
Subject [jira] [Commented] (MINIFI-444) MiNiFi C2 Server model for C2 Protocol and Flow Designer
Date Thu, 22 Mar 2018 03:03:00 GMT


ASF GitHub Bot commented on MINIFI-444:

Github user kevdoran commented on a diff in the pull request:
    --- Diff: minifi-c2/minifi-c2-commons/src/main/java/org/apache/nifi/minifi/c2/model/extension/
    @@ -0,0 +1,85 @@
    + * Licensed to the Apache Software Foundation (ASF) under one or more
    + * contributor license agreements.  See the NOTICE file distributed with
    + * this work for additional information regarding copyright ownership.
    + * The ASF licenses this file to You under the Apache License, Version 2.0
    + * (the "License"); you may not use this file except in compliance with
    + * the License.  You may obtain a copy of the License at
    + *
    + * Unless required by applicable law or agreed to in writing, software
    + * distributed under the License is distributed on an "AS IS" BASIS,
    + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
    + * See the License for the specific language governing permissions and
    + * limitations under the License.
    + */
    +package org.apache.nifi.minifi.c2.model.extension;
    +import io.swagger.annotations.ApiModel;
    +import io.swagger.annotations.ApiModelProperty;
    +import java.util.List;
    +import java.util.Set;
    + * A component provided by an extension bundle
    + */
    +public class ExtensionComponent extends DefinedType {
    +    // TODO, does arch/binary/compiler metadata need to be added here?
    --- End diff --
    Ok, so here is what I came up with for now:
    An extension component is uniquely identified by (bundle, type), where bundle = (group,
artifact, version) and type is a fully qualified class name. Bundle is optional in the case
that you have an extension component outside of a bundle (common in the C++ case for now),
in which case the fully qualified type must be globally unique.
    An extension component implementation is uniquely identified (bundle, type, build) where
build = (version, revision, timestamp, target architecture, compiler, compiler flags)
    In general, a flow designer should only have to target an extension component in order
to author a flow. Whether or not a flow can run on a given agent depends on if the extension
component has an available implementation on that agent.
    It's still a bit hand-wavy (at least for now), but I think this distinction should work
once we have more dynamic authoring and deployment logic that leverages a fully featured device
registry and extension registry. For now, we will focus on agent class name compatibility,
so we will have to assume that manifests for classes don't change (or at least, don't remove
capabilities) and use the intersection of all agent manifest capabilities when designing against
a an agent class label. 
    I need to flesh it out a bit more, but I think it should work. To get a sense of what
some of this looks like in code, look at the equals/hashcode methods for DefinedType and ExtensionComponent
after I push my next commit.

> MiNiFi C2 Server model for C2 Protocol and Flow Designer
> --------------------------------------------------------
>                 Key: MINIFI-444
>                 URL:
>             Project: Apache NiFi MiNiFi
>          Issue Type: New Feature
>            Reporter: Kevin Doran
>            Assignee: Kevin Doran
>            Priority: Major
> Draft a data model and rest api into the C2 server that would support the feature proposals
of a MiNiFi Agent C2 protocol [1] and a MiNiFi Flow Designer [2] 
> [1] []
> [2] [] 

This message was sent by Atlassian JIRA

View raw message