Set-HPOVServerProfileTemplate

[rismoney]

Set-HPOVServerProfileTemplate

Expected Behavior

be able to configure server profile templates

Actual Behavior

"not implemented"

Steps to reproduce

>  Set-HPOVServerProfileTemplate
Not implemented.
At C:\Program Files\WindowsPowerShell\Modules\HPOneView.420\HPOneView.420.psm1:94737 char:2
+     Throw "Not implemented."
+     ~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : OperationStopped: (Not implemented.:String) [], RuntimeException
    + FullyQualifiedErrorId : Not implemented.

Version Information

HPE OneView PowerShell Library Version (Get-HPOVVersion or $PSLibraryVersion):
HPE OneView Appliance Version (Get-HPOVVersion -ApplianceVer):
Output from $PSVersionTable on your Windows Host:

# Output from $PSVersionTable

How do you edit an already existing template?

[rismoney]

One additional point - New-HPOVServerProfileTemplate appears to only work for creation of server profile templates, and can't update/edit them.

[ChrisLynchHPE]

This isn't a bug. The Cmdlet hasn't been implemented yet. To edit a profile or template, you will need to get the resource, then modify the property of the specific section according to the REST API documentation. Then use Save-OVServerProfileTemplate or Save-OVServerProfile Cmdlets to save them to the appliance.

[ChrisLynchHPE]

Do you have a specific need right now to edit a setting? If so, I can help you with a workaround for now until they are implemented.

[rismoney]

I have encountered this on both the server profile template and the server profile cmdlets

A little background -
We are doing a huge HP migration project, that is going to involve moving hundreds of modules to an entirely new infrastructure. I started to look at managing this from a code perspective and initially liked the idea of using terraform (TF). What I found in the TF project was partial implementations of server profile management, where many subparts that are clearly listed within the core restapi were basically absent from the TF implementation. I guess it's a work in progress over there too, as it looks like after I put in some issues, work is underway to the underlying go libraries and will need to be completed before they can be exposed and subsequently coded up into the TF project.

So my thought was then let me bridge this gap and create the base objects with terraform since it mostly works and then run subequent powershell scripts to fully configure them. That's how I discovered this project.

So while it looks like the New* cmdlets in this area work, subsequent modifications won't. My hope is to be able to declaratively manage these things on some "getter/setter" level over the lifecycle of the frames. While I haven't yet tested the New* cmdlets, that might help at creation time getting them configured, not having these cmdlets will make it extremely challenging (read impossible) over the lifecycle of the devices to have to rely on delete/recreate and instead do it through the gui (not good for 100s of modules).

Currently the big gap both here and the TF repo is - logical storage (nearly all raid1 2 disk logical os) disks and bios settings on the profiletemplate.

I subsequently ran into a serverprofile issue on the TF side, where I couldn't create unassigned profiles, that apparently is another bug. So I am not exactly coping with infrastructure as code so well thus far on Synergy. I haven't ventured into ansible's repos yet, but I am just trying to find a way to automate this that is reliable and works. Interested in your thoughts on how to proceed.

[ChrisLynchHPE]

Currently the big gap both here and the TF repo is - logical storage (nearly all raid1 2 disk logical os) disks and bios settings on the profiletemplate.

I'm not following here. What would you need to change after profiles have been deployed? Typically customers have defined these policies, and then leave them alone unless there is a very specific need. I can certainly understand other aspects of a profile, like firmware, connections, fabrics, DAS and external storage policies would change (really add, not necessarily remove). With both Ansible and Terraform offering certain modifications to profiles and profile templates (mainly around firmware and external storage attachments), they are only lacking due to customer input and prioritizations we have to go through for all of the SDK's and scripting libraries we develop and maintain.

While a native Cmdlet doesn't technically exist yet within PowerShell, the PowerShell library is quite a bit more flexible than the others. In that as you have found out, unless specific support has been added to each object class, you would have to fork that repo and add the specific functionality. With the PowerShell library, it provides a REST client to interact with the REST API directly. There are core Cmdlets to initiate a connection, but all of the internal logic is handled by Send-OVRequest.

As the end of year HPE shutdown is coming in the next few weeks, I am planning on spending some of that time finally implementing the Set verb Cmdlets for modifying profiles and profile templates.

But again, without specifics I can only generally point you in a general direction.

[rismoney]

I'm not following here. What would you need to change after profiles have been deployed?

For today BIOS settings as I was attempting to use TF to create it via profile templates. I found out it was lacking and then tried to fill in the gaps missing with PS. But as I have recently learned, PS can't edit existing objects with the cmdlet, only via REST. This was an early use case I was running through. We are a financial firm where we need to make config changes to adapt workloads and we manage over 30+ bios settings on the fly. Again this was an initial finding. The point here also is not on what I need to change, but will I be locking myself into a config tool/approach that is not manageable over time. If I can't reasonably edit something when a need arises, (example: a developer suggests to disable hyperthreading) then what? I go into the GUI and change 150 profiles/templates? While the initial config/migrations is a burden to build out and we will have HPe help, I am even more concerned, when they leave and we are are left managing a fast growing multiple ring environment and seek to minimize config drift between what the code says is deployed and what is actually deployed.

