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

Refactor Pirania simplifying its code and fixing bugs #869

Merged
merged 57 commits into from
Jul 4, 2021

Conversation

spiccinini
Copy link
Contributor

@spiccinini spiccinini commented Apr 5, 2021

This is a big PR with a full rewrite of the pirania lua code and improvements in other parts of the pirania codebase. The main drive of this rewrite is to simplify the code as there were many layers, some obsoleted, and tinkering through the code was difficult. The way to store into the shared-state storage is maintained but the local storage is moved from a csv into a per voucher json file.

This code is not compatible with the lime-app UI. We may write a layer to make it compatible but I think that we should drop the member/visitor for the renewable vouchers.
Please comment what you think, I don't expect a full code review as it is a big rewrite.

I believe that this rewrite fixes many issues with the old code but as we all know, new code comes with new bugs.

Also fixes previous url (origin_url) that was being lost by mistake.
lua print function instroduced a expurius end of line and the response
was broken.
@spiccinini
Copy link
Contributor Author

After talking with Tania on how to deploy this new implementation on networks that already have pirania deployed I think it would be better to rename the shared-state database from vouchers to a new name for example pirania_vouchers.

@germanferrero
Copy link
Contributor

@spiccinini I have reviewed this PR finally. It was very easy to follow thanks to the documentation. The code is very clear too.
Yes, this code is not retro compatible with prior pirania shared state databases. I think that it makes sense, for the current stage of maturity of pirania, to choose a new database name, and tell users they will be starting the database again from scratch, so they can prepare them selves to upgrade pirania.

germanferrero and others added 7 commits June 7, 2021 10:42
In order to do this, add unique local and link local ipv6 to
pirania's allow list addresses

This fixes ubus requests in the portal
This brings pirania UI back to the portal
Simplifies the migration to the new pirania db as it
allows running the new and the old version of pirania
in the community in a mixed way.
@spiccinini
Copy link
Contributor Author

I've pushed changes so that the shared-state db is now pirania-vouchers instead of pirania, so now both the new and the old version can run in the same community without crashing.

@spiccinini spiccinini requested a review from nicopace June 28, 2021 19:05
packages/pirania/Readme.md Outdated Show resolved Hide resolved
@codecov-commenter
Copy link

codecov-commenter commented Jul 2, 2021

Codecov Report

Merging #869 (5d0ce90) into master (c7a8e21) will increase coverage by 1.46%.
The diff coverage is 83.38%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master     #869      +/-   ##
==========================================
+ Coverage   72.45%   73.92%   +1.46%     
==========================================
  Files          41       41              
  Lines        3616     3559      -57     
==========================================
+ Hits         2620     2631      +11     
+ Misses        996      928      -68     
Impacted Files Coverage Δ
...ckages/pirania/files/usr/lib/lua/voucher/hooks.lua 42.85% <28.57%> (+6.49%) ⬆️
...ckages/pirania/files/usr/lib/lua/voucher/utils.lua 70.83% <70.00%> (+22.89%) ⬆️
...ges/pirania/files/usr/lib/lua/voucher/vouchera.lua 52.66% <86.39%> (ø)
...pirania/files/usr/lib/lua/voucher/cgi_handlers.lua 91.66% <91.66%> (ø)
...ckages/pirania/files/usr/lib/lua/voucher/store.lua 92.00% <92.00%> (ø)
...kages/pirania/files/usr/lib/lua/voucher/config.lua 100.00% <100.00%> (ø)
...kages/lime-system/files/usr/lib/lua/lime/utils.lua 80.23% <0.00%> (-1.39%) ⬇️
...ages/lime-system/files/usr/lib/lua/lime/config.lua 97.60% <0.00%> (ø)
...es/pirania/files/usr/lib/lua/voucher/functools.lua
... and 5 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update c7a8e21...5d0ce90. Read the comment docs.

Copy link
Member

@nicopace nicopace left a comment

Choose a reason for hiding this comment

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

Impresive work!
have gone through it, did some comments.
By no means it has been a thorough review and no actual in device test was done.
I will unlock this so it can continue its development.

Would be good to add something on the README and on the Makefile to make sure that anyone that includes it knows that is dealing with alpha software.

* the rest of the packets are rejeted (drop and send an error to the client)

### HTTP flow
Copy link
Member

Choose a reason for hiding this comment

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

