Hello,

1) The folder structure in git is controlled by NiFi registry, so it
is not possible to create any different structure than what you are
seeing. Think of it like an internal database, you shouldn't really
need to know/care about the structure.

2a) Starting with NiFI 1.10.0 and registry 0.5.0, the disabled state
is captured when saving a versioned flow and will remain when imported
to another environment, so this should already be working.

2b) This is already how it works, it is a manual process to start
everything in the process group after initial import.

2c) This one I would have to double check, but I would expect it to
work as you described, meaning if something was stopped in the target
env, it would remain stopped after changing version on the process
group to a newer version.

Thanks,

Bryan


On Tue, May 4, 2021 at 8:07 AM <shweta.s...@t-systems.com> wrote:
>
> Hello Team,
>
> We are using NiFi, NiFi registry and GIT integration. We are facing below 
> issues. Request you to please guide us on the below issues:
>
>
>   1.  Problem :  NiFi Registry create folder in GitLab with bucket name and 
> store all the flows inside the same bucket.
> Expectation: Create the hierarchical folder structure to store the flows.
>
> Example: NiFi flow 123 is stored inside pg ABC and ABC is child pg of XYZ. 
> This XYZ is versioned in NiFi Registry in bucket name ASD. Now in Git ASD 
> folder will have all information of XYZ,ABC,123 this is flat folder structure 
> hence this needs to be checked if it can create the following folder 
> structure: XYZ → ABC → 123
>
>
>
> Question: Is it possible to do this? create folder structure in GIT in 
> hierarchical form?
>
>
>
>
>
>
>   1.  In the NiFi deployment process using NiFi, NiFi registry for deploying 
> the flows from Dev to Test environment we need to have below things in place:
>
>
> a) If a processor is disabled in the dev environment then it must remain 
> disabled in the target cluster. (Current solution -  Via NiFi rest API check 
> the status of process groups)
> b) If a process group is deployed for the first time, the process group 
> should not be started automatically and remains stopped(Current solution -  
> Via NiFi rest API check the flow names of dev and test flows and know if the 
> flow is new flow or updated flow)
> c) A process group which is upgraded adopts the status from the target 
> cluster (stopped process group remains stopped, started process group should 
> be started) (Current solution -  Via NiFi rest API check the status of 
> process groups in target environment before the update and keep the same 
> after the update)
>
>
> Question: Any idea how can we do this apart from the above(bold highlighted) 
> mentioned solutions?
>
>
> Thanks & Regards,
> Shweta Soni | Consultant
> T-Systems ICT India Pvt. Ltd.
> A Deutsche Telekom Group Company.
> Address: 5th Floor, Panchshil Business Park,
> Tower-A, C.S. No:20, Balewadi High Street, Pune, Maharashtra, India 411045
> Mobile: +91 9767205291
> Email :  shweta.s...@t-systems.com<mailto:shweta.s...@t-systems.com>
> Website: www.t-systems.com<http://www.t-systems.com/>
>
> Life is  for Sharing
>

Reply via email to