crontabs and common paths bundle #14
Conversation
|
||
files: | ||
|
||
"${g.nhw_crontabs}/${user}" |
zzamboni
Feb 28, 2012
Contributor
This should be modified to use paths.crontabs instead of g.nhw_crontabs.
This should be modified to use paths.crontabs instead of g.nhw_crontabs.
|
||
root_cron_repaired.(aix|sunos_5_10):: | ||
|
||
"/usr/bin/crontab ${g.nhw_crontabs}/${user}", |
zzamboni
Feb 28, 2012
Contributor
Change g.nhw_crontabs to paths.crontabs.
Change g.nhw_crontabs to paths.crontabs.
Hi Neil - thanks for the submission! I think the paths bundle is an excellent idea. I have made a couple of comments on some lines. |
I like the paths idea too. Maybe its just me and my brain wanting to limit scope, does anyone else find it easier to read a commit that is just a single sketch? |
That's the idea in general - one sketch per pull request. In this case I think it made sense to bundle them because one uses the other. --Diego On Feb 28, 2012, at 7:39 PM, Nick Andersonreply@reply.github.com wrote:
|
Made changes. |
On 02/28/2012 08:02 PM, Neil H Watson wrote:
Did you push your changes to your fork? I still see the g.nhw_crontabs Nick Anderson nick@cmdln.org |
@@ -0,0 +1,34 @@ | |||
bundle agent cronjobs(user, jobs) { |
nickanderson
Feb 29, 2012
Member
Should this one perhaps be named cronjobs_add since it just appends if not found?
Should this one perhaps be named cronjobs_add since it just appends if not found?
handle => "cronjobs_files_crontab", | ||
comment => "Promise table entries", | ||
create => "true", | ||
classes => if_repaired("crontab_repaired"), |
nickanderson
Feb 29, 2012
Member
Should this class be prefixed with sketchname_bundlename ?
or maybe sketchname_bundlename_${user}_crontab_repaired since I see your classing a command below on root_cron_repaired.
Should this class be prefixed with sketchname_bundlename ?
or maybe sketchname_bundlename_${user}_crontab_repaired since I see your classing a command below on root_cron_repaired.
commands: | ||
|
||
root_cron_repaired.(aix|sunos_5_10):: | ||
|
nickanderson
Feb 29, 2012
Member
Your classing this on root_cron_repaired, but I dont see where the root_cron_repaired class gets defined
Your classing this on root_cron_repaired, but I dont see where the root_cron_repaired class gets defined
neil what do you think about the bundle name change from cronjobs to cronjobs_add since it appends if not found. I think that would leave logical namespace for something like cronjobs_delete and other patterns for dealing with cronjobs, perhaps cron_d style related. |
I was thinking sketchname of cronjobs like you had but the only bundle you submitted in that sketch was also named cronjobs. I thought maybe just rename that bundle and we can add more cronjob related bundles to the sketch am curious what others think though before you keep making changes on my whims :) |
I agree - I think the sketch should be named |
@@ -0,0 +1,3 @@ | |||
author: Neil H Watson, neil@watson-wilson.ca | |||
ostype: Any UNIX |
nickanderson
Feb 29, 2012
Member
Are these metadata values for ostype, tested, and cfengine_version supposed to be valid cfengine classes?
Which ones are required?
Should there be a comma between the name and email address?
I ask because I am thinking ahead to what the not yet finished tooling is going to want to expect and it would be nice to have a tool that could be used to validate a submission
Are these metadata values for ostype, tested, and cfengine_version supposed to be valid cfengine classes?
Which ones are required?
Should there be a comma between the name and email address?
I ask because I am thinking ahead to what the not yet finished tooling is going to want to expect and it would be nice to have a tool that could be used to validate a submission
zzamboni
Feb 29, 2012
Contributor
In this case, ostype
should be unix
, which is a hard class defined by CFEngine on any Unix-style operating system. The author
should preferably be Name <email@address.com>
.
Indeed the idea is that we'll have a tool that can validate and submit sketches, and also one to install them.
In this case, ostype
should be unix
, which is a hard class defined by CFEngine on any Unix-style operating system. The author
should preferably be Name <email@address.com>
.
Indeed the idea is that we'll have a tool that can validate and submit sketches, and also one to install them.
nickanderson
Feb 29, 2012
Member
Which if any fields are required?
Which if any fields are required?
I have one other large sketch to add. Is it better to wait for this pull to complete and then start a new one? |
Your in the same spot I was, your clone is progressing at a faster pace than upstream. I don't know what the official stance is, but it is probably best to get your stuff on a feature branch. I see one more thing that needs to be addressed in the submission, Then you should update your clone from upstream, and create a feature branch off of it where you can add your new sketch and submit a pull request for that. I just had to work through doing that yesterday so if you need help let me know. |
Hi Neil, The best is to start a new branch for each sketch, then you can submit multiple pull requests simultaneously. --Diego On Feb 29, 2012, at 8:21 PM, Neil H Watson reply@reply.github.com wrote:
|
On 02/29/2012 08:57 PM, Diego Zamboni wrote:
If you branch before your changes are merged and do a pull request on Nick Anderson nick@cmdln.org |
I think these two sketches look good, anyone see any issues with merging? |
@@ -0,0 +1,3 @@ | |||
author: Neil H Watson <neil@watson-wilson.ca> | |||
ostype: Linux, Solaris 10, AIX | |||
tested: Debian 6 |
nickanderson
Mar 1, 2012
Member
oops, this should be a valid class name probably debian_6 ?
oops, this should be a valid class name probably debian_6 ?
@@ -0,0 +1,3 @@ | |||
author: Neil H Watson <neil@watson-wilson.ca> | |||
ostype: Linux, Solaris 10, AIX |
nickanderson
Mar 1, 2012
Member
I think these need to be valid class names as well.
I think these need to be valid class names as well.
neilhwatson
Mar 1, 2012
Author
Contributor
On Wed, Feb 29, 2012 at 07:29:20PM -0800, Nick Anderson wrote:
+ostype: Linux, Solaris 10, AIX
I think these need to be valid class names as well.
Are they supposed to be human or machine readable?
Neil Watson
Linux/UNIX Consultant
http://watson-wilson.ca
On Wed, Feb 29, 2012 at 07:29:20PM -0800, Nick Anderson wrote:
+ostype: Linux, Solaris 10, AIX
I think these need to be valid class names as well.
Are they supposed to be human or machine readable?
Neil Watson
Linux/UNIX Consultant
http://watson-wilson.ca
nickanderson
Mar 1, 2012
Member
On 02/29/2012 09:35 PM, Neil H Watson wrote:
Are they supposed to be human or machine readable?
I think in the metadata file they are supposed to be machine readable
probably the same classes that cfengine defines so that tools (not yet
built) can search for things or warn when installing if your
installing on a machine that classes dont match.
In the Readme.md I would guess either machine readable or human readable.
Nick Anderson nick@cmdln.org
On 02/29/2012 09:35 PM, Neil H Watson wrote:
Are they supposed to be human or machine readable?
I think in the metadata file they are supposed to be machine readable
probably the same classes that cfengine defines so that tools (not yet
built) can search for things or warn when installing if your
installing on a machine that classes dont match.
In the Readme.md I would guess either machine readable or human readable.
Nick Anderson nick@cmdln.org
zzamboni
Mar 1, 2012
Contributor
Yes, ostype and tested in the metadata.txt file are supposed to be CFEngine class names. I will clarify this in the guidelines document.
On Feb 29, 2012, at 9:38 PM, Nick Anderson wrote:
@@ -0,0 +1,3 @@
+author: Neil H Watson neil@watson-wilson.ca
+ostype: Linux, Solaris 10, AIX
On 02/29/2012 09:35 PM, Neil H Watson wrote:
Are they supposed to be human or machine readable?
I think in the metadata file they are supposed to be machine readable
probably the same classes that cfengine defines so that tools (not yet
built) can search for things or warn when installing if your
installing on a machine that classes dont match.
In the Readme.md I would guess either machine readable or human readable.
Nick Anderson nick@cmdln.org
Reply to this email directly or view it on GitHub:
https://github.com/cfengine/design-center/pull/14/files#r505508
Yes, ostype and tested in the metadata.txt file are supposed to be CFEngine class names. I will clarify this in the guidelines document.
On Feb 29, 2012, at 9:38 PM, Nick Anderson wrote:
@@ -0,0 +1,3 @@
+author: Neil H Watson neil@watson-wilson.ca
+ostype: Linux, Solaris 10, AIXOn 02/29/2012 09:35 PM, Neil H Watson wrote:
Are they supposed to be human or machine readable?
I think in the metadata file they are supposed to be machine readable
probably the same classes that cfengine defines so that tools (not yet
built) can search for things or warn when installing if your
installing on a machine that classes dont match.In the Readme.md I would guess either machine readable or human readable.
Nick Anderson nick@cmdln.org
Reply to this email directly or view it on GitHub:
https://github.com/cfengine/design-center/pull/14/files#r505508
That's why you never develop on your master branch - that way every branch starts off with the "clean" state of the master branch, without any other changes, and they can be merged independently. On Feb 29, 2012, at 8:58 PM, Nick Anderson wrote:
|
crontabs and common paths bundle.
bundles.cf: rm_rf and rm_rf_depth bundles: add docs and port to 3.5
Remove references to cf-report
Added more content instructing how to write promises
Crontabs is self explanatory. The paths bundle I'd like to be a community
effort to catalog the paths to commonly called commands.