Github user kevdoran commented on a diff in the pull request:
https://github.com/apache/nifi-minifi/pull/118#discussion_r175503881
--- Diff:
minifi-c2/minifi-c2-commons/src/main/java/org/apache/nifi/minifi/c2/model/AgentManifest.java
---
@@ -0,0 +1,82 @@
+/*
+ * 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
+ * http://www.apache.org/licenses/LICENSE-2.0
+ * 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;
+
+import io.swagger.annotations.ApiModel;
+import io.swagger.annotations.ApiModelProperty;
+import org.apache.nifi.minifi.c2.model.extension.Bundle;
+
+import java.util.List;
+
+@ApiModel
+public class AgentManifest {
+
+ private String identifier;
--- End diff --
No, this is a new identifier that will only be used by the C2 server. It
assumes the agent manifests are going to be persistable and reusable. It
probably would not be present when an agent manifest is being uploaded to a C2
server (e.g., in a C2 heartbeat from a MiNiFi agent or as the output of a
MiNiFi agent build that some build script uploads), but when the C2 server
persists it, it will serve as a unique ID that can be used to retrieve that
agent manifest again.
The primary use case would be when using a Flow Designer in NiFi, the user
chooses an agent class name from a list. That selection then returns one or
more agent manifests that are associated with that class name. So the way I am
picturing it the mapping of agent to agent manifest depends on context: from
the perspecitive of an agent instance, it's going to be 1-to-1 where the
manifest is always what it currently consists of. from the c2 server's
perspective, it will be 1-to-many, where it is keeping track of all manifests
for a given class name based on what has been uploaded to it.
These are still very new concepts, so if you have an input to help
formulate them that would be welcome! This is just an initial idea and I tried
to represent it the way that will support this use case. I'm sure it will
change a bit before the minifi-c2-server branch could be considered "done" and
merged to master.
---
