Zookeeper should have separate methods for exporting xml objects used in the setup process

[sraustein]

Background discussion: {{{ (10:58:55 AM) Michael Elkins: Question of the day (so far): is it safe for me to call Zookeeper.initialize() multiple times for the same handle? I ask because I'm trying to figure out if i need to cache the identity.xml somewhere, or whether i can just call that function to get it on demand (10:59:38 AM) Rob Austein: Should be safe but have not verified (11:00:07 AM) Rob Austein: Could also break generation of identity.xml out of initialization code (11:00:21 AM) Michael Elkins: I see two cases here: (11:00:38 AM) Michael Elkins: 1) we will eventually have a bootstrap script which will likely generate the first handle (11:00:57 AM) Michael Elkins: that will create the identity.xml outside of the gui, so i need some way to obtain it in-gui (11:01:20 AM) Michael Elkins: 2) for handles i create within the gui, i either need to store the result of initialize somewhere, or be able to regenerate it (11:02:04 AM) Rob Austein: everything needed to generate identity.xml is in ResourceHolderCA. sounds like minor refactoring problem }}}

I would like to have a way to generate on-demand the various xml files used in the parent/child/repo setup process, without needed to cache the results.

Trac ticket #168 component rpkid priority minor, owner sra, created by melkins on 2012-01-19T19:13:43Z, last modified 2012-02-17T03:10:35Z

[sraustein]

Generation of identity XML broken out into separate .generate_identity() method in [4235].

Note that what .generate_identity() (and a bunch of other methods) return is an etree_wrapper() object, which is a thin wrapper around a validated etree, suitable for writing the etree to a file or rendering it as a text string. In some cases it may be easier just to stash the etree_wrapper(), but whatever works.

Trac comment by sra on 2012-01-19T22:05:02Z

[sraustein]

I probably wasn't clear enough in my description, but I will need similar methods for all of the other functions which export xml files, such as configure_{parent,child,repository,publication_client}.

On Thu, Jan 19, 2012 at 10:05:02PM -0000, Trac Ticket System wrote:

168: Zookeeper should have separate methods for exporting xml objects used in

the setup process --------------------------+-------------------- Reporter: melkins | Owner: sra Type: enhancement | Status: closed Priority: minor | Component: rpkid Resolution: fixed | Keywords: Blocked By: | Blocking: --------------------------+-------------------- Changes (by sra):

• status: new => closed
• resolution: => fixed

Comment:

Generation of identity XML broken out into separate .generate_identity() method in [4235].

Note that what .generate_identity() (and a bunch of other methods) return is an etree_wrapper() object, which is a thin wrapper around a validated etree, suitable for writing the etree to a file or rendering it as a text string. In some cases it may be easier just to stash the etree_wrapper(), but whatever works.

Ticket URL: https://trac.rpki.net/ticket/168#comment:1 RPKI project tracker https://trac.rpki.net/ Tracker for RPKI project

Trac comment by melkins on 2012-01-19T22:24:37Z

[sraustein]

I probably wasn't clear enough in my description, but I will need similar methods for all of the other functions which export xml files, such as configure_{parent,child,repository,publication_client}.

No, I didn't read the ticket carefully enough.

Creating such methods for some of the other cases is not as simple, some of them contain objects generated and signed on the fly, or only generated under certain circumstances, etc.

I can hack up something, but before we go there, are you sure that just stashing the etree_wrapper objects somewhere until you're ready to do something with them won't suffice? There may be something I'm not really understanding about your usage model.

Trac comment by sra on 2012-01-19T23:07:15Z

[sraustein]

I can hack up something, but before we go there, are you sure that just stashing the etree_wrapper objects somewhere until you're ready to do something with them won't suffice? There may be something I'm not really understanding about your usage model.

What I envision is that the user will first export the identity.xml and send it to their rpki parent.

The parent will import the identity.xml via the "Import Child" form, which will internally call Zookeeper.configure_child(). The parent.xml needs to either be stashed in the gui's db at this point for later retrieval when the user clicks on a URL, or it needs to be generated on-demand when the user goes to retrieve the response to send back to the child.

Similar story for configuration of the repository and publication client.

One potential issue is that if the xml files can't be generated on the fly, there is no easy way for rpkic and the gui to interoperate effectively, unless those xml files are stored in the irdb tables.

Trac comment by melkins on 2012-01-19T23:33:29Z

[sraustein]

In [4240]: {{{

!CommitTicketReference repository="" revision="4240"

More XML-generation methods (see #168). }}}

Trac comment by sra on 2012-01-20T02:02:57Z

[sraustein]

I think this one's done, but I thought that once before, so I've been leaving it open for Michael to confirm.

Trac comment by sra on 2012-01-21T01:23:32Z

[sraustein]

Closed with resolution fixed