@@ -26,18 +27,17 @@ The general overview of the workflow between git repositories is as follows:
API REPOSITORY SITE X <--| |--> API REPOSITORY SITE Y
Each site administrator must first clone the remote MASTER REPOSITORY located on the git.grid5000.fr server and store it on a local machine (this is what I call the ADMIN REPOSITORY and has to be done once):
Then she manually adds/edits/removes the raw JSON files or uses the generator (more on that later). When she's done, she COMMITs her changes and PUSHes them to the MASTER REPOSITORY:
... editing ...
g5kadmin@host:/somewhere/reference-repository$ git commit -a -m "list of modifications"
Right now, the easiest way to get started is to look at some existing input files in the "generators/input" directory. There you can see how you can define sites, clusters, nodes and environments programmatically.
Then you may create a new input file or change an existing one and run it in simulation mode:
Right now, the easiest way to get started is to look at some existing input files in the "generators/input" directory. There you can see how you can define sites, clusters, nodes and environments programmatically.
Then you may create a new input file or change an existing one and run it in simulation mode: (run <code class="command">rake -T</code> to see the list of available tasks):
Your changes won't be applied but you'll see what would have been changed. Thus, the simulation mode is useful to review your changes before committing and check the ruby syntax of the input files.
When you are happy with your changes, you can then run the command without the -s flag:
Please be aware that config files (YAML format) may be passed on the command line, so that the values can be used in the input files via the <code>lookup(config_filename, key)</code> function. To tell the generator to include one or more config files, you must pass them in your command arguments:
{{Note|text=Note that the extension of config files MUST be <code>.yaml</code> or <code>.yml</code>, otherwise they won't be included.}}
Finally, commit your changes with a meaningful message in ENGLISH (you SHOULD first review the changes that will be committed by running the <code>git diff</code> command) and push them immediately to the MASTER REPOSITORY:
g5kadmin@host:/somewhere/reference-repository$ git commit -a -m "[<code class="replace">TAGS</code>] message"
{{Term|location=reference-repo|cmd=<code class="command">git</code> commit -a -m "[<code class="replace">TAGS</code>] message"}}
{{Note|text=<code>TAGS</code> is a comma-separated list of tags (e.g. <code class="replace">[rennes,lyon]</code>) that add parseable semantics to the commit message.}}
{{Note|text=<code class="replace">TAGS</code> is a comma-separated list of tags (e.g. <code class="replace">[rennes,lyon]</code>) that add parseable semantics to the commit message.}}
As of 2010/09/08, a synchronization task has been added that allows you to generate the diff between 2 commits (not necessarily consecutive).
Once you've committed your changes, run the <code>oar:generate</code> rake task to generate the corresponding oaradmin lines (run <code>$ rake -D</code> to see the list of available tasks):
I, [2012-07-25T17:06:57.985664 #8081] INFO -- : Node 'sol-36.sophia.grid5000.fr' is dead because '[phoenix] Could not respawn this node at Wed Jul 25 12:30:02 +0200 2012'
I, [2012-07-25T17:06:57.985794 #8081] INFO -- : Node 'sol-40.sophia.grid5000.fr' is dead because '[phoenix] Could not respawn this node at Wed Jul 25 12:30:01 +0200 2012'
I, [2012-07-25T17:06:57.986003 #8081] INFO -- : Node 'suno-21.sophia.grid5000.fr' is dead because 'Chassis is on, but the node never get up. No dhcp request received.'
== Filling the reference - Guidelines ==
...
...
@@ -128,10 +132,11 @@ After several discussions inside the PS team, we have fixed some attributes. All
::* ['''mounted''']''<font color="#FF0000">(if '''mountable'''==true)</font>'': <code>true</code> if the production environment mounts, configures this interface
:::* ['''network_address''']''<font color="#FF0000">(if '''mounted'''==true or '''management'''==true)</font>'': the DNS entry of the machine by this interface
:::* ['''device''']''<font color="#FF0000">(if '''mounted'''==true)</font>'': name of this interface in the production environment
:* ['''ip''']''<font color="#FF0000">(if '''enabled'''==true)</font>'': the IP of this interface
:* ['''ip''']''<font color="#FF0000">(if '''enabled'''==true)</font>'': the IP of this interface.
::*''<font color="#FF0000">(if '''enabled'''==true AND '''ip''' is empty)</font>'' : The dhcp provides no ip adress for this interface
:* ['''ip6''']: the IPv6 of this interface, for future use...
* '''bridged''': is the interface used for the KVM bridge in the production environment ? (true | false)
[ EDIT - 2010-09-13 ] No contestation, no more votes for the alternate propositions and no other entry proposed => the base version is validated.
==== script reaching IP/MAC addresses of cluster ====
...
...
@@ -160,7 +165,7 @@ interfaces.each do |interface|
Since users will make queries such as: "give me the description of that site at this date", the time between the date of the commit and the effective replication of the changes to the APIs must be as low as possible.
Since users will make queries such as: "give me the description of that site at this date", the time between the date of the commit and the effective replication of the changes to the APIs must be as low as possible.
That's why, right after your commit, you should push your changes to the remote MASTER REPOSITORY. Please note that commits whose committed date is older than 60 seconds will be rejected (if you encounter an error, check that your system clock is correctly synchronized with a time server).
