Re: Suggestions for Flow Development Lifestyle
I have a lot of interest in this too, as my team has run into these issues as well. I feel like there are also issues in trying to build a pull-request-like workflow, in that most NiFi design is done visually on the canvas but there isn't a good way, that I know of, to represent differences between versions in a visual way. Even if you enabled pull request-like functionality, I don't know that I would expect users to approve changes by examining diffs in the XML files. However, I did have one thing to add that I hope might help: On Tue, Feb 25, 2020 at 12:32 AM Eric Secules wrote: > I've also tried backing up my local registry to a separate branch in git > and manually merging it with the branch that central-reg backs up to, but > these git branches are glorified backups and the registry doesn't seem to > be built to pull updates from them. On top of that doing a code review on > the generated JSON describing a process group is difficult and I ran into > several merge conflicts testing out a very simple merge where the target > branch diverged slightly from the feature branch. > >From what I've seen, the registry will use any updates that are in the repo when it starts up. So you should be able to do something like this: 1. Make the registry pull (or clone) from the backup as part of its startup process 2. Restart the registry when a merge to master is made. AFAIK this should not affect any NiFi instances that are connected to the registry; they should continue to work once the registry comes back up It's a bit clunky but I think it works. -Ken
Re: NiFi Registry web documentation broken on Linux for Chrome and Firefox...
Russell, are you talking about https://nifi.apache.org/docs/nifi-registry-docs/index.html ? (FWIW, no problem for that link on MacOS Firefox) -Ken On Wed, Dec 11, 2019 at 12:26 PM Russell Bateman wrote: > Not long upon beginning to read this document, it becomes impossible to > scroll it. Sometimes, backing up to the first page and clicking on a > hyperlink (Starting NiFi Registry, I Started NiFi Registry. Now What?, > etc.) lands you where you want to read and you can scroll, but this is > usually short-lived. The scroll bar elevator is always the same height as > the scroll bar, as if your window height is also the total content > available. Even when you land somewhere and are able to scroll, this > ability will disappear after a little while. > > Or, I'm a monkey's uncle. It could be. Maybe my environment? > > $ uname -a > Linux nargothrond 4.15.0-66-generic #75-Ubuntu SMP Tue Oct 1 05:24:09 UTC > 2019 x86_64 x86_64 x86_64 GNU/Linux > $ cat /etc/os-release > NAME="Linux Mint" > VERSION="19 (Tara)" > ... > VERSION_CODENAME=tara > UBUNTU_CODENAME=bionic > > Google Chrome: 73.0.3683.103 64-bit > Firefox: 70.0.164-bit > > I don't have a perfect handle on the exact behavior, but it is very hard > to read straight through the document. I thought I'd ask if anyone else has > trouble. > > Russ >
Curious about Best Practices for Deployment of Workflows
Hi all, My group is getting started with NiFi and I'm hoping to draw on people's experience. I was curious if there were any best practices for NiFi when deploying workflows. When I deploy new code to production, there's often pull requests, code review, and then CI/CD to actually put it in production. Is there anything similar for workflows, or do people have solutions that they use? I'd love it if there was a way for someone to make a local change to a workflow/process group, push that up to the registry, and then a reviewer see a diff of the change, approve it, and then it get automatically put onto master. Is this something people tend to do with NiFi? -Ken
