ref: #88 (comment)

cc: @tariq1890
/help

We need to create an Issue template for this project. This can be something similar to the one found in the AWS provider of cluster-api

https://github.com/kubernetes-sigs/cluster-api-provider-aws/tree/master/.github

Good first issue.

/kind feature

Describe the solution you'd like
ref: #88 (comment)

Not necessary for this PR, as this is intended to be the last of refactor-heavy changes. We should definitely be looking into moving this method into a different package. I say this because this method has a high potential for reusability.

cc: @tariq1890
/help

/kind bug

Fixed in #99
ref: #92

What steps did you take and what happened:
[A clear and concise description of what the bug is.]

What did you expect to happen:

Anything else you would like to add:
[Miscellaneous information that will assist in solving the issue.]

Environment:

• cluster-api-provider-azure version: v0.1.0-alpha.3
• Kubernetes version: (use kubectl version): 1.13.3
• OS (e.g. from /etc/os-release): Ubuntu 18.04

/assign

Who owns the azure pipeline for this project? https://dev.azure.com/Cluster-API-Provider-Azure/Cluster-API-Provider-Azure%20Project/_build?definitionId=1, seems like it requires to switch to new project https://github.com/kubernetes-sigs/cluster-api-provider-azure

I did a bad thing in #68 and commented out the cluster and machine actuator tests, because the associated code had been fully refactored and the current code doesn't fit the old tests.

We've got to rewrite new tests ASAP.
/help
/priority critical-urgent
/cc @tariq1890 @soggiest

• Figure out a better way to bootstrap Kubernetes on the VMs
• Remove unused parts of the startup script

cluster-api upstream moved away from being aggregator-based to kube builder.

ref: #92
/milestone baseline
/assign

We need to define granular objectives so that the community is aware of the project's plan and future.

/kind feature

ref: #92, https://github.com/kubernetes-sigs/cluster-api-provider-azure/pull/88/files#r259902819

Describe the solution you'd like
[A clear and concise description of what you want to happen.]

Anything else you would like to add:
[Miscellaneous information that will assist in solving the issue.]

Environment:

• cluster-api-provider-azure version: v0.1.0-alpha.3
• Kubernetes version: (use kubectl version): 1.13.3
• OS (e.g. from /etc/os-release): Ubuntu 18.04

/help

Now that the project has been migrated into k-sigs, we need to define GitHub admins and maintainers.
/assign

Resources (VM + NIC public IP) are hard-coded to Zone 3

/kind feature
/assign
/milestone next

Right now, the machine's actuator Delete function deletes the entire resource group associated with it.

This should be updated to only delete the resources associated with the VM (OS Disk, Public IP address, virtual machine).

Implement both Delete and Reconcile operations.

Possible refactor: Move the creation of the network SG and NIC to be cluster actuator's responsibility instead of doing it as part of the machine deployment.

A check that validates that every go file has a license header.

For reference check : https://github.com/prometheus/prometheus/blob/7f7b21104734fd1c7a5d2b3bc812da96cd7c35a3/Makefile.common#L110

/good-first-issue

This overlaps with #11 with an emphasis on getting feedback on PRs quickly. In particular, we want to be able to do automated runs with gofmt, dep ensure, plus other useful static code analysis tools.

/kind feature
/assign
/milestone next

As per the discussion here: #17 (comment)

This would create a top-level AzClients interface hosting different operation groups from the Azure REST API

/kind feature

Fixed in #99
ref: #92

Describe the solution you'd like
[A clear and concise description of what you want to happen.]

Anything else you would like to add:
[Miscellaneous information that will assist in solving the issue.]

Environment:

• cluster-api-provider-azure version: v0.1.0-alpha.3
• Kubernetes version: (use kubectl version): 1.13.3
• OS (e.g. from /etc/os-release): Ubuntu 18.04

/assign

/kind feature

ref: #92

Describe the solution you'd like
[A clear and concise description of what you want to happen.]

Anything else you would like to add:
[Miscellaneous information that will assist in solving the issue.]

Environment:

• cluster-api-provider-azure version: v0.1.0-alpha.3
• Kubernetes version: (use kubectl version): 1.13.3
• OS (e.g. from /etc/os-release): Ubuntu 18.04

/assign

As per #17, we could move this to the controller package and pass this to the actuators

/kind feature

ref: #92

Describe the solution you'd like
[A clear and concise description of what you want to happen.]