this is really good documentation. Maybe can eventually be moved to a /docs/ folder, as it sort of exceeds the responsabilities of a readme: https://www.freecodecamp.org/news/how-to-write-a-good-readme-file/ (of course it is very opinionated... maybe something to put our opinions into :) ).

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes, it should not be in a Readme but at the same time we are using the readme of the packages as documentation. Maybe when we implement an automatic generation of the full docs of libremesh it may be good idea to remove this details from the Readme but for the time being I think that nobody will see it (and I will forget about it).

```

### TODO
Copy link
Member

Choose a reason for hiding this comment

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

TODO: migrate the todo to issues in the repository :)
Thanks for this!

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Ok I will open an issue with an open Roadmap of pirania with some bullets and we may open issues for each relevant thing.

print('true')
return true
else
return nil, 'false'
Copy link
Member

Choose a reason for hiding this comment

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

why is print('true') return true for true, and return nil, 'false' for false?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This is because how the processing of the functions from the main functions works ...it somewhat hacky.
I am pushing a clearer implementation, thanks.

for _, voucher in pairs(vouchera.vouchers) do
print(voucher.tostring())
end
return true
Copy link
Member

Choose a reason for hiding this comment

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

show_active and show seem very similar... could they be merged?

for _, voucher in pairs(vouchera.vouchers) do
if vouchera.is_active(voucher) then
print(voucher.mac)
end
Copy link
Member

Choose a reason for hiding this comment

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

same for show and show_active.. maybe they could all be merged?

--! This will eventualy prune the voucher in all the dbs after PRUNE_OLDER_THAN_S seconds.
--! It is important to maintain the "removed" (deactivated) voucher in the shared db for some time
--! so that all nodes (even nodes that are offline when this is executed) have time to update locally
--! and eventualy prune the voucher.
Copy link
Member

Choose a reason for hiding this comment

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

it is also important to leave them there for some time in case the owners of the devices go and claim that they don't have internet anymore and say that the voucher is still valid. if we remove the voucher alltogether no trace will be kept and these kind of scams are easy to happen.

local conn = ubus.connect()
if not conn then
error("Failed to connect to ubus")
local function unsafe_shell(command)
Copy link
Member

Choose a reason for hiding this comment

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

wasn't this function part of the utils module?

Copy link
Contributor Author

@spiccinini spiccinini Jul 4, 2021

Choose a reason for hiding this comment

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

Pirania does not have a direct dependency on the the lime-system package and I maintained it that way. But now shared-state depends on lime-system (well lime.utils only) we may also add this dependency and remove more code duplications. pirania-app is depending on lime-system so well it does not matter much now to maintain pirania package free of the lime dependency.

local function add_vouchers(msg)
local vouchers = {}
for _, vouch_data in pairs (msg.vouchers_data) do
local v = {name=vouch_data.name, code=vouch_data.code, expiration_date=vouch_data.expiration_date}
Copy link
Member

Choose a reason for hiding this comment

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

looks like a table selective copy, like:
v = selective_copy(vouch_data, ["name", "code", "expiration_date"])
Just a thought... it has to be somewhere :)

for _, voucher in pairs(vouchera.vouchers) do
if vouchera.is_active(voucher) then
table.insert(result.macs, voucher.mac)
end
end
printJson(result);
Copy link
Member

Choose a reason for hiding this comment

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

looks very similar to a function in the voucher binary, were similar information got printed.

Copy link
Member

Choose a reason for hiding this comment

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

have you seen this @spiccinini ?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes, in all cases it may be refactored into a generic apply_func_to_vouchers_if_condition(vouchers, func, condition), that is a map(func, filter(condition, vouchers)) (I don't like a lot this generic functions, I prefer to do them explicit in code). Maybe a more specific apply_to_active_vouchers(function) may be used (that I would prefer), but this won't serve all the cases mentioned. So for me it is not very clear that this refactor is a clear improvement (I mean maintainable without losing clarity and ease of reading).

@@ -1,2 +1,2 @@
#!/bin/sh
shared-state sync pirania
shared-state sync pirania-vouchers
Copy link
Member

Choose a reason for hiding this comment

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

The hooks folder should be documented within it, and outside of it somewhere, so people wanting to modify the behaviour can tell when that code is being executed or when code should be added here.

Copy link
Member

Choose a reason for hiding this comment

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

have you seen this @spiccinini ?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Hi Nico, yes. Indeed it should be Documented! This PR is not to fix every missing thing in Pirania, that is why I merged the branch even if not all improvement suggestions are done.

@spiccinini spiccinini merged commit 55ec0b8 into libremesh:master Jul 4, 2021
@spiccinini
Copy link
Contributor Author

Thanks Nico for the review!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants