Separate doorman and networkmap url in node.conf (of a Corda node)

Description

Split Doorman and Network Map into separate processes started independently, ie either one or the other, or both (one after the other) at boot time. This also includes splitting the compatibilityZoneURL config in node.conf into two.

A comment from DevOps team:

As a DevOps I want to be able to run Doorman and NetworkManager on two separate servers without any extra software in front of them.

After period of testing in Corda Connect and other environment I don't see a way to continue work with Doorman and NetworkMap in the current form. It's too complicated.

The first step to simplified it is to properly separate NetworkMap and Doorman. I know that you can run them in two separate modes, but it's just half-bake. It needs a proper separation with two separate entries on configuration and fully independent of each other.

Activity

Show:
Nigel King
May 16, 2018, 7:08 AM
Edited

Can someone please tell me if the Story points for Development is 2? If so, why are we descoping from GA - this is really important

Mike Ward
May 16, 2018, 8:34 AM
Edited

, & - don't stress - this is an exercise that should work out better for your needs. A couple of objectives:

  • We need to scope as tightly as possible what we must deliver on June 30 to Finastra. This particular feature is something that WE need, not a part of the binding commitment we have to Finastra. GA is being defined as the specific deliverables for Finastra.

  • We want to decouple Doorman / Network Map so it can iterate releases based on your needs. So the hope here is we can move quicker to satisfy the Network requirements without needlessly having a release timed to Enterprise.

will clarify further today with a view of not only what we are trying to achieve in the short term but the direction we are aiming longer term. If we have dependencies on Corda or Enterprise then let's ensure those dependencies are reflected in the GA priorities.

& FYI.

I've put this into the Corda Network Services 1.0 Epic. But can you and ensure that release meets the timing needs of our biggest customer - the Network team.

Nigel King
May 16, 2018, 10:13 AM

Thanks I think we need to discuss, because it sounds like Devops team will have to upgrade our current production environment to GA for Finastra, with all the attendant problems mentioned in this ticket. And then subsequently upgrade again to a release with Network Services 1.0. I think we will need to be precise on the risk - is it we burn devops hours on setup unnecessarily (if so, how many) and/or do we have problems operating the services in the current software setup (if so, what problems)?. Thx

Katelyn Baker
June 25, 2018, 10:10 AM

Un-tagging as "fixed in 3.2" as my cherry-pick and subsequent efforts to get that working started pulling far to much stuff back. This is going to need re-doing from scratch on the branch

Katelyn Baker
July 2, 2018, 4:15 PM

Backported to 3.2 and V3 branches

Assignee

Katelyn Baker

Reporter

Shams Asari

Sprint

None

Epic Link

None

Priority

High

Engineering Teams

None

Fix versions

Affects versions

None

Story Points / Dev Days

2

Build cut

None
Configure