Giter Site home page Giter Site logo

fog-aliyun's Introduction

Fog::Aliyun

Installation

Add this line to your application's Gemfile:

gem 'fog-aliyun'

And then execute:

    $ bundle

Or install it yourself as:

    $ gem install fog-aliyun

Usage

Before you can use fog-aliyun, you must require it in your application:

require 'fog/aliyun'

Since it's a bad practice to have your credentials in source code, you should load them from default fog configuration file: ~/.fog. This file could look like this:

default:
  aliyun_accesskey_id:     "<YOUR_ACCESS_KEY_ID>"
  aliyun_accesskey_secret: "<YOUR_SECRET_ACCESS_KEY>"
  aliyun_region_id:        "<YOUR_TARGET_REGION>"

Connecting to OSS

conn = Fog::Storage[:aliyun]

If you haven't modified your default fog configuration file or you don't want to use it, you can load your credentials by this way:

opt = {
  :provider                => 'aliyun',
  :aliyun_accesskey_id     => <YOUR_ACCESS_KEY_ID>,
  :aliyun_accesskey_secret => <YOUR_SECRET_ACCESS_KEY>,
  :aliyun_oss_bucket       => <YOUR_OSS_BUCKET>,
  :aliyun_region_id        => <YOUR_TARGET_REGION>,
  :aliyun_oss_endpoint     => <YOUR_OSS_ENDPOINT>,
}
conn = Fog::Storage.new(opt)

-> Note: :aliyun_region_id is optional and default to "cn-hangzhou".

-> Note: :aliyun_oss_endpoint is optional. If it is not specified, it will be generated automatically by :aliyun_region_id. Its basic format is oss-<region-id>.aliyuncs.com and with default schema "http" and default port "80". If you want to use https or 443 port, you can use a format <schema>://oss-<region-id>.aliyuncs.com:<port>.

Fog::Aliyun Abstractions

Fog::Aliyun provides both a model and request abstraction. The request abstraction provides the most efficient interface and the model abstraction wraps the request abstraction to provide a convenient ActiveModel like interface.

Request Layer

The Fog::Storage object supports a number of methods that wrap individual HTTP requests to the OSS API.

To see a list of requests supported by the storage service:

conn.requests

This returns:

[[nil, :copy_object], [nil, :delete_bucket], [nil, :delete_object], [nil, :get_bucket], [nil, :get_object], [nil, :get_object_http_url], [nil, :get_object_https_url], [nil, :head_object], [nil, :put_bucket], [nil, :put_object], [nil, :list_buckets], [nil, :list_objects], [nil, :get_containers], [nil, :get_container], [nil, :delete_container], [nil, :put_container]]

Example Requests(list_buckets)

To request all of buckets:

conn.list_buckets

And this returns like the flowing;

[{"Location"=>"oss-cn-beijing", "Name"=>"dt1", "CreationDate"=>"2015-07-30T08:38:02.000Z"},  {"Location"=>"oss-cn-shenzhen", "Name"=>"ruby1", "CreationDate"=>"2015-07-30T02:22:34.000Z"}, {"Location"=>"oss-cn-qingdao", "Name"=>"yuanhang123", "CreationDate"=>"2015-05-18T03:06:31.000Z"}]

You can also request in this way;

conn.list_buckets(:prefix=>"pre")

Here is a summary of the optional parameters:

Parameters Description
:prefix The bucket name of the results must start with 'prefix'.It won't filter prefix information if not set
Data Types: String
Defaults:none
:marker The result will start from the marker alphabetically.It wil start from the first if not set.
Data Types: String
Defaults: none
:maxKeys Set the max number of the results. It will set to 100 if not set. The max value of maxKeys is 1000.
Data Types: String
Defaults: 100

To learn more about Fog::Aliyun request methods, you can refer to our source code. To learn more about OSS API, refer to AliYun OSS API.

Model Layer

Fog models behave in a manner similar to ActiveModel. Models will generally respond to create, save, destroy, reload and attributes methods. Additionally, fog will automatically create attribute accessors.

Here is a summary of common model methods:

Method Description
create Accepts hash of attributes and creates object.
Note: creation is a non-blocking call and you will be required to wait for a valid state before using resulting object.
save Saves object.
Note: not all objects support updating object.
destroy Destroys object.
Note: this is a non-blocking call and object deletion might not be instantaneous.
reload Updates object with latest state from service.
attributes Returns a hash containing the list of model attributes and values.
identity Returns the identity of the object.
Note: This might not always be equal to object.id.

The remainder of this document details the model abstraction.

Note: Fog sometimes refers to OSS containers as directories.

List Directories

