[j-nsp] Junoscript -> Netconf

[Phil Shafer]

Richard A Steenbergen writes:
>Is there a replacement for the old junoscript load_configuration function 
>in netconf?

Netconf's <edit-config> operation is functionally equivalent to
the junoscript <load-configuration> RPC.  The contents vary
slightly, but the meat (<configuration>) is identical.

>... and I see an edit-config which lets you pass 
>incremental updates of a config in-band but only in XML format, but I 
>don't see a way to pass regular old-fashioned JUNOS config in-band.

Ah, <load-configuration> takes the "format" attribute, but
<edit-config> requires that attribute on the <configuration> element
and the text configuration (yeah, xml is text but...) to be inside a
<configuration-text> element.

    <rpc>
      <edit-config>
        <target><candidate/></target>
        <config>
          <configuration format="text">
            <configuration-text>
              system host-name foo;
            </configuration-text>
          </configuration>
        </config>
      </edit-config>
    </rpc>
    ]]>]]>

>Either I'm missing something really obvious, or else it seems like we've 
>managed to lose some very basic functionality by moving from junoscript to 
>netconf.

We haven't lost any functionality, just moved it inside the rules of
netconf.  The <config> element contains the data, as defined by the
data model, so the <configuration> element is the highest level where
we can put JUNOS-specific data.

>JunoScript APIs don't seem to have been published since 7.4 
>either, it looks like everything is moving towards Netconf... Does anyone 
>have any idea how long the Junoscript API will stay around?

I haven't watched the docs, but the Junoscript APIs haven't changed
much over time.  The docs should be released for each JUNOS release,
and I recall a move not long ago to create three distinct sections of
the documentation, one for JUNOScript, one for netconf, and one for
the JUNOS-specific data model that defines the XML content both
protocols traffic in.

The contents that the APIs manipulate are tied to the release, so
they'll grow as JUNOS grows, but the operations in the API (especially
the configuration-related operations) are stable across releases.

The same engine runs junoscript and netconf, so new netconf features
like "create" (fail the load if this element already exists in the
candidate configuration database) are supported by both protocols.

Thanks,
 Phil