Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Fix for starting libs client from module #420

Merged
merged 1 commit into from May 9, 2016
Merged

Fix for starting libs client from module #420

merged 1 commit into from May 9, 2016

Conversation

clintkitson
Copy link
Member

This commit makes it so that libstorage client is started once
per module. This allows you to configure libs client settings
including volume and integration settings per module.

@clintkitson clintkitson added this to the 0.4.0 milestone May 9, 2016
@coveralls
Copy link

Coverage Status

Coverage remained the same at 100.0% when pulling b29f7bd on clintonskitson:bugfix/start_libs_in_module into 31c54b5 on emccode:master.

@akutz
Copy link
Member

akutz commented May 9, 2016

Hi @clintonskitson,

This could be an issue. The line lsc, _, err, errs := libstorage.New(mc.Config) actually attempts to spin up a server if no host is detected. I think we should leave lines 164 - 174 and then update the new code to use the Dial method instead of the New method. The Dial method only attempts to connect to an existing host.

@clintkitson
Copy link
Member Author

@akutz Will take a peak here.

@clintkitson clintkitson force-pushed the bugfix/start_libs_in_module branch from b29f7bd to 29f53e2 Compare May 9, 2016 21:31
@codecov-io
Copy link

codecov-io commented May 9, 2016 •
edited

Current coverage is 100%

Merging #420 into master will not change coverage

@@           master   #420   diff @@
====================================
  Files           1      1          
  Lines          93     93          
  Methods         0      0          
  Messages        0      0          
  Branches        0      0          
====================================
  Hits           93     93          
  Misses          0      0          
  Partials        0      0

Powered by Codecov. Last updated by 22a69e7...b29f7bd

@coveralls
Copy link

Coverage Status

Coverage remained the same at 100.0% when pulling 29f53e2 on clintonskitson:bugfix/start_libs_in_module into 22a69e7 on emccode:master.

@clintkitson
Updated CLI to not enable pathcache
df3b155 
Since a CLI starts and exits, the extra overhead required from
enabling the caching of doing a list attached method on launch is
not needed.
@clintkitson clintkitson force-pushed the bugfix/start_libs_in_module branch from 29f53e2 to df3b155 Compare May 9, 2016 21:38
@coveralls
Copy link

Coverage Status

Coverage remained the same at 100.0% when pulling df3b155 on clintonskitson:bugfix/start_libs_in_module into 22a69e7 on emccode:master.

@clintkitson clintkitson merged commit 54a1b1b into rexray:master May 9, 2016
akutz added a commit to akutz/rexray that referenced this pull request May 10, 2016
@akutz
REX-Ray 0.4.0 Release Candidate 1
15a9e14 
REX-Ray 0.4.0 introduces centralized configuration and control along
with a new client/server architecture -- features made possible by
[libStorage](https://github.com/emccode/libstorage). Users are no
longer required to configure storage drivers or store privileged
information on all systems running the REX-Ray client. The new client
delegates storage-platform related operations to a remote,
libStorage-compatible server such as REX-Ray or
[Poly](https://github.com/emccode/polly).

Please note that the initial release of REX-Ray 0.4 includes support
for only the following storage platforms:

    * ScaleIO
    * VirtualBox

Support for the full compliment of drivers present in earlier versions
of REX-Ray will be reintroduced over the course of several, incremental
updates, beginning with 0.4.1.

NEW FEATURES
    * Distributed architecture (rexray#399, rexray#401, rexray#411, rexray#417, rexray#418, rexray#419, rexray#420, rexray#423)
    * Volume locking mechanism (rexray#171)
    * Volume creation with initial data (rexray#169)

ENHANCEMENTS
    * Improved storage driver logging (rexray#396)
    * Docker mount path (rexray#403)

BUG FIXES
    * Fixed issue with install script (rexray#409)
    * Fixed volume ls filter (rexray#400)
    * Fixed panic during access attempt of offline REX-Ray daemon (rexray#148)
akutz added a commit to akutz/rexray that referenced this pull request May 10, 2016
@akutz
REX-Ray 0.4.0 Release Candidate 1
6fce380 
REX-Ray 0.4.0 introduces centralized configuration and control along
with a new client/server architecture -- features made possible by
libStorage (https://github.com/emccode/libstorage). Users are no
longer required to configure storage drivers or store privileged
information on all systems running the REX-Ray client. The new client
delegates storage-platform related operations to a remote,
libStorage-compatible server such as REX-Ray or
Poly (https://github.com/emccode/polly).

Please note that the initial release of REX-Ray 0.4 includes support
for only the following storage platforms:

  * ScaleIO
  * VirtualBox

Support for the full compliment of drivers present in earlier versions
of REX-Ray will be reintroduced over the course of several, incremental
updates, beginning with 0.4.1.

NEW FEATURES
  * Distributed architecture (rexray#399, rexray#401, rexray#411, rexray#417, rexray#418, rexray#419, rexray#420, rexray#423)
  * Volume locking mechanism (rexray#171)
  * Volume creation with initial data (rexray#169)

ENHANCEMENTS
  * Improved storage driver logging (rexray#396)
  * Docker mount path (rexray#403)

BUG FIXES
  * Fixed issue with install script (rexray#409)
  * Fixed volume ls filter (rexray#400)
  * Fixed panic during access attempt of offline REX-Ray daemon (rexray#148)
akutz added a commit to akutz/rexray that referenced this pull request May 10, 2016
@akutz
REX-Ray 0.4.0 Release Candidate 1
4cff7bd 
REX-Ray 0.4.0 introduces centralized configuration and control along
with a new client/server architecture -- features made possible by
libStorage (https://github.com/emccode/libstorage). Users are no
longer required to configure storage drivers or store privileged
information on all systems running the REX-Ray client. The new client
delegates storage-platform related operations to a remote,
libStorage-compatible server such as REX-Ray or
Poly (https://github.com/emccode/polly).

Please note that the initial release of REX-Ray 0.4 includes support
for only the following storage platforms:

  * ScaleIO
  * VirtualBox

Support for the full compliment of drivers present in earlier versions
of REX-Ray will be reintroduced over the course of several, incremental
updates, beginning with 0.4.1.

NEW FEATURES
  * Distributed architecture (rexray#399, rexray#401, rexray#411, rexray#417,
                              rexray#418, rexray#419, rexray#420, rexray#423)
  * Volume locking mechanism (rexray#171)
  * Volume creation with initial data (rexray#169)

ENHANCEMENTS
  * Improved storage driver logging (rexray#396)
  * Docker mount path (rexray#403)

BUG FIXES
  * Fixed issue with install script (rexray#409)
  * Fixed volume ls filter (rexray#400)
  * Fixed panic during access attempt of offline REX-Ray daemon (rexray#148)
akutz added a commit to akutz/rexray that referenced this pull request Jul 24, 2017
@akutz
Merge pull request rexray#420 from akutz/feature/service-iids
cb80e3e 
Service Names & Instance IDs
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees

@akutz akutz

Labels
None yet
Projects
None yet
Milestone
0.4.0
Development

Successfully merging this pull request may close these issues.

None yet
4 participants
@clintkitson @coveralls @akutz @codecov-io