Skip to content

Don't NullRef during Get-AzureDeployment when the cloud service has extended configuration #4788

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.

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

Merged
merged 5 commits into from
Nov 2, 2017

Conversation

spaoliello
Copy link
Contributor

@spaoliello spaoliello commented Oct 13, 2017

Description


This checklist is used to make sure that common guidelines for a pull request are followed. You can find a more complete discussion of PowerShell cmdlet best practices here.

General Guidelines

  • Title of the pull request is clear and informative.
  • There are a small number of commits, each of which have an informative message. This means that previously merged commits do not appear in the history of the PR. For more information on cleaning up the commits in your PR, see this page.
  • The pull request does not introduce breaking changes (unless a major version change occurs in the assembly and module).

Testing Guidelines

  • Pull request includes test coverage for the included changes.
  • PowerShell scripts used in tests should do any necessary setup as part of the test or suite setup, and should not use hard-coded values for locations or existing resources.

Cmdlet Signature Guidelines

  • New cmdlets that make changes or have side effects should implement ShouldProcess and have SupportShouldProcess=true specified in the cmdlet attribute. You can find more information on ShouldProcess here.
  • Cmdlet specifies OutputType attribute if any output is produced - if the cmdlet produces no output, it should implement a PassThru parameter.

Cmdlet Parameter Guidelines

  • Parameter types should not expose types from the management library - complex parameter types should be defined in the module.
  • Complex parameter types are discouraged - a parameter type should be simple types as often as possible. If complex types are used, they should be shallow and easily creatable from a constructor or another cmdlet.
  • Cmdlet parameter sets should be mutually exclusive - each parameter set must have at least one mandatory parameter not in other parameter sets.

@azuresdkci
Copy link

Can one of the admins verify this patch?

@cormacpayne
Copy link
Member

@azuresdkci add to whitelist

@@ -104,8 +105,18 @@ internal XElement Serialize()
{
XElement certificateElement = new XElement(this.ns + "Certificate");
certificateElement.SetAttributeValue("name", certificate.Key);
certificateElement.SetAttributeValue("thumbprint", certificate.Value.Thumbprint);
certificateElement.SetAttributeValue("thumbprintAlgorithm", certificate.Value.ThumbprintAlgorithm);
if (certificate.Value.Thumbprint != null)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could certificate.Value be null?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No. It's a value driven by the foreach loop over existing elements.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I meant this.Certificates is of type Dictionary<string, CertificateConfiguration>();. and the for loop make sure that variable "certificate" is not null... I wonder if "certificate.Value' can be null.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh, I see what you're asking.
Certificates.value won't be null because in the deserializer where it's set up, an element to the Dictionary is only added after the CertificateConfiguration object is created using an Object Initializer (so it can't be null).
See lines 44-53.

}
if (certificate.Value.ThumbprintAlgorithm != null)
{
certificateElement.SetAttributeValue("thumbprintAlgorithm", certificate.Value.ThumbprintAlgorithm);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would it be better to define a constant string instead of using hard coded string literals?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was following the existing pattern of the file. There are no constants at all.

@cormacpayne cormacpayne removed their assignment Oct 18, 2017
@markcowl
Copy link
Member

markcowl commented Oct 23, 2017

@spaoliello @vanbasten2323 The PR is failing for CredScan issues. Go to http://aka.ms/credscan for information on suppressing any false positives. The report is here: https://azuresdkci.westus2.cloudapp.azure.com/job/powershell/70/artifact/src/Package/credscan-matches.tsv

@spaoliello
Copy link
Contributor Author

Tests were added, and are passing.

@cormacpayne
Copy link
Member

@hyonholee @vanbasten2323 would one of you be able to sign off on the changes made by Simon?

@@ -224,6 +224,13 @@
<None Include="Resources\DiagnosticsExtension\Files\diagnostics.wadcfgx">
<CopyToOutputDirectory>Always</CopyToOutputDirectory>
</None>
<None Include="Resources\ServiceManagement\Files\dSMSTest.cscfg">
<SubType>Designer</SubType>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

you don't need this line ..., do you?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, I think Visual Studio added it automatically.
I can remove it.

</ConfigurationSettings>
<Certificates>
<Certificate name="ThumbprintCert" thumbprint="{{PLACEHOLDER}}" thumbprintAlgorithm="sha1" />
<Certificate name="dSMSCert" sourceLocation="/genevacustomers/monitoring/prod/warmpath/test/auxweb/certificates/chained/portaldogfoodmdscert.pfx" />
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The relative sourceLocation works if you are using RDFE to perform deployments. It will automatically use the closest dSMS server location.
I tested this deployment with that format and it does work.

$result = New-AzureDeployment -ServiceName $svcName -Package $cspkg -Configuration $cscfgChanged -Label $svcName -Slot Staging;

# Get Deployment
$deploy = Get-AzureDeployment -ServiceName $svcName -Slot Staging;
Copy link
Contributor

@vanbasten2323 vanbasten2323 Oct 25, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So before the change, if the you have a line in cscfg like: , then you would get null ref error when you create a new deployment. Is my understanding correct?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes. If you didn't supply a thumbprint attribute, it would NullRef when you perform Get-AzureDeployment

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Then shouldn't the NullRef exception be thrown when you do New-AzureDeployment? The PR topic says the exception happens when you do Get-AzureDeployment

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The NullRef was only thrown when I ran Get-AzureDeployment. The test goes through CRUD to ensure it's not occurring anywhere else. I'd rather have extra coverage :)

$newConfig | Set-Content $cscfgChanged;

# Update configuration
$result = Set-AzureDeployment -Config -ServiceName $svcName -Configuration $cscfgChanged -Slot Staging;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do you need to get a new config and do a Set-AzureDeployment on the new config? I don't quite understand.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's to test round-trip. Deploy (tests New) Get (tests Get) Update (tests Set).
I wanted to make sure all parts could handle config without thumbprints.

@vanbasten2323
Copy link
Contributor

Looks good to me.

@markcowl
Copy link
Member

markcowl commented Nov 1, 2017

@vanbasten2323 Can you sign off based on the responses to your comments?

@vanbasten2323
Copy link
Contributor

@markcowl Approved. Sorry for the delay. It's my first time to approve the PR on GitHub. Was not familiar with the approve procedure before.

@markcowl
Copy link
Member

markcowl commented Nov 2, 2017

@vanbasten2323 Thanks for the review.

LGTM to me as well.

On demand pr here: https://azuresdkci.westus2.cloudapp.azure.com/view/PowerShell/job/powershell-demand/114/

@cormacpayne cormacpayne merged commit 8f54a4b into Azure:preview Nov 2, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants