Batch first OM based cmdlet

[jasper-schneider]

• Batch PowerShell data models and tool to generate them
• Infrastructure for cmdlets based on the Batch OM
• Get-AzureBatchWorkItem cmdlet + some unit tests

[azuresdkci]

Can one of the admins verify this patch?

[azurecla]

Hi @jasper-schneider, I'm your friendly neighborhood Azure Pull Request Bot (You can call me AZPRBOT). Thanks for your contribution!

It looks like you're working at Microsoft (jaschnei). If you're full-time, we DON'T require a contribution license agreement.

If you are a vendor, or work for Microsoft Open Technologies, DO please sign the electronic contribution license agreement. It will take 2 minutes and there's no faxing! https://cla.azure.com.

TTYL, AZPRBOT;

[stankovski]

@azuresdkci add to whitelist

[stankovski]

@azuresdkci test this please

[matt-gibbs]

Should follow up with Yugang on the changes to move all xunit use to the package instead of the extension.

[jasper-schneider]

I'll send him mail.

[ogail]

All code inside cmdlets including checks and everything should be wrapped in the client. For example, this class should be (using ExecuteCmdlet as this is the expected method)

public override void ExecuteCmdlet()
{
    WorkItemsFilterOptions options = new WorkItemsFilterOptions { Name = Name, Filter = Filter };
    BatchClient.GetWorkItem(
}

Please fix this pattern in all future cmdlets

[jasper-schneider]

Updated to using ExecuteCmdlet()

Regarding putting everything into a client method, how does that work when the two parameter sets have different output types (single object vs. collection object)? I'd rather not have the method have output type object, so it seems like I need to do some parameter processing in the cmdlet to choose the correct client method. Looking at Storage's Get-AzureStorageBlob for example, it seems like they're doing something similar with choosing the method to use based on parameter set. Is there a different example I should be following?

[ogail]

In this case, your conv. method will return collection and you need to call write object with true flag. PowerShell will handle the single/multiple case:

WriteObject(collection, true);

[jasper-schneider]

Hmm, I'd prefer to call WriteObject(collection, false) in the case that I'm actually returning a collection. We have a custom enumerator that has some features that let it handle large scale data sets pretty well, such as only querying the service in chunks when the enumerator is actually being iterated through and supporting parallel iteration very well. Walking through the entire collection up front removes some of these benefits.
Would this level of logic in the cmdlet be ok?
if (name not null) { WriteObject(client.GetSingleItem()); }
else { WriteObject(client.GetCollection(), false); }

[ogail]

• Add a mocked scenario test
• Remove the code generation tool code

[jasper-schneider]

Removed code gen tool.

Regarding the mocked scenario tests, the Batch OM isn't built on top of Hyak yet, so it doesn't hook into the Http interceptor. We do have a plan to replace the Batch OM REST layer with Hyak in the future, in which case we should get this behavior.
We discussed this a bit at our last meeting, but we haven't used Hyak yet because of the way Batch auth works using signed headers. We heard there's a supported way to add delegates to update the header, and we're in the process of investigating this, but we're not there yet.
We do have our own live scenario test system in place that we will be adding to as we move forward.
Feel free to email me and Charlie if you'd like to discuss this further.

[markcowl]

@azuresdkci test this please

[markcowl]

@jasper-schneider We cannot accept this PR that adds such an olde version of storage to the ARM clients. Please upgrade to a later version of storage and submit for the next release (end of Feb).

[ogail]

@jasper-schneider these tests are for guarding your cmdlets in case a change happened in PowerShell code so people can verify the change without need for pinging every single service team