knife-openstack 2.0.1 → 4.0.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (60) hide show
  1. checksums.yaml +5 -5
  2. data/lib/chef/knife/cloud/openstack_server_create_options.rb +64 -51
  3. data/lib/chef/knife/cloud/openstack_service.rb +33 -17
  4. data/lib/chef/knife/cloud/openstack_service_options.rb +34 -24
  5. data/lib/chef/knife/openstack_flavor_list.rb +18 -4
  6. data/lib/chef/knife/openstack_floating_ip_allocate.rb +22 -9
  7. data/lib/chef/knife/openstack_floating_ip_associate.rb +24 -12
  8. data/lib/chef/knife/openstack_floating_ip_disassociate.rb +25 -12
  9. data/lib/chef/knife/openstack_floating_ip_list.rb +18 -4
  10. data/lib/chef/knife/openstack_floating_ip_release.rb +16 -4
  11. data/lib/chef/knife/openstack_group_list.rb +21 -4
  12. data/lib/chef/knife/openstack_helpers.rb +20 -4
  13. data/lib/chef/knife/openstack_image_list.rb +22 -8
  14. data/lib/chef/knife/openstack_network_list.rb +18 -4
  15. data/lib/chef/knife/openstack_server_create.rb +36 -35
  16. data/lib/chef/knife/openstack_server_delete.rb +17 -5
  17. data/lib/chef/knife/openstack_server_list.rb +5 -6
  18. data/lib/chef/knife/openstack_server_show.rb +4 -5
  19. data/lib/chef/knife/openstack_volume_list.rb +10 -9
  20. data/lib/knife-openstack/version.rb +2 -2
  21. metadata +17 -91
  22. data/.github/ISSUE_TEMPLATE.md +0 -21
  23. data/.gitignore +0 -32
  24. data/.travis.yml +0 -10
  25. data/CHANGELOG.md +0 -335
  26. data/CONTRIBUTING.MD +0 -164
  27. data/Gemfile +0 -21
  28. data/README.md +0 -179
  29. data/Rakefile +0 -27
  30. data/knife-openstack.gemspec +0 -30
  31. data/spec/functional/flavor_list_func_spec.rb +0 -47
  32. data/spec/functional/floating_ip_list_func_spec.rb +0 -48
  33. data/spec/functional/group_list_func_spec.rb +0 -65
  34. data/spec/functional/image_list_func_spec.rb +0 -53
  35. data/spec/functional/network_list_func_spec.rb +0 -46
  36. data/spec/functional/server_create_func_spec.rb +0 -118
  37. data/spec/functional/server_delete_func_spec.rb +0 -84
  38. data/spec/functional/server_list_func_spec.rb +0 -98
  39. data/spec/functional/server_show_func_spec.rb +0 -46
  40. data/spec/functional/volume_list_func_spec.rb +0 -46
  41. data/spec/integration/cleanup.rb +0 -89
  42. data/spec/integration/config/environment.yml.sample +0 -13
  43. data/spec/integration/openstack_spec.rb +0 -649
  44. data/spec/spec_context.rb +0 -56
  45. data/spec/spec_helper.rb +0 -128
  46. data/spec/unit/openstack_flavor_list_spec.rb +0 -30
  47. data/spec/unit/openstack_floating_ip_allocate_spec.rb +0 -56
  48. data/spec/unit/openstack_floating_ip_associate_spec.rb +0 -40
  49. data/spec/unit/openstack_floating_ip_disassociate_spec.rb +0 -39
  50. data/spec/unit/openstack_floating_ip_list_spec.rb +0 -27
  51. data/spec/unit/openstack_floating_ip_release_spec.rb +0 -49
  52. data/spec/unit/openstack_group_list_spec.rb +0 -44
  53. data/spec/unit/openstack_image_list_spec.rb +0 -32
  54. data/spec/unit/openstack_network_list_spec.rb +0 -39
  55. data/spec/unit/openstack_server_create_spec.rb +0 -449
  56. data/spec/unit/openstack_server_delete_spec.rb +0 -43
  57. data/spec/unit/openstack_server_list_spec.rb +0 -32
  58. data/spec/unit/openstack_server_show_spec.rb +0 -42
  59. data/spec/unit/openstack_service_spec.rb +0 -128
  60. data/spec/unit/openstack_volume_list_spec.rb +0 -30
