are you using berkshelf? berks can show you outdated cookbooks using berks outdated. We manually run this and update minor version changes whenever
available, and then test it in staging. Except the version bump in
Berksfile, rest is automates (i.e. uploading cookbook & testing it on
staging ).
I assumed Chef server could do it too. Chef Server bump all version of
cookbooks I uploaded, all I need is to assign a specific version of
cookbook to run list. I think that is not what I am talking about.
Take source code of tomcat for example. I download the source code zip, put
it in “file” folder. I write a recipe to install it, blah, blah blah.
What I concern is how to do the upgrade, when major version changes come?
What is the best practice or say “common practice” you guys using?
Sincerely,
Howard Zhang Haohua
MSc Student in Information Technology
The Department of Computer Science and Engineering
School of Engineering
Hong Kong University of Science and Technology
Email: howardzhanghaohua@gmail.com about.me/HowardZhang
are you using berkshelf? berks can show you outdated cookbooks using berks outdated. We manually run this and update minor version changes
whenever available, and then test it in staging. Except the version bump in
Berksfile, rest is automates (i.e. uploading cookbook & testing it on
staging ).
I assumed Chef server could do it too. Chef Server bump all version of
cookbooks I uploaded, all I need is to assign a specific version of
cookbook to run list. I think that is not what I am talking about.
Take source code of tomcat for example. I download the source code zip,
put it in “file” folder. I write a recipe to install it, blah, blah blah.
What I concern is how to do the upgrade, when major version changes come?
What is the best practice or say “common practice” you guys using?
Sincerely,
Howard Zhang Haohua
MSc Student in Information Technology
The Department of Computer Science and Engineering
School of Engineering
Hong Kong University of Science and Technology
Email: howardzhanghaohua@gmail.com about.me/HowardZhang
are you using berkshelf? berks can show you outdated cookbooks using berks outdated. We manually run this and update minor version changes
whenever available, and then test it in staging. Except the version bump in
Berksfile, rest is automates (i.e. uploading cookbook & testing it on
staging ).
I assumed Chef server could do it too. Chef Server bump all version of
cookbooks I uploaded, all I need is to assign a specific version of
cookbook to run list. I think that is not what I am talking about.
Take source code of tomcat for example. I download the source code zip,
put it in “file” folder. I write a recipe to install it, blah, blah blah.
What I concern is how to do the upgrade, when major version changes come?
What is the best practice or say “common practice” you guys using?
Sincerely,
Howard Zhang Haohua
MSc Student in Information Technology
The Department of Computer Science and Engineering
School of Engineering
Hong Kong University of Science and Technology
Email: howardzhanghaohua@gmail.com about.me/HowardZhang
are you using berkshelf? berks can show you outdated cookbooks using berks outdated. We manually run this and update minor version changes
whenever available, and then test it in staging. Except the version bump in
Berksfile, rest is automates (i.e. uploading cookbook & testing it on
staging ).
I ran over some recipes in several cookbooks maintained by the
community.
All I see is installation. I wonder the best practice of upgrading
and
uninstalling software?
Could you give me some brief idea how to upgrade and uninstall
software?
(please do not say " apt-get uninstall").
Some cookbooks ship recipes for uninstall. But most don’t bother.
Either you uninstall via "apt-get uninstall " (I prefer purge). Or
you just throw that vm away.
When you automate the creation of virtual machines, its easier to just
remove the recipe from the node and re-install the node then to spent
valuable tech-time touching the node(s) and removing the software by
hand.
Upgrading I do by hand (apt-get upgrade). I tried using the :upgrade
action on the package resource once, but that upgrades packages as soon
as some new version is available and not during hours I have time for
this. Its not much fun when the whole web-app shuts down during
office-hours because apache has to stop, update and restart. Better
schedule that time. Or just create a new node with the current versions,
let the reverse-proxy pick that up and then remove the old node…
Yes, I know the “package” resource, but the prerequisite is that I
have pack my own source code into a .deb package or .rpm package.
But if the software is developed by myself, I did not pack the source
code, and it do not exist in any package repository.
What is the common practice on this situation?
The common practice is to package your software for your OS of choice
using FPM[1] and stick it in an appropriate package repository that you
host yourself.
Yes, I know the “package” resource, but the prerequisite is that I have
pack my own source code into a .deb package or .rpm package.
But if the software is developed by myself, I did not pack the source code,
and it do not exist in any package repository.
What is the common practice on this situation?
If you have non-packaged code that you want to cleanup, I’d recommend
creating a cleanup recipe that removes it (perhaps stopping a service,
removing files and directories, etc).
For non-packaged things, it is hard to make a general uninstall
solution, so the common practice, if you can call it that, is custom
uninstall recipes.
seth
–
Seth Falcon | Development Lead | Opscode | @sfalcon
Yes, I know the “package” resource, but the prerequisite is that I have
pack my own source code into a .deb package or .rpm package.
But if the software is developed by myself, I did not pack the source
code,
and it do not exist in any package repository.
What is the common practice on this situation?
If you have non-packaged code that you want to cleanup, I’d recommend
creating a cleanup recipe that removes it (perhaps stopping a service,
removing files and directories, etc).
For non-packaged things, it is hard to make a general uninstall
solution, so the common practice, if you can call it that, is custom
uninstall recipes.
seth
–
Seth Falcon | Development Lead | Opscode | @sfalcon
Hi,
I am new to Chef.
I ran over some recipes in several cookbooks maintained by the community.
All I see is installation. I wonder the best practice of upgrading and
uninstalling software?
Could you give me some brief idea how to upgrade and uninstall software?
(please do not say " apt-get uninstall").
Some cookbooks ship recipes for uninstall. But most don’t bother.
Either you uninstall via "apt-get uninstall " (I prefer purge). Or you just throw that vm away.
When you automate the creation of virtual machines, its easier to just remove the recipe from the node and re-install the node then to spent valuable tech-time touching the node(s) and removing the software by hand.
Upgrading I do by hand (apt-get upgrade). I tried using the :upgrade action on the package resource once, but that upgrades packages as soon as some new version is available and not during hours I have time for this. Its not much fun when the whole web-app shuts down during office-hours because apache has to stop, update and restart. Better schedule that time. Or just create a new node with the current versions, let the reverse-proxy pick that up and then remove the old node…