The "problem" is inherited from the old SNMP CLI definition which was re-generated in XML by me and is now generated here: https://github.com/vyos/vyos-1x/blob/current/interface-definitions/snmp.xml#L230-L237.

VyOS CLI (aka vbash) will check the existance of the view once you enter the set service snmp v3 group defaultgroup view 'defaultview' command. This check could be removed to ease your proposal and the check can simply be moved down into the Python script generting the configuration.

Please retest with latest ISO

I just tested with VyOS-1.2.0-rolling+201807010337. I deleted my SNMPv3 config completely and set it again.

edit service snmp
set contact 'xy'
set description 'xy'
set listen-address 172.16.100.10
set location 'xy'
set trap-target 172.16.10.45
set v3 engineid 'id'
set v3 group nmsreadonly mode 'ro'
set v3 group nmsreadonly seclevel 'priv'
set v3 group nmsreadonly view 'all'
set v3 user nms auth encrypted-key '0xkey'
set v3 user nms auth type 'sha'
set v3 user nms engineid '0xid'
set v3 user nms group 'nmsreadonly'
set v3 user nms mode 'ro'
set v3 user nms privacy encrypted-key '0xkey'
set v3 user nms privacy type 'aes'
set v3 view all oid 1

On commit I get:

You must create view "all" first

Commit failed

Then I discarded everything and tried to set view first:

vyos@vyos-test# set v3 view all oid 1

  Set failed

Maybe this test helps something :-)

@Line2 thanks for retesting.

Actually our problem is our solution. We have a completion helper when specifing the view associated with the SNMP v3 group (https://github.com/vyos/vyos-1x/blob/current/interface-definitions/snmp.xml#L233-L235). This is actually the same behavior as in VyOS 1.1.x which results in:

$ cat /opt/vyatta/share/vyatta-cfg/templates/service/snmp/v3/group/node.tag/view/node.def
type: txt
help: Defines the name of view
allowed: /bin/cli-shell-api listNodes service snmp v3 view

Here you see that the completionHelper will indeed become a allowed: line when entering the node. Thus we can choose - have a completion helper - or no completion helper (which is more error prone as this will become a commiterror)

@dmbaturin andy thoughts on this?

I was able to copy-paste configuration on latest VyOS 1.2.0 rolling update in my configuration
I also mentioned that my current configuration has not separate set v3 engineid 'id' command as in initial comment,
and it is working without problem.

There is another issue. Encrypted password is not copied or processed well,
so I have to remove hash and set plain password for new config.
I am not sure is it a bug at all. I am going to investigate it on next tests.
We still have manual work after transfer config which should be definitely avoid.

Encrypted passwords depend on the engineID, or lets say it in other words - encrypted passwords are hashed/salted with the engine ID. Migrating the encrypted string to a different machine with a different engine ID will fail.