Ideas for new features

[urosgruber]

I'm not sure what would be the best way to write about this and how detailed I need to be. But let me write a list of feature would make pot even better. Most of it I use through pre-post hooks and other wrappers around pot command

• able to set tags to each pot. For example, prod, stgn, web, db etc., on top of this pot ls could benefit using filter by tags, to show only production pots for example.
• allow specifying IP for nat rule per pot. I'm using some pots with different services but not all use the same IP for its nat traffic. I also limit ports with the nat rule. For example, allow only traffic to http(s). And what is the reason port export is not allowed with alias network type?
• jail system allows using custom fstab file to mount and unmount different FS. I've checked the source code and it looks implementation does not utilize this. Any particular reason?
• able to output more pot attributes while listing it, maybe event in a more tabular format or potentially JSON format. Nice addition to that is to have a parameter to specify what attribute to output
  pot ls -o name,active,type,ip
• able to search pot while doing list pot ls foo* would list all pots begin with foo. I believe this can be done via grep regexp rule.
• able to execute some command with jexec inside running pot
  pot exec -p mypot -- ls -al
• able to add custom attributes to a pot, prefixed with user.
  pot set-attr -A user.account -V 12345. If later this could be used to list only pots that belong to user.account = 12345 would be even better
• some commands use -p parameter to specify what pot to affect. I believe all commands could behave in a way that any parameter without a flag is actually pot name, for example
  pot start <potname> vs pot set-attr -p <potname>. Not use if this is a limitation within the shell or something else. But I believe pot set-attr -A <attribute> -V <value> <potname> would be more natural to use.
• I've noticed that base files are fetched and stored in /tmp folder. Would be possible to have this saved inside /pot folder structure and also if there is a way to list those base files.
• Starting pot outputs a lot of text, there is exec.consolelog flag for jail to set a file to output to.
• Is there a specific reason why hooks are not using jail exec.pre* exec.post* functionality. I remember some discussion a while about non persistent jails. But is there a need to support this for one-off commands?

I know a lot to ask but at least I would love some feedback and should I write more details for each feature? I'm sure I will come up with some more when going through all the features and testing how to integrate them into our system.

[pizzamig]

Hi. Thanks for writing this down. I'll try to reply:

• tags: nothing against it, it's just a pain to manage with shell scripts :)
• IP for nat rule per pot: this is not impossible, but more i complicates things. I have to check the code
• pot export for alias makes no sense: with alias, everything is already automatically exposed. When the jail is on an internal bridge, pot export will add a redirection rule to make the service reachable
• fstab: I want to be able to mount all filesystem without starting a jail. Re-implement it, allows me to do that and to support exotic features, like change the mountpoint of zfs dataset at start/stop
• pot ls: tabular format, json, and so on. I'm very open to any improvements here
• pot ls foo*: doable, but it would be more correct pot ls 'foo*' because otherwise the glob will be interpreted by the shell before being passed to pot.
• pot exec: very good idea
• user.account attribute: is this some for of additional labeling?
• pot cmd -p potname: oh yes, one of the pain points. There are commands (like set-cmd) that won't support the removal of -p. I would be more keen to force -p everywhere (currently only start/stop/term/run don't use it
• base files in /tmp: I'm currently reworking a bit this area, to support custom base.txz. Maybe I can reuse the pot/cache dataset, it would make sense
• consolelog: I have to spend some time and look into it, but the log management is in depth need of love.
• hooks: in a sense, pot extends jail features, sometimes I re-implement some of them to be more general. pre/post stop hooks won't be executed if the jail is already stopped (non persistent jails will just vanish on their own). Moreover, it's easier for me to inject environment variables and control how the hooks are executed.

In general, I think it would make sense to split those feature requests in separated Github issues, I will also tag some of them as "Good first issue"

[urosgruber]

Ok @pizzamig I'll then go thrugh this and create tickets. Also I'll try to help on coding as well, but not that experienced in shell.