To retrieve a list of directories:

dirs = conn.directories

This returns a collection of Fog::Storage::Aliyun::Directory models:

Get Directory

To retrieve a specific directory:

dir = dirs.get "dir"

This returns a Fog::Storage::Aliyun::Directory instance:

Create Directory

To create a directory:

dirs.create :key => 'backups'

Delete Directory

To delete a directory:

directory.destroy

Note: Directory must be empty before it can be deleted.

Directory URL

To get a directory's URL:

directory.public_url

List Files

To list files in a directory:

directory.files

Note: File contents is not downloaded until body attribute is called.

Upload Files

To upload a file into a directory:

file = directory.files.create :key => 'space.jpg', :body => File.open "space.jpg"

Note: For files larger than 5 GB please refer to the Upload Large Files section.

Upload Large Files

OSS requires files larger than 5 GB (the OSS default limit) to be uploaded into segments along with an accompanying manifest file. All of the segments must be uploaded to the same container.

Segmented files are downloaded like ordinary files. See Download Files section for more information.

Download Files

The most efficient way to download files from a private or public directory is as follows:

File.open('downloaded-file.jpg', 'w') do | f |
  directory.files.get("my_big_file.jpg") do | data, remaining, content_length |
    f.syswrite data
  end
end

This will download and save the file.

Note: The body attribute of file will be empty if a file has been downloaded using this method.

If a file object has already been loaded into memory, you can save it as follows:

File.open('germany.jpg', 'w') {|f| f.write(file_object.body) }

Note: This method is more memory intensive as the entire object is loaded into memory before saving the file as in the example above.

File URL

To get a file's URL:

file.public_url

Copy File

Cloud Files supports copying files. To copy files into a container named "trip" with a name of "europe.jpg" do the following:

file.copy("trip", "europe.jpg")

To move or rename a file, perform a copy operation and then delete the old file:

file.copy("trip", "germany.jpg")
file.destroy

Delete File

To delete a file:

file.destroy

Development

After checking out the repo, run bin/setup to install dependencies. Then, run rake spec to run the tests. You can also run bin/console for an interactive prompt that will allow you to experiment.

To install this gem onto your local machine, run bundle exec rake install. To release a new version, update the version number in version.rb, and then run bundle exec rake release, which will create a git tag for the version, push git commits and tags, and push the .gem file to rubygems.org.

Testing

To run test suite use the following command:

rake spec

Code coverage

To run test suite with code coverage:

export COVERAGE=true
rake spec

The result will be generated in coverage folder.

Integration tests

To run integration tests please prepare a set of AliCloud credentials to be used by integration tests.

Define the credentials and bucket in ~/.fog file in using following format:

default:
  aliyun_accesskey_id:     "...access key..." # You can create a set of credentials  
  aliyun_accesskey_secret: "...secret..." # using Alicloud console portal
  aliyun_region_id:        "...region name..." # Example: cn-shanghai
  aliyun_oss_bucket:       "...name of the bucket..." # Example: fog-integration-test-bucket

WARNING: Do NOT use any productive account credentials and buckets for the testing, it may be harmful to your data!

