dmsimard | apollo13: it's beautiful :p http://logs.openstack.org/03/630303/8/check/ara-integration-fedora-2.7.5/9f9f2ad/logs/data/server/ | 01:41 |
---|---|---|
dmsimard | now, pretend we have that database file right there | 02:14 |
dmsimard | gvincent: tristanC had some interesting ideas on how we could get the interface to work without the django api server running | 03:00 |
dmsimard | I was pondering how to properly reproduce something that is similar to the current ara-report approach | 03:01 |
tristanC | yeah, what i suggested is that for the "ci job report" interface, it would be great if the webclient could talk directly to the sqlite file, without having to bother with a rest-api service | 03:05 |
dmsimard | The other thing to think about is that "ara generate html" doesn't scale very well in 0.x, to the point where I don't like to recommend it | 03:05 |
tristanC | and perhaps, we could add ara to the zuul's packages.json and then integrate the rendering component directly inside the zuul dashboard | 03:05 |
dmsimard | apollo13: ^ if you have an opinion | 03:06 |
dmsimard | oh, that too, yes | 03:06 |
gvincent | @tristanC, How do you want to do this: "it would be great if the webclient could talk directly to the sqlite file, without having to bother with a rest-api service" | 07:03 |
tristanC | gvincent: https://github.com/kripken/sql.js/#usage ? | 07:26 |
tristanC | gvincent: perhaps we generate a javascript interface out of the django_rest relational model sql query? | 07:27 |
tristanC | https://github.com/kripken/sql.js/#loading-a-database-from-a-server | 07:28 |
tristanC | or perhaps the (standalone) "ci job report" interface could just be a subset of the main interface, using manually written sql expression | 07:39 |
gvincent | I don't understand tristanC the problem we try to solve here | 07:44 |
gvincent | "how we could get the interface to work without the django api server running" < this? | 07:45 |
tristanC | gvincent: this is the "ci job report" use-case, where the ara databases is just copied to a remote logserver. How would you setup an api service to expose those files content? | 07:46 |
gvincent | ok | 07:46 |
gvincent | so maybe instead of producing a sqlite.db file | 07:47 |
gvincent | we can create a result.json file | 07:47 |
gvincent | and load it with the configuration on startup | 07:47 |
gvincent | like we load the config.json file | 07:47 |
gvincent | config.mode = "standalone" | 07:47 |
gvincent | config.db = "results.json" | 07:47 |
tristanC | gvincent: if sql.js could work, or that intermediary result.json file, then you would just go to "logserver/ara-ui.html?job=check/project/job/build/uuid/ara-report" | 07:48 |
gvincent | yes | 07:48 |
gvincent | the main idea is then to create a interface for the persistence | 07:49 |
gvincent | and choose the interface depending on the configuration | 07:49 |
tristanC | gvincent: note that zuul is already producing a job-output.json... what would be the difference with the results.json? :-) | 07:49 |
gvincent | I don't see the job-output.json | 07:50 |
gvincent | :D | 07:50 |
tristanC | gvincent: http://logs.openstack.org/56/535556/17/check/tox-pep8/5995841/job-output.json.gz | 07:50 |
gvincent | I'm thinking about a json file with the interface of the API | 07:50 |
tristanC | gvincent: sounds like exactly what we need :) (again, for the standalone ci job report use case) | 07:51 |
gvincent | yeah the interface is not the same as the ARA api | 07:51 |
gvincent | but yeah | 07:51 |
*** themroc has joined #ara | 08:06 | |
apollo13 | dmsimard: opinion on what exactly? | 08:47 |
apollo13 | oh hai tristanC :D | 08:47 |
apollo13 | having that whole stuff in zuul would be great | 08:48 |
*** herald85 has joined #ara | 08:52 | |
tristanC | apollo13: greeting, it seems like a great integration opportunity between zuul and ara dashboard | 09:15 |
apollo13 | absolutely | 09:15 |
gvincent | hum manage.py was removed in ara server? | 09:41 |
gvincent | ok moved in ara/server/__main__.py | 09:42 |
gvincent | this introduce some cognitive effort ^ | 09:45 |
gvincent | logger in test in the server are anoying | 10:04 |
*** jungleslow has quit IRC | 10:24 | |
*** jungleslow has joined #ara | 10:26 | |
openstackgerrit | Guillaume Vincent proposed openstack/ara-server master: Add Tasks, Records and Plays to Playbook serializer https://review.openstack.org/630926 | 10:29 |
ara-slack | kelian.saintbonnet: @kelian.saintbonnet has joined the channel | 11:10 |
ara-slack | kelian.saintbonnet: I everyone! | 11:18 |
ara-slack | I am trying to make ARA work with AWX but I cannot get it work. I've successfully installed ARA in the awx_task container and configured it. If I try a playbook with the ansible-playbook command throught cli, the database is populated after the playbook run. However, if I try a playbook with AWX (via the web ui), the database is unchanged. Do you have any idea why it is not working? | 11:18 |
*** openstackgerrit has quit IRC | 11:22 | |
apollo13 | kelian.saintbonnet probably awx uses it's own callbacks? | 12:28 |
ara-slack | dmsimard: @kelian.saintbonnet there is an issue getting ara to work in the default virtualenv: https://github.com/ansible/awx/issues/1737#issuecomment-442454519 | 12:49 |
ara-slack | dmsimard: Create a new venv without inheriting system-site-packages, install ara in it, set it as callback and then select that new virtualenv you created in the awx web interface | 12:50 |
ara-slack | kelian.saintbonnet: Thanks apollo13, I changed the callback plugin path in AWX web ui and I don't have error anymore. However, running a playbook still does not populate the database. | 13:52 |
ara-slack | kelian.saintbonnet: I'll try your suggestion @dmsimard, thank you! | 13:52 |
ara-slack | kelian.saintbonnet: @dmsimard I modified the /etc/ansible/ansible.cfg file to set the newly created virtualenv as callback and I set it in AWX as well. Is it the only field to be edited? | 14:06 |
ara-slack | dmsimard: In your job templates, you should have a field to select the venv you're interested in | 14:08 |
ara-slack | dmsimard: There might also be a field somewhere to use a specific virtualenv by default, I forget | 14:08 |
ara-slack | dmsimard: I've been meaning to write docs about this for a long time but haven't got around to it. Would gladly accept a patch though :p | 14:10 |
*** etienne has quit IRC | 14:32 | |
ssbarnea|rover | dmsimard: please let me know when you have 10 free minutes as I want to check something with you about ARA UX. | 14:35 |
dmsimard | ssbarnea|rover: what's up ? | 14:48 |
*** openstackgerrit has joined #ara | 14:51 | |
openstackgerrit | David Moreau Simard proposed openstack/ara-server master: Add Tasks, Records and Plays to Playbook serializer https://review.openstack.org/630926 | 14:51 |
dmsimard | gvincent: ^ fixed the linters job error, was a minor thing | 14:51 |
ssbarnea|rover | dmsimard: nothing in particular, but wanted to share some minor pains I have and see if newer versions are going to fix them, or if I could attempt to make a PR to address them | 14:54 |
ssbarnea|rover | dmsimard: can we bj? | 14:54 |
dmsimard | gvincent: left a comment in https://review.openstack.org/#/c/630926/ | 14:55 |
dmsimard | ssbarnea|rover: unless there's anything confidential can we do it here so other people can weigh in if appropriate? :D | 14:55 |
ssbarnea|rover | no confidential but more about visual, i want to show the layout. | 14:56 |
ssbarnea|rover | example: https://logs.rdoproject.org/openstack-periodic/git.openstack.org/openstack-infra/tripleo-ci/master/periodic-tripleo-centos-7-master-containers-build/ff19bca/ara-report/ | 14:57 |
ssbarnea|rover | a) content does not use full page width. | 14:57 |
dmsimard | ssbarnea|rover: the UI is being rewritten from scratch | 14:57 |
ssbarnea|rover | dmsimard: ok. so no need to continue. | 14:58 |
ssbarnea|rover | any previews? | 14:58 |
ssbarnea|rover | i asked because i wanted to know if it would worth spending time making PR to alter current UI. | 14:58 |
ssbarnea|rover | if is rewritten, it means that it should not try to do anythign. | 14:58 |
dmsimard | ssbarnea|rover: https://review.openstack.org/#/q/project:openstack/ara-web | 14:59 |
dmsimard | http://logs.openstack.org/51/628451/7/check/ara-web-build-dashboard/ef65311/npm/html/playbooks | 14:59 |
dmsimard | note that it's far from finished, we are still working on getting the right pieces in the right places with the API | 14:59 |
ssbarnea|rover | dmsimard: yep, looks easy stage but i like the direction. really happy to see that you already did something I wanted but didn't had time to say | 15:00 |
dmsimard | credit goes to gvincent :) | 15:01 |
ssbarnea|rover | clicking on the playbook row should open the list of tasks, like a folder. another click should collapse it. | 15:01 |
ssbarnea|rover | i see the playbook like collapsable folder made of tasks | 15:01 |
dmsimard | we'll try to learn from the mistakes of the first ui | 15:02 |
openstackgerrit | Guillaume Vincent proposed openstack/ara-server master: Add Tasks, Records and Plays to Playbook serializer https://review.openstack.org/630926 | 15:02 |
gvincent | ssbarnea|rover> clicking on the playbook row should open the list of tasks, like a folder > yes this is a WIP https://review.openstack.org/#/c/628451/ | 15:03 |
ssbarnea|rover | gvincent: will I be able to expand/collapse multiple playbooks? | 15:04 |
gvincent | nope | 15:05 |
gvincent | ssbarnea|rover, what problem you try to solve when you want to expand multiple playbook? | 15:05 |
dmsimard | gvincent: re: manage.py -- what's the problem ? | 15:08 |
gvincent | here the etherpad we started https://etherpad.openstack.org/p/ara-ui | 15:08 |
dmsimard | logs are too verbose ? | 15:09 |
gvincent | dmsimard, manage.py doesn't exists anymore | 15:09 |
gvincent | and the replacement doesn't work | 15:09 |
dmsimard | gvincent: it's been working for me? ara-manage <something> | 15:09 |
dmsimard | ara-manage runserver, ara-manage makemigrations, etc | 15:09 |
gvincent | how to you get ara-manage? | 15:09 |
dmsimard | it's in $PATH when installed or in virtualenv bin directory | 15:10 |
dmsimard | for example https://github.com/openstack/ara-server/blob/master/tox.ini#L23-L29 | 15:11 |
gvincent | yeah so "pip install -e . && ara-manage test" doesn't work | 15:11 |
gvincent | django.core.exceptions.ImproperlyConfigured: The SECRET_KEY setting must not be empty. | 15:13 |
gvincent | and except this, when somebody use to work with django, the command he run is "python manage.py test" | 15:14 |
gvincent | removing it force the user to read the doc | 15:15 |
gvincent | that is why I spoke about cognitive effort | 15:15 |
gvincent | "pip install tox" doesn't work, the command is "pip install --user tox" or better "python -m pip install --user tox" | 15:16 |
dmsimard | we can maybe add manage.py back | 15:16 |
dmsimard | I think I took it out when we switched the configuration to dynaconf | 15:17 |
gvincent | the commit message spoke about "python -m ara.server" | 15:18 |
dmsimard | yeah but dynaconf required to be loaded dynamically at every endpoint (manage.py, wsgi, etc) | 15:18 |
dmsimard | until apollo13 switched things around to not require that | 15:19 |
dmsimard | so we can probably add manage.py back in | 15:19 |
apollo13 | didn't you leave manage.py as symlink anyways? | 15:19 |
apollo13 | gvincent: the SECRET_KEY will be missing when you use manage.py too ;) | 15:20 |
gvincent | @apollo13, yeah it's more a configuration issue | 15:20 |
dmsimard | I'm very on the fence about SECRET_KEY not being set by default | 15:20 |
gvincent | test should work out of the box | 15:20 |
dmsimard | I know why it exists and why it is important | 15:21 |
dmsimard | but it's that one extra step that people didn't need to care about before | 15:21 |
gvincent | I disagree | 15:21 |
gvincent | https://github.com/lesspass/lesspass/blob/master/containers/backend/lesspass/settings.py#L11-L14 | 15:21 |
dmsimard | gvincent: so you have a different secret key at each runtime ? | 15:22 |
apollo13 | yeah, but then again that won't even work for the tests | 15:22 |
gvincent | but for test you can overwrite the configuration https://github.com/lesspass/lesspass/blob/master/containers/backend/lesspass/settings.py#L162-L171 | 15:22 |
apollo13 | because currently integration or so has two invocations | 15:22 |
apollo13 | gvincent: that is a hack at best imo | 15:22 |
apollo13 | but I'd be okay with that | 15:22 |
dmsimard | what we could do | 15:22 |
dmsimard | is persist a generated random key in the config file | 15:22 |
dmsimard | the config file we generate at the end of settings.py | 15:22 |
gvincent | @apollo13, "yeah, but then again that won't even work for the tests" if you generate the secret key at startup if not in conf no | 15:23 |
dmsimard | i,e, this file http://logs.openstack.org/03/630303/8/check/ara-integration-fedora-2.7.5/9f9f2ad/logs/data/server/default_config.yaml | 15:23 |
gvincent | dmsimard, we should differenciate test from normal run | 15:23 |
dmsimard | gvincent: tox takes care of setting the vars | 15:23 |
gvincent | out of the box test should not require anything | 15:24 |
apollo13 | gvincent: they don't, tox takes care of that | 15:24 |
gvincent | dmsimard, tox yes, but you need to read the doc | 15:24 |
apollo13 | *shrug* | 15:24 |
gvincent | I try to follow the adage "don't make me think" | 15:24 |
apollo13 | I am fighting all day with people who don't think and then break something, so… | 15:25 |
apollo13 | ala; oh awx did lost my data | 15:25 |
apollo13 | well did you tell it to use a persistent storage for postgres? no why would I? because the supplied compose is for testing only… | 15:26 |
dmsimard | gvincent: so I can address the missing manage.py | 15:26 |
dmsimard | we can agree on that | 15:26 |
gvincent | @apollo13, fact is people don't read the doc, and a good interface is self documented | 15:27 |
dmsimard | I think we agree that it would also be nice for SECRET_KEY to have a default | 15:27 |
apollo13 | gvincent: those people are not my target area though | 15:27 |
apollo13 | bbl gotta run | 15:27 |
apollo13 | anyways I am -1 on any default that decreses security to non-existant | 15:28 |
gvincent | I can read the doc, my point was, I know django and python, and I needed to open the tox.ini and the readme to understand how I can only run unit test in a django project | 15:28 |
dmsimard | apollo13: I'll try and see if I can propose something, we can discuss in the review | 15:28 |
dmsimard | would manage.py be exactly the same file as __main__.py ? should we symlink it ?https://github.com/openstack/ara-server/blob/master/ara/server/__main__.py | 15:29 |
gvincent | https://www.amazon.com/Dont-Make-Me-Think-Usability/dp/0321344758 | 15:30 |
gvincent | Don't Make Me Think: A Common Sense Approach to Web Usability, 2nd Edition | 15:30 |
*** etienne has joined #ara | 15:34 | |
gvincent | apollo13, we don't have the same target: my target are python devs who want to contribute on ara | 15:35 |
gvincent | python django dev* more precisely | 15:35 |
openstackgerrit | David Moreau Simard proposed openstack/ara-server master: Re-add manage.py to the root of the repository https://review.openstack.org/631006 | 15:36 |
apollo13 | dmsimard: afaik yes | 15:43 |
apollo13 | gvincent: don't get me wrong, I am not against running tests and even a dev server without any settings -- I am all in favor for that | 15:44 |
apollo13 | I just do not want to end up with a static SECRET_KEY in most deployments | 15:44 |
gvincent | I agree with you so | 15:44 |
gvincent | :D | 15:44 |
apollo13 | gvincent: and don't make me think is relatively; I think you usually cannot run any tests in a complex project without reading the docs | 15:45 |
apollo13 | ie what if you have a hard requirement on redis and postgres? | 15:45 |
gvincent | for you unit tests? | 15:45 |
apollo13 | yes | 15:45 |
apollo13 | ie if you are using json fields in your models, sqlite will not cut it | 15:46 |
apollo13 | or really, anything from contrib.postgres | 15:46 |
gvincent | unit test should not rely on your implementation | 15:46 |
apollo13 | in theory yes, in practice it is rather hard to mock out your database | 15:46 |
gvincent | I prefer integration tests for those, and design pattern to create good unit tests | 15:47 |
gvincent | in lesspass I'm using docker to do some integration tests https://github.com/lesspass/lesspass/blob/master/containers/test.sh | 15:48 |
apollo13 | well yes, though most projects tend to mix unit and integration tests and I am not even sure django would let you start without pg if you use pg features | 15:48 |
apollo13 | gvincent: haha, now we are going full circle, as a django dev I'd expect manage.py test and now I should find a shell script to start a docker run? :D | 15:49 |
gvincent | @apollo13, python manage.py works | 15:49 |
gvincent | https://github.com/lesspass/lesspass/tree/master/containers/backend | 15:50 |
gvincent | those are different tests | 15:50 |
apollo13 | yeah, but the point being to execute the tests you need to read the docs | 15:50 |
apollo13 | the tests == all of them | 15:50 |
apollo13 | oh you are working on lesspass? | 15:51 |
gvincent | I'm the creator of lesspass | 15:51 |
apollo13 | I never understood that project /o\ | 15:51 |
apollo13 | I mean I understand, I just could never find a usecase | 15:51 |
gvincent | I spoke about the unit test, the tox -e py3 on ara | 15:51 |
gvincent | but yeah if you want to run all the tests, on complex projects you will need to read the doc, or see the .travis.yml file :D | 15:52 |
gvincent | https://github.com/lesspass/lesspass/tree/master/containers/backend | 15:52 |
ara-slack | slackbot: Pssst! I didn’t unfurl https://github.com/lesspass/lesspass/tree/master/containers/backend because it was already shared in this channel quite recently (within the last hour) and I didn’t want to clutter things up. | 15:52 |
gvincent | https://raw.githubusercontent.com/lesspass/lesspass/master/.travis.yml | 15:53 |
apollo13 | "unfurl"? what is that bot thingy trying to do? | 15:53 |
apollo13 | gvincent: right | 15:53 |
dmsimard | not sure what happened with the slackbot there | 15:54 |
dmsimard | I think it just relayed a message that slackbot sent to it | 15:55 |
dmsimard | er | 15:55 |
dmsimard | ara-slack is something I wrote to bridge irc and slack | 15:55 |
apollo13 | anyways, I am fine with setting the SECRET_KEY in tests with the hack lesspass uses and probably also fine to generate a random otherwise | 15:55 |
dmsimard | then there's slackbot which is that integrated slack bot thing | 15:55 |
apollo13 | I just think that the user experience from the latter is subpar if someone deploys it and wonders why they cannot login after a server restart | 15:55 |
openstackgerrit | David Moreau Simard proposed openstack/ara-server master: Create a persistent default random secret key if none are set https://review.openstack.org/631011 | 15:56 |
dmsimard | apollo13, gvincent: what do you think about ^ | 15:56 |
dmsimard | It seems like it works at first glance | 15:56 |
apollo13 | dmsimard: import get_random_string from django.utils.crypto | 15:57 |
apollo13 | https://github.com/django/django/blob/master/django/utils/crypto.py#L48 | 15:57 |
dmsimard | apollo13: sure | 15:57 |
apollo13 | that should work without settings module set | 15:57 |
apollo13 | (hopefully) | 15:57 |
gvincent | yes random is cryptographically not a good generator | 15:58 |
apollo13 | otherwise looks good, though it will break if you split that out into a cli command :) | 15:58 |
gvincent | I use SECRET_KEY=$(LC_ALL=C tr -dc A-Za-z0-9_ </dev/urandom | head -c 32) | 15:58 |
gvincent | in lesspass to generate the env variable | 15:58 |
apollo13 | nice defensive coding, wouldn't have thought to set LC_ALL for tr :D | 15:59 |
gvincent | it works on mac and linux | 15:59 |
gvincent | @apollo13, it was in a hacker news comment when lesspass reach the main page | 16:00 |
gvincent | it's not from me :D | 16:00 |
openstackgerrit | David Moreau Simard proposed openstack/ara-server master: Create a persistent default random secret key if none are set https://review.openstack.org/631011 | 16:00 |
dmsimard | gvincent: there's a lot of smart people on HN if you can filter the trolls | 16:00 |
gvincent | true | 16:00 |
dmsimard | getting to the front page of HN can be both a blessing and a curse :p | 16:00 |
dmsimard | happy to see you're still alive | 16:01 |
apollo13 | btw what do you folks think if we added some code to manage.py that would a) check if there is a tty and then b) ask to generate a default config before going on? | 16:01 |
gvincent | but troll are a good way to found the pain point of the user | 16:01 |
apollo13 | this would make it explicit that a config is generated and could also tell the user the location of it | 16:01 |
gvincent | and if you read carrefully you have all the problem you need to solve if you want to be successful | 16:01 |
gvincent | this is my secret sauce :D for all startuper | 16:01 |
dmsimard | gvincent: yeah, you need to try to find the useful feedback in there | 16:01 |
gvincent | ahah everyfeedback is good, the more hate you have, the better is | 16:02 |
dmsimard | apollo13: could we perhaps just print something all the time ? regardless if there's a tty or not ? | 16:02 |
gvincent | if people insult you, you know that the problem they have is big! | 16:02 |
dmsimard | like default configuration created at $path | 16:02 |
gvincent | I think apollo13 imagine something like print("Secret not found, generating one ...") | 16:03 |
apollo13 | dmsimard: yes, and probably even "using config $xxx" | 16:03 |
dmsimard | sure | 16:04 |
apollo13 | gvincent: I was mainly after an indication to tell the user what's going on | 16:04 |
gvincent | +1 | 16:04 |
apollo13 | I'd be fine with either approach | 16:04 |
dmsimard | we can do both | 16:04 |
apollo13 | actually I think a print ala "generating secret key" in get_secret_key would be very nice to have and a good indication of what is going on | 16:07 |
apollo13 | sorry to be a pain in the ass, but I care strongly about security :( | 16:08 |
dmsimard | no, we're on the same wavelength | 16:12 |
dmsimard | I'm trying to see if I can use logging instead of a print | 16:12 |
dmsimard | it's not printing right now :D | 16:12 |
apollo13 | ah yes, which logger are you using? | 16:13 |
apollo13 | oh wait | 16:13 |
dmsimard | I'm thinking there might be some sort of race | 16:13 |
apollo13 | logging at this point might be weird | 16:13 |
dmsimard | because logging is configured during settings | 16:13 |
dmsimard | yeah | 16:13 |
apollo13 | because django might have cleared logging conf, yeah | 16:13 |
dmsimard | so just a print then? :/ | 16:15 |
apollo13 | I think that would be the safest | 16:15 |
*** dougbtv has joined #ara | 16:15 | |
apollo13 | you could inspect & reconfigure the logging config but probably not worth it | 16:16 |
apollo13 | also I think the runserver messages are also print | 16:16 |
apollo13 | (not the access log, but the startup messages) | 16:16 |
dmsimard | oh, wait, I know | 16:19 |
dmsimard | hang on | 16:19 |
dmsimard | ok, it works, sending it in a sec | 16:22 |
*** themroc has quit IRC | 16:29 | |
dmsimard | ah crap | 16:34 |
dmsimard | failed | 16:35 |
dmsimard | ammended my commit (muscle memory) while I wanted to create a new one haha | 16:35 |
apollo13 | reflog? | 16:35 |
dmsimard | let me split it out and send it | 16:35 |
openstackgerrit | David Moreau Simard proposed openstack/ara-server master: Create a persistent default random secret key if none are set https://review.openstack.org/631011 | 16:38 |
openstackgerrit | David Moreau Simard proposed openstack/ara-server master: Load logging from settings.py to tell users about the things we do https://review.openstack.org/631018 | 16:38 |
dmsimard | apollo13, gvincent: ^ | 16:38 |
dmsimard | oops, stray comment | 16:39 |
apollo13 | hehe | 16:40 |
apollo13 | so I can discard my "You just did though ;)" comment on your print comment? | 16:40 |
openstackgerrit | David Moreau Simard proposed openstack/ara-server master: Load logging from settings.py to tell users about the things we do https://review.openstack.org/631018 | 16:40 |
dmsimard | apollo13: yeah :p | 16:41 |
dmsimard | ah, wait | 16:41 |
dmsimard | caught something else | 16:41 |
openstackgerrit | David Moreau Simard proposed openstack/ara-server master: Create a persistent default random secret key if none are set https://review.openstack.org/631011 | 16:41 |
openstackgerrit | David Moreau Simard proposed openstack/ara-server master: Load logging from settings.py to tell users about the things we do https://review.openstack.org/631018 | 16:42 |
dmsimard | sorry for the spam | 16:42 |
dmsimard | here, let me even get the new integration jobs to run on top of that tree | 16:43 |
openstackgerrit | David Moreau Simard proposed openstack/ara-infra master: WIP: New ARA 1.0 integration jobs https://review.openstack.org/630303 | 16:44 |
dmsimard | apollo13: ^ so Zuul has this "depends-on" syntax that allows for preparing a git repo with a patch that hasn't landed yet | 16:45 |
dmsimard | useful when working with multiple projects | 16:45 |
apollo13 | interesting | 16:45 |
apollo13 | I just manually write the gerrit review url in there? | 16:46 |
dmsimard | it also won't let the "child" patch merge so long as the "parent" patch hasn't merged | 16:46 |
dmsimard | it works for projects that zuul knows about, yes | 16:46 |
dmsimard | for example if you're writing something in ara-plugins that won't work until something has landed in ara-server, you can put your patch in ara-plugins as depends-on of that ara-server patch | 16:46 |
dmsimard | so when zuul runs the jobs for ara-plugins, it will pull that patch when installing ara-server | 16:47 |
dmsimard | so you can test that it works without needing to merge | 16:47 |
apollo13 | nice | 16:47 |
dmsimard | if we really wanted to | 16:48 |
dmsimard | openstack's zuul is also set up to know about ansible's github repo | 16:48 |
dmsimard | so we could even use a depends-on a github PR link | 16:48 |
apollo13 | mhm, I have an idea | 16:48 |
dmsimard | although right now we install ansible from pip | 16:48 |
dmsimard | so we would need to adjust the job to use ansible from source if need be | 16:49 |
apollo13 | actually no, if we want to use logging at that level we have to do it like this | 16:49 |
apollo13 | grml, merge zuul I want to test that locally :D | 17:02 |
apollo13 | dmsimard: would it make sense to only write a default config if no ARA_SETTINGS are specified? | 17:03 |
openstackgerrit | Merged openstack/ara-server master: Re-add manage.py to the root of the repository https://review.openstack.org/631006 | 17:06 |
openstackgerrit | Merged openstack/ara-server master: Create a persistent default random secret key if none are set https://review.openstack.org/631011 | 17:06 |
openstackgerrit | Merged openstack/ara-server master: Load logging from settings.py to tell users about the things we do https://review.openstack.org/631018 | 17:06 |
apollo13 | dmsimard: haha, we need to make ara/server/__main__.py executable for the symlink to work properly, that is if we want to execute it without "python manage.py" | 17:07 |
dmsimard | Errr | 17:11 |
dmsimard | I... guess ? | 17:11 |
dmsimard | apollo13: re: ARA_SETTINGS | 17:12 |
dmsimard | Maybe | 17:12 |
openstackgerrit | Florian Apolloner proposed openstack/ara-server master: Adjusted requirements to include yaml for dynaconf. https://review.openstack.org/631026 | 17:12 |
apollo13 | or we make it an actual file and just import the stuff, probably nicer | 17:12 |
openstackgerrit | Florian Apolloner proposed openstack/ara-server master: Alternative approach to manage.py instead of symlink. https://review.openstack.org/631027 | 17:14 |
apollo13 | hehe and we are not even using the default config file | 17:15 |
dmsimard | Oh yeah, that's nice | 17:16 |
dmsimard | I'll review after lunch | 17:17 |
apollo13 | this is what ara tries to load https://dpaste.de/cooS :D | 17:17 |
apollo13 | obviously not our default config :þ | 17:17 |
dmsimard | That's dynaconf ? | 17:19 |
apollo13 | yes | 17:20 |
apollo13 | that's where it looks by default | 17:21 |
apollo13 | that is if we do not set ARA_SETTINGS | 17:21 |
dmsimard | I guess I will also need to update docs for SECURE_KEY | 17:21 |
apollo13 | which we need to set before loading the settings obviously, which means SERVER_DIR gets a chicken egg problem, though I'll just hardcode that for that | 17:21 |
apollo13 | SECRET_* | 17:21 |
dmsimard | Yes :) | 17:21 |
*** herald85 has quit IRC | 17:22 | |
apollo13 | actually, default config like we set it now will break if you have a config and change server_dir there | 17:23 |
apollo13 | then it will write a new config :D | 17:23 |
apollo13 | I'll go fixing | 17:23 |
dmsimard | Thanks for fixing my stuff :p | 17:25 |
openstackgerrit | Florian Apolloner proposed openstack/ara-server master: Fixed default configuration loading and do not write default config if a config is specified. https://review.openstack.org/631029 | 17:28 |
openstackgerrit | Florian Apolloner proposed openstack/ara-server master: Fixed config code example if the path has spaces. https://review.openstack.org/631030 | 17:31 |
apollo13 | dmsimard: I am also going to lunch; any objections to rename DEFAULT_CONFIG to DEFAULT_SETTINGS to be in line with django/dynaconf terminology? | 17:32 |
dmsimard | Sure | 17:33 |
dmsimard | No objections | 17:33 |
openstackgerrit | Florian Apolloner proposed openstack/ara-server master: Renamed most of config to settings and dropped the default_ prefix. https://review.openstack.org/631034 | 17:39 |
apollo13 | all yours | 17:39 |
apollo13 | sorry for the spam, I guess :þ | 17:45 |
dmsimard | apollo13: if only I could get spam bug fixes every day | 18:43 |
dmsimard | I would be soooo happy | 18:43 |
dmsimard | s/spam bug fixes/spammed by bug fixes/ | 18:43 |
apollo13 | If I wouldn't have to work, I'd be soooooooo happy | 18:43 |
apollo13 | actually no, I like my work and wouldn't know what to do with my free time^^ | 18:43 |
dmsimard | apollo13: https://review.openstack.org/#/c/631029/ is failing on ERROR! Unexpected Exception, this is probably a bug: [Errno 2] No such file or directory: '/home/zuul/.ara/server/default_config.yaml' | 18:47 |
dmsimard | http://logs.openstack.org/29/631029/1/check/ara-server-ansible-integration/b2c8d3b/ara-report/result/4f78e88f-aa59-4a19-83da-5d2823e3ce88/ | 18:47 |
dmsimard | and it's making the two other reviews failing since they're based on top of it | 18:47 |
apollo13 | no it's not a bug | 18:48 |
apollo13 | at least not in my code | 18:48 |
apollo13 | I think | 18:48 |
apollo13 | is ARA_SETTINGS set there? | 18:48 |
apollo13 | haha, I know why it fails | 18:49 |
apollo13 | because you did set SERVER_DIR externally but the default config should end up in the default location if not specified | 18:49 |
apollo13 | so yeah, default config creation probably needs an os.makedirs | 18:50 |
apollo13 | open to ideas, the thing is we need to construct something as default that does not need anything else from settings | 18:50 |
apollo13 | although we could place it in server dir if that is in os.environ | 18:52 |
apollo13 | I'll upload a new patch set | 18:52 |
apollo13 | this will get ugly | 18:54 |
dmsimard | hmmmm | 18:54 |
apollo13 | I am not sure what the best approach is | 18:55 |
apollo13 | ARA_BASE_DIR is basically a setting | 18:55 |
apollo13 | so the default settings file should not depend on it | 18:55 |
dmsimard | it should ideally not be hardcoded either | 18:56 |
openstackgerrit | Merged openstack/ara-server master: Adjusted requirements to include yaml for dynaconf. https://review.openstack.org/631026 | 18:56 |
openstackgerrit | Merged openstack/ara-server master: Alternative approach to manage.py instead of symlink. https://review.openstack.org/631027 | 18:56 |
apollo13 | dmsimard: I disagree, either we use a settings file from a hardcoded location or we set ARA_SETTINGS to specify our own | 18:57 |
dmsimard | We could "bypass" dynaconf for ARA_BASE_DIR and ARA_SERVER_DIR ? | 18:57 |
apollo13 | we could, though we'd have to reevaluate it right after loading because the config file could change those again | 18:57 |
dmsimard | we can call them something else | 18:57 |
apollo13 | although env variables would win I guess | 18:57 |
dmsimard | and not include them in the config file template | 18:58 |
apollo13 | now that would be getting ugly :D | 18:58 |
dmsimard | as to not induce confusion | 18:58 |
apollo13 | the thing is, if we do rely on those variables at all we write a new settings default file everytime this variable is changed | 18:58 |
apollo13 | which feels weird at best | 18:58 |
dmsimard | ok let's take a step back | 18:59 |
dmsimard | ultimately, these two variables are used to define where the default configuration file will be generated and where the database will be stored by default | 19:00 |
apollo13 | ultimately just one though, ARA_SERVER_DIR | 19:00 |
dmsimard | I guess | 19:01 |
apollo13 | it might make sense to reduce it to one | 19:01 |
apollo13 | and then maybe use that to generate the config file | 19:01 |
apollo13 | the two feel kinda weird | 19:01 |
dmsimard | I'm not sure I fully remember why these two exist | 19:01 |
apollo13 | I think it is just because django had base_dir and you probably then wanted different folders for client & server and what not | 19:02 |
dmsimard | yeah | 19:02 |
apollo13 | I think we could drop server_dir and just use base_dir as base for ~/.ara/server | 19:02 |
apollo13 | ~/.ara doesn't really matter for anything we do | 19:02 |
dmsimard | sure | 19:02 |
apollo13 | we need one folder | 19:02 |
dmsimard | ok so now we have one setting instead of two | 19:02 |
dmsimard | does that help us ? not really ? | 19:03 |
apollo13 | no, we still need to read it from the environment | 19:03 |
apollo13 | but that should be okay | 19:03 |
dmsimard | can we do something like | 19:03 |
apollo13 | still better than two | 19:03 |
dmsimard | hmm | 19:03 |
dmsimard | nevermind | 19:03 |
dmsimard | yeah let's go with that for now | 19:03 |
dmsimard | if it feels clunky we can iterate on it | 19:04 |
dmsimard | os.getenv("ARA_BASE_DIR", os.expanduser("~/.ara/server")) ? | 19:04 |
dmsimard | or ARA_SERVER_DIR, I suppose | 19:04 |
dmsimard | oh, that's where django will end up sending static files too | 19:05 |
apollo13 | yeah | 19:06 |
apollo13 | although that is just defaults, users can change it then anyways | 19:07 |
apollo13 | so BASE_DIR = os.getenv("ARA_BASE_DIR", os.expanduser("~/.ara/server")) sounds fine to me | 19:07 |
apollo13 | with the fact that we need to reread it after loading settings if someone did change it there | 19:07 |
openstackgerrit | Florian Apolloner proposed openstack/ara-server master: Fixed default configuration loading and do not write default config if a config is specified. https://review.openstack.org/631029 | 19:12 |
apollo13 | dmsimard: ^ next try, let's see what zuul says | 19:13 |
*** weshay has joined #ara | 19:26 | |
openstackgerrit | Florian Apolloner proposed openstack/ara-server master: Fixed default configuration loading and do not write default config if a config is specified. https://review.openstack.org/631029 | 19:38 |
apollo13 | typo ;) | 19:38 |
*** dougbtv has quit IRC | 19:44 | |
dmsimard | apollo13: +2 on https://review.openstack.org/#/c/631029/3 but left a comment | 22:55 |
openstackgerrit | Merged openstack/ara-server master: Add Tasks, Records and Plays to Playbook serializer https://review.openstack.org/630926 | 23:19 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!