This script replaces the existing Makefile, and will be extended
to provide more functionality in future commits.
It also takes over ownership of the Ansible vault password, which
is now expected to be stored in lcitool's own config directory
along with more settings that will be introduced later.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
---
guests/Makefile | 12 ---------
guests/ansible.cfg | 1 -
guests/lcitool | 76 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 76 insertions(+), 13 deletions(-)
delete mode 100644 guests/Makefile
create mode 100755 guests/lcitool
diff --git a/guests/Makefile b/guests/Makefile
deleted file mode 100644
index 39ebe52..0000000
--- a/guests/Makefile
+++ /dev/null
@@ -1,12 +0,0 @@
-all:
-
-site:
- @ansible-playbook site.yml
-
-bootstrap:
- @ansible-playbook --ask-pass bootstrap.yml
-
-clean:
- @rm -f *.retry log
-
-.PHONY: all site bootstrap clean
diff --git a/guests/ansible.cfg b/guests/ansible.cfg
index 84fde77..6b18c57 100644
--- a/guests/ansible.cfg
+++ b/guests/ansible.cfg
@@ -5,7 +5,6 @@ inventory = ./inventory
log_path = ./log
nocows = 1
squash_actions = package
-vault_password_file = ~/.ansible/libvirt-jenkins-ci.vault-password
[ssh_connection]
pipelining = True
diff --git a/guests/lcitool b/guests/lcitool
new file mode 100755
index 0000000..aaee5f9
--- /dev/null
+++ b/guests/lcitool
@@ -0,0 +1,76 @@
+#!/bin/sh
+
+# -------------------
+# Utility functions
+# -------------------
+
+# die MESSAGE
+#
+# Abort the program after displaying $MESSAGE on standard error.
+die() {
+ echo "$1" >&2
+ exit 1
+}
+
+# ----------------------
+# User-visible actions
+# ----------------------
+
+do_help() {
+ echo "\
+Usage: $CALL_NAME ACTION [OPTIONS]
+
+Actions:
+ list List known guests
+ prepare GUEST|all Prepare or update GUEST. Can be run multiple times
+ update GUEST|all Alias for prepare
+ help Display this help"
+}
+
+do_list() {
+ # List all guests present in the inventory. Skip group names,
+ # comments and empty lines
+ grep -vE '^#|^\[|^$' inventory | sort -u
+}
+
+do_prepare() {
+ GUEST="$1"
+
+ test "$GUEST" || {
+ die "$(do_help)"
+ }
+ do_list | grep -q "$GUEST" || test "$GUEST" = all || {
+ die "$PROGRAM_NAME: $GUEST: Unknown guest"
+ }
+
+ VAULT_PASS_FILE="$CONFIG_DIR/vault-password"
+
+ # Make sure required passwords exist and are not invalid (empty)
+ test -f "$VAULT_PASS_FILE" && test "$(cat "$VAULT_PASS_FILE")" || {
+ die "$PROGRAM_NAME: $VAULT_PASS_FILE: Missing or invalid password"
+ }
+
+ ansible-playbook \
+ --vault-password-file "$VAULT_PASS_FILE" \
+ -l "$GUEST" \
+ site.yml
+}
+
+# ---------------------
+# Program entry point
+# ---------------------
+
+CALL_NAME="$0"
+PROGRAM_NAME="${0##*/}"
+CONFIG_DIR="$HOME/.config/$PROGRAM_NAME"
+
+test -f "$PROGRAM_NAME" || {
+ die "$PROGRAM_NAME: Must be run from the source directory"
+}
+
+case "$1" in
+ list) do_list ;;
+ prepare|update) do_prepare "$2" ;;
+ *help) do_help ;;
+ *) die "$(do_help)" ;;
+esac
--
2.13.6
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
On Wed, 2017-10-18 at 19:11 +0200, Andrea Bolognani wrote: > This script replaces the existing Makefile, and will be extended > to provide more functionality in future commits. > > It also takes over ownership of the Ansible vault password, which > is now expected to be stored in lcitool's own config directory > along with more settings that will be introduced later. > > Signed-off-by: Andrea Bolognani <abologna@redhat.com> > --- > guests/Makefile | 12 --------- > guests/ansible.cfg | 1 - > guests/lcitool | 76 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ > 3 files changed, 76 insertions(+), 13 deletions(-) > delete mode 100644 guests/Makefile > create mode 100755 guests/lcitool FYI: I came up with a cuter name, licito[1], and I will use that when pushing unless someone feel strongly otherwise . [1] As in LIbvirt CI TOol -- Andrea Bolognani / Red Hat / Virtualization -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
On Thu, Oct 19, 2017 at 01:40:39PM +0200, Andrea Bolognani wrote: > On Wed, 2017-10-18 at 19:11 +0200, Andrea Bolognani wrote: > > This script replaces the existing Makefile, and will be extended > > to provide more functionality in future commits. > > > > It also takes over ownership of the Ansible vault password, which > > is now expected to be stored in lcitool's own config directory > > along with more settings that will be introduced later. > > > > Signed-off-by: Andrea Bolognani <abologna@redhat.com> > > --- > > guests/Makefile | 12 --------- > > guests/ansible.cfg | 1 - > > guests/lcitool | 76 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > 3 files changed, 76 insertions(+), 13 deletions(-) > > delete mode 100644 guests/Makefile > > create mode 100755 guests/lcitool > > FYI: I came up with a cuter name, licito[1], and I will use that when > pushing unless someone feel strongly otherwise . I liked manage better that lcitool, but lcitool makes sense as well. However, I don't like licito, it might sound cool but IMHO it's not useful at all. Pavel -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
On Thu, 2017-10-19 at 14:04 +0200, Pavel Hrdina wrote: > > > This script replaces the existing Makefile, and will be extended > > > to provide more functionality in future commits. > > > > > > It also takes over ownership of the Ansible vault password, which > > > is now expected to be stored in lcitool's own config directory > > > along with more settings that will be introduced later. > > > > > > Signed-off-by: Andrea Bolognani <abologna@redhat.com> > > > --- > > > guests/Makefile | 12 --------- > > > guests/ansible.cfg | 1 - > > > guests/lcitool | 76 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > > 3 files changed, 76 insertions(+), 13 deletions(-) > > > delete mode 100644 guests/Makefile > > > create mode 100755 guests/lcitool > > > > FYI: I came up with a cuter name, licito[1], and I will use that when > > pushing unless someone feel strongly otherwise . > > I liked manage better that lcitool, but lcitool makes sense as well. > However, I don't like licito, it might sound cool but IMHO it's not > useful at all. I liked 'manage' better as well but it's also extremely generic, so the moment we started writing data outside the source directory it was automatically off the table. Neither of the other names is particularly useful, they're just names but at least they're both fairly unique and reasonably easy to remember. I think that 'licito' is a very fair name, and using it would definitely not be illegal :P http://www.spanishcentral.com/translate/l%C3%ADcito So if your only argument against it is that you don't like it very much, my reply is that I do like it quite a bit and, well, I get to name the programs I write :) -- Andrea Bolognani / Red Hat / Virtualization -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
On Thu, Oct 19, 2017 at 02:42:15PM +0200, Andrea Bolognani wrote: > On Thu, 2017-10-19 at 14:04 +0200, Pavel Hrdina wrote: > > > > This script replaces the existing Makefile, and will be extended > > > > to provide more functionality in future commits. > > > > > > > > It also takes over ownership of the Ansible vault password, which > > > > is now expected to be stored in lcitool's own config directory > > > > along with more settings that will be introduced later. > > > > > > > > Signed-off-by: Andrea Bolognani <abologna@redhat.com> > > > > --- > > > > guests/Makefile | 12 --------- > > > > guests/ansible.cfg | 1 - > > > > guests/lcitool | 76 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > > > 3 files changed, 76 insertions(+), 13 deletions(-) > > > > delete mode 100644 guests/Makefile > > > > create mode 100755 guests/lcitool > > > > > > FYI: I came up with a cuter name, licito[1], and I will use that when > > > pushing unless someone feel strongly otherwise . > > > > I liked manage better that lcitool, but lcitool makes sense as well. > > However, I don't like licito, it might sound cool but IMHO it's not > > useful at all. > > I liked 'manage' better as well but it's also extremely generic, so > the moment we started writing data outside the source directory it > was automatically off the table. I agree with that, manage is not usable in this case. > Neither of the other names is particularly useful, they're just > names but at least they're both fairly unique and reasonably easy > to remember. I think that 'licito' is a very fair name, and using > it would definitely not be illegal :P > > http://www.spanishcentral.com/translate/l%C3%ADcito > > So if your only argument against it is that you don't like it very > much, my reply is that I do like it quite a bit and, well, I get to > name the programs I write :) Well, yes and no :) you can name the program but you also need to have an ACK from community to accept that name. "licito" is just a cool name that doesn't tell you anything from the first glance what it is. On the other hand lcitool tells you that it's some kind of tool and that the "lci" part specifies what kind of tool it is. It's not only that I don't personally like it but it also looks like some randomly chosen name even though there is some pattern behind it. I vote for lcitool instead of licito. Pavel -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
On Thu, 2017-10-19 at 14:53 +0200, Pavel Hrdina wrote: > > So if your only argument against it is that you don't like it very > > much, my reply is that I do like it quite a bit and, well, I get to > > name the programs I write :) > > Well, yes and no :) you can name the program but you also need to have > an ACK from community to accept that name. "licito" is just a cool name > that doesn't tell you anything from the first glance what it is. On the > other hand lcitool tells you that it's some kind of tool and that the > "lci" part specifies what kind of tool it is. It's not only that I > don't personally like it but it also looks like some randomly chosen > name even though there is some pattern behind it. > > I vote for lcitool instead of licito. I don't feel like any of your arguments have much weight, since for most applications the name only has a very vague correlation with the functionality or intended purpose, if that: see mutt, dnf, evince, firefox, ansible and so, so many more examples. That said, point taken about the need for the community to stand behind a name before it can be adopted. Most importantly, I feel like we could both spend our time in a more productive way than argue about this, so let's just stick with the existing name unless someone comes up with a different one that manages to make everyone happy. -- Andrea Bolognani / Red Hat / Virtualization -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
On Thu, Oct 19, 2017 at 03:53:48PM +0200, Andrea Bolognani wrote: > On Thu, 2017-10-19 at 14:53 +0200, Pavel Hrdina wrote: > > > So if your only argument against it is that you don't like it very > > > much, my reply is that I do like it quite a bit and, well, I get to > > > name the programs I write :) > > > > Well, yes and no :) you can name the program but you also need to have > > an ACK from community to accept that name. "licito" is just a cool name > > that doesn't tell you anything from the first glance what it is. On the > > other hand lcitool tells you that it's some kind of tool and that the > > "lci" part specifies what kind of tool it is. It's not only that I > > don't personally like it but it also looks like some randomly chosen > > name even though there is some pattern behind it. > > > > I vote for lcitool instead of licito. > > I don't feel like any of your arguments have much weight, since > for most applications the name only has a very vague correlation > with the functionality or intended purpose, if that: see mutt, > dnf, evince, firefox, ansible and so, so many more examples. And there could be a lot of examples to support my statement. > That said, point taken about the need for the community to stand > behind a name before it can be adopted. > > Most importantly, I feel like we could both spend our time in a > more productive way than argue about this, so let's just stick > with the existing name unless someone comes up with a different > one that manages to make everyone happy. Since lcitool was also your idea I didn't think that you would not like to use it and prefer the new one. Anyway, thanks for sticking with the current name. Pavel -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
© 2016 - 2025 Red Hat, Inc.