Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

New module: app_info #259

Open
wants to merge 4 commits into
base: main
Choose a base branch
from
Open

New module: app_info #259

wants to merge 4 commits into from

Conversation

aalaesar
Copy link
Member

@aalaesar aalaesar commented Apr 21, 2023

Add a simple module to get application informations (status, update, etc)
This is intended to be a foundation for the next module for app management

@staticdev
Copy link
Collaborator

staticdev commented Apr 21, 2023

@aalaesar package managers in general resolve better if you send the complete list of apps in one command. I know this works for example for apt and pip packages. Not sure if it is the case for occ, but could be worth to try for make it more efficient.

Btw @wiktor2200 met me in person today by chance and recognized me xD

@aalaesar
Copy link
Member Author

aalaesar commented Apr 23, 2023

@aalaesar package managers in general resolve better if you send the complete list of apps in one command. I know this works for example for apt and pip packages. Not sure if it is the case for occ, but could be worth to try for make it more efficient.

It is not the case the the occ cli tool unfortunately, there are options to get all info at once but it make it less actionable.
The current issue is that , for gathering infos about all applications on a moderate instance, the module take just too much time...
hmm
I suspected that calling occ would be costly in time (maybe that's how the run_occ function is implemented that is not optimized)
There is indeed the risk for the module to badly scale (in running time) in case of large amount of application installed on an instances.
In that case I think splitting the information gathering In Two modules would be simplier:

  • one module to get facts about the nexcloud server with general information (all applications and update available), easy to get in a static and limited number of calls to occ.
  • one app_info module to get more details about one application in particular

@wiktor2200 wiktor2200 added enhancement New feature or request python Pull requests that update Python code labels Apr 27, 2023
@aalaesar aalaesar marked this pull request as ready for review July 30, 2023 15:50
@aalaesar
Copy link
Member Author

Hello there.
I'm back after some personal issues that took me away from my projects.
I wanted to finish the app_info module.
From my point of vue, the module is finished
but the CI seems broken with concurrency issues with docker and the tests running in parallel, and also the occ install command failing somehow 😕
as the change is not related to the installation role, this can be merged.

@aalaesar aalaesar changed the title first draft of app_infos New module: app_info Aug 22, 2023
@aalaesar
Copy link
Member Author

@staticdev @wiktor2200
Gentle up 😄 could you review the module?
it's a fairly simple one as it only gather infos for only one app

Copy link
Collaborator

@wiktor2200 wiktor2200 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi! @aalaesar sorry for late review.
I've analyzed your code and it looks good.
I'm not convinced only by naming for "shipped" apps, I'd personally rename it to "pre-installed", "default", "enabled_by_default' or similar.
Here in documentation https://docs.nextcloud.com/server/latest/admin_manual/apps_management.html#apps-management they call them: default enabled or enabled by default.

But it's up to you, so I leave approve for your code :)

Copy link
Collaborator

@staticdev staticdev left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry also for taking long and welcome back! From my side the functional side looks good. I found a couple of issues with the imports, some are super minor/cosmetic but anyway they should be on top level.

@@ -0,0 +1,194 @@
#!/usr/bin/python
# -*- coding: utf-8 -*-
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
# -*- coding: utf-8 -*-
import copy
import json
from ansible.module_utils.basic import AnsibleModule
from ansible_collections.nextcloud.admin.plugins.module_utils.occ import \
run_occ
from ansible_collections.nextcloud.admin.plugins.module_utils.occ_args_common import \
OCC_ARGS_SPEC

Encoding is not necessary to add anymore uft-8 is the default https://stackoverflow.com/questions/14083111/should-i-use-encoding-declaration-in-python-3

Instead I would add all imports here, see explanation below.

#!/usr/bin/python
# -*- coding: utf-8 -*-

# Copyright: (c) 2023, Marc Crébassa <[email protected]>
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would also avoid adding license to each file since we already have clear license settings on Github and on the repo.


import copy
import json
from ansible.module_utils.basic import AnsibleModule
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is normally good to separate build-in imports from 3rd party

import json

from ansible.module_utils.basic import AnsibleModule

Comment on lines +103 to +106
from ansible_collections.nextcloud.admin.plugins.module_utils.occ import run_occ
from ansible_collections.nextcloud.admin.plugins.module_utils.occ_args_common import (
OCC_ARGS_SPEC,
)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would do long imports like this:

from ansible_collections.nextcloud.admin.plugins.module_utils.occ import \
    run_occ
from ansible_collections.nextcloud.admin.plugins.module_utils.occ_args_common import \
    OCC_ARGS_SPEC

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that part was formatted by only-black

returned: success
"""

import copy
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Imports should come right after #!/usr/bin/python, in this case is not a good idea to declare variables before imports.

@aalaesar
Copy link
Member Author

I'm not convinced only by naming for "shipped" apps, I'd personally rename it to "pre-installed", "default", "enabled_by_default' or similar. Here in documentation https://docs.nextcloud.com/server/latest/admin_manual/apps_management.html#apps-management they call them: default enabled or enabled by default.

But it's up to you, so I leave approve for your code :)

Hello there ! 😃
Thank you for your feedback .
Regarding your 2 points:
I'm simply reusing the terminology used by the occ cli to list or filter the apps that comes preinstalled with the server, but I'm not saying it's the best word.
Regarding pre installed apps I think they are not all pre-enabled, so its hard to tell which one was enabled at any given time, as the list of enabled apps is live, and there is no filter of my knowledge to list de pre enabled apps, I can't generate this info.

@aalaesar
Copy link
Member Author

Sorry also for taking long and welcome back! From my side the functional side looks good. I found a couple of issues with the imports, some are super minor/cosmetic but anyway they should be on top level.

Hello There ! 😃
Thank you for your feedback.
Regarding your comments we will have to decide between official ansible doc regarding module code format or python formatting good practices 😕
Regards
Aal.

@wiktor2200
Copy link
Collaborator

I'm simply reusing the terminology used by the occ cli to list or filter the apps that comes preinstalled with the server, but I'm not saying it's the best word.
Regarding pre installed apps I think they are not all pre-enabled, so its hard to tell which one was enabled at any given time, as the list of enabled apps is live, and there is no filter of my knowledge to list de pre enabled apps, I can't generate this info.

Ok, so let's stick to one naming convention or we would to change it everywhere otherwise (we still can in the future).
And that's true, pre-enabled apps are hard to determine and I think it also has changed over time in official Nextcloud repo, so I agree with current solution. :)

@staticdev
Copy link
Collaborator

Sorry also for taking long and welcome back! From my side the functional side looks good. I found a couple of issues with the imports, some are super minor/cosmetic but anyway they should be on top level.

Hello There ! 😃 Thank you for your feedback. Regarding your comments we will have to decide between official ansible doc regarding module code format or python formatting good practices 😕 Regards Aal.

Oh my, this documentation really surprises me. Looks like it is stopped in time. In this case, let's keep your solution. If I have some time i will create an issue on Ansible side.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request python Pull requests that update Python code
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants