I am using Apache Pulsar, and I'm trying to deploy a Pulsar function, but I'm getting this error:
org.apache.pulsar.broker.web.RestException: Policies not found for myTenant/myNamespace namespace
I've checked the code in my function, and everything looks fine.
I'm using Pulsar 2.6.0, but I've tried other versions and gotten the same result.
What's causing this issue? How do I resolve it?
You need to ensure that the tenant and namespace exist that you're trying to deploy the function/sink/source into.
If the tenant or namespace don't exist, then you will get this error because the policy doesn't yet exist. (The policy is created when the namespace is created.)
Try creating the tenant and namespace with the Admin CLI, like this:
bin/pulsar-admin tenants create myTenant
bin/pulsar-admin namespaces create myTenant/myNamespace
If you need to provide additional options, such as the roles or clusters that will be used, those need to be specified. (If you're just using Pulsar standalone, probably you won't need to worry about that.) If someone else manages the cluster (or if you don't have admin permission), you need to ensure that you're writing to the correct tenant/namespace. If you're still having issues, you will need to talk to your cluster admin.
You can find the docs here about how to use the Pulsar Admin CLI commands: http://pulsar.apache.org/docs/en/pulsar-admin/
More specifically, here for tenants create: http://pulsar.apache.org/docs/en/pulsar-admin/#create-4
and here for namespaces create: http://pulsar.apache.org/docs/en/pulsar-admin/#create-2
Related
I'm pursuing DSC as a lightweight solution for managing local user accounts on distributed Windows instances in favour of connecting said instances to Active Directory.
Adding and removing specified local users works as expected, but I also want to check that ONLY the specified accounts exist (or are enabled) on each configured node.
e.g. - If I were to create a new local admin account with 'xUser CreateUserAccount / Ensure = Present', if I were to remove the code from my DSC script, that user would still exist on the target node. Similarly, if someone were to create a local user account by some other means, there would be no warning of the unexpected configuration drift through the DSC server.
To remove any unexpected accounts, I would first need be made aware of these accounts by some other means, and then specify 'xUser RemoveUserAccount'.
I have not found a way around this with the first 100 Google results on the topic. Has anyone solved this apparent conundrum with DSC? Should I rather look to something else e.g. Terraform?
Working with Azure, we started with AKS last year. On creation of the AKS clusters we use, we checked what needed to be done up front to enable rbac at a later moment and we then thought that setting 'rbac' to 'enabled' was the only thing we needed. This results in the following:
Now we're trying to implement rbac integration of AKS with AAD, but I read some seemingly conflicting pre-requisites. Some say that in order to integrate AAD and AKS, you need rbac enabled at cluster creation. I believe we have set that correct, looking at the picture above.
But then in the Azure docs, it is mentioned that you need to create a cluster and add some AAD-integration keys for the client and server applications.
My question is actually two-fold:
when people say you need rbac enabled in your aks cluster during creation do they actually mean you should select the 'rbac:enabled' box AND make sure you create the AAD-related applications up front and also configure these during cluster creation?
Is there a way to setup the AKS-AAD rbac connection on a cluster that has rbac:enabled but misses the aadProfile configuration?
I believe we indeed need to re-create all our clusters, but I want to know for sure by asking here as it's not 100% clear to me from what I've read online (also here at stack exchange) and it's going to be an awful lot of work.
For all of your requirements, you only need to make sure the RBAC enabled for your AKS cluster and it only can enable in the creation time. Then you can update the credential of the existing AKS AAD profile like this:
Before update:
CLI update command:
az aks update-credentials -g yourResourceGroup -n yourAKSCluster --reset-aad --aad-server-app-id appId --aad-server-app-secret appSecret --aad-client-app-id clientId --aad-tenant-id tenantId
After update:
yes, that is correct
no, there is no way of doing that. you need to recreate.
A little context: I'm having to migrate a project from AWS, where I'm currently using ECS, to Azure, where I'll be using AKS since their ACS (ECS equivalent) is deprecated.
This is a regular Django app, with its configuration variables being fetched from a server-config.json hosted on a private S3 bucket, the EC2 instance has the correct role with S3FullAccess,
I've been looking into reproducing that same behavior but with Azure Blob Storage instead, having achieved no success whatsoever :-(.
I tried using the Service Principal concept and adding it to the AKS Cluster with Storage Blob Data Owner roles, but that doesn't seem to work. Overall it's been quite the frustrating experience - maybe I'm just having a hard time grasping the right way to use the permissions/scopes. The fact that the AKS Cluster creates its own resource group is something unfathomable - but I've attempted attaching the policies to it as well, to no avail. I then moved onto a solution indicated by Microsoft.
I managed to bind my AKS pods with the correct User Managed Identity through their indicated solution aad-pod-identity, but I feel like I'm missing something. I assigned Storage Blob Data Owner/Contributor to the identity, but still, when I enter the pods and try to access a Blob (using the python sdk), I get a resource not found message.
Is what I'm trying to achieve possible at all? Or will I have to change to a solution using Azure Keyvault/something along those lines?
first off all, you can use AKS Engine which is more or less ACS for Kubernetes now.
As for the access to the blob storage, you dont have to use Managed Service Identity, you can just use account name\key ( which is a bit less secure, but a lot less error prone and more examples exist ). The fact that you are getting resource not found error most likely means your auth part is fine, you just dont have access to the resource, according to this storage blob contributor should be fine if you assigned it at a proper scope. For this to work 100% just give your identity contributor access at subscription level, this way its guaranteed to work.
I've found an example of using python with MSI (here). You should start with that (and grant your identity contributor access) and verify you can list resource groups. when that works making reading blobs working should be trivial.
I am trying to understand how can I run a python application inside azure container that can spin up various resources like VM, route-table inside resource group of Azure.
http://azure-sdk-for-python.readthedocs.io/en/latest/
Looks like the examples provided in azure python sdk sets authentication stuff like credentials, subscription ID, etc.
Is there a way to avoid setting up of this information by using Role Based Access Control ? What if I provide container an Contributor access to the resource group, in that case, would i able to avoid setting up authentication variables and still achieve creating resources or atleast read/access resources in resource group ?
No, how do you think that would work? In order to be able to create\read\modify resources you need permissions (else anyone would be able to do that). There is no way to do that without some sort of Auth.
I'm trying to build a small program to change the autoscale settings for our Azure WebApps, using the Microsoft.WindowsAzure.Management.Monitoring and Microsoft.WindowsAzure.Management.WebSites NuGet packages.
I have been roughly following the guide here.
However, we are interested in scaling WebApps / App Services rather than Cloud Services, so I am trying to use the same code to read the autoscale settings but providing a resource ID for our WebApp. I have already got the credentials required for making a connection (using a browser window popup for Active Directory authentication, but I understand we can use X.509 management certificates for non-interactive programs).
This is the request I'm trying to make. Credentials already established, and an exception is thrown earlier if they're not valid.
AutoscaleClient autoscaleClient = new AutoscaleClient(credentials);
var resourceId = AutoscaleResourceIdBuilder.BuildWebSiteResourceId(webspaceName: WebSpaceNames.NorthEuropeWebSpace, serverFarmName: "Default2");
AutoscaleSettingGetResponse get = autoscaleClient.Settings.Get(resourceId); // exception here
The WebApp (let's call it "MyWebApp") is part of an App Service Plan called "Default2" (Standard: 1 small), in a Resource Group called "WebDevResources", in the North Europe region. I expect that my problem is that I am using the wrong names to build the resourceId in the code - the naming conventions in the library don't map well onto what I can see in the Azure Portal.
I'm assuming that BuildWebSiteResourceId is the correct method to call, see MSDN documentation here.
However the two parameters it takes are webspaceName and serverFarmName, neither of which match anything in the Azure portal (or Google). I found another example which seemed to be using the WebApp's geo region for webSpaceName, so I've used the predefined value for North Europe where our app is hosted.
While trying to find the correct value for serverFarmName in the Azure Portal, I found the Resource ID for the App Service Plan, which looks like this:
/subscriptions/{subscription-guid}/resourceGroups/WebDevResources/providers/Microsoft.Web/serverfarms/Default2
That resource ID isn't valid for the call I'm trying to make, but it does support the idea that a 'serverfarm' is the same as an App Service Plan.
When I run the code, regardless of whether the resourceId parameters seem to be correct or garbage, I get this error response:
<string xmlns="http://schemas.microsoft.com/2003/10/Serialization/">
{"Code":"SettingNotFound","Message":"Could not find the autoscale settings."}
</string>
So, how can I construct the correct resource ID for my WebApp or App Service Plan? Or alternatively, is there a different tree I should be barking up to programatially manage WebApp scaling?
Update:
The solution below got the info I wanted. I also found the Azure resource explorer at resources.azure.com extremely useful to browse existing resources and find the correct names. For example, the name for my autoscale settings is actually "Default2-WebDevResources", i.e. "{AppServicePlan}-{ResourceGroup}" which I wouldn't have expected.
There is a preview service https://resources.azure.com/ where you can inspect all your resources easily. If you search for autoscale in the UI you will easily find the settings for your resource. It will also show you how to call the relevant REST Api endpoint to read or update that resorce.
It's a great tool for revealing a lot of details for your deployed resources and it will actually give you an ARM template stub for the resource you are looking at.
And to answer your question, you could programmatically call the REST API from a client with updated settings for autoscale. The REST API is one way of doing this, the SDK another and PowerShell a third.
The guide which you're following is based on the Azure Service Management model, aka Classic mode, which is deprecated and only exists mainly for backward compatibility support.
You should use the latest
Microsoft.Azure.Insights nuget package for getting the autoscale settings.
Sample code using the nuget above is as below:
using Microsoft.Azure.Management.Insights;
using Microsoft.Rest;
//... Get necessary values for the required parameters
var client = new InsightsManagementClient(new TokenCredentials(token));
client.AutoscaleSettings.Get(resourceGroupName, autoScaleSettingName);
Besides, the autoscalesettings is a resource under the "Microsoft.Insights" provider and not under the "Microsoft.Web" provider, which explains why you are not able to find it with your serverfarm resourceId.
See the REST API Reference below for getting the autoscale settings.
GET
https://management.azure.com/subscriptions/{subscription-id}/resourceGroups/{resource-group-name}/providers/microsoft.insights/autoscaleSettings/{autoscale-setting-name}?api-version={api-version}