Dr Venu Murthy

It was a jam-packed event and thanks to Amazon for the invite. The Agenda  All most all the tracks were overflowing and informative. Thanks for the Amaze-On Amazon

Having brought down the environment creation time for Bangalore International Airport Project from three and a half days to 3 hours, all that in one click, I realized that all this was possible due to the magic of "DevOps". I wanted to share my enthusiasm with a wider group and called for applications for DevOps Enablement program. I also wanted it to be an experiment on how successful it would go with non-Developer or non-tech folks and hence opened it up for people from sales as well. To my amazement, they too were able to pick up these skills easily. Below is the feedback from them on their learning experience. Below is the Feedback from the attendees of my DevOps Enablement course. First of all, you are an amazing teacher. I thought I would attend one session, but now I am hooked. Thank you for introducing us to the another side of Ops. In 2 classes you have already managed to answer a lot of questions (cloud, VMs. hypervisors) that have been lingering a

Dear Friends, Our Dream has come true! It takes 9 months for a mother to bring another life. That is the amount of time it has taken me to demystify the otherwise terse and abstract cloud computing concepts. And thanks to Packt Publishing I for helping me impart this knowledge in the most engaging way. The Full video course is out you can get more details about it here . You can get more details about the course here without registering. The Overview video is out for all. It was a tough negotiation with publisher to give out this valuable video for free I hope that it will get you started on your "Infrastructure as Code" journey. Three points I would like to share, which might help you are:- People are watching us! Packt publishing approached me watching the screencasts I had posted on Youtube. (Which until then I was certain that nobody was watching). Good news is Video course royalty is 3 times that of a book! Bad news is because its 3 times the

Just a brain dump, will format it latter https://letsencrypt.org/getting-started/ ~/letsencrypt$ sudo ./letsencrypt-auto certonly -d venumurthy.com -d www.venumurthy.com Congratulations! Your certificate and chain have been saved at   https://letsencrypt.org/getting-started/  /etc/letsencrypt/live/obhiyo.com/fullchain.pem cert.pem  chain.pem  fullchain.pem  privkey.pem vim sites-enabled/000-default.conf <VirtualHost 54.169.00.52:443>         ServerName www.venumurtyy.com         ServerAdmin contact@venumurty.com         DocumentRoot /var/www/venumurthy         SSLEngine on         SSLCertificateFile /etc/letsencrypt/live/vm.com/cert.pem         SSLCertificateKeyFile /etc/letsencrypt/live/vm.com/privkey.pem         SSLCertificateChainFile /etc/letsencrypt/live/vm.com/fullchain.pem         ErrorLog ${APACHE_LOG_DIR}/error.log         CustomLog ${APACHE_LOG_DIR}/access.log combined </VirtualHost> vim /etc/apache2/sites-available/default-ssl.conf            

While installing OpenStack Liberty release you disable the keystone service from starting up automatically and we also see a note such as " In Kilo and Liberty releases, the keystone project deprecates eventlet in favor of a separate web server with WSGI extensions. This guide uses the Apache HTTP server with   mod_wsgi   to serve Identity service requests on port 5000 and 35357. By default, the keystone service still listens on ports 5000 and 35357. Therefore, this guide disables the keystone service. The keystone project plans to remove eventlet support in Mitaka."   The reason behind this is Eventlet by design performs well in networked environments and handles everything in a single thread. Due to Apache's ability to do multi-threading it was better to use it as the frontend. Keystone depends on apache/web-server modules to handle federated identity (validation of SAML and etc) and similar Single Sign On type authentication. Eventlet has proven problemati

Source This is our life when we are working on automating some really complicated machine building and provisioning procedures. I.e. while developing the playbooks in Ansible, or CookBooks in Chef or manifests in Puppet. It is not easy to fail faster and fix early as the script might have to download all the dependencies again and again. Adding to all the odds, it could be that the dependencies are being downloaded on a low bandwidth. Even though Vagrant makes bringing up VM and their management faster, the provisioning (using Ansible, Chef or Puppet or etc) might take inordinately long times when it involves, and it usually does involve downloading packages on the VMs. And it gets painful when you have to download a full stack of several libraries to test your VM. To help overcome this issue, we can use the following to cache the dependencies and test the configuration scripts or recipes faster, the following should set you up (assuming you have vagrant already installe