I create one compute instance 'yhd-notebook' in Azure Machine Learning compute with user1. When I login with user2, and try to open the JupyterLab of this compute instance, it shows an error message like below.
User user2 does not have access to compute instance yhd-notebook.
Only the creator can access a compute instance.
Click here to sign out and sign in again with a different account.
Is it possible to share compute instance with another user? BTW, both user1 and user2 have Owner role with the Azure subscription.
According to MS, all users in the workspace contributor and owner role can create, delete, start, stop, and restart compute instances across the workspace. However, only the creator of a specific compute instance is allowed to access Jupyter, JupyterLab, and RStudio on that compute instance. The creator of the compute instance has the compute instance dedicated to them, have root access, and can terminal in through Jupyter. Compute instance will have single-user login of creator user and all actions will use that user’s identity for RBAC and attribution of experiment runs. SSH access is controlled through public/private key mechanism.
Expanding a little on #hui chen's useful answer.
Although you can't share computer instances from azure's web interface you can access the compute instance's jupyter directly by sshing into them (note that ssh runs on port 50000). jupyter runs on port 8888.
I haven't experimented with the filesystem synchronization yet... so be careful. Also none of this is guaranteed.
Related
currently I have some prblem about my DataBricks workspace when an user was deleted and it cause some issue:
Applications or scripts that use the tokens generated by the user will no longer be able to access the Databricks API
Jobs owned by the user will fail
Clusters owned by the user will stop
Queries or dashboards created by the user and shared using the Run as Owner credential will have to be assigned to a new owner to prevent sharing from failing
How can I keep these resource operate normaly ?
How can I keep these resource operate normaly ?
The main solution for this is to use service principals instead of user identity for all production clusters/jobs/SQL queries/dashboards/...
Databricks documentation has a dedicated article about use of the service principals.
When submitting an aml compute job, I want to access the nodes where the compute happens for debugging purposes. The portal gives me the IP address, the port and the nodeID, but no password seems to exist within the portal.
How am I supposed to connect to the machine?
I am running on NC6 machines for a single node training. I have already tried to run the command given through the portal, but the node is (hopefully so) protected by a password.
In order to be able to log in to the nodes of an AML Compute cluster, you have to provide a username and password and ssh key (ssh key is optional), when you create the cluster. You can only do that at creation time.
When you are setting up your cluster, you can define a username/password/ssh key that can be used to login to the cluster. If you did not define these at the time of creation, you would need to recreate the cluster unfortunately.
We are working on better documenting this, and also update our messaging a bit.
i have created one windows machine in my hyper-v after sysprep i have upload my VHD to azure account
when i am trying to login that windows machine i am unable to login the account getting disable
can any one please let me know how to login into that machine in azure account
In Adv Thanks.
Of course it is disabled.
sysprep is designed to put the OS into OEM state. All local accounts and user profiles are deleted. Because it will be the base image for all your future VMs.
This process creates a so called generalized image. The process is described here. You can read more about sysprep itself and the process of generalization here.
What you probably need (only probably, because you do not state your real use case), is a specialized image. Specialized image is the only way to just use the VM as is - with all its user profiles. You can read about that process here.
By using the specialized image your OS is left untouched with all its user profiles.
I have been able to successfully create a Google Container Cluster in the developers console and have deployed my app to it. This all starts up fine, however I find that I can't connect to Cloud SQL, I get;
"Error: Handshake inactivity timeout"
After a bit of digging, I hadn't had any trouble connecting to the Database from App Engine or my local machine so I thought this was a little strange. It was then I noticed the cluster permissions...
When I select my cluster I see the following;
Permissions
User info Disabled
Compute Read Write
Storage Read Only
Task queue Disabled
BigQuery Disabled
Cloud SQL Disabled
Cloud Datastore Disabled
Cloud Logging Write Only
Cloud Platform Disabled
I was really hoping to use both Cloud Storage and Cloud SQL in my Container Engine Nodes. I have allowed access to each of these API's in my project settings and my Cloud SQL instance is accepting connections from any IP (I've been running Node in a Managed VM on App Engine previously), so my thinking is that Google is Explicitly disabling these API's.
So my two part question is;
Is there any way that I can modify these permissions?
Is there any good reason why these API's are disabled? (I assume there must be)
Any help much appreciated!
With Node Pools, you can sort of add scopes to a running cluster by creating a new node pool with the scopes you want (and then deleting the old one):
gcloud container node-pools create np1 --cluster $CLUSTER --scopes $SCOPES
gcloud container node-pools delete default-pool --cluster $CLUSTER
The permissions are defined by the service accounts attached to your node VMs during cluster creation (service accounts can't be changed after a VM is instantiated, so this the only time you can pick the permissions).
If you use the cloud console, click the "More" link on the create cluster page and you will see a list of permissions that you can add to the nodes in your cluster (all defaulting to off). Toggle any on that you'd like and you should see the appropriate permissions after your cluster is created.
If you use the command line to create your cluster, pass the --scopes command to gcloud container clusters create to set the appropriate service account scopes on your node VMs.
Hmm, I've found a couple of things, that maybe would be interested:
Permissions belong to a service account (so-called Compute Engine default service account, looks like 12345566788-compute#developer.gserviceaccount.com)
Any VM by default works using this service account. And its permissions do not let us Cloud SQL, buckets and so on. But...
But you can change this behavior using another service account with the right perms. Just create it manually and set only needed perms. Switch it out using gcloud auth activate-service-account --key-file=/new-service-account-cred.json
That's it.
For the cloudsql there's the possibility to connect from containers specifying a proxy as explained here https://cloud.google.com/sql/docs/postgres/connect-container-engine
We have a VM say SampleVM depoyed & running on Azure Environment and on the same we have created 2 instances One is WebRole & other is WorkerRole running onto Slot staging.
My prob is I am able to Start/Stop SampleVM through powershell command but How can I Start/Stop a single instance(WebRole or WorkerRole) running on a SampleVM.
However when I stop SampleVM then both the Instance also stopped but I want to stop only one Instance/VM i.e. WebRole Or WorkerRole.
Please provide some powershell command with the argument pass to Stop/Start a single instance
Good answer by Gaurav, but I wanted to add a bit more detail, as I think there may be a bit of confusion around web and worker roles. Each role is a definition for a group of virtual machines that do the same thing, as constructed by you (you don't deal with the OS - you just kickstart your app, and Azure takes care of the VM itself).
When a Cloud Service is running, there will be a minimum of one instance of each role type. So in your case, running both a web role and worker role, you'll have at least two VMs running.
If you choose to scale out your web role to, say, 3 instances, and then decide to dial it back to 2 instances, you cannot choose which one to shut down; this is taken care of by Azure's fabric. Remember that each instance of a role is running identical code, and Azure load-balances traffic to your role instances (through external endpoints that you define). The only thing you need to worry about is shutdown. You have approx. 5 minutes to clean up any running processes (and you can easily take a particular instance out of the load balancer during shutdown, since you receive a Stopping() event).
You cannot shut down an entire role (e.g. all instances of a role) within a cloud service (so... you can't take down your worker role instances while leaving your web role instances running). If that's a requirement, then you can always consider running your web role in one Cloud Service and worker role in another Cloud Service. If they use queues to pass data, everything will still work as before. If the web role instances need direct access to worker role instances, you could put both Cloud Services into a Virtual Network.
One more thing to consider: You don't have to have separate roles. If cost is a factor, you can run all your code in your web role. Takes little work to spin up additional processes / threads in your web role, during OnStart() - remember that role instances are full Windows Server virtual machines; run whatever you want. With a single role definition, scaling is a bit coarse: Everything is scaled together. With separate roles, you can fine-tune your scaling (much more important when building larger systems).
David's broader points about how to model your PaaS service are all correct. But to add to it, there is a new Service Management API that has just been released called Delete Role Instance which will let you delete a specific instance of a role - http://msdn.microsoft.com/en-us/library/windowsazure/dn469418.aspx. This functionality is brand new to allow you to choose which instance to delete instead of being subject to the default fabric behavior that David describes (always deleting the last instance).
Simple answer is that as of today, you can't stop a single instance of your web/worker role. When you stop a role, all instances are stopped. You could remove instances from your role but again you can't specify which particular instance you want to remove. See #kwill's answer below.
You may also find following links useful for deleting specific role instances:
http://gauravmantri.com/2013/10/16/a-new-version-of-windows-azure-service-management-api-is-available-with-delete-specific-role-instances-and-more-goodies/
https://github.com/richorama/Two10.Azure.SelfDestruct