summaryrefslogtreecommitdiffstats
path: root/bitbake/lib/hashserv
Commit message (Collapse)AuthorAgeFilesLines
* bitbake: hashserv: client: Fix changing stream modesJoshua Watt2024-05-311-4/+8
| | | | | | | | | | | | | | | | | | | | | When switching from normal mode to stream mode, skip calling self._set_mode() again because this will cause a recursion into the _set_mode() function and causes problems. Also cleanup some of the error checking during this process This bug affected when a client would attempt to switch from one stream mode to another, and meant that the server would get an invalid message from the client. This would cause the server to disconnect the client, and the client would then reconnect in normal mode which was the mode it wanted anyway and thus it would carry on without any errors. This made the bug not visible on the client side, but resulting in a lot of backtrace JSON decoding exceptions in the server logs. (Bitbake rev: 1826bc41ab3369ac40034c5eaf698748b769b881) Signed-off-by: Joshua Watt <JPEWhacker@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: asyncrpc: Remove ClientPoolJoshua Watt2024-05-312-162/+0
| | | | | | | | | | | | Batching support on the client side has proven to be a much more effective way of dealing with server latency than multiple client connections and is also much nicer on the server, so drop the client pool support from asyncrpc and the hash server (Bitbake rev: 6f80560f1c7010d09fe5448fdde616aef8468102) Signed-off-by: Joshua Watt <JPEWhacker@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bitbake: Drop older python version compatibility codeRichard Purdie2024-05-311-3/+0
| | | | | | | | | | | | | | cooker: We can call multiprocessing close() unconditionally and tweak a comment give 3.8 is now the minimum version. lib/bb: We can drop the logger addition code only needed before 3.6 asyncrpc/hashserv: Since the minimum version is 3.8, we can drop the conditional code. (Bitbake rev: 16f4386400f88ba50605307961c248bef09895c1) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: hashserv: server: Add support for SO_REUSEPORTJoshua Watt2024-05-301-2/+4
| | | | | | | | | | | | | | SO_REUSEPORT is a socket option that allows multiple servers to listen on the same TCP port, and the kernel will automatically load balance the connections between them. This is particularly helpful for the hash server since it runs in a single thread. To take advantage of a multi-core server, multiple servers can be started in parallel with this option (up to 1 per CPU) and the kernel will load balance between them. (Bitbake rev: d72d5a7decb489e2af0ebc43cfea0ca3e4353e9b) Signed-off-by: Joshua Watt <JPEWhacker@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: hashserv: client: Add batch stream APIJoshua Watt2024-05-302-9/+172
| | | | | | | | | | | | | Changes the stream mode to do "batch" processing. This means that the sending and reciving of messages is done simultaneously so that messages can be sent as fast as possible without having to wait for each reply. This allows multiple messages to be in flight at once, reducing the effect of the round trip latency from the server. (Bitbake rev: e768d0f17bdb97f6ff013ec3a41f182fecd47a55) Signed-off-by: Joshua Watt <JPEWhacker@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: hashserv: client: Fix mode state errorsJoshua Watt2024-04-161-29/+10
| | | | | | | | | | | | | | | | | | Careful reading of the code can contrive cases where poorly timed ConnectionError's will result in the client mode being incorrectly reset to MODE_NORMAL when it should actual be a stream mode for the current command. Fix this by no longer attempting to restore the mode when the connection is setup. Instead, attempt to set the stream mode inside the send wrapper for the stream data, which means that it should always end up in the correct mode before continuing. Also, factor out the transition to normal mode into a invoke() override so it doesn't need to be specified over and over again. (Bitbake rev: 0cd276fd98eeca463518d4a42675fffb18d6b3de) Signed-off-by: Joshua Watt <JPEWhacker@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: asyncrpc: include parse_address from hashservMichael Opdenacker2024-04-141-26/+1
| | | | | | | | | | | | | | Moving the code and related definitions from hashserv/__init__.py to asyncrpc/client.py, allowing this function to be used in other asyncrpc clients. (Bitbake rev: b67bb05e431414866b8e8c6a4c88d20b9cdb44a3) Signed-off-by: Michael Opdenacker <michael.opdenacker@bootlin.com> Suggested-by: Joshua Watt <JPEWhacker@gmail.com> Cc: Tim Orling <ticotimo@gmail.com> Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: hashserv: Re-enable connection pooling with psycopg 3 driverTobias Hagelborn2024-02-231-1/+5
| | | | | | | | | | | | Re-enable connection pooling in case `postgresql+psygopg` driver is used. Async connection pooling is supported in psycopg 3 [psycopg] driver in SQLAlchemy. Allow the connection pool to grow to arbitrary size. (Bitbake rev: 4fe05513b5314c201725e3f8ad54f58d70c56258) Signed-off-by: Tobias Hagelborn <tobiasha@axis.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bitbake: hashserv: Postgres adaptations for ignoring duplicate insertsTobias Hagelborn2024-02-191-15/+38
| | | | | | | | | | | | | | | | Hash Equivalence server performs unconditional insert also of duplicate hash entries. This causes excessive error log entries in Postgres. Rather ignore the duplicate inserts. The alternate behavior should be isolated to the postgres engine type. (Bitbake rev: e8d2d178d0fe96f9d6031c97328e8be17d752716) Signed-off-by: Tobias Hagelborn <tobiasha@axis.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> Signed-off-by: Joshua Watt <JPEWhacker@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: hashserv: Add Client PoolJoshua Watt2024-02-192-0/+163
| | | | | | | | | | Implements a Client Pool derived from the AsyncRPC client pool that allows querying for multiple equivalent hashes in parallel (Bitbake rev: ba4c764d8061c7b88cd4985ca493d6ea6e317106) Signed-off-by: Joshua Watt <JPEWhacker@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: hashserv: Add unihash-exists APIJoshua Watt2024-02-195-33/+138
| | | | | | | | | | | | | | | Adds API to check if the server is aware of the existence of a given unihash. This can be used as an optimization for sstate where a client can query the hash equivalence server to check if a unihash exists before querying the sstate cache. If the hash server isn't aware of the existence of a unihash, then there is very likely not a matching sstate object, so this should be able to significantly cut down on the number of negative hits on the sstate cache. (Bitbake rev: cfe0ac071cfb998e4a1dd263f8860b140843361a) Signed-off-by: Joshua Watt <JPEWhacker@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: hashserv: sqlalchemy: Use _execute() helperJoshua Watt2024-02-191-157/+140
| | | | | | | | | | Use the _execute() helper to execute queries. This helper does the logging of the statement that was being done manually everywhere. (Bitbake rev: 0409a00d62f45afb1b172acbcea17bf17942e846) Signed-off-by: Joshua Watt <JPEWhacker@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: hashserv: Add Unihash Garbage CollectionJoshua Watt2024-02-195-116/+649
| | | | | | | | | | | | Adds support for removing unused unihashes from the database. This is done using a "mark and sweep" style of garbage collection where a collection is started by marking which unihashes should be kept in the database, then performing a sweep to remove any unmarked hashes. (Bitbake rev: 433d4a075a1acfbd2a2913061739353a84bb01ed) Signed-off-by: Joshua Watt <JPEWhacker@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: hashserv: sqlite: Ensure sync propagates to database connectionsJoshua Watt2023-12-041-2/+7
| | | | | | | | | | | | | | | When the sqlite database backend was restructured, the code to make the databases run in WAL mode and to control if sync() is called was accidentally dropped. This caused terrible database performance to the point that server timeouts were occurring causing really slow builds. Fix this by properly enabling WAL mode and setting the synchronous flag as requested (Bitbake rev: c5b8c91d325ed1ca8abe5fe28d989693555c0622) Signed-off-by: Joshua Watt <JPEWhacker@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bitbake-hashclient: Add commands to get hashesJoshua Watt2023-12-021-0/+20
| | | | | | | | | | Adds subcommands to query the server for equivalent hashes and for output hashes. (Bitbake rev: 36ba202232399738670c9fb11169ead5590a3e82) Signed-off-by: Joshua Watt <JPEWhacker@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: hashserv: server: Add owner if user is logged inJoshua Watt2023-11-092-0/+12
| | | | | | | | | | If a user is authenticated with the server, report them as the owner of a report (Bitbake rev: a9fd4a45bb6e5ac9832835897f594f3bbf67e1aa) Signed-off-by: Joshua Watt <JPEWhacker@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: hashserv: Allow self-service deletionJoshua Watt2023-11-092-3/+6
| | | | | | | | | | | Allows users to self-service deletion of their own user accounts (meaning, they can delete their own accounts without special permissions). (Bitbake rev: 2d4439948a5328a9768bca9eaec221eb82af3cb2) Signed-off-by: Joshua Watt <JPEWhacker@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: hashserv: tests: Allow authentication for external server testsJoshua Watt2023-11-091-35/+74
| | | | | | | | | | | | If BB_TEST_HASHSERV_USERNAME and BB_TEST_HASHSERV_PASSWORD are provided for a server admin user, the authentication tests for the external hashserver will run. In addition, any users that get created will now be deleted when the test finishes. (Bitbake rev: 0e945d3dec02479df1157f48fd44223c2bfb34a3) Signed-off-by: Joshua Watt <JPEWhacker@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bitbake-hashclient: Output stats in JSON formatJoshua Watt2023-11-091-1/+2
| | | | | | | | | | Outputting the stats in JSON format makes more sense as it's easier for a downstream tool to parse if desired. (Bitbake rev: 3a18066e479ab06bdb08e258fc4aacad5e73222e) Signed-off-by: Joshua Watt <JPEWhacker@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: hashserv: test: Add bitbake-hashclient testsJoshua Watt2023-11-091-23/+277
| | | | | | | | | | The bitbake-hashclient command-line tool now has a lot more features which should be tested, so add some tests for them. (Bitbake rev: 178cf99673d7ddf8e0bb63a5a43331a18f3286d5) Signed-off-by: Joshua Watt <JPEWhacker@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: hashserv: Add database column query APIJoshua Watt2023-11-095-0/+35
| | | | | | | | | | | Adds an API to retrieve the columns that can be queried on from the database backend. This prevents front end applications from needing to hardcode the query columns (Bitbake rev: abfce2b68bdab02ea2e9a63fbb3b9e270428a0a6) Signed-off-by: Joshua Watt <JPEWhacker@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: hashserv: Add db-usage APIJoshua Watt2023-11-095-0/+70
| | | | | | | | | | Adds an API to query the server for the usage of the database (e.g. how many rows are present in each table) (Bitbake rev: c9c1224447e147e0de92953bc85cea75670b898c) Signed-off-by: Joshua Watt <JPEWhacker@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: hashserv: Add become-user APIJoshua Watt2023-11-093-5/+94
| | | | | | | | | | | | Adds API that allows a user admin to impersonate another user in the system. This makes it easier to write external services that have external authentication, since they can use a common user account to access the server, then impersonate the logged in user. (Bitbake rev: 71e2f5b52b686f34df364ae1f2fc058f45cd5e18) Signed-off-by: Joshua Watt <JPEWhacker@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: hashserv: Add user permissionsJoshua Watt2023-11-096-45/+935
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Adds support for the hashserver to have per-user permissions. User management is done via a new "auth" RPC API where a client can authenticate itself with the server using a randomly generated token. The user can then be given permissions to read, report, manage the database, or manage other users. In addition to explicit user logins, the server supports anonymous users which is what all users start as before they make the "auth" RPC call. Anonymous users can be assigned a set of permissions by the server, making it unnecessary for users to authenticate to use the server. The set of Anonymous permissions defines the default behavior of the server, for example if set to "@read", Anonymous users are unable to report equivalent hashes with authenticating. Similarly, setting the Anonymous permissions to "@none" would require authentication for users to perform any action. User creation and management is entirely manual (although bitbake-hashclient is very useful as a front end). There are many different mechanisms that could be implemented to allow user self-registration (e.g. OAuth, LDAP, etc.), and implementing these is outside the scope of the server. Instead, it is recommended to implement a registration service that validates users against the necessary service, then adds them as a user in the hash equivalence server. (Bitbake rev: 69e5417413ee2414fffaa7dd38057573bac56e35) Signed-off-by: Joshua Watt <JPEWhacker@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: hashserv: Implement read-only version of "report" RPCJoshua Watt2023-11-092-3/+26
| | | | | | | | | | When the hash equivalence server is in read-only mode, it should still return a unihash for a given "report" call if there is one. (Bitbake rev: d0bbb98553f5f3451606bd5f089b36cfe4219dc2) Signed-off-by: Joshua Watt <JPEWhacker@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: hashserv: Add SQLalchemy backendJoshua Watt2023-11-093-3/+341
| | | | | | | | | | | Adds an SQLAlchemy backend to the server. While this database backend is slower than the more direct sqlite backend, it easily supports just about any SQL server, which is useful for large scale deployments. (Bitbake rev: e0b73466dd7478c77c82f46879246c1b68b228c0) Signed-off-by: Joshua Watt <JPEWhacker@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: hashserv: Abstract databaseJoshua Watt2023-11-093-401/+439
| | | | | | | | | | Abstracts the way the database backend is accessed by the hash equivalence server to make it possible to use other backends (Bitbake rev: 04b53deacf857488408bc82b9890b1e19874b5f1) Signed-off-by: Joshua Watt <JPEWhacker@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: asyncrpc: Prefix log messages with client infoJoshua Watt2023-11-091-5/+5
| | | | | | | | | | Adds a logging adaptor to the asyncrpc clients that prefixes log messages with the client remote address to aid in debugging (Bitbake rev: f4d64ce73c2449c008ff5d9b32376a2893ef7195) Signed-off-by: Joshua Watt <JPEWhacker@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: hashserv: tests: Add external database testsJoshua Watt2023-11-091-10/+44
| | | | | | | | | | Adds support for running the hash equivalence test suite against an external hash equivalence implementation. (Bitbake rev: c1fbc3f68b94905d19ffcf4a6da5b27f0bf14599) Signed-off-by: Joshua Watt <JPEWhacker@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: hashserv: Add websocket connection implementationJoshua Watt2023-11-093-0/+31
| | | | | | | | | | | | | | | Adds support to the hash equivalence client and server to communicate over websockets. Since websockets are message orientated instead of stream orientated, and new connection class is needed to handle them. Note that websocket support does require the 3rd party websockets python module be installed on the host, but it should not be required unless websockets are actually being used. (Bitbake rev: 56dd2fdbfb6350a9eef43a12aa529c8637887a7e) Signed-off-by: Joshua Watt <JPEWhacker@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: asyncrpc: Abstract socketsJoshua Watt2023-11-093-106/+69
| | | | | | | | | | | | | Rewrites the asyncrpc client and server code to make it possible to have other transport backends that are not stream based (e.g. websockets which are message based). The connection handling classes are now shared between both the client and server to make it easier to implement new transport mechanisms (Bitbake rev: 2aaeae53696e4c2f13a169830c3b7089cbad6eca) Signed-off-by: Joshua Watt <JPEWhacker@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: hashserv: Add API to clean unused entriesJoshua Watt2023-10-093-1/+43
| | | | | | | | | | Adds an API to remove unused entries in the outhash database based on age and if they are referenced by any unihash (Bitbake rev: a169ac523d166c6cbba918b152a76782176c3e88) Signed-off-by: Joshua Watt <JPEWhacker@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: hashserv: Extend get_outhash API to optionally include unihashJoshua Watt2023-10-092-17/+32
| | | | | | | | | | | Extends the get_outhash API with a flag indicating whether to include the unihash in the output. This is means that the query doesn't require the unihash entry to be present to return a result (Bitbake rev: b8d6abfeb4a0765727a62b3d8d83276335c7c7d6) Signed-off-by: Joshua Watt <JPEWhacker@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: hashserv: Add remove APIJoshua Watt2023-10-093-0/+66
| | | | | | | | | | Adds a `remove` API to the client and server that can be used to remove hash equivalence entries that match a particular critera (Bitbake rev: 861d068b3a9fb5e91a01dbec54996a5a6f93ef29) Signed-off-by: Joshua Watt <JPEWhacker@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: hashserv: Improve behaviour for better determinism/sstate reuseRichard Purdie2021-10-112-8/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | We have a choice of policy with hashequivalence - whether to reduce sstate duplication in the sstate feed to a minimum or have maximal sstate reuse from the user's perspective. The challenge is that non-matching outhashes are generated due to determinism issues, or due to differences in host gcc version, architecture and so on and the question is how to reconcile then. The approach before this patch is that any new match is added and matches can update. This has the side effect that a queried value from the server can change due to the replacement and you may not always get the same value from the server. With the client side caching bitbake has, this can be suboptimal and when using the autobuilder sstate feed, it results in poor artefact reuse. This patch switches to the other possible behaviour, once a hash is assigned, it doesn't change. This means some sstate artefacts may be duplicated but dependency chains aren't invalidated which I suspect may give better overall performance. Update the tests to match the new behaviour. (Bitbake rev: 20d6ac753efa364349100cdc863e5eabec8e5b78) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: hashserv: Fix diverging report race conditionJoshua Watt2021-10-114-153/+314
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fixes the hashequivalence server to resolve the diverging report race error. This error occurs when the same task(hash) is run simultaneous on two different builders, and then the results are reported back but the hashes diverge (e.g. have different outhashes), and one outhash is equivalent to a hash and another is not. If taskhash was not originally in the database, the client will fallback to using the taskhash as the suggested unihash and the server will see reports come in like: taskhash: A unihash: A outhash: B taskhash: C unihash: C outhash: B taskhash: C unihash: C outhash: D Note that the second and third reports are the same taskhash, with diverging outhashes. Taskhash C should be equivalent to taskhash (and unihash) A because they share an outhash B, but the server would not do this when tasks were reported in the order shown. It became clear while trying to fix this that single large table to store all reported hashes was going to make these updates difficult since updating the unihash of all entries would be complex and time consuming. Instead, it makes more sense to split apart the database into two tables: One that maps taskhashes to unihashes and one that maps outhashes to taskhashes. This should hopefully improve the parsing query times as well since they only care about the taskhashes to unihashes table, at the cost of more complex INNER JOIN queries on the lesser used API. Note this change does delete existing hash equivlance data and starts a new database table rather than converting existing data. (Bitbake rev: dff5a17558e2476064e85f35bad1fd65fec23600) Signed-off-by: Joshua Watt <JPEWhacker@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: hashserv: Add tests for diverging reportsJoshua Watt2021-10-111-0/+53
| | | | | | | (Bitbake rev: 953c8d622c9d1bc1eb06bcaf1eaa3aa9f85d0bc2) Signed-off-by: Joshua Watt <JPEWhacker@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: async: Close sync client event loopJoshua Watt2021-10-111-1/+0
| | | | | | | | | | Prevents `ResourceWarning: unclosed event loop` warnings when using the synchronous client and python exits (Bitbake rev: 8b95972bc04ce52a98c7780184af15a5e95f987b) Signed-off-by: Joshua Watt <JPEWhacker@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bitbake: asyncrpc: Defer all asyncio to child processJoshua Watt2021-08-231-2/+2
| | | | | | | | | | | | | | Reworks the async I/O API so that the async loop is only created in the child process. This requires deferring the creation of the server until the child process and a queue to transfer the bound address back to the parent process (Bitbake rev: 8555869cde39f9e9a9ced5a3e5788209640f6d50) Signed-off-by: Joshua Watt <JPEWhacker@gmail.com> [small loop -> self.loop fix in serv.py] Signed-off-by: Scott Murray <scott.murray@konsulko.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bitbake: asyncrpc: Catch early SIGTERMJoshua Watt2021-07-291-12/+42
| | | | | | | | | | | | | | | | | If the SIGTERM signal is sent to an asyncrpc server before it has installed the SIGTERM handler in the main loop, it may miss the signal which will can cause the calling process to wait forever on the join(). To resolve this, the calling process should mask of SIGTERM before forking the server process and the server should unmask the signal only after the handler is installed. To simplify the usage of the server, an new helper function called serve_as_process() is added to do this automatically and correctly. Thanks: Scott Murray <scott.murray@konsulko.com> for helping debug (Bitbake rev: ef2865efa98ad20823267364f2159d8d8c931400) Signed-off-by: Joshua Watt <JPEWhacker@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: hashserver/client.py: drop unused importsArmin Kuster2021-05-141-3/+0
| | | | | | | (Bitbake rev: 9dc77266085c605b108641a9d76ac4dbdc064c34) Signed-off-by: Armin Kuster <akuster808@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: hashserv/server.py: drop unused importsArmin Kuster2021-05-141-7/+0
| | | | | | | | | remove unused vars. (Bitbake rev: 3287d28a506f67abd192799e61ef28e74ce7002d) Signed-off-by: Armin Kuster <akuster808@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: hashserv: Refactor to use asyncrpcPaul Barker2021-04-272-306/+41
| | | | | | | | | | The asyncrpc module can now be used to provide the json & asyncio based RPC system used by hashserv. (Bitbake rev: 5afb9586b0a4a23a05efb0e8ff4a97262631ae4a) Signed-off-by: Paul Barker <pbarker@konsulko.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: hashserv: Use generic ConnectionErrorPaul Barker2021-04-272-14/+9
| | | | | | | | | | The Python built-in ConnectionError type can be used instead of a custom HashConnectionError type. This will make code refactoring simpler. (Bitbake rev: 8a796c3d6d99cfa8ef7aff0ae55bb0f23bbbeae1) Signed-off-by: Paul Barker <pbarker@konsulko.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: hashserv: Add get-outhash messagePaul Barker2021-02-102-14/+38
| | | | | | | | | | | | | | | The get-outhash message can be sent via the get_outhash client method. This works in a similar way to the get message but looks up a db entry by outhash rather than by taskhash. It is intended to be used as a read-only form of the report message. As both handle_get_outhash and handle_report use the same query string we can factor this out. (Bitbake rev: dc19606ada29a4d8afde4fcecd8ec986b47b867e) Signed-off-by: Paul Barker <pbarker@konsulko.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: hashserv: server: Support searching upstream for outhashPaul Barker2021-02-102-0/+32
| | | | | | | | | | | | | Use the new get-outhash message to perform a read-only query against an upstream server (if present) when a reported taskhash/outhash combination is not found in the current database. If a matching entry is found upstream it is copied into the current database so it can be found by future queries. (Bitbake rev: 2be4f7f0d2ccb09917398289e8140e1467e84bb2) Signed-off-by: Paul Barker <pbarker@konsulko.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: hashserv: Support read-only serverPaul Barker2021-02-103-11/+51
| | | | | | | | | | | | | | | | | | The -r/--readonly argument is added to the bitbake-hashserv app. If this argument is given then clients may only perform read operations against the server. The read-only mode is implemented by simply not installing handlers for write operations, this keeps the permission model simple and reduces the risk of accidentally allowing write operations. As a sqlite database can be safely opened by multiple processes in parallel, it's possible to start two hashserv instances against a single database if you wish to export both a read-only port and a read-write port. (Bitbake rev: 492bb02eb0e071c792407ac3113f92492da1a9cc) Signed-off-by: Paul Barker <pbarker@konsulko.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: hashserv: client: Fix handling of null responsesPaul Barker2021-02-061-1/+1
| | | | | | | | | | If the server returns an empty response ("null" in json), this cannot be iterated to check for the presence of the "chunk-stream" key. (Bitbake rev: bf75370bcd6d02ed08cd959eec6190196b792515) Signed-off-by: Paul Barker <pbarker@konsulko.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: hashserv: Fix broken AF_UNIX path length limitJoshua Watt2020-12-102-5/+26
| | | | | | | | | | | | Fixes the bug were long paths would break Unix domain socket clients (for real this time; the previous attempt was missing os.path.basename). Adds some tests to prevent regressions (Bitbake rev: 77790e3656048eff5cb1a086c727d86d32773b68) Signed-off-by: Joshua Watt <JPEWhacker@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: hashserv: client: Fix AF_UNIX path length limitsJoshua Watt2020-12-091-3/+12
| | | | | | | | | | | | | | | | Restores a fix for unix domain socket path length limits when using the synchronous hash equivalence client that was accidentally removed when the async client was added. Unfortunately, it's much more difficult to fix the same problem when using the async client directly due to the interaction of chdir() and async code, but this will at least restore the old behavior in the synchronous case. (Bitbake rev: 53e85022a8b1c8f407c9418260c59beffb96f0f9) Signed-off-by: Joshua Watt <JPEWhacker@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
generated by cgit v1.2.3-54-g00ecf (git 2.39.0) at 2024-06-18 01:01:07 +0000