yagna | open platform and marketplace for distributed computations

Great question! Assuming you are referring to a single task or group of tasks launched in a Golem execute_tasks call, the answer is No, you cannot directly and completely cancel a task using the REST API. (prove me wrong!, see about me at end)

However, a task can be indirectly cancelled (but subsequently retried) by terminating its associated agreement via the REST API!, provided you can discover (presumably by means other than the REST API) a task's associated agreement id.

Terminating an agreement to cancel and retry a task can be done via a POST http method. I give an example below.

use this reference to see the available endpoints and affirm for yourself:

• https://github.com/golemfactory/yagna/tree/0.9_to_master/core/market/src/rest_api

read on only if you want to see an example of how to hack a cancel and retry

pre: container is running on 192.168.1.100 and yagna daemon on port 7465

the key to making this work is discovering a task's agreement id. here i show how obtaining the agreement id is possible indirectly by monitoring events in the requestor script. alternatives may include monitoring for new activities in the yagna daemon log file and parsing the associated activity id.

Given that every task is associated one-to-one bidirectionally with an agreement id, i will describe how to terminate a specific agreement and consequently cancel and retry its task one at a time with said id.

Here is how cancelling (and retrying) a specific task by way of terminating its agreement can be done in the context of the task model with curl for example in a bash script

It's a nice idea & it's doable.

You can differentiate requestors by their id's. To get the nodes' id (requestor or provider) just run yagna id list (yagna daemon has to be running - yagna service run).

Probably the most challenging part would be to modify ReactToProposal handler of CompositeNegotiator. Current implementation casts Proposal (Demand in this context) into ProposalView. Unfotunatelly at this point requestor_id is lost. For testing purposes you can just filter requestors directly in fn handle() and return Ok(ProposalResponse::RejectProposal {....}) when you want to block a requestor. Your field of interest is msg.demand.issuer_id.

If you want to introduce some kind of public/private key pair functionality, it could achieved by adding custom * demand/offer constraint* that is understood by both your requestor and provider. Unfortunately at this time there is no public documentation on this topic.

Please feel free to reach out if you have further questions.

I'm not sure what is the reason here, but it seems like DNS is not able to resolve _net._tcp.dev.golem.network SRV record yielding 'Not Implemented'. It is very odd, since Yagna is using Google's DNS servers as a default.

When you face this again pls try to check output of following command

You can use

If you're compiling something with OpenSSL for armhf, then you'll need to have the libssl-dev package installed for that architecture. That will involve setting up dpkg for it via dpkg --add-architecture armhf and then doing an apt-get update and apt-get install libssl-dev:armhf.

Note that it may not be possible to install multiple versions of libssl-dev at once, and resolving the dependencies in a way that doesn't end up removing a lot of packages may be tricky. Debian-style multiarch is very capable, but it can be a bit fiddly at times.

You definitely should not vendor OpenSSL because it frequently comes out with security updates. Similarly, it is also a bad idea to statically link OpenSSL. If you do vendor or statically link it, unless you are extremely careful to keep it up to date, your code will contain security vulnerabilities.

stat is a Statvfs structure, the return type of Statvfs::blocks_available() is fsblkcnt_t, and the return type of Statvfs::fragment_size() is c_ulong. These two types are defined in the libc package, which is a paper-thin wrapper around the low-level C OS-calls. The types are equivalent to the C types in the OS-specific *.h files. The sizes of the types vary from platform to platform.

The library you're compiling appears to have some assumptions baked in about these sizes and their arithmetic compatibility.

Some bug reports to the library authors would be in order.

If you're willing to patch the library yourself, then you should first investigate your platform's libc package and check the definitions of all types involved in the errors you're seeing. Then fix the arithmetic expressions so the types are compatible and they don't overflow.

I don't think Rust's type system is smart enough to support one body of code that handles all potential combinations of type sizes both safely (without overflow or truncation) and efficiently (without needlessly casting everything up to u128) . It might be that platform-specific patches are necessary.