#8 python replacement of setup-ds.pl
Closed: Fixed 6 years ago Opened 7 years ago by firstyear.

We would like to replace the setup-ds.pl tool with a python one. This is a highlevel tracker of the feature, and it's goals.

  • Tool should be interruptable - and can recover / remove partial installs
  • API should be exposed, which is better than calling pl scripts. IE a downstream can include the library and call it internally.

Metadata Update from @firstyear:
- Issue assigned to firstyear

7 years ago

Metadata Update from @firstyear:
- Issue assigned to firstyear

7 years ago

Is this ticket also relevant for replacement of dsremove.pl ?

Metadata Update from @tbordaz:
- Custom field Origin adjusted to Community
- Custom field Review Status adjusted to review

7 years ago

Yes it is. This should replace both the functions of installation and removal.

Just for logging. Robustness of those script was requested https://pagure.io/freeipa/issue/6756

Yep. That was one of my goals also.

  • "Tool should be interruptable - and can recover / remove partial installs" ~= idempotent? ;)
  • Would the utility be interactive or a file based or both?
  • Would it set up one server or server(s)?
  • Would it configure the remote server(s)?
  • Would it cover the replication, plug-ins, and backend configurations?
    (Sorry, I'm dumping RFEs here... :)
  • interruptable -- yes
  • both file and interactive (only file atm)
  • one server only
  • no to remote: we have ansible for that
  • backend yes, plugin / replication probably yes, but not in first release .

I am new to this project and trying to learn more about it. I want to participate in this discussion so that I can learn from lib389 developers. Here is my something I want to ask @firstyear
If the new python tool can create 1 server from a file than it can easily create multiple servers from the file, so is there any special reason considering that you want the python setup script to setup only one server.

@ankity10 In this case why not just run the install multiple times? Rather than trying to excess functionality and code, we should make the tool "do enough" and then use other tools on top to create more complex patterns.

For example, if you want to install two instances, you run dscreate twice. If you want to install on a remote server, you use ssh or ansible rather than trying to embed SSH control logic in our tools.

We have limited resources as is in the team, and certainly limited expertise over things like SSH, so we should delegate complex patterns to higher level tools instead.

What we should focus on is getting our single server installation story correct and solid first instead.

Satisfactory explanation, I understood its not a good strategy to reinvent the wheel. Thanks.

@ankity10 No problem, thank you for asking the question!

This is now at a point from some other tickets where we can use the python installer in tests with correct operation,

Metadata Update from @firstyear:
- Issue close_status updated to: Fixed
- Issue status updated to: Closed (was: Open)

6 years ago

Login to comment on this ticket.

Metadata