- move Neutron FloatingIP API from extension to feature
- introduce FloatingIpForServer as abstract domain object to represents Nova and Neutron objects
- manage floating ip cache and its invalidation
This works around a regression with InputStream payloads that I cannot
track down. Using simpleUpload instead of multipartUpload is more
optimal since the former avoids creating a multipart form request.
- fix NovaComputeServiceExpectTest
- fix NovaComputeServiceExpectTest
- fix CreateSecurityGroupIfNeededTest
- fix FindSecurityGroupInRegionOrCreateTest
- fix checkstyle
- fix removal from security group cache
- fix listSecurityGroupsForNode
- change both Nova and Neutron listSecurityGroupsForNode to use NovaApi.listSecurityGroupForServer
Refactors the Keystone Authentication and Service Catalog classes to a
common model that can be used by V2 and V3 of Keystone. Each version
will have their own Authentication APIs and Service Catalog Suppliers,
and the higher level Keystone Authentication will transparently delegate
to the right API based on the keystone-version property.
OpenStack APIs will just have to define the default keystone-version
property they work with, and declare the generic Keystone Authentication
and Service Catalog modules.
Co-authored-by: Andrea Turli <andreaturli@apache.org>
Previously with GCS and its maximum 32 parts, the slicing algorithm
would sliced 3.2 GB blobs into (31) 32 MB parts and (1) 2.3 GB part.
With this algorithm it creates (31) 100 MB parts and (1) smaller part.
MultipartUploadSlicingAlgorithm creates multiple equal-sized parts and
a remaining amount. BaseBlobStore.putMultipartBlob used this
interface incorrectly, which could create more parts than intended
since the remaining size could be larger than the part size. This
manifested with Google Cloud Storage which only allows 32 parts.
Previously this method only reported whether it created a container or
not and callers could not determine whether there was an error or if
the container already existed. References gaul/s3proxy#122.
Previously read returned a value between -128 and 127. -1 indicates
end of stream, causing issues for callers. Instead return values
between 0 and 255 as intended.
HTTP headers are case insensitive by nature (see RFC 2616). When addUserMetadataTo check if this is indeed a user metadata header, it must properly ignore case.
The fix make sure that both metadataPrefix and the header key are compared with toLowerCase().
This solves issue with minio metadata read
