django.contrib.auth CLI

[Jamesie Pic]

Hi all,

Currently, django has user management commands createsuperuser and changepassword, which allow to automate some user management with an automated Configuration Management (CM) tool, such as Ansible.

For example, you have a list of users in an a site-specific configuration data repository, ie. of yaml files. You can program your CM can iterate on it to create super users (example).

The only issue is that it will choke when trying to create duplicates so that's one thing I'd like to request comments about with the purpose of a patch proposal to provide an idempotent command (example). Another possibility to achieve idempotence is to use another username list.

However what happens when a user leaves the team is that we add them to another list, "remove_users" (example). Our CM will iterate over those, and delete the users. It would be easier with a CLI command to drop a user /by login name/.

Yes of course we can stack some statements with semi colons, injecting code into stdin of the django-admin shell command, and create a juicy one-liner. I've been doing that for a while myself (some years), over again, so if you're open to contributions I can direct some of that energy upstream instead of in my own one-liners / deployment recipes.

I don't think this is a good candidate for being in an external app in my opinion because the CM recipe should work with a Django fresh project, and not require to install an extra app, hence the "containing it in a one-liner".

Thanks for reading,

Have a great day

--

∞

[Adam Johnson]

This sounds like it could be useful but not sure how many projects manage their Django users through config management commands like this.

Whilst you say it would be useful in core, if you had a concrete implementation in a third party app that would provide more to talk about, and allow you to solve your problem for the current project?

There are also probably some other commands that could have idempotent modes, maybe loaddata?

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAC6Op1_2iuRVFonCsYFhNZEfTfwfqEJB4PC0upjtYMzphvKXzg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--

Adam

[Jamesie Pic]

Hi Adam,

Yeah it would be funny, maybe I'm even the only Django user that automates deployments with a CM, or to take "ootb automation experience" up to that point (maybe because I have extreme DevOps expertise ?).

Implementing this in a third party app is pointless: it will be more useful as scripts in the CM role that will then work with any django project, as I've been doing so far.

Because then my generic CM recipe can deploy any django project, without "please install my app that will provide a working CLI for impotence and user removal" (great security feature to have by the way). Yeah, it's almost 2019, can Django learn about post-deployment task idempotence ?

Doing this in an external app is pointless, we'd be adding a manual step to automate another one, i'm sorry but i can't do that, it doesn't make any sense to me.

Also, that was explained in my initial email, sorry if it wasn't clear.

Best

[Jamesie Pic]

Sorry, I forgot to answer about the loaddata proposal.

So, loaddata will not do user removal for one thing.

About user creation, the process we have is:

- add the user to the users list,

- set the password in `ansible-vault create passwords/username`

- CM will execute createsuperuser for users,

From that, it should maintain the userbase, on an ootb django project.

The workflow you are suggesting is:

- add the user to the users list,

- set the password in `ansible-vault create passwords/username`,

- somehow parse the settings to know the user model,

- generate a json file with the users, and hope that it will work with their model,

- use a script that django doesn't have to generate a salted password,

- upload the script and apply it.

I don't think I want my automation steps to rely on hope.

What about the debugging process of such a complex implementation for such a simple task ?

The cost is not worth the benefit. Injecting code in django-admin shell still does the same with

a much cheaper complexity cost.

Have a great day.

[ludovic coues]

I'm sure your extreme DevOps expertise can find a way to automate the deployment of a pip package.

I mean, you are argument about manual step for an automatic step is a straw man.

Let's say you make two deployment of your app. One on your system, one on premises on a customer system. You want both system to make use of a different set of user. But you want that idenpotent function to manage user on both system. Because that's part of your solution. You want to automate deploying your requirements.txt more than your set of user.

Beside, these days, starting your pet Django feature as a third party project is the recommended way to go. You will be able to react more quickly to user demand while your feature mature and the Django project will be able to judge how useful is your project.

Look at whitenoise or Django rest framework.

And please, read the code of conduct one more time. No subscriber of this mailing list should have to read Neither this email nor your because we are acting like children, being all snarky and passive aggressive.

--

You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAC6Op19o1wUCd4CSvxHLKHAdBduPOO4H6PuhtuyZc_LYBO9ooA%40mail.gmail.com.

[Jamesie Pic]

Hello Ludovic,

I'm glad this little joke tickled you, sorry for being that childish but sometimes I can't help it (I don't see how anybody could feel rationnaly offended since this joke talking about me). In reality, I've just been automating Django deployments for 10 year. So, if it takes 50 years to be an expert in something, I'm definitely too young to be an expert in anything ;)

Yes I have package deployment automation, because I maintain more than 30 open source packages, most of them for Django, on PyPi alone, some on NPM. The reason it's not the point, is that my CM aims at automating deployment of django projects, not of "django projects that have added my poor django app that provides a fixed createsuperuser and a removeuser CLI".

So, if i'm doing this automation again (and I am), it will be in the CM, **not** in an app, because in this case, it **doesn't make sense to do it in an app, it would just make my CM more incompatible with OOTB Django**. It's the third time I'm explaining this, please excuse me for giving up as from where i'm standing it seems nobody is able to counter that objection, but I really feel like it's being purposely ignored.

We never have two deploys "one local one production", we always have "one local one staging one production" so that's three.

Ludovic, nowadays in the DevOps world we don't "automate deployment of requirements.txt" anymore, we don't "compile a virtualenv on the target" anymore, because we have separated "build-time" from "test-time" and "deploy-time", thanks to containers.

This doesn't need to "react to changes or user feedback", the needs have been the same for 10 years, add/remove users in an automated way. Currently, we're injecting code in django-admin shell.

Oh what's that final line of your email you're accusing me of being passive aggressive :D

I do not have any more energy for this contribution, I'll just add it to my little monster crudlfap because that's my layer for any new project, as I have exigence for Controllers to refactor view code, and working ForeignKey/FileField forms out of the box (that means JS), now is the time crudlfap also compensate for Django's lack of OOTB automation feature, despite how basic they can be.

Case closed as far as I'm concerned.

My apologies to all the community for being unable to defend this proposal. Note to self: if I couldn't defend something as basic and obvious as this, learn that I will never be able to defend any proposal.

Keep up the great work overall, sincerely

Have a beautiful day,

[Jamesie Pic]

Forgot a note about extreme devops:

It's when you have an automatic deployment per feature branch (example).

GitLab even has a feature to help it called dynamic environments, currently they only support Kubernetes out of the box, but it's also possible with playlabs, the result of open sourcing the playbooks we've had in production this year at the government.

Have a great day, and most importantly: have FUN :)

[Jamesie Pic]

Hi smart nerds,

I'm sorry if my sense of humour was too much to handle for you.

But to compensate I offer the unfrustrating python CLI package, and at the same time most awesome CLI CRUD for Django to my knowledge, on yourlabs.io/oss/clilabs

One last thing, verrry important for the record, in case anybody reading wants to learn eXtreme DevOps: making a django app is an horrible suggestion, because automation tool should be automatically made available, pip install is automatable so it works, we can have an automatic pre-task that installs it, but adding to INSTALLED_APPS is a manual step, which makes django-apps and management commands that require in-project installation a horrible mistake, typical of "going one step forward and then one step back" in automation.

Exactly why this is a python package, with support for django, from the beginning. Maybe if django supports a system like pluggy this can change, but for now making this a django app would be counter productive.

Have a great day