Vast support - #21
Conversation
| Mapping of sharetype definitions. Key is sharetype name. Values are mappings with keys/values: | ||
| description: Optional string | ||
| is_public: Optional bool, default true | ||
| extra_specs: Required list |
| driver_handles_share_servers: Required bool | ||
| snapshot_support: Optional bool | ||
| share_backend_name: Required string | ||
| vippoolname: Required string, tofu resource vippool name |
There was a problem hiding this comment.
Every other parameter here is snake case, so I'd have thought this should be vip_pool_name?
| driver_handles_share_servers = each.value.extra_specs.driver_handles_share_servers | ||
| snapshot_support = lookup(each.value.extra_specs, "snapshot_support", null) | ||
| share_backend_name = each.value.extra_specs.share_backend_name | ||
| "vast:vippoolname" = vastdata_vip_pool.vippools[each.value.extra_specs.vippoolname].name |
There was a problem hiding this comment.
So what happens if you set up share types for non-vast shares types?
| variable "vippools" { | ||
| description = <<-EOT | ||
| Map of vippools. Key is tofu resource name. Values are mappings with keys/values: | ||
| name: Optional string, if not provided network is used to template name of format "openstack_vlan_<segmentation_id>" |
There was a problem hiding this comment.
Surely we just use the key? This just seems to make it really unclear to me, what am I missing?
There was a problem hiding this comment.
The name will be the name in VAST, both Hollie and Stig used the format of openstack_vlan_<segmentation_id> , because the network is created at the same time the segmentation_id is not known, so this ensures the vippool from that network is named in that format. But you can override that just by setting the name = "..." , I guess it would be best to ask to @oneswig or @holliefae if this is a required/preferred naming for all VAST vippools.
| } | ||
|
|
||
|
|
||
| variable "password" { |
There was a problem hiding this comment.
So this is going to end up in state, is that OK? If so it should at least be flagged in docs.
There was a problem hiding this comment.
https://opentofu.org/docs/language/state/sensitive-data/
These variables were taken from https://github.com/stackhpc/opentofu-vast-manila/blob/main/main.tf#L1 , and are needed for the provider I will make a note here and in the docs about it being stored in the state.
Looking into making these optional / grouping them into a vast variable that is optional so that tofu doesn't complain when these are defined.
| } | ||
|
|
||
|
|
||
| variable "password" { |
There was a problem hiding this comment.
I think this has to be vast_password?
| default = "10.3.2.10" | ||
| } | ||
|
|
||
| variable "username" { |
There was a problem hiding this comment.
I think this has to be vast_username?
sjpb
left a comment
There was a problem hiding this comment.
Need to document the fact it needs a custom openstack provider for share config
Need to remove the vast provider config as it needs non-optional auth info
| port = optional(number) | ||
| } | ||
| default = null | ||
| sensitve = true |
Adding support for
vastdataresources:vastdata_tenantvastdata_vip_poolAdding support for custom openstack manila resources:
openstack_sharedfilesystem_sharetype_v2openstack_sharedfilesystem_sharetype_access_v2