Skip to content
This repository has been archived by the owner on Jan 18, 2022. It is now read-only.

Refactored connection configuration & added alpha locator flow #646

Merged
merged 9 commits into from
Dec 14, 2018

Conversation

jessicafalk
Copy link
Contributor

@jessicafalk jessicafalk commented Dec 6, 2018

Description

Added the new alpha locator flow and refactored the Connection config as part of it.
Read in commit order:

  1. Simplifying configurations necessary for connections. The validation we have been doing was very basic (does that string contain anything), so removed them
  2. Updated Worker & WorkerConnectors and added new alpha locator flow
  3. removing tests

When is which flow chosen for the default worker connector?

  1. If we have a Login Token & a PIT -> Alpha Locator
  2. If we have Steam Credentials or only a Login Token -> Locator
  3. Else -> Receptionist

Tests

ran a cloud deployment, connected successfully

Documentation

none yet

Primary reviewers

@jamiebrynes7 @samiwh

@improbable-prow-robot improbable-prow-robot added do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. size/L Denotes a PR that changes 150-299 lines, ignoring generated files. labels Dec 6, 2018
@improbable-prow-robot improbable-prow-robot added size/XXL Denotes a PR that changes 600+ lines, ignoring generated files. and removed size/L Denotes a PR that changes 150-299 lines, ignoring generated files. labels Dec 7, 2018
@jessicafalk jessicafalk changed the title [WIP] new locator flow added alpha locator flow Dec 7, 2018
@improbable-prow-robot improbable-prow-robot removed the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Dec 7, 2018
@jessicafalk jessicafalk requested review from jamiebrynes7, samiwh and zeroZshadow and removed request for jamiebrynes7 December 7, 2018 15:40
@jessicafalk jessicafalk changed the title added alpha locator flow Refactored connection configuration & added alpha locator flow Dec 7, 2018
/// </summary>
/// <returns>True, if should connect via the Locator, false otherwise.</returns>
protected override bool ShouldUseLocator()
protected override ConnectionService GetConnectionService()
Copy link

Choose a reason for hiding this comment

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

Since this is getting more complicated now, why not accept a command line argument for connectionService? Then we assert the parameters using that. The logic within here is too magical at this point.

(Can be done in another PR, shall I make a ticket for it?)

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 launcher does not pass that argument in... so we would need to check for both cases:

  1. it is available
  2. it is not available

Copy link

Choose a reason for hiding this comment

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

Oh I see... will the launcher always be using a particular kind of service?

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 provides everything to use the alpha locator flow, but you can also use the normal locator flow

Copy link

Choose a reason for hiding this comment

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

discussed offline, looks good

protected override ConnectionParameters GetConnectionParameters(string workerType, ConnectionService service)
{
// UseExternalIp needs to be true when using the locator
var useExternalIp = service != ConnectionService.Receptionist || UseExternalIp;
Copy link

Choose a reason for hiding this comment

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

This should be service == this || service == that instead of service != other /* this imples it's this or that */ (if we add a new method it'll be a bug)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

good point!

DeploymentTag = steamDeploymentTag,
Ticket = steamTicket,
},
ProjectName = CommandLineUtility.GetCommandLineValue(
Copy link

Choose a reason for hiding this comment

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

What happens if project name is empty?

/// <param name="connectionFuture">The <see cref="Future{T}"/> of the <see cref="Connection"/> object that we use to connect to the SpatialOS Runtime.</param>
/// <param name="workerType">The type of the worker.</param>
/// <param name="logger">The logger used by the worker.</param>
/// <param name="origin">The position of the worker.</param>
Copy link

Choose a reason for hiding this comment

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

Why was the text changed from "the origin of this worker in local Unity space" changed to "The position of the worker"? The latter is more ambiguous

Copy link
Contributor Author

Choose a reason for hiding this comment

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

good point, will change back

/// <summary>
/// Stores the configuration needed to connect via the Alpha Locator.
/// </summary>
public struct AlphaLocatorConfig
Copy link
Contributor

Choose a reason for hiding this comment

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

Possibly better to swap these names around. If we know this one is definitely going to be the one we use going forward it might be better to call this the LocatorConfig and the other one the LegacyLocatorConfig.

Copy link
Contributor

Choose a reason for hiding this comment

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

Or we change the names to say what kind of tokens they are using. We can change this later though so it's not that big a deal.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Main reason why I call them that way is because the Worker SDK is calling them like that. The current locator flow is still the standard locator, while the new locator is in the alpha namespace

UseExternalIp = true,
},
EnableProtocolLoggingAtStartup = false,
DefaultComponentVtable = new ComponentVtable(),
Copy link
Contributor

Choose a reason for hiding this comment

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

This feels weird to be in the worker connector classes. I think it needs a larger refactor to get it out so there is no change to make for now, but it does feel weird.

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 don't find it too weird, as the worker connector takes care of specifying the exact connection logic, but I agree that we could probably separate it out a bit more. Gonna create a ticket to redesign this in the near future

/// <param name="logger">The logger used by this worker.</param>
/// <param name="origin">The origin of this worker in the local Unity space.</param>
/// <returns>A <see cref="Task{TResult}"/> to run this method asyncally and retrieve the created <see cref="Worker"/> object upon connecting successfully.</returns>
private static async Task<Worker> TryToConnect(Future<Connection> connectionFuture,
Copy link
Contributor

@samiwh samiwh Dec 13, 2018

Choose a reason for hiding this comment

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

Nit - All async functions should have the world Async in them. So this should be TryToConnectAsync.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

done

@jessicafalk jessicafalk merged commit 624dd24 into master Dec 14, 2018
@jessicafalk jessicafalk deleted the feature/pit branch December 14, 2018 15:04
jessicafalk pushed a commit that referenced this pull request Nov 15, 2019
* Cleanup pass

* Remove include
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
size/XXL Denotes a PR that changes 600+ lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants