Scenario/Intent

Implement power device resource

Scenario/Intent

oneview_ethernet_network :bulk_create action is not idempotent

Environment Details

• oneview Cookbook Version: master
• OneView Version: 2.0

Steps to Reproduce

Create a recipe with a oneview_ethernet_network resource with the :bulk_create action, and run it twice.

Expected Result

Create the networks on the first run, and do nothing on the second.

Actual Result

It create the networks on the first run, but results in an error on the second. Error basics: 400: "CRM_DUPLICATE_BULK_NETWORK_NAME","message":"Some network names already exist."

Scenario/Intent

Implement server hardware type actions

Scenario/Intent

SimpleCov is complaining the resource providers aren't being tested by RSpec, but they are by the ChefSpec.

Should we remove them from the coverage report? Or should we migrate the tests to plain RSpec?

Environment Details

• oneview Cookbook Version: New (Post 1.0.0)

Steps to Reproduce

rake test

Expected Result

Coverage report should not be bellow expected

Actual Result

Coverage report is failing due to low coverage

Scenario/Intent

Implementation of Unmanaged Device and its actions

Scenario/Intent

When adding a network set with a native_network or network_list containing networks that don't exist.

Environment Details

• oneview Cookbook Version: 0.2.0
• OneView Version: 2.0
• chef-client Version: all
• platform: all

Steps to Reproduce

Running this should do it:

oneview_network_set 'ChefNetworkSet_1' do
  client <my_client>
  native_network 'FakeNetworkThatDoesNotExist'
  ethernet_network_list ['FakeNetworkThatDoesNotExist2', 'FakeNetworkThatDoesNotExist3']
  action :create
end

Expected Result

Give a helpful message saying the network could not be found

Actual Result

