Skip to content
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

Added telemetries #7474

Merged
merged 8 commits into from
Jun 19, 2018
Merged

Added telemetries #7474

merged 8 commits into from
Jun 19, 2018

Conversation

kuvinodms
Copy link

No description provided.


[Parameter(ParameterSetName = "ApplicationParameterFilePath")]
[Parameter(ParameterSetName = "ApplicationName")]
[ref]$status
Copy link
Contributor

Choose a reason for hiding this comment

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

$status is good candidate global variable - then you won't need to pass along.

Copy link
Author

Choose a reason for hiding this comment

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

Lets us PassByReference as its more controlled and always safer then to use Global variable

Copy link
Author

Choose a reason for hiding this comment

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

Passing an extra optional parameter (with reference) still seems fine to me as there is no extra memory usage

Copy link
Contributor

Choose a reason for hiding this comment

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

In this case there does not seem to be usual problems related to global variables. Before execution a command will set status and that will always be the truth - we don't have multi-threading or parallelization in our flow.
I am in favor of global as code will be cleaner without need to pass $status everywhere.

Copy link
Author

Choose a reason for hiding this comment

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

Using global variable now.

@@ -142,6 +146,7 @@

if (!$SkipPackageValidation)
{
$status.value = "NewApp-TestingApplicationPackage"
$packageValidationSuccess = (Test-ServiceFabricApplicationPackage $AppPkgPathToUse)
Copy link
Contributor

Choose a reason for hiding this comment

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

Let's remove redundant Test-. Keep it only in deploy.ps1

Copy link
Author

Choose a reason for hiding this comment

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

Will raise a separate PR for the same

Copy link
Contributor

Choose a reason for hiding this comment

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

Please file an issue for that - otherwise we will miss it.

Copy link
Author

Choose a reason for hiding this comment

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

if (!$?)
{
throw (Get-VstsLocString -Key SFSDK_UnableToUnregisterAppType)
}
$ApplicationTypeAlreadyRegistered = $false
Copy link
Contributor

Choose a reason for hiding this comment

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

why this change?

Copy link
Author

Choose a reason for hiding this comment

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

Its a bug since !$? check for last command ran successfully or not and $ApplicationTypeAlreadyRegistered = $false is not the one for which we're checking for

@@ -230,6 +236,7 @@
# It will unregister the existing application's type and version even if its different from the application being created,
if ((Get-ServiceFabricApplication | Where-Object {$_.ApplicationTypeVersion -eq $($app.ApplicationTypeVersion) -and $_.ApplicationTypeName -eq $($app.ApplicationTypeName)}).Count -eq 0)
{
$status.value = "NewApp-UnregisteringApplicationType"
Copy link
Contributor

Choose a reason for hiding this comment

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

Rather than settings similar status multiple places, you can move it to separate method and call it from both New/upgrade file. I don't think adding "NewApp-" or "UpgradeApp-" prefix is necessary.

Copy link
Author

@kuvinodms kuvinodms Jun 15, 2018

Choose a reason for hiding this comment

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

Adding these prefixes will give us clear idea about the code flow without any need to look in other trace to decide whether code is in Create flow or Upgrade flow.
Lets keep it!

Copy link
Contributor

Choose a reason for hiding this comment

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

Do we really need to know whether it is upgrade or new when lets say registering the package? This information seems to be redundant.
On the positive side we will be able to move code to common functions and re-use them.

Copy link
Author

Choose a reason for hiding this comment

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

Removing it in the hope that we don't need to know whether code failed in CreateApp or UpgradeApp.

} finally {
}
catch {
Write-Telemetry "Task_InternalError" "TaskStatus: $status | Exception: $_.Exception.GetType().FullName"
Copy link
Contributor

Choose a reason for hiding this comment

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

Remove words "TaskStatus:" and "Exception:". We can use convention to have status and exception type separated by | without any space.

Copy link
Author

Choose a reason for hiding this comment

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

Used it for readability. If you don't see any use then lets remove it.

Copy link
Contributor

Choose a reason for hiding this comment

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

It is redundant. As we will never need to see full string. We will always query this data via kusto and it is easier to write query without these extra characters

}
catch {
Write-Telemetry "Task_InternalError" "TaskStatus: $status | Exception: $_.Exception.GetType().FullName"
}
Copy link
Contributor

Choose a reason for hiding this comment

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

Don't you need to re-throw?

Copy link
Author

Choose a reason for hiding this comment

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

Yes we need to re throw


$global:operationId = $SF_Operations.Undefined
Copy link
Member

Choose a reason for hiding this comment

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

why undefined?

Copy link
Member

Choose a reason for hiding this comment

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

Shouldn't it be connect?

Copy link
Contributor

Choose a reason for hiding this comment

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

it is set to connect in Connect helper Connect-ServiceFabricClusterFromServiceEndpoint.ps1

@@ -107,11 +111,13 @@ try {

if (!$skipValidation)
{
$global:operationId = $SF_Operations.TestApplicationPackage
Copy link
Member

Choose a reason for hiding this comment

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

Should we add Get Application as operation as well

Copy link
Contributor

Choose a reason for hiding this comment

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

Vinod did not add it initially. I am not sure whether he had a reason. But I agree ideally we should add.

Copy link
Contributor

Choose a reason for hiding this comment

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

done

Copy link
Contributor

Choose a reason for hiding this comment

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

Added a few other missing as well

}
$erroCode = ('"{0}":{1}' -f $erroCodeMsg, $errorMsg)
## Form errorcode as json string
$erroCode = '{' + $erroCode + '}'
Copy link
Member

Choose a reason for hiding this comment

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

variable name can be improved

Copy link
Contributor

Choose a reason for hiding this comment

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

}
$erroCode = ('"{0}":{1}' -f $erroCodeMsg, $errorMsg)
## Form errorcode as json string
$erroCode = '{' + $erroCode + '}'
Copy link
Member

Choose a reason for hiding this comment

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

This doesn't ensure json string if char escaping etc is required. Use native ways to genrate the json

Copy link
Contributor

Choose a reason for hiding this comment

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

done.

do
{
$exceptionTypes += $exception.GetType().FullName + ";"
$exception = $exception.InnerException
Copy link
Member

Choose a reason for hiding this comment

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

Consider handling AggregateException as well

@bishal-pdMSFT bishal-pdMSFT merged commit 0ed8fab into master Jun 19, 2018
bishal-pdMSFT added a commit that referenced this pull request Jun 19, 2018
* Added telemetries

* Updating reference values

* Updated code as per review comments

* Adding a text message before force removing application package

* Modified code as per review comments

* re-factor telemetry to common code and re-use across all SF tasks

* make.json changes

* PR comments

# Conflicts:
#	Tasks/ServiceFabricDeployV1/task.json
#	Tasks/ServiceFabricDeployV1/task.loc.json
bishal-pdMSFT added a commit that referenced this pull request Jun 20, 2018
* Added telemetries

* Updating reference values

* Updated code as per review comments

* Adding a text message before force removing application package

* Modified code as per review comments

* re-factor telemetry to common code and re-use across all SF tasks

* make.json changes

* PR comments

# Conflicts:
#	Tasks/ServiceFabricDeployV1/task.json
#	Tasks/ServiceFabricDeployV1/task.loc.json
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.

5 participants