Hi All, On Thu, 2019-06-27 at 21:51 +0200, michal.lowas-rzechonek@xxxxxxxxxxx wrote: > Hi everyone, > > On 06/27, Gix, Brian wrote: > > I am starting to think we may need multiple methods here to deal with > > the desired use cases: > > I don't like this. Back in the day we discussed that we'd like to avoid > D-Bus API bloat... > > > * ImportNodeProvData() > > (...) > > The daemon method would perform a GetManagedObject of the calling > > application, to create a node.json with all of the Composition data, > > elements, models, features, etc. > > While the initial idea was indeed about importing the whole node, > including configuration, models etc., during implementation we figured > that the reason to do it is to eventually Attach() to such a node - it > doesn't make sense to import something you wouldn't use. > > If so, then you need to have an appropriate application anyway, which > the daemon can simply query for all the needed info, as it does at the > moment during Join() and CreateNetwork() calls. This nicely fits into > REQUEST_TYPE processing in get_managed_objects_cb(). > > This results in smaller API and *significantly* simpler code. As you > mentioned, doing a full migration is complicated. > > > * MigrateNode() > > This method would be what Inga and I had originally envisioned for the > > ImportLocalNode() call... It would contain *all* the information that > > a pre-existing node had... including preconfigured pub/sub, features, > > Sequence value that reflected that this node already existed elsewhere > > on the mesh, but was simply being migrated to this device, etc. > > The application can do all the configuration using loopback Config > Server messages, so I don't think we need a Migrate() call at all. The > application already receives current node configuration when > Attach()ing, so it can determine if something needs to be reconfigured. I don't see this actually working very well. Firstly, these "Loop-back" Config Server messages do not all actually work unless the node is a Provisioner, which will *not* be required of most nodes. And However, even if the App went through all of the restoration of all the settings under the control of the Provisioner via this Config Server loop-back method, there is still the critical issue of Sequence numbers. A node that is being migrated needs to pick up where it was prior to the migration, assuming that it has already had conversations with other nodes, and has entries in their Replay Protection List. If we want a single method (avoid API bloat) I don't think we have any choice but to use a well developed structure (like JSON or XML) that faithfully sets up the node in the state it was in prior to Migration. We can perhaps "Overload" this functionality by allowing a minimal JSON with only Prov Data parts, if we are looking for a Provisioning shortcut, and always requiring the ObjectManager calls fetch the Composition (if the JSON was minimal) and to Sanity check the Composition (if the JSON contains a fully developed/configured Migrated node). > > And again, you would need an Attach()able application anyway, so all the > information would need to be duplicated in application's D-Bus > interfaces and in the JSON passed to Migrate() call. This seems like a > violation of DRY principle. > > regards
