#Question about cluster Day 0 Builds once REST is the only option

1 messages · Page 1 of 1 (latest)

cloud shuttle
#

I asked in this ansible channel but was encouraged to ask here. I noticed on this issue from last year where Laurent Nicolas commented: "This is an ONTAP limitation. The REST APIs only manages data vservers and hide system resources. Root aggregates are also hidden. This is an effort to simplify and hide some of the ONTAP complexity."

https://github.com/ansible-collections/netapp.ontap/issues/120

If REST hides the "ONTAP complexity" then how can we do complex things? Right now I have Day 0 playbooks that do complex things such as building clusters, renaming root aggregates, etc.. . If this wont be viable in the future using ANSIBLE (REST) then what is the path forward? Would Ansible/REST users have push a majority of commands through say the na_ontap_rest_cli module?

GitHub
cannot rename root aggregate · Issue #120 · ansible-collections/net...

Summary When trying to rename an aggregate i get an error the aggregate is not found Component Name na_ontap_aggregate Ansible Version $ ansible --version [DEPRECATION WARNING]: Ansible will requir...

royal stone
#

There is an RFE to expose root aggregates via REST. RFE 1525372

cloud shuttle
#

thats just one piece of the puzzle. Hopefully building a cluster from Day 0 will still be possible using only rest. Can anyone confirm that is possible?

#

by day 0 I mean only the SP is configured on each node and nothing more

fair garnet
#

also this: [WARNING]: Falling back to ZAPI because of unsupported option(s) or option value(s) in REST: ['flowcontrol_admin']

fair garnet
#

Also who's silly idea is that: Not supported with REST, use ports or from_lag_ports. Why one cannot specify ifgrp name when creating ifgrp?

fair garnet
#

Also: "Specifies the maximum transmission unit (MTU) reported by the port. Not supported with REST."
Really someone decided to not include mtu option in network/ethernet/port? I mean do you teach your REST dudes basic networking at all?

dusky slate
#

im interested in this too. there is quite a few things you cannot do in REST and limitations such unable to pass in a name etc as above. we have had to change designs to overcome issues like ifgrp names and aggr names as REST creates them automattically

cloud shuttle
#

I would like to let the API team know that I build between 500-800 clusters a month without ever touching the console. It is absolutely critical that I can continue doing this when zapi is no longer supported. Right now I get the sense that wont be possible.

spring sluice
#

Kinda funny that even NetApp employees suffer from the REST API design decisions. Who needs feature parity? MVP it is... 🙄

drowsy moss
#

I'm also interested in this. I've got a lot of automation for Day 0 builds like @cloud shuttle . In some cases, falling back to ZAPI is enough, but when that goes away it will be critical that everything is exposed via REST

drowsy moss