If I want to run software collections code without enabling bash and running interactively, I have to pass the whole command on the command line like this:
scl enable rh-maven35 "mvn package" |
I’ll need to use this form to run from Ansible.
If I want to run software collections code without enabling bash and running interactively, I have to pass the whole command on the command line like this:
scl enable rh-maven35 "mvn package" |
I’ll need to use this form to run from Ansible.
I’ve been interested in the intersection of Ansible and Java development. To test this out, I want to build a “Hello World” maven App and use Ansible to drive the process to build, test, and deploy it. I’m going to use the Software Collections way of installing and running Maven to build a simple Tomcat Web Application as the basis.
Now that we can use the REST API to list inventory, it is not a big stretch to decide we want to kick off Jobs, too. Here it is in a nutshell, and some related operations for working with jobs and templates.
Continue reading
In an earlier post, I wrote about using the OpenStack Ansible inventory helper when calling and Ansible command line tools. However, When developing an playbook, often there is more information pulled from the inventory than just the set of hosts. Often, the inventory also collects variables that are used in common across multiple playbooks. For this reason, and many more, I want to be able to call an Ansible playbook or Ad-Hoc command from the command line, but use the inventory as defined by an Ansible Tower instance. It turns out this is fairly simple to do, using the REST API.
While Tower makes it easy to manage custom inventory, I still want to develop using the command line. Thus, I want to generate a comparable smart inventory for my Ansible playbook as I get from tower.
Continue reading
“First make it work, then make it faster” — Brian Kerningham
However, if the program takes too long to run, it might not be possible to make it correct. Iterative development breaks down when each iteration takes several hours. Some R code I was working with was supposed to run for a 1000 iterations, but with each iteration taking 75 seconds to run, we couldn’t take the time to let it run to completion. The problem was the continued appending of rows to a data.frame object. Referred to as the Second Circle here. That in turn points to this larger article about problems R programmers find themselves facing. . How does one extricate oneself? Here were my steps.
Continue reading
Reading draws me in. While this has done me much good in my life, it also means that I can easily get sucked into reading a news site, and waste too much time. It took me a long time to figure out how to effectively block sites that I want to browse occasionally.
When a user requests a code review, the review is responsible for making sure that the code is tested. While the quality of the tests is a subjective matter, their presences is not; either they are there or they are not there. If they are not there, it is on the developer to explain why or why not.
Not every line of code is testable. Not every test is intelligent. But, at a minimum, a test should ensure that the code in a patch is run at least once, without an unexpected exception.
I’ve played Go for years. I’ve found that having a graphical Go client has helped me improve my game immensely. And, unlike many distractors,. I can make a move, then switch back in to work mode without really losing my train of thought.
I always like the QGo client. I have found it to be worthwhile to build and run from the git repo. After moving to RHEL 7.5 for my desktop, I had to go through the process again. Here is the short version.
The policy .yaml file generated from oslo has the following format:
# Intended scope(s): system #"identity:update_endpoint_group": "rule:admin_required" # Delete endpoint group. # DELETE /v3/OS-EP-FILTER/endpoint_groups/{endpoint_group_id} # Intended scope(s): system #"identity:delete_endpoint_group": "rule:admin_required" |
This is not very useful for anything other than feeding to oslo-policy to enforce. If you want to use these values for anything else, it would be much more useful to have each rule as a dictionary, and all of the rules in a list. Here is a little bit of awk to help out:
#!/usr/bin/awk -f BEGIN {apilines=0; print("---")} /#"/ { if (api == 1){ printf(" ") }else{ printf("- ") } split ($0,array,"\"") print ("rule:", array[2]); print (" check:", array[4]); rule=0 } /# / {api=1;} /^$/ {api=0; apilines=0;} api == 1 && apilines == 0 {print ("- description:" substr($0,2))} /# GET/ || /# DELETE/ || /# PUT/ || /# POST/ || /# HEAD/ || /# PATCH/ { print (" " $2 ": " $3) } api == 1 { apilines = apilines +1 } |
I have it saved in mungepolicy.awk. I ran it like this:
cat etc/keystone.policy.yaml.sample | ./mungepolicy.awk > /tmp/keystone.access.yaml |
And the output looks like this:
--- - rule: admin_required check: role:admin or is_admin:1 - rule: service_role check: role:service - rule: service_or_admin check: rule:admin_required or rule:service_role - rule: owner check: user_id:%(user_id)s - rule: admin_or_owner check: rule:admin_required or rule:owner - rule: token_subject check: user_id:%(target.token.user_id)s - rule: admin_or_token_subject check: rule:admin_required or rule:token_subject - rule: service_admin_or_token_subject check: rule:service_or_admin or rule:token_subject - description: Show application credential details. GET: /v3/users/{user_id}/application_credentials/{application_credential_id} HEAD: /v3/users/{user_id}/application_credentials/{application_credential_id} rule: identity:get_application_credential check: rule:admin_or_owner - description: List application credentials for a user. GET: /v3/users/{user_id}/application_credentials HEAD: /v3/users/{user_id}/application_credentials rule: identity:list_application_credentials check: rule:admin_or_owner |
Which is valid yaml. It might be a pain to deal with the verbs in separate keys. Ideally, that would be a list, too, but this will work for starters.