QUESTION: Is local process with Kubernetes complimentary to Dev Spaces or a replacement?

[clawrenceks]

I am sure this information must exist somewhere, but I am unable to find any specific guidance. Is the new Local Process with Kubernetes feature designed to complement Azure Dev Spaces (e.g. both should be used together) or is it designed as the next generation replacement for Azure Dev Spaces?

There seems to be little material describing which of the two options should be used, although I see in the Azure Portal that the Local Process with Kubernetes Feature is the default offering now.

[Gordonby]

Hi Chris Lawrence (@clawrenceks)
LPK is a simpler solution to many of the development scenarios that Dev Spaces currently fulfils. We're working hard on new features for LPK, and hopefully for many it will be suitable, easier tooling for their iterative development needs.

Once we've gathered more feedback form customers about LPK and released some of the features we're working on, we'll be in a good place to add to the documentation about which tooling is better for different scenarios.

[Cpcrook]

Gordon Byers (@Gordonby) Not sure if this is the correct venue, but until LPK supports Linux, is it possible to re-enable AZDS Connect menu options in the VSCode extension?

We're using AZDS within Linux dev containers, and the lack of ability in VSCode to pin extension versions means we're SOL for support at the moment.

[Gordonby]

Hi Chris Crook (@Cpcrook), i think greenie-msft has been emailing you about this point.
Can you let me know the disto/version of linux you're using?

[Cpcrook]

Hi Gordon Byers (@Gordonby) -- our dev containers are running on a Docker image based on the dotnetcore 3.1 sdk image here which is Debian 10. We add Azure CLI to that, and run an automatic task on folder open to login to AKS, install kubectl, setup dev spaces.

We were relying on the "clone" service redirection story previously. I think we have a workaround for now (as long as the CLI continues to support the functionality in the older extension version). We've reverted back to the Azure Dev Spaces extension version 2.0.220200514 using the workaround pertaining to broken extension downgrades noted here. Seems to work for now with:

azds --version

Azure Dev Spaces CLI
1.0.20200707.1
API v3.2

Just a bit inconvenient as the extension downgrade dance has to be done any time a dev container is rebuilt.

[PashaPash]

Chris Lawrence (@clawrenceks) according to the latest doc update, it is no longer possible to use Local Process together with Dev Spaces:

You can't use Local Process with Kubernetes on a cluster with Azure Dev Spaces enabled. If you would like to use Local Process with Kubernetes on a cluster with Azure Dev Spaces enabled, you must disable Azure Dev Spaces before connecting to your cluster.

Gordon Byers (@Gordonby) is there any plans to re-enable Local Process debugging for AZDS-enabled clusters? We are migrating to AKS / Dev Spaces from per-developer local docker installations, and shared base space + Local Process debugging is a primary usecase for us.

[greenie-msft]

Hi Pavel Pachobut (@PashaPash),

At the moment, there is no plan to re-enable LPK routing on a Dev Spaces enabled AKS cluster.

Can you provide additional details as to why Local Process with Kubernetes and the isolation mode that comes with it does not fulfill your development requirements? Similarly to Dev Spaces routing, the isolation mode in LPK allows developers to work in a shared environment.

[PashaPash]

greenie-msft we have 30+ services project, the plan was to

• host latest (master) version of all services in shared space
• allow QA to upload PR-based service builds to their child spaces (so they will test on all masters + one service PR, similar to Github Actions case from the documentation)
• allow developers to work on same shared space + LPK for the service they need to develop / debug locally

Without LPK routing on AKS we have to keep to separate clusters for QA (with Dev Spaces) and for Dev (LPK).
Not a blocker, but adds some overhead - we have to keep shared space up to date on both clusters, and we also have to pay for two clusters.

[greenie-msft]

Hi Pavel Pachobut (@PashaPash),

Thank you for the additional details.

I should clarify my earlier comment - I'm referring to our new routing capability when I say "isolation mode" in LPK. Here is a doc explaining this capability: https://aka.ms/lpk-isolation

Does this help meet your requirements?

Please let me know if you have any other questions.

[PashaPash]

Hi greenie-msft,

"isolation mode" in LPK does not cover base usecase for QA. QA does not have local version, their deployments should be fully hosted on aks.

• QA needs fully hosted environment with ability to override a single deployment via CD (exactly as described at https://docs.microsoft.com/en-us/azure/dev-spaces/how-to/github-actions). They don't have local processes, don't have local dev tools installed, no source code checked out locally. They need an ability to override a single aks deployment and host an overridden service / pod on aks. That is exactly what DevSpaces allows to do, and LPK does not.
• Dev needs the same hosted environment, but with ability to isolate and route a single service traffic to their own PC. LPK does that, but DevSpaces does not allow that anymore.

Cluster should be either in LPK mode (no hosted overriden containers, not suitable for QA), or in DevSpaces mode (no local debugging, not suitable for Dev).

I understand that local process debugging in DevSpace was a preview, so up to your team to drop it without notice. Just curious what was the reason to drop a really developers-oriented feature out of DevSpaces - as that actually turned DevSpaces into QaSpaces for us.

[Cpcrook]

Pavel Pachobut (@PashaPash) the use case you described sounds like what review apps are designed to accomplish -- they defer and route traffic from unchanged services to the parent space, but route traffic to a modified service to the updated deployment, allowing testing to proceed against the changed service(s) while still allowing those to interact with any unmodified services on which they depend.

You'd have CI/CD pipelines setup to deploy a review app to a new Kubernetes namespace (say, specific to a PR). Traffic to services not modified as part of that PR would go to the parent namespace.

[PashaPash]

Chris Crook (@Cpcrook) yes, quite close to review apps. But we also need traffic flow back from the parent namespace to some modified service, depending on initial request url. DevSpaces seems to be a closest match.

[andrewsali]

Is review apps also available via github actions? (dev spaces supports this QA/review functionality using github)

…

On Thu, Aug 6, 2020, 18:55 Pavel Pochobut ***@***.***> wrote: @Cpcrook <https://github.com/Cpcrook> yes, quite close to review apps. But we also need traffic flow back from the parent namespace to some modified service, depending on initial request url. DevSpaces seems to be a closest match. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#366 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADTBRJ3BIYRCE7WN5RK4VF3R7LN67ANCNFSM4OKXMXEQ> .

[greenie-msft]

Hi Pavel Pachobut (@PashaPash),

Thank you for further clarifying your requirements.

The isolation mode in LPK takes advantage of our new routing capability. It is currently limited to the LPK experience, but we will soon support enabling routing independently. This will allow you to use routing for additional scenarios outside of the LPK workflow (e.g. GitHub Actions PR Flow). We also plan to publish an improved PR Flow which will use our new routing implementation.

The combination of what I've described above will allow you to achieve the same value as our traditional Routing/PR Flow experiences. QA will be able to test code changes in the cluster outside of the developer experience.

I'll keep this thread live and provide an update as soon as we release and document these scenarios.

If you have any further questions, please feel free to reach out via email:
Nicholas.Greenfield@microsoft.com

Thank you,
Nick