Anything else you would like to add:
[Miscellaneous information that will assist in solving the issue.]

Environment:

• cluster-api-provider-azure version: v0.1.0-alpha.3
• Kubernetes version: (use kubectl version): 1.13.3
• OS (e.g. from /etc/os-release): Ubuntu 18.04

/help

As we move through a few refactoring efforts (#68, #88), it's a good time to capture some of the work required to bring us to a MVP capz implementation.

Here are some known issues that we'd want to resolve for the mvp:

• (#100) master builds (i.e., make binaries-dev works), but doesn't result in a working cluster
• (#97) Repo versioning
• (#98) Document development process
• (#101) capz needs to be deployed in a region that supports Availability Zones
  • Resources (VM + NIC public IP) are hard-coded to Zone 3
• (#102) VM cannot be attached to backend pool (NIC needs to either use a Standard SKU PIP or not have a PIP attached) & backend pool reconciliation code doesn't exist
• (#103) Store public IP DNS name in Cluster object for use in machine scripts (includes updating associated types)
• (#104) Control plane VM is open to the internet
• (#105) Subnets + NSGs: ReconcileNetwork should implement two subnets, control plane and node, with NSGs scoped to the role
• (#106) Implement/update delete methods for Cluster/Machine objects

Additional things to consider, but are not strictly required for mvp:

• (#107) Investigating using distroless/static for image building (https://github.com/kubernetes-sigs/cluster-api-provider-azure/pull/88/files#r259902819)
• (#108) Update Makefile
• (#109) Types need to be updated (+ regenerate deepcopy, CRDs, RBAC)
• (#110) Minimize calls to Azure by storing more information in Cluster & Machine objects
• (#111) Update helper packages (tokens, certificates, etc.)
• (#112) Dedupe dependencies and move startup scripts to cloud-init
• (#113) Investigate VMSS (Virtual Machine Scale Sets)
• (#114) Hard-coded parameters
• (#94) Improve logging
• (#115) More intelligent reconcile logic for subresources

I'll get these into their own issues; just wanted to open this umbrella as a starting point.

/milestone mvp
/cc @soggiest @tariq1890

/kind bug

Partially addressed in #99
ref: #92

What steps did you take and what happened:
[A clear and concise description of what the bug is.]

What did you expect to happen:

Anything else you would like to add:
[Miscellaneous information that will assist in solving the issue.]

Environment:

• cluster-api-provider-azure version: v0.1.0-alpha.3
• Kubernetes version: (use kubectl version): 1.13.3
• OS (e.g. from /etc/os-release): Ubuntu 18.04

/assign

Once the API is stable, consider moving from storing the status in annotations to the Machine ProviderStatus field

• Do master updates to kubelet and control panel versions in place
• For node updates, delete current node and recreate

/kind feature

ref: #92

Describe the solution you'd like
[A clear and concise description of what you want to happen.]

Anything else you would like to add:
[Miscellaneous information that will assist in solving the issue.]

Environment:

• cluster-api-provider-azure version: v0.1.0-alpha.3
• Kubernetes version: (use kubectl version): 1.13.3
• OS (e.g. from /etc/os-release): Ubuntu 18.04

/help

Follow the code here: kubernetes-sigs/cluster-api-provider-aws#543

/help
/milestone baseline

This project needs a headline ;)

/kind bug

ref: #92

What steps did you take and what happened:
[A clear and concise description of what the bug is.]

What did you expect to happen:

Anything else you would like to add:
[Miscellaneous information that will assist in solving the issue.]

Environment:

• cluster-api-provider-azure version: v0.1.0-alpha.3
• Kubernetes version: (use kubectl version): 1.13.3
• OS (e.g. from /etc/os-release): Ubuntu 18.04

/kind feature

ref: #92

Describe the solution you'd like
[A clear and concise description of what you want to happen.]

Anything else you would like to add:
[Miscellaneous information that will assist in solving the issue.]

Environment:

• cluster-api-provider-azure version: v0.1.0-alpha.3
• Kubernetes version: (use kubectl version): 1.13.3
• OS (e.g. from /etc/os-release): Ubuntu 18.04

/help

/kind feature

ref: #92

Describe the solution you'd like
[A clear and concise description of what you want to happen.]

Anything else you would like to add:
[Miscellaneous information that will assist in solving the issue.]

Environment:

• cluster-api-provider-azure version: v0.1.0-alpha.3
• Kubernetes version: (use kubectl version): 1.13.3
• OS (e.g. from /etc/os-release): Ubuntu 18.04

/help

Refer to https://goreportcard.com/report/github.com/kubernetes-sigs/cluster-api-provider-azure

/good-first-issue

We need to skip e2e tests when the KUBECONFIG env var is not present. Please use t.Skip() for this.

This is the test that needs skipping:

FIrst crack at parity with other cluster-api projects here: kubernetes/test-infra#10670
There's still some work to be done to assess the appropriate plugins for the project.

/assign

ref: #92
/milestone baseline
/assign

/kind feature

ref: #92

Describe the solution you'd like
[A clear and concise description of what you want to happen.]

Anything else you would like to add:
[Miscellaneous information that will assist in solving the issue.]

Environment:

• cluster-api-provider-azure version: v0.1.0-alpha.3
• Kubernetes version: (use kubectl version): 1.13.3
• OS (e.g. from /etc/os-release): Ubuntu 18.04

/assign

Some features that may be worthwhile for the project (especially for integration tests):

• Unlimited CI/CD minutes
• 10 parallel jobs for free
• Microsoft hosted agents for all OSes
• Extensions marketplace

One downside with Azure Pipelines is the inability to cache files across subsequent runs of the same pipeline. There might be less need for this cache, given the unlimited CI times

Upsides of Travis is that jobs can cache files to be used by other jobs/builds and downsides are the 50 minute time limit per job and max 5 concurrent builds

The integration tests are currently triggered manually after a preliminary code review.

It would be nice to have this somewhat automated. Previously, Travis was set to trigger builds on PRs (before the repo was made public). However, there are a few issues with this. Most importantly, a PR could contain specially crafted code to dump secrets/POST them to some server somewhere.

In addition, we could probably split the integration tests and the unit tests.

Add relevant links and documents that cover the following:

1. Code Style Guidelines

The integration tests at the moment aren't covering Kubernetes functionality. Maybe add Kubernetes conformance tests as part of an integration test? Use https://github.com/heptio/sonobuoy

Right now, we are using golang:1.10.3 as the base builder image. We should be using a more recent version in our docker build manifest

This is a good first issue.

We need to create a PR template for this project. This can be something similar to the one found in the AWS provider of cluster-api

https://github.com/kubernetes-sigs/cluster-api-provider-aws/tree/master/.github

Good first issue.

/assign

Dep check seems to have been removed with the new bazel artifacts. We need to add a new Makefile check so that dep check is made available for use in the CI cycles.

Describe the solution you'd like
The goals are two-fold here:

1. Adopt a consistent pattern/interface for retrieving/modifying/deleting Cluster/Machine/Azure resources
2. Minimize calls to Azure by storing more information in Cluster & Machine objects

For each actuator reconciler, we currently have Reconcile and Delete methods which operate over the lower-level Azure resources.

Instead of handling implementation details in the top-level reconciler, we should scope them to the resources that they're operating over. As an example, a SubnetSpec should instead be generated/manipulated by a subnet reconciler:

As a concrete reference, see the ReconcileNetwork() method for Cluster API Provider AWS.

A secondary problem is that in our current actuator reconciler model, we make a variety of Create/Update calls to the Azure API, in instances where a Get would suffice. This means we're attempting to modify a majority of the Azure resources we create on every round-trip of a reconciler.

Finally, we do not fully utilize the defined types in the capz API, instead accepting an ambiguous spec and returning a loosely-defined interface, instead of a concrete type.

This means that we are required to query Azure for cluster/machine information, instead of being able to reference the ClusterSpec, ClusterStatus, MachineSpec, and MachineStatus directly, which should be our sources of truth.

As a solution, we can:

• Redefine the Service interface to present only Reconcile and Delete methods
• Add a temporary interface (GetterService) to represent packages that don't adhere to the Reconcile/Delete model
• Refactor packages to adhere to Reconcile/Delete model, which will convert and store Azure resource information in the relevant Spec or Status
• Redefine package-level CreateOrUpdate/Gets as unexported methods (only to be used by the package-level Reconcile/Delete)
• Remove references to unexported methods from the top-level reconcilers
• Remove the temporary GetterService interface

The work to accomplish this has begun in #174.

ref: #92
/kind feature

ref: #88 (comment)

cc: @tariq1890
/help

Since we are using prow jobs, we should now remove files related to Azure Pipelines as well as the badge!