The tests are using [https://github.com/aliyun/aliyun-cli#installation](Aliyun CLI) to setup integration bucket and content for tests, please install it locally before running integration tests.

Aliyun CLI will be configured automatically as part of test execution using the credentials provided for fog connection.

Then run the test suite with INTEGRATION environment variable to activate integration tests:

export INTEGRATION=true
rake spec

Performance test

Performance tests are providing memory consumption report for download/upload operations.

export PERFORMANCE=true
rake spec

Publish a new release

  1. Update the next version in the file lib/fog/aliyun/version
  2. Update the CHANGELOG.md
  3. Build the next release by running command
    gem build fog-aliyun.gemspec 
  4. Push the next release to the https://rubygems.org/
    gem push fog-aliyun-<version>.gem 

License

The gem is available as open source under the terms of the MIT License.

fog-aliyun's People

Contributors

chushenmeshile avatar dengqinsi avatar digitallyborn avatar geemus avatar janehyt avatar joy-n-craft avatar kgaikwad avatar lijianxun avatar philippthun avatar plribeiro3000 avatar tokengeek avatar upadhyeammit avatar xiaozhu36 avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

fog-aliyun's Issues

Timeouts if internal URLs needs to be used

Hi,

we are currently using the fog-aliyun gem to store/get data from OSS. Unfortunately, it seems like the gem only supports internal endpoint URLs for the multipart upload part, as it is possible to provide the endpoint as an argument there (

def initiate_multipart_upload(bucket, object, endpoint)
). For nearly all other calls the endpoint urls gets generated (e.g.:
endpoint = 'http://' + location + '.aliyuncs.com'
) which leads to the point that a non internal URL gets generated and used. This leads to timeouts if the VMs are not allowed to connect to the Internet.

Maybe the code could be adjusted to handle the endpoint generation like it is done in the multipart upload code.

Thanks for your help.

Incomplete error status code handling

Hi,

The 404 check in

return nil if data[:status] == 404
is not sufficient, as it doesn't handle any other error status (like 403 or 500).

This code should be updated to introduce better error status handling.
In addition, it makes sense to introduce status check guard logic also to other places where the interaction with OSS API is made.
For example, it can make sense to additionally handle the errors in these functions:
https://github.com/fog/fog-aliyun/blob/master/lib/fog/aliyun/models/storage/files.rb#L18
https://github.com/fog/fog-aliyun/blob/master/lib/fog/aliyun/models/storage/files.rb#L60

Thanks

Failed to get server collection using Fog::Compute::Aliyun::Servers

I am using below gem versions:

fog-aliyun (0.3.2)
fog-core (2.1.2)
fog-json (1.2.0)

compute_instance.images returns Fog::Compute::Aliyun::Images which contains list of objects of type Fog::Compute::Aliyun::Image.

Similarly, if I try for compute_instance.servers, it is returning Fog::Compute::Aliyun::Servers with empty list no any server instance inside.

<Fog::Compute::Aliyun::Servers [ ] >

Note - I have created one instance.

When I call .all method on compute_instance.servers it returns list of hash which includes details of that created instance. In short .list_servers method gives a list of created instances.

Is this expected behavior?

The create_disk method of compute model fails with IncompeteSignature

Here is the error, the same accesskey,secretkey works for other calls like list images, list servers even it works with OSS,

Excon::Error::BadRequest (Expected([200, 203]) <=> Actual(400 Bad Request))
excon.error.response
  :body          => "{\"Recommend\":\"https://error-center.aliyun.com/status/search?Keyword=IncompleteSignature&source=PopGw\",\"Message\":\"The request signature does not conform to Aliyun standards. server string to sign is: ****

,\"RequestId\":\"886024CB-30A3-4945-AC3D-D52F706B65A0\",\"HostId\":\"ecs.aliyuncs.com\",\"Code\":\"IncompleteSignature\"}"
  :cookies       => [
  ]
  :headers       => {
    "Access-Control-Allow-Headers" => "X-Requested-With, X-Sequence, _aop_secret, _aop_signature"
    "Access-Control-Allow-Methods" => "POST, GET, OPTIONS"
    "Access-Control-Allow-Origin"  => "*"
    "Access-Control-Max-Age"       => "172800"
    "Connection"                   => "close"
    "Content-Length"               => "647"
    "Content-Type"                 => "application/json; charset=UTF-8"
    "Date"                         => "Mon, 11 Feb 2019 10:17:04 GMT"
    "Server"                       => "Jetty(7.2.2.v20101205)"
  }
  :host          => "ecs.aliyuncs.com"
  :local_address => "****"
  :local_port    => 56738
  :path          => "****"
  :port          => 443
  :reason_phrase => "Bad Request"
  :remote_ip     => "****"
  :status        => 400
  :status_line   => "HTTP/1.1 400 Bad Request\r\n"

Not support aliyun oss internal model

rake aborted!
Excon::Error::Forbidden: Expected(200) <=> Actual(403 Forbidden)
excon.error.response
  :body          => "<?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<Error>\n  <Code>AccessDenied</Code>\n  <Message>The bucket you access does not belong to you.</Message>\n  <RequestId>5D008E974B39ED0046A010FE</RequestId>\n  <HostId>xxxgitbackup.oss-cn-hangzhou.aliyuncs.com:80</HostId>\n</Error>\n"
  :cookies       => [
  ]
  :headers       => {
    "Connection"        => "keep-alive"
    "Content-Length"    => "265"
    "Content-Type"      => "application/xml"
    "Date"              => "Wed, 12 Jun 2019 05:33:11 GMT"
    "Server"            => "AliyunOSS"
    "x-oss-request-id"  => "5D008E974B39ED0046A010XX"
    "x-oss-server-time" => "33"
  }
  :host          => "xxxgitbackup.oss-cn-hangzhou.aliyuncs.com"
  :local_address => "172.18.2.xx"
  :local_port    => 36126
  :path          => "/?uploads"
  :port          => 80
  :reason_phrase => "Forbidden"
  :remote_ip     => "47.110.178.xx"
  :status        => 403
  :status_line   => "HTTP/1.1 403 Forbidden\r\n"
/opt/gitlab/embedded/lib/ruby/gems/2.5.0/gems/excon-0.62.0/lib/excon/middlewares/expects.rb:7:in `response_call'
/opt/gitlab/embedded/lib/ruby/gems/2.5.0/gems/excon-0.62.0/lib/excon/middlewares/response_parser.rb:9:in `response_call'
/opt/gitlab/embedded/lib/ruby/gems/2.5.0/gems/excon-0.62.0/lib/excon/connection.rb:414:in `response'
/opt/gitlab/embedded/lib/ruby/gems/2.5.0/gems/excon-0.62.0/lib/excon/connection.rb:263:in `request'
/opt/gitlab/embedded/lib/ruby/gems/2.5.0/gems/fog-core-2.1.0/lib/fog/core/connection.rb:81:in `request'
/opt/gitlab/embedded/lib/ruby/gems/2.5.0/gems/fog-aliyun-0.3.3/lib/fog/aliyun/storage.rb:150:in `request'
/opt/gitlab/embedded/lib/ruby/gems/2.5.0/gems/fog-aliyun-0.3.3/lib/fog/aliyun/requests/storage/list_objects.rb:54:in `list_multipart_uploads'
/opt/gitlab/embedded/lib/ruby/gems/2.5.0/gems/fog-aliyun-0.3.3/lib/fog/aliyun/requests/storage/put_object.rb:76:in `put_multipart_object'
/opt/gitlab/embedded/lib/ruby/gems/2.5.0/gems/fog-aliyun-0.3.3/lib/fog/aliyun/requests/storage/put_object.rb:20:in `put_object'
/opt/gitlab/embedded/lib/ruby/gems/2.5.0/gems/fog-aliyun-0.3.3/lib/fog/aliyun/models/storage/file.rb:119:in `save'
/opt/gitlab/embedded/lib/ruby/gems/2.5.0/gems/fog-core-2.1.0/lib/fog/core/collection.rb:50:in `create'

Publish new version

Important fixes like #10 never make the way into a proper release at the moment. This is causing problems in downstream consumers, such as GitLab which recently added Aliyun support for backups.

As the library is basically untouched for over 1 yr, a 0.2.0 or even 1.0.0 release really should be done.

Document need more detail

Since the document in Aliyun didn't define the * aliyun_oss_endpoint* , * aliyun_oss_location* and * aliyun_oss_bucket* like this gem does.

It took me sometime to figure it out. Give an example might help more people like me.

aliyun:
    provider:                aliyun
    aliyun_accesskey_id:     <YOUR KEY>
    aliyun_accesskey_secret: <YOUR SECRET>
    aliyun_oss_endpoint:     http://oss-cn-beijing.aliyuncs.com
    aliyun_oss_location:     oss-cn-beijing
    aliyun_oss_bucket:       mybucket 

Especially:

  1. aliyun_oss_endpoint MUST contain "http://" and MUST NOT contain bucket name. Aliyun defines my endpoint as mybucket.oss-cn-beijing.aliyuncs.com instead of http://oss-cn-beijing.aliyuncs.com
  2. aliyun_oss_location can be found in the part from your endpoint.

Deprecation warnings

Hi,

When I run integration test, I see the following message in the console:

[fog][DEPRECATION] Unable to load Fog::Aliyun::Storage
[fog][DEPRECATION] Falling back to deprecated constant Fog::Storage::Aliyun. The preferred format of service provider constants has changed from service::provider to provider::service. Please update this service provider to use the preferred format.

Please upgrade deprecated code.

Thanks

[aliyun_oss_endpoint] when the parameter points to the VPC internal network address, Ali Cloud ECS traffic will still go to the public network

Hi.
我在阿里云的ecs服务器上部署了gitlab,并设置了如下参数:

gitlab_rails['backup_upload_connection'] = {
'provider' => 'aliyun',
'aliyun_accesskey_id' => '******',
'aliyun_accesskey_secret' => ''******',',
'aliyun_oss_bucket' => ''******',',
'aliyun_region_id' => 'cn-zhangjiakou',
'aliyun_oss_endpoint' => 'http://oss-cn-zhangjiakou-internal.aliyuncs.com'
}

于此同时,我在 linux 的 crontab 设置了计划任务,它每天00:00执行备份计划
docker exec -t gitlab gitlab-backup create
此时,此时我发现每天执行备份计划的时候,备份文件上传到 oss 的时候走的是公网流量,而不是 endpoint 指定的内网。
我的ECS服务器和OSS均位于cn-zhangjiakou


Hi.
I deployed GitLab on the ECS server of Ali Cloud and set the following parameters:

gitlab_rails['backup_upload_connection'] = {
'provider' => 'aliyun',
'aliyun_accesskey_id' => '******',
'aliyun_accesskey_secret' => ''******',',
'aliyun_oss_bucket' => ''******',',
'aliyun_region_id' => 'cn-zhangjiakou',
'aliyun_oss_endpoint' => 'http://oss-cn-zhangjiakou-internal.aliyuncs.com'
}

At the same time, I set up the scheduling task in the Linux crontab, which executes the backup plan at 00:00 every day
docker exec -t gitlab gitlab-backup create
At this point, I noticed that when I was doing a daily backup plan, I was uploading the backup files to OSS using public network traffic instead of the endpoint specified Intranet.
My ECS server and OSS are both located at cn-zhangjiakou

Enhance tests

Motivation

This document proposes enhancements to be done for integration/unit tests to increase fog-aliyun library code coverage and improve stability as far as more integration tests will run on automatic/nightly basis.

Area to be covered

Currently, the primary targets of this document is to provide tests scenarios for storage and OSS buckets api area, as it's critical for CloudFoundry operations.

Test environments

General recommendation is to run this test on automatic (when a new PR or commit enter into the repository) and on nightly basis to catch issues if some changes be at AliCloud OSS api level.

As regions available in China and Worldwide may differ from each other, it recommended to run integration test in China region (Shanghai) and in Europe (Frankfurt) to verify that the library behave equally regardless of region.

Extra options for test environments:

  • Run tests with internal endpoint
Region Public Endpoint Private Endpoint
Shanghai
Frankfurt

Priority: HIGH

Test scenarios

Auth & Connectivity scenarios

  1. Test that API can be accessed using valid credentials:
    • The goal of this test is to verify that connection to api is possible using valid credentials.
    • Expected result: OSS API should be accessible
    • Priority: High
  2. (NEGATIVE TEST) Test that API cannot be accessed using incorrect credentials:
    • The goal of this test is to get error if connection to api is not possible due to invalid credentials.
    • Expected result: An error should be thrown with details.
    • Priority: Low
  3. Test that API can be accessed if time zone is correct (valid signature computation)
    • The goal of this test is to validate that signature generated for requests is valid and acceptable by API.
    • Expected result: OSS API should be accessible
    • Priority: Low
  4. (NEGATIVE TEST) Test that API can be accessed if time zone is NOT correct (invalid signature computation)
    • The goal of this test is to provide error details if signature wrongly generated (for example if timezone incorrect)
    • Expected result: An error should be throw with details.
    • Priority: Low
  5. Test region is selected according to provider configuration
    • The goal of this test is to ensure that region provided in configuration is really used for connection.
    • Expected results: The requests should point to the provided region
    • Extra scenario: check default region is used if no region provided explicitly.
    • Priority: High

Entity operations

  1. Add tests for each type of entity that validates the following operations:
Method Description Priority
create Accepts hash of attributes and creates object.Note: creation is a non-blocking call and you will be required to wait for a valid state before using resulting object. High
save Saves object.Note: not all objects support updating object. High
destroy Destroys object.Note: this is a non-blocking call and object deletion might not be instantaneous. High
reload Updates object with latest state from service. Medium
attributes Returns a hash containing the list of model attributes and values. Medium
identity Returns the identity of the object.Note: This might not always be equal to object.id. Low

Buckets scenarios

  1. Test that it is possible to get single bucket
    • Get listing of single bucket
    • Expected result: Bucket should be found
    • Priority: Low
  2. Test that it is possible to list all buckets
    • Get listing of all buckets
    • Expected result: Buckets should be found
    • Extra scenarios: List buckets using prefix, marker and maxKeys options.
    • Priority: Low
  3. Test that it is possible to create a new bucket.
    • Create new bucket using api
    • Expected result: Bucket should be created
    • Priority: Low
  4. Test that it is possible to destroy a bucket.
    • Destroy bucket using api
    • Expected result: Bucket should be deleted
    • Priority: Low
  5. (NEGATIVE TEST) Test that error is thrown when trying to create already existing bucket
    • Create a new bucket using the same name as the already existing one.
    • Expected result: On save it should throw exception.
    • Priority: Low
  6. (NEGATIVE TEST) Test that error is thrown when trying to access non-existing bucket
    • Ask for non-existing bucket should fail with error.
    • Expected result: Not found error
    • Priority: Low
  7. (NEGATIVE TEST) Test that error is thrown when trying to destroy non-existing bucket
    • Destroy for non-existing bucket should fail with error.
    • Expected result: Not found error
    • Priority: Low
  8. (NEGATIVE TEST) Test that error is thrown when trying to access protected bucket from other account.
    • Ask for protected bucket should fail with error.
    • Expected result: Not found error / Access error?
    • Priority: Low

Files & Directory scenarios

  1. Test get nested directories and files in nested directory
    • The goal of this test is to validate that files and directories can be queried if structure is nested.
    • Expected result: Nested list should be possible.
    • Priority: Medium
  2. Test that it is possible to upload (write) a file
    • The goal of this test is to validate that file is persisted correctly
    • Expected result: The file is created and the content equal to the uploaded file
    • Priority: High
  3. Test that it is possible to upload (write) large file (multi part upload)
    • The goal of this test is to validate that file is persisted correctly
    • Expected result: The file is created and the content equal to the uploaded file
    • Priority: High
  4. Test that it is possible to get file details like public_url
    • The goal of this test is to test attributes of files
    • Expected result: The attribute should match to the expected value
    • Priority: Low
  5. Test that it is possible to destroy a file/directory
    • The goal of this test is to check destroy functionality
    • Expected result: Should destroy the file/directory
    • Extra scenario: Destroy of non-empty directory should fail
    • Priority: High
  6. Test file/directory listing using parameters such as prefix, marker, delimeter and etc...
    • The goal of this test is to check that response returned according to the provided parameters.
    • Expected result: Response should meet expectations
    • Priority: High
  7. Test file copy operations
    • The goal of this test is to verify file copy operations.
    • Expected result: The copy of file should match to the original file
    • Priority: Low
  8. Test getting bucket when directory exists named with the same name as a bucket.
    • The goal of this test is to check that fog receives a reference to directory and not to the bucket if
      directory name matches to the bucket name.
    • Expected result: The api should provide reference to the bucket (like in AWS).
    • Priotity: Low

Exconn warnings

Hi, when I run integration tests with export EXCON_DEBUG=true I get the following warnings from excon library (responsible for requests):

[excon][WARNING] Invalid Excon request keys: :resource, :endpoint, :location, :bucket
/Library/Ruby/Gems/2.6.0/gems/excon-0.73.0/lib/excon/connection.rb:433:in `validate_params'
/Library/Ruby/Gems/2.6.0/gems/excon-0.73.0/lib/excon/connection.rb:235:in `request'
/Library/Ruby/Gems/2.6.0/gems/fog-core-2.2.0/lib/fog/core/connection.rb:79:in `request'
/Users/i068165/Work/fog/xjfog/lib/fog/aliyun/storage.rb:153:in `request'
/Users/i068165/Work/fog/xjfog/lib/fog/aliyun/requests/storage/get_containers.rb:50:in `get_containers'
/Users/i068165/Work/fog/xjfog/lib/fog/aliyun/models/storage/directories.rb:13:in `all'
/Users/i068165/Work/fog/xjfog/spec/fog/integration_spec.rb:23:in `block (2 levels) in <top (required)>'
/Library/Ruby/Gems/2.6.0/gems/rspec-core-3.9.2/lib/rspec/core/example.rb:257:in `instance_exec'
/Library/Ruby/Gems/2.6.0/gems/rspec-core-3.9.2/lib/rspec/core/example.rb:257:in `block in run'
/Library/Ruby/Gems/2.6.0/gems/rspec-core-3.9.2/lib/rspec/core/example.rb:503:in `block in with_around_and_singleton_context_hooks'
/Library/Ruby/Gems/2.6.0/gems/rspec-core-3.9.2/lib/rspec/core/example.rb:460:in `block in with_around_example_hooks'
/Library/Ruby/Gems/2.6.0/gems/rspec-core-3.9.2/lib/rspec/core/hooks.rb:481:in `block in run'
/Library/Ruby/Gems/2.6.0/gems/rspec-core-3.9.2/lib/rspec/core/hooks.rb:619:in `run_around_example_hooks_for'
/Library/Ruby/Gems/2.6.0/gems/rspec-core-3.9.2/lib/rspec/core/hooks.rb:481:in `run'
/Library/Ruby/Gems/2.6.0/gems/rspec-core-3.9.2/lib/rspec/core/example.rb:460:in `with_around_example_hooks'
/Library/Ruby/Gems/2.6.0/gems/rspec-core-3.9.2/lib/rspec/core/example.rb:503:in `with_around_and_singleton_context_hooks'
/Library/Ruby/Gems/2.6.0/gems/rspec-core-3.9.2/lib/rspec/core/example.rb:254:in `run'
/Library/Ruby/Gems/2.6.0/gems/rspec-core-3.9.2/lib/rspec/core/example_group.rb:644:in `block in run_examples'
/Library/Ruby/Gems/2.6.0/gems/rspec-core-3.9.2/lib/rspec/core/example_group.rb:640:in `map'
/Library/Ruby/Gems/2.6.0/gems/rspec-core-3.9.2/lib/rspec/core/example_group.rb:640:in `run_examples'
/Library/Ruby/Gems/2.6.0/gems/rspec-core-3.9.2/lib/rspec/core/example_group.rb:606:in `run'
/Library/Ruby/Gems/2.6.0/gems/rspec-core-3.9.2/lib/rspec/core/runner.rb:121:in `block (3 levels) in run_specs'
/Library/Ruby/Gems/2.6.0/gems/rspec-core-3.9.2/lib/rspec/core/runner.rb:121:in `map'
/Library/Ruby/Gems/2.6.0/gems/rspec-core-3.9.2/lib/rspec/core/runner.rb:121:in `block (2 levels) in run_specs'
/Library/Ruby/Gems/2.6.0/gems/rspec-core-3.9.2/lib/rspec/core/configuration.rb:2058:in `with_suite_hooks'
/Library/Ruby/Gems/2.6.0/gems/rspec-core-3.9.2/lib/rspec/core/runner.rb:116:in `block in run_specs'
/Library/Ruby/Gems/2.6.0/gems/rspec-core-3.9.2/lib/rspec/core/reporter.rb:74:in `report'
/Library/Ruby/Gems/2.6.0/gems/rspec-core-3.9.2/lib/rspec/core/runner.rb:115:in `run_specs'
/Library/Ruby/Gems/2.6.0/gems/rspec-core-3.9.2/lib/rspec/core/runner.rb:89:in `run'
/Library/Ruby/Gems/2.6.0/gems/rspec-core-3.9.2/lib/rspec/core/runner.rb:71:in `run'
/Library/Ruby/Gems/2.6.0/gems/rspec-core-3.9.2/lib/rspec/core/runner.rb:45:in `invoke'
/Library/Ruby/Gems/2.6.0/gems/rspec-core-3.9.2/exe/rspec:4:in `<main>'
[excon][WARNING] The following request keys are only valid with the associated middleware:
/Library/Ruby/Gems/2.6.0/gems/excon-0.73.0/lib/excon/connection.rb:440:in `validate_params'
/Library/Ruby/Gems/2.6.0/gems/excon-0.73.0/lib/excon/connection.rb:235:in `request'
/Library/Ruby/Gems/2.6.0/gems/fog-core-2.2.0/lib/fog/core/connection.rb:79:in `request'
/Users/i068165/Work/fog/xjfog/lib/fog/aliyun/storage.rb:153:in `request'
/Users/i068165/Work/fog/xjfog/lib/fog/aliyun/requests/storage/get_containers.rb:50:in `get_containers'
/Users/i068165/Work/fog/xjfog/lib/fog/aliyun/models/storage/directories.rb:13:in `all'
/Users/i068165/Work/fog/xjfog/spec/fog/integration_spec.rb:23:in `block (2 levels) in <top (required)>'
/Library/Ruby/Gems/2.6.0/gems/rspec-core-3.9.2/lib/rspec/core/example.rb:257:in `instance_exec'
/Library/Ruby/Gems/2.6.0/gems/rspec-core-3.9.2/lib/rspec/core/example.rb:257:in `block in run'
/Library/Ruby/Gems/2.6.0/gems/rspec-core-3.9.2/lib/rspec/core/example.rb:503:in `block in with_around_and_singleton_context_hooks'
/Library/Ruby/Gems/2.6.0/gems/rspec-core-3.9.2/lib/rspec/core/example.rb:460:in `block in with_around_example_hooks'
/Library/Ruby/Gems/2.6.0/gems/rspec-core-3.9.2/lib/rspec/core/hooks.rb:481:in `block in run'
/Library/Ruby/Gems/2.6.0/gems/rspec-core-3.9.2/lib/rspec/core/hooks.rb:619:in `run_around_example_hooks_for'
/Library/Ruby/Gems/2.6.0/gems/rspec-core-3.9.2/lib/rspec/core/hooks.rb:481:in `run'
/Library/Ruby/Gems/2.6.0/gems/rspec-core-3.9.2/lib/rspec/core/example.rb:460:in `with_around_example_hooks'
/Library/Ruby/Gems/2.6.0/gems/rspec-core-3.9.2/lib/rspec/core/example.rb:503:in `with_around_and_singleton_context_hooks'
/Library/Ruby/Gems/2.6.0/gems/rspec-core-3.9.2/lib/rspec/core/example.rb:254:in `run'
/Library/Ruby/Gems/2.6.0/gems/rspec-core-3.9.2/lib/rspec/core/example_group.rb:644:in `block in run_examples'
/Library/Ruby/Gems/2.6.0/gems/rspec-core-3.9.2/lib/rspec/core/example_group.rb:640:in `map'
/Library/Ruby/Gems/2.6.0/gems/rspec-core-3.9.2/lib/rspec/core/example_group.rb:640:in `run_examples'
/Library/Ruby/Gems/2.6.0/gems/rspec-core-3.9.2/lib/rspec/core/example_group.rb:606:in `run'
/Library/Ruby/Gems/2.6.0/gems/rspec-core-3.9.2/lib/rspec/core/runner.rb:121:in `block (3 levels) in run_specs'
/Library/Ruby/Gems/2.6.0/gems/rspec-core-3.9.2/lib/rspec/core/runner.rb:121:in `map'
/Library/Ruby/Gems/2.6.0/gems/rspec-core-3.9.2/lib/rspec/core/runner.rb:121:in `block (2 levels) in run_specs'
/Library/Ruby/Gems/2.6.0/gems/rspec-core-3.9.2/lib/rspec/core/configuration.rb:2058:in `with_suite_hooks'
/Library/Ruby/Gems/2.6.0/gems/rspec-core-3.9.2/lib/rspec/core/runner.rb:116:in `block in run_specs'
/Library/Ruby/Gems/2.6.0/gems/rspec-core-3.9.2/lib/rspec/core/reporter.rb:74:in `report'
/Library/Ruby/Gems/2.6.0/gems/rspec-core-3.9.2/lib/rspec/core/runner.rb:115:in `run_specs'
/Library/Ruby/Gems/2.6.0/gems/rspec-core-3.9.2/lib/rspec/core/runner.rb:89:in `run'
/Library/Ruby/Gems/2.6.0/gems/rspec-core-3.9.2/lib/rspec/core/runner.rb:71:in `run'
/Library/Ruby/Gems/2.6.0/gems/rspec-core-3.9.2/lib/rspec/core/runner.rb:45:in `invoke'
/Library/Ruby/Gems/2.6.0/gems/rspec-core-3.9.2/exe/rspec:4:in `<main>'

High CPU when fog-aliyun is used in CF Cloud Controller

When switching in a CF landscape with "some usage" the cloud controller from bits-service to fog, we observed a drastic increase in CPU usage of the ruby processes of the Cloud Controller (see attached monitoring screenshot).
Such an increase was not observed on AWS, Azure and GCP where we switched from bits to fog as well. The CF usage (# of cf-push operations) should be comparable between the different IaaS.

Droplets in the blobstore are deleted on stop/restart of CF application, with fog-aliyun v0.3.8

We have evaluated fog-aliyun v0.3.8 on our AlibabaCloud CF landscape and encountered some problems with the blobstore.

Setup:
cf-deployment v12.39.0
capi-release 1.91.0-sap.2

The capi-release patched to use fog-aliyun in v0.3.8.

Deployment of Cloud Foundry is successful. A first push of an application also works. But after stopping and restarting and application, the droplets in the blobstore are deleted. Apps cannot be started any more.

We suspect that directory names are not correctly determined in this part of the coding:

def check_directory_key(directory_key)
.
It could be that the path to the "buildpack_cache" folder is incorrectly truncated and so parent folders are deleted as well.
The "buildpack_cache" content is cleaned up by the cc-worker jobs.

fog-aliyun is not compatible with Ruby 3.X

With Ruby 3.x this gem cannot be used anymore due to the following error:

undefined method `encode' for URI:Module

The encode method was removed with Ruby 3: https://docs.knapsackpro.com/2020/uri-escape-is-obsolete-percent-encoding-your-query-string

To reproduce the issue run the unit/integration test with ruby 3.x. This can be done for example by changing the version in .ruby-version to e.g. 3.0.4.

Open questions:

  • Does aliyun-sdk needs to be updated and test as well? Looks like last commit is ~2 years old.

Connection within the same VPC

The Internal domain name is expected to be used when accessing OSS on the ECS server within the same VPC, but it looks like the "-internal" part is not included in the result of the get_bucket_location function query.

Next fog release

Hi there,

When the next fog-aliyun is planned to be released? The master branch has some bug fixes that are not part of the latest release.

Thanks,
Dmitry

gem version 0.0.10 removed from repository

Hi,

is there a specific reason why the version 0.0.10 was completely deleted from repositories? I understand the need for security patches, but deleting the release is kind of inconvenient ...

Best

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.