Export locations are usually too difficult to memo
rize.Currently, there is no way to determine the
export location before the share is created, so
users wait until the share creation request gets
completed, and then they check the export
locations to mount the share. The generated
export locations are often not human readable
and it is hard to memorize and control them.
Implements: bp/human-readable-export-locations
Change-Id: I72ac7e24ddd4330d76cafd5e7f78bac2b0174883
'reserved_share_extend_percentage' backend config option allows Manila
to consider different reservation percentage for share extend
operation. With this option, under existing limit of
'reserved_share_percentage', we do not want user to create new share if
limit is hit, but allow user to extend existing share.
DocImpact
Closes-Bug: #1961087
Change-Id: I000a7f530569ff80495b1df62a91981dc5865023
This change gives the Container driver the ability to create share
servers that span multiple subnets in the same availability zone, where
previously it was only possible to do so with one subnet per
availability zone. It also enables the driver to create new subnets on
share networks that already have shares exported on them.
Some relevant changes in the driver behavior:
- container creation is now separate from its start
- containers no longer use the default Docker network; instead,
dedicated networks are created (one for each subnet)
- fetch_container_addresses now returns a list of addresses
- find_container_veth, _get_veth_state, _get_corresponding_veth were
removed
- these new methods were written:
- start_container
- fetch_container_interfaces
- create_network
- remove_network
- connect_network
- disconnect_network
- get_container_networks
- get_container_veths
- get_network_bridge
- get_veth_from_bridge
- _setup_server_network
DocImpact
Depends-On: I7de9de4ae509182e9494bba604979cce03acceec
Partially-Implements: blueprint multiple-share-network-subnets
Signed-off-by: Eduardo Santos <eduardo.experimental@gmail.com>
Change-Id: I81a616b57c95508f30d872383f5c2d68718950d7
Manila can now configure a share network with multiple subnets
in an availability zone. Also, it can add a new subnet for an
availability that has share servers, which will triger an update
share server allocations.
Changes:
- API:
- Bump version to 2.70.
- setup share network with multiple subents per az.
- Block manage server with multiple subnets.
- Allow add subnet for in-use share servers.
- `share_network_subnet_id` is dropped from ShareServer view
- `share_network_subnet_ids` is added in ShareServer view
- `network_allocation_update_support` is added to ShareServer and
ShareNetwork views.
- Add a check operation for share network subnet create.
- DB:
- Remove `share_network_subnet_id` from share_servers.
- Create mapping table `share_server_share_network_subnet_mappings`.
- Fix queries with new db design.
- Add migration downgrade and upgrade alembic.
- Add `share_network_subnet_id` to the NetworkAllocations.
- Scheduler:
- Change `AvailabilityZoneFilter` to take in account if the
host supports the allocation required by the setup request.
- Manager:
- Bump RPC API version.
- `_setup_server` allocating multiple subnets.
- Modify signature of driver `_setup_server` interface, passing a
list of `network_info` for each subnet.
- Share server DB creation to inform a list of subnets and
create with `network_allocation_update_support`.
- Implement `check_update_share_server_network_allocations` and
`update_share_server_network_allocations`.
- Drivers:
- For legacy compatibility, all drivers implementing `_setup_server`
consume the first element of the `network_ino`.
- Dummy Driver:
- Implement `_setup_server` with new signature as multiple subnet.
- Modify the `backend_details` to save allocations for all subnets.
- Report update allocation and share server multiple subnet support.
- Implement `check_update_share_server_network_allocations` and
`update_share_server_network_allocations` interfaces.
Signed-off-by: Felipe Rodrigues <felipefuty01@gmail.com>
Co-Authored-By: Andre Beltrami <debeltrami@gmail.com>
Co-Authored-By: Fábio Oliveira <fabioaurelio1269@gmail.com>
Co-Authored-By: Nahim Alves de Souza <nahimsouza@outlook.com>
Co-Authored-By: Caique Mello <caique_mellosbo@hotmail.com>
DocImpact
APIImpact
Partially-Implements: blueprint multiple-share-network-subnets
Change-Id: I7de9de4ae509182e9494bba604979cce03acceec
This config option allows different value for reservation percentage,
mostly useful on the platforms, where shares can only be created from
the snapshot on the host where snapshot was taken. The lower value of
this config option against existing (reserved_share_percentage) allows
to create shares from the snapshot on the same host up to a higher
threshold even though non-snapshot/regular share create fails.
In case this config option is not set, the shares created from snapshot
will use reservation percentage value set in 'reserved_share_percentage'.
This will be useful for users who want to keep same reservation percentage
for both non-snapshot/regular and snapshot shares.
DocImpact
Closes-Bug: #1938060
Change-Id: I390da933fe92875e3c7ee40709eacacc030278dc
This implementation adds the functionality to add/update security services
to in use share networks using the container driver. The container driver will
also try to setup security services while creating share servers. Currently, the
only supported security service type is LDAP.
Co-Authored-By: Carlos Eduardo <ces.eduardo98@gmail.com>
Partially Implements: bp add-security-service-in-use-share-networks
Depends-On: I129a794dfd2d179fa2b9a2fed050459d6f00b0de
Change-Id: Ifb8b9ebe6eb0661844c794ca1a32e35105652f72
Implements the driver interface methods for enabling a share or
a share server to be migrated. They can only work across backends
that work at same volume group.
Change-Id: I813801fd64d4d605c0a4fe06c7a130ad00865b6d
Depends-On: Ic0751027d2c3f1ef7ab0f7836baff3070a230cfd
Implements: bp container-share-server-migration
Implements: bp container-share-migration
The LVM driver accepts a "lvm_share_export_ips"
option instead of "lvm_share_export_ip" since
the Pike release [1]. Let's drop support for this
option and cleanup compatibility code.
[1] Ib3594aa5d7751c829820fce830d87f6ceea6b049
Change-Id: Ifdeb470438c204cc6cc370517833cb2cab5b7822
This patch implements managing and unmanaging of share
servers and shares functionality to the Container driver.
Depends-On: I452c2a99b186f53d737cb7fbd7eabfcfd9b249d6
Implements: bp container-driver-manage-unmanage-with-share-servers
Change-Id: I623c88dd1155740f0a444d2063236d91efd3bd1e
The container driver code needs a refactor to facilitate
the development of new functionality. This patch improves:
- Error handling: don't swallow every exception.
- Method modularization: move common code to private methods.
- Move methods to more appropriate classes: methods should live
in classes that encapsulate their responsibility. E.g: the
protocol helper should not access the container to obtain its
IP address, it should invoke a method from the container helper.
- Don't use share_id everywhere: even though the code
currently does not use the instance_id, deriving the
share name from the export location makes it easier to
support instance_id or manage/unmanage future implementations.
Change-Id: I36b1757acbacfeb48264946ff7a5299ddd3307e8
Please read spec for design detail [1].
Support IPv6 in IP drivers, networks and share
type extra specs.
Co-Authored-By: TommyLikeHu(tommylikehu@gmail.com)
Co-Authored-By: Ben Swartzlander <ben@swartzlander.org>
[1] f7202a6cfe32a057f752a4e393f848f8a0211c36
DocImpact
Partial-Implements: blueprint support-ipv6-access
Change-Id: I96d3389262e9829b8b4344870cdf5c76abd22828
In '_teardown_server' method driver was searching for all matches of
'veth' prefix and looping them for deletion. But using Xenial host
it finds each such veth name twice and tries to delete the same veth
twice too getting following error:
ovs-vsctl: no row "veth7ac5738" in table Interface
So, fix it by translating 'list' of veths to 'set' that
will have only unique names.
Change-Id: I819a885547f9fc595b15f98e4c94de21e33914ac
Closes-Bug: #1630512
Docker containers were previously started with insufficient
privileges to successfully mount a LV created on host.
This change fixes this problem.
Closes-Bug: 1613675
Change-Id: I63f3480ace3be70100a245570d7f3579b333e972
This driver exploits a Docker container as a share server instead
of a virtual machine. The container acts as a CIFS server
and shares logical volume attached to it. The volume gets created
simultaneously to the container on a host in a volume group
specified by the user.
DocImpact
Change-Id: I711813a2022d765ab7a70ed670e34f68f9cf1399
Implements: blueprint manila-container-driver
jayaanand.borra@netapp.com