NoMethodError
-------------
undefined method `[]' for nil:NilClass

Scenario/Intent

Add support to Server Hardware Type in API300

Scenario/Intent

Implement actions for Firmware Driver

Scenario/Intent

Add support to the new Fabrics functionality :set_reserved_vlan_range

• Create the resource Fabrics
• Create action :set_reserved_vlan_range (API300::Synergy only)
• Add tests for Fabrics

Scenario/Intent

When trying to compare two hashes that has no-diff ( i.e. for each key 'k' in 'a', a[k] == b[k] ) with the OneviewCookbook::Helper#get_diff the result returned is '\n'.

Environment Details

• oneview Cookbook Version: 1.1.0
• OneView Version: N/A
• chef-client Version: N/A
• platform: N/A

Steps to Reproduce

Use get_diff method with two hashes with no-diff like:

a = { a: 'test', b: 'second' }
b = { a: 'test', c: 'other', b: 'second' }
get_diff(a, b)

Expected Result

get_diff should return ''

Actual Result

get_diff returns '\n'

Scenario/Intent

Support more API versions and the new/updated resources associated with them

Environment Details

• oneview Cookbook Version: 1.1.0
• OneView Version: 200, 300, and beyond

Description

In order to support newer API versions and yet maintain compatibility with previous ones, we'll need to do a pretty big refactor. The work is already underway, but this issue can capture some of the ideas and thoughts behind it, and serve as a discussion forum. From what we've discussed already, this refactor will likely include:

• Splitting most of the logic for resource actions into separate "provider" modules/classes.
• Supporting only 1 API version and HW variant per chef-client run. Because of the differences in the resources for separate API versions and how the providers would have to be split out, we need to load the providers at compile time, not runtime.

Outstanding Questions

1. How do we handle resources that have new/updated properties for newer API versions? For example, for oneview_server_profile, how do we add an os_deployment_image property to the API300 provider but make it clear that it isn't used in the API200 provider? Seems like there's a lot of room for confusion here.
2. Similarly, how should completely new resources be handled that don't exist in API200 (e.g., all the I3S stuff)?
3. Is there a good way to support multiple versions and variants in a chef-client run? I haven't found a good solution for it yet, but it may be possible.

Scenario/Intent

Implement Storage volume attachments

Scenario/Intent

Add support to Enclosure Group on API300.

Environment Details

• oneview Cookbook Version: 1.1.0
• OneView Version: 300

Scenario/Intent

Add support to Logical interconnect on API300.

Environment Details

• oneview Cookbook Version: 1.1.0
• OneView Version: 300

Scenario/Intent

Implement Server profile template actions

Scenario/Intent

Implement Logical switch resource with all the standard actions and tests.

https://github.com/HewlettPackard/oneview-chef/blob/master/resources/volume.rb#L51 is missing an &. There's a single & that should be &&. Currently throws an error similar to:

    ================================================================================
    Error executing action `create` on resource 'oneview_volume[CHEF_VOL_01]'
    ================================================================================

    NoMethodError
    -------------
    undefined method `&' for "ThreePAR7200-3167":String

    Cookbook Trace:
    ---------------
    /home/vagrant/chef-repo/.chef/local-mode-cache/cache/cookbooks/oneview/resources/volume.rb:51:in `load_storage_system'

Easy fix, but we'll want to add some tests too.

Scenario/Intent

Create a volume using a volume_template.

Environment Details

• oneview Cookbook Version: 1.0.0
• OneView Version: Any
• chef-client Version: Any
• platform: Any

Steps to Reproduce

Run an example like this one in the examples, in which no storage_system property is specified (it's specified in the template, so I shouldn't have to).

I used this code:

oneview_volume 'VOL_1' do
  client my_client
  data(
    description: 'General',
    provisionedCapacity: 1024 * 1024 * 10
  )
  volume_template "VOL_TEMPLATE"
end

Expected Result

It should be able to create the volume.

Actual Result

It raises an error saying Unspecified property: 'storage_system'. Please set it before attempting this action.

Scenario/Intent

Default action for interconnects is :none, but it is not implemented.

Environment Details

• N/A

Steps to Reproduce

Run any oneview_interconnect resource with default action.

Expected Result

Nothing should happen.

Actual Result

it fails since the :none action was not implemented.

Scenario/Intent

Re-running the same recipe that added a storage system (with the :add action) always results in an update, regardless of whether or not it's needed. (On the name and password)

Environment Details

• oneview Cookbook Version: 1.1.0
• OneView Version: 3.0

Steps to Reproduce

Run any simple recipe with a oneview_storage_system resource with the :add action. The example will do.

Expected Result

On subsequent runs, it shouldn't say it's going to update the name every time. From what I can tell, the name doesn't even appear to be configurable, right?
Also, it continues to try to update the password; I'm not sure if we can avoid that part, but what do you all think about only updating the password if the username has also changed or it's not in a good state (as defined by the state? status?)?

Actual Result

It tries to update the StorageSystem name and password:

INFO: Updating oneview_storage_system '172.18.11.12'

    - Update oneview_storage_system '172.18.11.12'

      credentials:
        password: nil -> myPassword123
      name: ThreePAR7200-6955 -> 172.18.11.12

Note that it doesn't break anything or cause any errors, but it does throw off the resources updated count, etc.

Scenario/Intent

Add support to Managed SAN on API300

Scenario/Intent

Some dependencies require lower versions of Ruby and we need to manage them so Travis won't fail.

Scenario/Intent

Implement Logical Interconnect resource and actions.

Implement the Logical Switch groups resource with its actions and unit tests.

Actions:

• standard_actions

Scenario/Intent

Add support to SAN Manager on API300

Scenario/Intent

Storage system resource implementation

Scenario/Intent

Implement Firmware bundle resource

Scenario/Intent

Add support to Datacenter in API300.

Scenario/Intent

Uses should be able to set the bandwidth on the following resources:

• oneview_fc_network
• oneview_fcoe_network
• oneview_network_set

Also, it would be nice to have a helper property: associated_san.

Environment Details

• oneview Cookbook Version: 1.1.0
• OneView Version: 3.0

When updating resources, there is no log output that indicates what is changed; just that it needs updated. However, when trying to debug a resource that continually needs updated because it seems to never match the definition, it's impossible to tell why.

For instance, if you have:

oneview_ethernet_network 'Chef-Eth-Net' do
  client <my_client>
  data(
    vlanId: 51,
    purpose: 'General',
    smartLink: true,
    privateNetwork: false
  )
end

It will always get "updated". On further investigation, it's because "smartLink"=>false on OneView, and it can't be set to false. It's pretty easy to output a diff for single-level hashes like ethernet_network data. You could just output:

...
[2016-09-01T19:48:39+00:00] INFO: Update oneview_ethernet_network 'Chef-Eth-Net'

    - Update oneview_ethernet_network 'Chef-Eth-Net'

  key1: old_val -> new_val
  key2: old_val -> new_val
...

However, for nested hashes, this may prove a little more difficult. We could do a dot chain, which could look something like:

...
[2016-09-01T19:48:39+00:00] INFO: Update oneview_ethernet_network 'Chef-Eth-Net'

    - Update oneview_ethernet_network 'Chef-Eth-Net'

  key1: old_val -> new_val
  first_level.key2: old_val -> new_val
  first_level.second.third.key3: old_val -> new_val
...

The easiest option would just be to print a debug statement with both complete hashes (no diff), but I think it's worth handling cleaner than that. Thoughts?

Travis job for Ruby 2.1 is failing and outputting the following message:

An error occurred while installing buff-extensions (2.0.0), and Bundler cannot continue.
Make sure that gem install buff-extensions -v '2.0.0' succeeds before bundling.

Scenario/Intent

Add Synergy remaining networks support (FC, FCoE, Network Set)

They should be splitted into providers, the resources must be updated, but they haven't any new added features.

Scenario/Intent

Add support to Rack using API300

Scenario/Intent

Add support to Power Devices in API300

Scenario/Intent

Implement Volume actions

Scenario/Intent

Switch resource implementation

There are some resources implemented without usage in README file. We need to create all these resource examples in README.

Scenario/Intent

Implementation of Uplink Set actions

Scenario/Intent

Implementation of san manager actions

@jsmartt suggested and I totally agree that maybe we should keep only a few examples in the README and add links to the examples files.

Scenario/Intent

Implemente managed sans actions

Scenario/Intent

Add support to Server Hardware on API300.

Environment Details

• oneview Cookbook Version: 1.1.0
• OneView Version: 300

Scenario/Intent

Implementation of actions for storage pool

Scenario/Intent

Add support to Unmanaged Devices on API300.

Scenario/Intent

oneview_server_hardware resources should not call the update method. Really, I think we need to remove the :add action, keeping only the :add_if_missing and :remove actions.

Environment Details

• oneview Cookbook Version: master
• OneView Version: 2.0

Steps to Reproduce

Add server-hardware, then update the resource with a different licensingIntent, for example.

Expected Result

Nothing. These resources cannot be updated. There's no API endpoint, and no SDK update method.

Actual Result

OneviewSDK::MethodUnavailable : The method #update is unavailable for this resource

Scenario/Intent

I'd like to be able to set the client object once and then all resources that don't set the client property will use that as a default.

Environment Details

• oneview Cookbook Version: 1.0.0

Steps to Reproduce

[If you are filing an issue, what are the things we need to do in order to reproduce your problem? How are you using this cookbook or any resources it includes?]

Expected Result

Set the client object once and everything that doesn't override it will use that as a default.

Actual Result

You have to pass in a client object for EVERY resource

As we know, OneView has a dedicated endpoint for Connection templates that are used by the Ethernet networks.

So, after some research I concluded that we could implement in Chef 2 actions for it, one is update and the other one is reset_to_default.

Although being that simple the names/URI for the Connection templates is not available to the end-user, it needs to be acquired through the Ethernet network name.

So my question is: It makes more sense to create a separate Chef resource for the Connection template or add these 2 actions in the Ethernet network resource?

Implement the Server Hardware resource with its actions and unit tests.

Actions:

• add
• add_if_missing
• remove
• refresh
• set_power_state
• update_ilo_firmware

Scenario/Intent

Implement unit tests missing and remaining actions

In order to help ensure good code and ensure PRs include all the expected things, it would be helpful to create a default comment for new PRs. (We can also do this for issues.) I saw this on the rsyslog cookbook, and the docs for how to do it are here.

Let's use this issue to discuss whether or not this is worth doing, and what the default should be.