You may run into the following error when attempting to install blobfuse on CentOS 7, or at least that happened to me when trying to follow MSFT install instructions (possibly because I’ve erroneously added RHEL8 package repository):
https://packages.microsoft.com/rhel/7/prod/blobfuse-1.4.4-CentOS-7.0-x86_64.rpm: [Errno 14] HTTPS Error 404 - Not Found
Trying other mirror.
To address this issue please refer to the below wiki article
If above article doesn't help to resolve this issue please use https://bugs.centos.org/.
The other day I was trying to set up Azure storage account lifecycle management policy via Terraform. Azure storage account lifecycle management policies allow you to transition your data to the appropriate access tiers or expire at the end of the data’s lifecycle. Unfortunately on attempt to apply Terraform template I got an error:
Error: expanding Storage Account Management Policy: (Management Policy Name "management-policy-name" / Storage Account Name "storage-account-name" / Resource Group "resource-group-name"): expanding the 0th rule: can't specify 'tier_to_cool_after_days_since_modification_greater_than' and 'tier_to_cool_after_days_since_last_access_time_greater_than' at the same time
The error was a bit confusing as it complains about tier_to_cool_after_days_since_modification_greater_than and tier_to_cool_after_days_since_last_access_time_greater_than being specified at the same time, whereas Terraform definition contained only one of those settings (tier_to_cool_after_days_since_modification_greater_than).
Basically this error occurred due to the fact that in the Terraform Azure RM provider this functionality was not fully implemented for versions prior to 3.0.0, earlier versions had only partial implementation (before that provider schema changes were in place, but corresponding changes for the expand/flatten logic were missing) which was causing this error (source). So to resolve such error (providing that you don’t try to specify two settings mentioned in error message at the same time in your template) you need to make sure that your Terraform Azure RM provider version is 3.0.0 or newer.
I’ve run into this error while going through one of the Kubernetes courses on LinkedIn Learning where exercise files were not updated. Basically on attempt to create deployment from YAML file with the following command:
kubectl create -f testdeployment.yaml
You may get the following error:
error: resource mapping not found for name: "SampleApp" namespace: "" from "testdeplyoment.yaml": no matches for kind "Deployment" in version "apps/v1beta1" ensure CRDs are installed first
Immediately one can say that something is not OK within YAML file, but it is not super obvious what exactly at first glance. Here goes deployment YAML file which allows to reproduce this error:
Now the cause of this error is use of deprecated API version – starting from Kubernetes 1.16 deployment in the extensions/v1beta1, apps/v1beta1, and apps/v1beta2 API versions is no longer served and you have to switch to use of apps/v1 instead (source). So to fix this error you just have to change apiVersion value to apps/v1. You can possible run into this or similar error when trying to leverage some old YAML definition and it may come in handy to know how to fix this. Based on the list of deprecated APIs removed in 1.16 you can get this error while trying to deploy NetworkPolicy or PodSecurityPolicy against extensions/v1beta1, DaemonSet against extensions/v1beta1 or extensions/v1beta2, Deployment against extensions/v1beta1, apps/v1beta1, and apps/v1beta2 API versions and couple of other resource types.
Whenever I observe a Windows user (sometimes very proficient in IT) struggling with UI to invoke some sort of a tool of immediate necessity and just scrolling through start menu icons instead of relying on “CTRL + R + type exact executable or applet name” or just “WIN + type immediately what you need” I found it really weird. I mean that’s fine for vi proficient Linux command line guru or a Windows user whose needs do not go beyond web browsing and couple of regularly used apps/games, but when I see this type of behavior from full-time IT person touching Windows systems on a daily basis that seems to me a really strange avoidance to learn fundamentals/tools of one’s craft 🙂
As I’m currently using Linux more and more it is quite interesting to observe various levels of the same paradox/pattern among more then proficient Linux (desktop) users. For example, the other day during the training, I was observing instructor trying to guide a student to invoke Linux context menu and use “Open in Terminal” while that stubbornly tried to rely on search to find Terminal icon there 🙂 So use of context menu from empty desktop area and selecting “Open in Terminal” is a LEVEL2 way of accessing Terminal… but honestly what one should do, and what is true LEVEL3 ,is to use CTRL+ALT+T hotkey whenever one needs to jump into terminal from desktop UI, this is as cool as using what was called MCSE hot key in times long forgotten to invoke Task Manager (CTRL+ALT+ESC). Using hotkeys may not or may not impress other people (frequently it does), but you should learn them just because it makes your work so much efficient – after passing through short learning curve you just won’t want to use “long path” of accessing things which is reserved for people who didn’t care to learn shortcuts and trying not to notice how slow and clumsy wading through UI is at times.
I just wanted to share/reiterate that knowing some hotkeys just speed ups you a lot, and I guess the one should remember that being a professional implies both understanding of software use cases and inner workings as well as its usage basics (such as knowledge of hotkeys and UI features) – both things are required to be considered as a professional in the field IMO and it is sad to see that some trying to neglect the basics, let’s do not do that 🙂
Assume the following scenario you trying to run Azure DevOps pipeline from one Azure DevOps repo and it relies on some contents in another Azure DevOps repo which specified in resources section of your YAML pipeline (for example it can be a repo which stores your master templates). You absolutely sure that your resources section is right and that it contains correct values for repository type and name as you were reusing this configuration in some other pipelines in other projects. For example, your pipeline resources section may look as follows:
Nonetheless your YAML pipeline stored in your new Azure DevOps repository keeps failing with the following error:
remote: TF401019: The Git repository with name or identifier CORRECT_REPOSITORY_NAME does not exist or you do not have permissions for the operation you are attempting.
Here is a sample error message screenshot from pipeline job history:
So the problem here (as we are sure that resource section repository config is OK) is configuration of a DevOps project which contains failing pipeline. To resolve this you will need to disable the following project settings:
Limit job authorization scope to current project for non-release pipelines
Limit job authorization scope to referenced Azure DevOps repositories
Once these setting changed you should be able to re-run pipeline to make sure that it no longer fails due to TF401019 error.