Typically customers have defined these policies, and then leave them alone unless there is a very specific need. I can certainly understand other aspects of a profile, like firmware, connections, fabrics, DAS and external storage policies would change (really add, not necessarily remove). With both Ansible and Terraform offering certain modifications to profiles and profile templates (mainly around firmware and external storage attachments), they are only lacking due to customer input and prioritizations we have to go through for all of the SDK's and scripting libraries we develop and maintain.

Again yes there is coverage lacking overall. Selling the frames as composable infrastructure akin to cloud management, has an expectation around basic CRUD operations on all the rest objects. Today I seemingly don't get this coverage unless I hit the native rest.

While a native Cmdlet doesn't technically exist yet within PowerShell, the PowerShell library is quite a bit more flexible than the others. In that as you have found out, unless specific support has been added to each object class, you would have to fork that repo and add the specific functionality. With the PowerShell library, it provides a REST client to interact with the REST API directly. There are core Cmdlets to initiate a connection, but all of the internal logic is handled by Send-OVRequest.

True! Powershell has the most robust capabilities, particularly the ability to fallback on REST. This just leaves a fair amount of work to wrap in a sane manner to maintain a level of idempotency we are striving for versus imperative script running. On the PS side this approach would strategically align closer towards DSC, or creating appropriate getter/setters with conditionals.

As the end of year HPE shutdown is coming in the next few weeks, I am planning on spending some of that time finally implementing the Set verb Cmdlets for modifying profiles and profile templates.

But again, without specifics I can only generally point you in a general direction.

That's cool. I guess after looking over all the projects I am just saddened. HPe should have focused on one or 2 approaches to gain operational completeness and instead chose all the tools-puppet, chef ansible, terraform, powershell, et al where each lack a sort of semblance of comprehensive api coverage out of the box. This leaves me without a tool to manage things without going to the more rudimentary api level. Luckily I am not locked into one approach yet as I am still at the tool selection stage.

There are a ton of options contained within profiles and I was trying to avoid REST calls directly unless I was left no other choice because it adds a complexity of sane wrapping/abstraction that a customer shouldn't be burdened with under the guise of HPe supporting config management tooling.

[ChrisLynchHPE]

But as I have recently learned, PS can't edit existing objects with the cmdlet, only via REST.

Each Cmdlet is wrapped code around REST API manipulation, often the parameters map to specific sections of an objects property and allowed values. So while technically a "native" Cmdlet doesn't exist, you can still make changes to a resource via PowerShell. I would ask that you take a look at our curated scripts we have up on the oneview-samples repo.

For instance, here is a sample script to modify a profile template with a new baseline, even though there isn't a native Cmdlet to do this operation.

One more bit of information here. We haven't focused so much on editing existing profile or profile template objects because those tend to be pretty static and only change in very specific situations based on direct customer research. There are native ways to manipulate them without complex coding (i.e. changing the baseline as I showed above). And there are other operations that are more complex that are common that are supported, like adding a storage volume to a profile or profile template that New-OVServerProfileAttachVolum supports.

As for the rest of your comments, I will certainly take it back to the other dev team that owns the rest of our tools. We have been focusing on very specific integrations, Ansible and Terraform as the main two. But those rely on SDK's that are not shared between them (Ruby and Python). So the SDK's have to be updated first before attempting to leverage the functionality within the automation tools (Ansible or Terraform).

[rismoney]

That link was extremely helpful! I was not aware of Save-OVServerProfile cmdlet.

This might be a workable fix. I will test it against localStorage and some of the other attributes I was hoping to modify. This may provide a stop-gap until I can declaratively manage it using terraform or other CM tool. Thank you!

[ChrisLynchHPE]

Save-OVServerProfileTemplate and Save-OVServerProfile really are just similar calls to Set-OVResource. There are other Core Cmdlets, which are documented in the Library chapter of each release, and there is a diagram in the How to start using the library documentation section.

[rismoney]

This worked exactly as described.

Here is what I came up with-

Import-Module HPEOneView.420
Param(
  [string]$hostname,
  [string]$username,
  [string]$password,
  [string]$profile_template_name=""
  
)

$one_view_connection = Connect-HPOVMgmt -Hostname $hostname -UserName $username -Password $password
$ConnectedSessions

$spt = Get-HPOVServerProfileTemplate -Name $profile_template_name

$controller_settings = @(
  @{deviceSlot='Embedded';
    initialize=$false;
    logicalDrives = @(
      @{bootable=$true;
        name='OS';
        numPhysicalDrives=2;
        raidLevel="RAID1"
      }
    )
  mode='Mixed'}
  )


$currentstorage = $spt.localStorage
$currentstorage.complianceControl = "Checked"
$currentstorage.controllers = $controller_settings
Save-HPOVServerProfileTemplate -InputObject $spt | Wait-HPOVTaskComplete | fl *

[ChrisLynchHPE]

Glad to hear. Do know that HPE OneView 4.20 and associated libraries are no longer supported. So you should plan on updating OneView and your SDK's to current versions.