@@ -1,164 +0,0 @@
1
- # Contributing to Chef's knife-openstack
2
-
3
- We're glad you want to contribute to Chef's knife-openstack! The first step is the desire to improve the project.
4
-
5
- ## Getting in Contact with Us
6
-
7
- If you're interested in contributing to Chef's knife-openstack or just have a question about one of one of them we'd love to chat. You can find us in #general on the [Chef Community Slack](https://community-slack.chef.io/).
8
-
9
- ## Submitting Issues
10
-
11
- Not every contribution comes in the form of code. Submitting, confirming, and triaging issues is an important task for any project. At Chef we use GitHub to track all project issues.
12
-
13
- ## Contribution Process
14
-
15
- We have a 3 step process for contributions:
16
-
17
- 1. Commit changes to a git branch, making sure to sign-off those changes for the [Developer Certificate of Origin](#developer-certification-of-origin-dco).
18
- 2. Create a GitHub Pull Request for your change, following the instructions in the pull request template.
19
- 3. Perform a [Code Review](#code-review-process) with the cookbook maintainers on the pull request.
20
-
21
- ### Code Review Process
22
-
23
- Code review takes place in GitHub pull requests. See [this article](https://help.github.com/articles/about-pull-requests/) if you're not familiar with GitHub Pull Requests.
24
-
25
- Once you open a pull request, cookbook maintainers will review your code using the built-in code review process in Github PRs. The process at this point is as follows:
26
-
27
- 1. A maintainer will review your code and merge it if no changes are necessary. Your change will be merged into the cookbooks's `master` branch and will be noted in the cookbook's `CHANGELOG.md` at the time of release.
28
- 2. If a maintainer has feedback or questions on your changes they they will set `request changes` in the review and provide an explanation.
29
-
30
- ### Developer Certification of Origin (DCO)
31
-
32
- Licensing is very important to open source projects. It helps ensure the software continues to be available under the terms that the author desired.
33
-
34
- Chef uses [the Apache 2.0 license](https://github.com/chef/chef/blob/master/LICENSE) to strike a balance between open contribution and allowing you to use the software however you would like to.
35
-
36
- The license tells you what rights you have that are provided by the copyright holder. It is important that the contributor fully understands what rights they are licensing and agrees to them. Sometimes the copyright holder isn't the contributor, such as when the contributor is doing work on behalf of a company.
37
-
38
- To make a good faith effort to ensure these criteria are met, Chef requires the Developer Certificate of Origin (DCO) process to be followed.
39
-
40
- The DCO is an attestation attached to every contribution made by every developer. In the commit message of the contribution, the developer simply adds a Signed-off-by statement and thereby agrees to the DCO, which you can find below or at <http://developercertificate.org/>.
41
-
42
- ```
43
- Developer's Certificate of Origin 1.1
44
-
45
- By making a contribution to this project, I certify that:
46
-
47
- (a) The contribution was created in whole or in part by me and I
48
- have the right to submit it under the open source license
49
- indicated in the file; or
50
-
51
- (b) The contribution is based upon previous work that, to the
52
- best of my knowledge, is covered under an appropriate open
53
- source license and I have the right under that license to
54
- submit that work with modifications, whether created in whole
55
- or in part by me, under the same open source license (unless
56
- I am permitted to submit under a different license), as
57
- Indicated in the file; or
58
-
59
- (c) The contribution was provided directly to me by some other
60
- person who certified (a), (b) or (c) and I have not modified
61
- it.
62
-
63
- (d) I understand and agree that this project and the contribution
64
- are public and that a record of the contribution (including
65
- all personal information I submit with it, including my
66
- sign-off) is maintained indefinitely and may be redistributed
67
- consistent with this project or the open source license(s)
68
- involved.
69
- ```
70
-
71
- For more information on the change see the Chef Blog post [Introducing Developer Certificate of Origin](https://blog.chef.io/2016/09/19/introducing-developer-certificate-of-origin/)
72
-
73
- #### DCO Sign-Off Methods
74
-
75
- The DCO requires a sign-off message in the following format appear on each commit in the pull request:
76
-
77
- ```
78
- Signed-off-by: Julia Child <juliachild@chef.io>
79
- ```
80
-
81
- The DCO text can either be manually added to your commit body, or you can add either **-s** or **--signoff** to your usual git commit commands. If you forget to add the sign-off you can also amend a previous commit with the sign-off by running **git commit --amend -s**. If you've pushed your changes to GitHub already you'll need to force push your branch after this with **git push -f**.
82
-
83
- ### Chef Obvious Fix Policy
84
-
85
- Small contributions, such as fixing spelling errors, where the content is small enough to not be considered intellectual property, can be submitted without signing the contribution for the DCO.
86
-
87
- As a rule of thumb, changes are obvious fixes if they do not introduce any new functionality or creative thinking. Assuming the change does not affect functionality, some common obvious fix examples include the following:
88
-
89
- - Spelling / grammar fixes
90
- - Typo correction, white space and formatting changes
91
- - Comment clean up
92
- - Bug fixes that change default return values or error codes stored in constants
93
- - Adding logging messages or debugging output
94
- - Changes to 'metadata' files like Gemfile, .gitignore, build scripts, etc.
95
- - Moving source files from one directory or package to another
96
-
97
- **Whenever you invoke the "obvious fix" rule, please say so in your commit message:**
98
-
99
- ```
100
- ------------------------------------------------------------------------
101
- commit 370adb3f82d55d912b0cf9c1d1e99b132a8ed3b5
102
- Author: Julia Child <juliachild@chef.io>
103
- Date: Wed Sep 18 11:44:40 2015 -0700
104
-
105
- Fix typo in the README.
106
-
107
- Obvious fix.
108
-
109
- ------------------------------------------------------------------------
110
- ```
111
-
112
- ## Using git
113
-
114
- For collaboration purposes, it is best if you create a GitHub account and fork the repository to your own account. Once you do this you will be able to push your changes to your GitHub repository for others to see and use.
115
-
116
- ### Branches and Commits
117
-
118
- You should submit your patch as a git branch named after the Github issue, such as GH-22\. This is called a _topic branch_ and allows users to associate a branch of code with the ticket.
119
-
120
- It is a best practice to have your commit message have a _summary line_ that includes the ticket number, followed by an empty line and then a brief description of the commit. This also helps other contributors understand the purpose of changes to the code.
121
-
122
- ```text
123
- [GH-22] - platform_family and style
124
-
125
- * use platform_family for platform checking
126
- * update notifies syntax to "resource_type[resource_name]" instead of
127
- resources() lookup
128
- * GH-692 - delete config files dropped off by packages in conf.d
129
- * dropped debian 4 support because all other platforms have the same
130
- values, and it is older than "old stable" debian release
131
- ```
132
-
133
- Remember that not all users use Chef in the same way or on the same operating systems as you, so it is helpful to be clear about your use case and change so they can understand it even when it doesn't apply to them.
134
-
135
- ### More information
136
-
137
- Additional help with git is available on the [Community Contributions](https://docs.chef.io/community_contributions.html#use-git) page on the Chef Docs site.
138
-
139
- ## Contribution Do's and Don't's
140
-
141
- Please do include tests for your contribution. If you need help, ask on the [chef-dev mailing list](https://discourse.chef.io/c/dev) or the [Chef Community Slack](https://community-slack.chef.io/). Not all platforms that a cookbook supports may be supported by Test Kitchen. Please provide evidence of testing your contribution if it isn't trivial so we don't have to duplicate effort in testing.
142
-
143
- Please do indicate new platform (families) or platform versions in the commit message, and update the relevant ticket.
144
-
145
- If a contribution adds new platforms or platform versions, indicate such in the body of the commit message(s), and update the relevant issues. When writing commit messages, it is helpful for others if you indicate the issue. For example: git commit -m '[ISSUE-1041] - Updated pool resource to correctly delete.'
146
-
147
- Please do ensure that your changes do not break or modify behavior for other platforms supported by the cookbook. For example if your changes are for Debian, make sure that they do not break on CentOS.
148
-
149
- Please do **not** modify the version number in the `metadata.rb`, a maintainer will select the appropriate version based on the release cycle information above.
150
-
151
- Please do **not** update the `CHANGELOG.md` for a new version. Not all changes to a cookbook may be merged and released in the same versions. A maintainer will update the `CHANGELOG.md` when releasing a new version of the cookbook.
152
-
153
- ## Chef Community
154
-
155
- Chef is made possible by a strong community of developers and system administrators. If you have any questions or if you would like to get involved in the Chef community you can check out:
156
-
157
- - [Chef Mailing List](https://discourse.chef.io/)
158
- - [Chef Community Slack](https://community-slack.chef.io/)
159
-
160
- Also here are some additional pointers to some awesome Chef content:
161
-
162
- - [Chef Docs](https://docs.chef.io/)
163
- - [Learn Chef](https://learn.chef.io/)
164
- - [Chef Website](https://www.chef.io/)
data/Gemfile DELETED
@@ -1,21 +0,0 @@
1
- # frozen_string_literal: true
2
- source "https://rubygems.org"
3
-
4
- # Specify your gem's dependencies in knife-openstack.gemspec
5
- gemspec
6
-
7
- group :development do
8
- gem "guard-rspec"
9
- gem "mixlib-shellout"
10
- gem "rake", "~> 11.0"
11
- gem "rspec", "~> 3.0"
12
- gem "chefstyle"
13
- gem "rspec-expectations"
14
- gem "rspec-mocks"
15
- gem "rspec_junit_formatter"
16
- end
17
-
18
- # our use of the fork can go away if they merge https://github.com/skywinder/github-changelog-generator/pull/453
19
- group(:changelog) do
20
- gem "github_changelog_generator", git: "https://github.com/tduffield/github-changelog-generator", branch: "adjust-tag-section-mapping"
21
- end
data/README.md DELETED
@@ -1,179 +0,0 @@
1
- # Knife OpenStack
2
-
3
- [![Gem Version](https://badge.fury.io/rb/knife-openstack.svg)](https://rubygems.org/gems/knife-openstack) [![Build Status](https://travis-ci.org/chef/knife-openstack.svg?branch=master)](https://travis-ci.org/chef/knife-openstack) [![Dependency Status](https://gemnasium.com/chef/knife-openstack.svg)](https://gemnasium.com/chef/knife-openstack)
4
-
5
- This is the official Chef Knife plugin for OpenStack Compute (Nova). This plugin gives knife the ability to create, bootstrap and manage instances in OpenStack Compute clouds. It has been tested against the `Diablo` through `Kilo` releases in configurations using Keystone against the OpenStack API (as opposed to the EC2 API).
6
-
7
- Please refer to the [CHANGELOG](CHANGELOG.md) for version history and known issues.
8
-
9
- - Documentation: <https://github.com/chef/knife-openstack/blob/master/README.md>
10
- - Source: <http://github.com/chef/knife-openstack/tree/master>
11
- - Issues: <https://github.com/chef/knife-openstack/issues>
12
- - Slack: <http://community-slack.chef.io/>
13
- - Mailing list: <https://discourse.chef.io/>
14
-
15
- Note: Documentation needs to be updated in chef docs
16
-
17
- ## Requirements
18
-
19
- - Chef 12.0 higher
20
- - Ruby 2.2.2 or higher
21
-
22
- ## Installation
23
-
24
- Using [ChefDK](https://downloads.chef.io/chef-dk/), simply install the Gem:
25
-
26
- ```bash
27
- chef gem install knife-openstack
28
- ```
29
-
30
- ## Configuration
31
-
32
- In order to communicate with an OpenStack API you will need to tell Knife your OpenStack Auth API endpoint, your Dashboard username and password (tenant is optional). The easiest way to accomplish this is to create these entries in your `knife.rb` file:
33
-
34
- ```ruby
35
- ### Note: If you are not proxying HTTPS to the OpenStack auth port, the scheme should be HTTP
36
- knife[:openstack_auth_url] = "http://cloud.mycompany.com:5000/v2.0/tokens"
37
- knife[:openstack_username] = "Your OpenStack Dashboard username"
38
- knife[:openstack_password] = "Your OpenStack Dashboard password"
39
- knife[:openstack_tenant] = "Your OpenStack tenant name"
40
- knife[:openstack_region] = "Your OpenStack Region"
41
- ```
42
-
43
- All of Fog's `openstack` options (`openstack_domain_name`, `openstack_project_name`, ...) are supported. This includes support for the OpenStack Identity v3
44
-
45
- ```ruby
46
- knife[:openstack_auth_url] = "http://cloud.mycompany.com:5000/v3/auth/tokens"
47
- knife[:openstack_username] = "Your OpenStack Dashboard username"
48
- knife[:openstack_password] = "Your OpenStack Dashboard password"
49
- knife[:openstack_project_name] = "Your OpenStack project"
50
- knife[:openstack_domain_name] = "Your OpenStack domain"
51
- ```
52
-
53
- If your knife.rb file will be checked into a SCM system (ie readable by others) you may want to read the values from environment variables. For example, using the conventions of [OpenStack's RC file](http://docs.openstack.org/user-guide/content/cli_openrc.html) (note the `openstack_auth_url`):
54
-
55
- ```ruby
56
- knife[:openstack_auth_url] = "#{ENV['OS_AUTH_URL']}/tokens"
57
- knife[:openstack_username] = "#{ENV['OS_USERNAME']}"
58
- knife[:openstack_password] = "#{ENV['OS_PASSWORD']}"
59
- knife[:openstack_tenant] = "#{ENV['OS_TENANT_NAME']}"
60
- knife[:openstack_region] = "#{ENV['OS_REGION_NAME']}"
61
- ```
62
-
63
- If your OpenStack deployment is over SSL, but does not have a valid certificate, you can add the following option to bypass SSL check:
64
-
65
- ```ruby
66
- knife[:openstack_insecure] = true
67
- ```
68
-
69
- If you need to use alternate service endpoints for communicating with OpenStack, you can set the following option:
70
-
71
- ```ruby
72
- knife[:openstack_endpoint_type] = "internalURL"
73
- ```
74
-
75
- You also have the option of passing your OpenStack API Username/Password into the individual knife subcommands using the `-A` (or `--openstack-username`) `-K` (or `--openstack-password`) command options
76
-
77
- ```bash
78
- # provision a new image named kb01
79
- knife openstack server create -A 'MyUsername' -K 'MyPassword' --openstack-api-endpoint 'http://cloud.mycompany.com:5000/v2.0/tokens' -f 1 -I 13 -S trystack -i ~/.ssh/trystack.pem -r 'role[webserver]'
80
- ```
81
-
82
- Additionally the following options may be set in your `knife.rb`:
83
-
84
- - flavor
85
- - image
86
- - openstack_ssh_key_id
87
- - template_file
88
-
89
- ## Subcommands
90
-
91
- This plugin provides the following Knife subcommands. Specific command options can be found by invoking the subcommand with a `--help` option.
92
-
93
- ### `knife openstack server create`
94
-
95
- Provisions a new server in an OpenStack Compute cloud and then perform a Chef bootstrap (using the SSH protocol). The goal of the bootstrap is to get Chef installed on the target system so it can run Chef Client with a Chef Server. The main assumption is a baseline OS installation exists (provided by the provisioning). It is primarily intended for Chef Client systems that talk to a Chef server. By default the server is bootstrapped using the [chef-full](https://github.com/opscode/chef/blob/master/chef/lib/chef/knife/bootstrap/chef-full.erb) template (default since the 10.10 release). This may be overridden using the `-d` or `--template-file` command options. If you do not have public IP addresses, use the `--openstack-private-network` option to use the private IP address for bootstrapping. In addition, you can use the `--bootstrap-network NAME` option to specify an alternate network for either a private or public network. If a network name isn't specified, the default name will be `'public'` for a public network and `'private'` for a private network e.g. when the `--openstack-private-network` option is specified. Please see `knife openstack server create --help` for all of the supported options.
96
-
97
- #### Working with Windows Images
98
-
99
- Provisioning and bootstrapping for Windows 2003 and later images is now supported. The Windows images need to have WinRM enabled with Basic Authentication configured. Current support does not support Kerberos Authentication.
100
-
101
- Example:
102
-
103
- ```bash
104
- $ knife openstack server create -I <Image> -f <Flavor> -S <keypair_name> --bootstrap-protocol winrm -P <Administrator_Password> -x Administrator -N <chef_node_name> --bootstrap-template windows-chef-client-msi.erb
105
- ```
106
-
107
- NOTE:
108
-
109
- - Bootstrap Protocol (`--bootstrap-protocol`) is required to be set to `winrm`.
110
- - Administrator Username (`--winrm-user` or `-x`) and Password (`-P`) are required parameters.
111
- - If the Template File (`--template`) is not specified it defaults to a Linux distro (most likely Ubuntu).
112
-
113
- #### Working with Floating IPs
114
-
115
- To use a floating IP address while bootstrapping nodes, use the `-a` or `--openstack-floating-ip` option.
116
-
117
- ### `knife openstack server delete`
118
-
119
- Deletes an existing server in the currently configured OpenStack account. If a floating IP address has been assigned to the node, it is disassociated automatically by the OpenStack server. **PLEASE NOTE** - this does not delete the associated node and client objects from the Chef server without using the `-P` option to purge the client.
120
-
121
- ### `knife openstack server list`
122
-
123
- Outputs a list of all servers in the currently configured OpenStack account. **PLEASE NOTE** - this shows all instances associated with the account, some of which may not be currently managed by the Chef server.
124
-
125
- ### `knife openstack flavor list`
126
-
127
- Provides a list of all available flavors (available "hardware" configurations for a server) available to the currently configured OpenStack account. Each flavor has a unique combination of virtual cpus, disk space and memory capacity. This data may be useful when choosing a flavor to pass to the `knife openstack server create` subcommand.
128
-
129
- ### `knife openstack volume list`
130
-
131
- Provides a list of all volumes in the currently configured OpenStack account. Each volume shows its size and its availibility to be attached to server. This data may be useful when choosing a volume to pass to the `knife openstack server create` subcommand.
132
-
133
- ### `knife openstack image list`
134
-
135
- Lists all available images and snapshots available to the currently configured OpenStack account. An image is a collection of files used to create or rebuild a server. The retuned list filters out image names ending in 'initrd', 'kernel', 'loader', 'virtual' or 'vmlinuz' (this may be disabled with `--disable-filter`). This data may be useful when choosing an image to pass to the `knife openstack server create` subcommand.
136
-
137
- ### `knife openstack group list`
138
-
139
- Provides a list of the security groups available to the currently configured OpenStack account. Each group may have multiple rules. This data may be useful when choosing your security group(s) to pass to the `knife openstack server create` subcommand.
140
-
141
- ### `knife openstack network list`
142
-
143
- Lists the networks available to the currently configured OpenStack account. This data may be useful when choosing your networks to pass to the `knife openstack server create` subcommand. This command is only available with OpenStack deployments using the Neutron network service (not nova-network). Please see `knife openstack server create --help` for all of the supported options.
144
-
145
- ### `knife openstack floating_ip list`
146
-
147
- Lists all of the available `floating-ips` you have associated with your account. You can ask for more via: `knife openstack floating_ip allocate --pool POOL` if you have run out. You can also `knife openstack floating_ip associate FLOATING_IP --instance-id INSTANCE_ID` and too. If you need to remove the `floating-ip` you can `disassociate` with the same command. If you would like to give back the `floating-ip` you can `knife openstack floating_ip release FLOATING_IP_ID`
148
-
149
- ## Contributing
150
-
151
- For information on contributing to this project see <https://github.com/chef/chef/blob/master/CONTRIBUTING.md>
152
-
153
- ## License
154
-
155
- Author:: Seth Chisamore ([schisamo@chef.io](mailto:schisamo@chef.io))
156
-
157
- Author:: Matt Ray ([matt@chef.io](mailto:matt@chef.io))
158
-
159
- Author:: Chirag Jog ([chirag@clogeny.com](mailto:chirag@clogeny.com))
160
-
161
- Author:: JJ Asghar ([jj@chef.io](mailto:jj@chef.io))
162
-
163
- Copyright:: Copyright (c) 2011-2016 Chef Software, Inc.
164
-
165
- License:: Apache License, Version 2.0
166
-
167
- ```text
168
- Licensed under the Apache License, Version 2.0 (the "License");
169
- you may not use this file except in compliance with the License.
170
- You may obtain a copy of the License at
171
-
172
- http://www.apache.org/licenses/LICENSE-2.0
173
-
174
- Unless required by applicable law or agreed to in writing, software
175
- distributed under the License is distributed on an "AS IS" BASIS,
176
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
177
- See the License for the specific language governing permissions and
178
- limitations under the License.
179
- ```
data/Rakefile DELETED
@@ -1,27 +0,0 @@
1
- # frozen_string_literal: true
2
- # Author:: Kaustubh Deorukhkar (<kaustubh@clogeny.com>)
3
- # Copyright:: Copyright (c) 2013-2016 Chef Software, Inc.
4
-
5
- require "bundler"
6
- require "bundler/setup"
7
- require "bundler/gem_tasks"
8
- require "chefstyle"
9
- require "rubocop/rake_task"
10
- require "rspec/core/rake_task"
11
- require "github_changelog_generator/task"
12
- require "knife-openstack/version"
13
-
14
- RuboCop::RakeTask.new
15
-
16
- RSpec::Core::RakeTask.new(:spec)
17
-
18
- task default: [:rubocop, :spec]
19
-
20
- GitHubChangelogGenerator::RakeTask.new :changelog do |config|
21
- config.future_release = Knife::OpenStack::VERSION
22
- config.max_issues = 0
23
- config.add_issues_wo_labels = false
24
- config.enhancement_labels = "enhancement,Enhancement,New Feature,Feature".split(",")
25
- config.bug_labels = "bug,Bug,Improvement,Upstream Bug".split(",")
26
- config.exclude_labels = "duplicate,question,invalid,wontfix,no_changelog,Exclude From Changelog,Question,Discussion,Tech Cleanup".split(",")
27
- end
@@ -1,30 +0,0 @@
1
- # -*- encoding: utf-8 -*-
2
- # frozen_string_literal: true
3
- $LOAD_PATH.push File.expand_path("../lib", __FILE__)
4
- require "knife-openstack/version"
5
-
6
- Gem::Specification.new do |s|
7
- s.name = "knife-openstack"
8
- s.version = Knife::OpenStack::VERSION
9
- s.version = "#{s.version}-alpha-#{ENV['TRAVIS_BUILD_NUMBER']}" if ENV["TRAVIS"]
10
- s.platform = Gem::Platform::RUBY
11
- s.has_rdoc = true
12
- s.extra_rdoc_files = ["README.md", "LICENSE"]
13
- s.authors = ["JJ Asghar"]
14
- s.email = ["jj@chef.io"]
15
- s.homepage = "https://github.com/chef/knife-openstack"
16
- s.summary = "A Chef knife plugin for OpenStack clouds."
17
- s.description = "A Chef knife plugin for OpenStack clouds."
18
- s.license = "Apache-2.0"
19
-
20
- s.files = `git ls-files`.split("\n")
21
- s.test_files = `git ls-files -- {test,spec,features}/*`.split("\n")
22
- s.executables = `git ls-files -- bin/*`.split("\n").map { |f| File.basename(f) }
23
- s.require_paths = ["lib"]
24
-
25
- s.required_ruby_version = ">= 2.2.2"
26
-
27
- s.add_dependency "fog", "~> 1.23"
28
- s.add_dependency "chef", ">= 12"
29
- s.add_dependency "knife-cloud", "~> 1.2.0"
30
- end
@@ -1,47 +0,0 @@
1
- # frozen_string_literal: true
2
- #
3
- # Author:: Mukta Aphale (<mukta.aphale@clogeny.com>)
4
- # Author:: Ameya Varade (<ameya.varade@clogeny.com>)
5
- # Copyright:: Copyright (c) 2013-2014 Chef Software, Inc.
6
- # License:: Apache License, Version 2.0
7
- #
8
- # Licensed under the Apache License, Version 2.0 (the "License");
9
- # you may not use this file except in compliance with the License.
10
- # You may obtain a copy of the License at
11
- #
12
- # http://www.apache.org/licenses/LICENSE-2.0
13
- #
14
- # Unless required by applicable law or agreed to in writing, software
15
- # distributed under the License is distributed on an "AS IS" BASIS,
16
- # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
17
- # See the License for the specific language governing permissions and
18
- # limitations under the License.
19
-
20
- require "spec_helper"
21
- require "chef/knife/openstack_flavor_list"
22
- require "chef/knife/cloud/openstack_service"
23
- require "support/shared_examples_for_command"
24
-
25
- describe Chef::Knife::Cloud::OpenstackFlavorList do
26
- let (:instance) { Chef::Knife::Cloud::OpenstackFlavorList.new }
27
-
28
- context "functionality" do
29
- before do
30
- resources = [TestResource.new(id: "resource-1", name: "m1.tiny", vcpus: "1", ram: 512, disk: 0),
31
- TestResource.new(id: "resource-2", name: "m1-xlarge-bigdisk", vcpus: "8", ram: 16_384, disk: 50),
32
- ]
33
- allow(instance).to receive(:query_resource).and_return(resources)
34
- allow(instance).to receive(:puts)
35
- allow(instance).to receive(:create_service_instance).and_return(Chef::Knife::Cloud::Service.new)
36
- allow(instance).to receive(:validate!)
37
- instance.config[:format] = "summary"
38
- end
39
-
40
- it "lists formatted list of resources" do
41
- expect(instance.ui).to receive(:list).with(["Name", "ID", "Virtual CPUs", "RAM", "Disk",
42
- "m1-xlarge-bigdisk", "resource-2", "8", "16384 MB", "50 GB",
43
- "m1.tiny", "resource-1", "1", "512 MB", "0 GB"], :uneven_columns_across, 5)
44
- instance.run
45
- end
46
- end
47
- end