Serial console support is horribly fragile (was: Limit number of console-watching processes to 1)

Currently, users can call start_console() on a node as many times as they want, with each call starting a new IPMI tool. This could cause 2 DOS-y types of problems:
a) I'm not sure if IPMI even supports more than one console-gathering process, and
b) this could create a bunch of processes on the HaaS API server
Multiple IPMItool instantiations aren't necessary, since just 1 instantiation will record the entire serial console, and many others can fetch the contents in parallel.
We should limit this to 1 process (perhaps using the DB).
Note that this might cause issues with making HaaS multi-node (see #416) since we're just logging to a tmp file, thus requiring some more work, but let's leave that as separate future work.

Thanks for bringing this up --- the general kludgy-ness of the
implementation has been bugging me.
We really need a better story on process-control re: serial console
stuff in general. Here's a somewhat more ambitious idea of where this
could go (eventually, we could talk about possible shorter-term fixes as
well):
Rather than having start_console/stop_console, we just use a persistent
connection or websocket, don't do logging at all, and just dump the
output from the ipmi process to the response until the client
disconnects, at which point we kill ipmitool.
There's still the question about multiple connections, but this at least
gives a clean way to make sure the process dies when it's supposed to.

I'm removing the easy label for this, and putting one of the (many, for some reason) discussion labels on this. We need to decide on an appropriate solution before someone goes and codes it.

I'm changing the title of this to make it a little more obvious what the core issue is. I feel pretty strongly that we need to pin down a better design, not just find some hacky way of fixing the handful of serious issues we have now.

ipmitool doesn't seem to multiplex the serial console when multiple processes connect to it. I don't think it's too big of a restriction to just refuse to allow more than one connection to the serial console; we can just lock a file under /tmp whose name is a function of the node's name and do the above, but report an error if there's an existing serial connection.

It makes sense to put a lock on the console, only allowing one person to watch at a time. I don't think lack of multiplexing will be an issue for the console.
I think we need to make sure that the lock gets released if the connection is unresponsive for x time, in case the stream drops without the process being killed, or something whacky happens on the user's side...

The one downside to using a lock in /tmp is that it only works if you only have one API server. When I was playing with it before, running two ipmitool processes looking at the serial console didn't seem to break anything, just only one of them actually gets the data. So there are two ways of doing this:

Use a lock, report an error, and only support one API server
No locking, if a user tries to open more than one instance of the console they just get no data. This lets us run more than one API server, but is less user-friendly.

@henn, @gsilvis, @lokI8, can we come to a consensus? I don't have a strong opinion.

So, I want to fix this already. Here's what I'd like to do:

Rip most of the direct console support out of the API server proper.
Add a separate daemon that will manage the consoles.

Operation of the daemon
"Admin" operations
These operations would require some kind of authentication/authorization. This could just be a password, which is stored by the daemon (salted & hashed) and also somewhere where the API server can get at it (in cleartext or equivalent, so it can be used, not just checked). Probably an extra column in the obm table or such.

PUT /node/{node_id}/owner takes a parameter in the body identifying a project which "owns" the node. If there are any existing connections to the console of this node, they are dropped, and their URLs (described  below) are invalidated.
DELETE /node/{node_id}/owner removes any owner from the the node. Any existing console connections are dropped, and their URLs are invalidated.
POST /node/{node_id}/console-endpoints takes the node's current project id, and returns a new, cryptographically random URL like /node/{node_id}/console?token=<unguessable UUID>) that can be used to connect to the console. This is similar to how nova manages the VNC console for its VMs. If the supplied project does not match the current owner of the node, the request is rejected. The project parameter is for synchronization, as described below.

Regular user operations

GET /console/<unguessable UUID> connects to the console identified by the URL, which will have been returned by  an admin-only call as described above. If there is an existing connection, we could either reject the request or drop the existing connection. A successfully connection would just start streaming data from the console, so you could just curl the URL to start reading the console.

HIL API server changes

We drop the current console code entirely
We re-implement show_console as follows:

Verify auth, as with any API call.
Do a POST on the console daemon to get an unguessable URL. We supply the project that the DB says owns the node in the body.
If the above is successful, either redirect the client to our secure URL, or connect to it and proxy.

Modify project_connect_node to do a PUT with the new project to the appropriate URL on the console daemon.
Modify project_detach_node to do a DELETE on the node owner URL.

project body parameter: why
The project body parameter in the secure URL request is there to avoid the a race condition between project_detach_node/project_connect_node and show_console, where:

The request handler for show_console checks the authentication and authorization constraints.
Then, the request handlers for project_{detach,connect}_node run all the way through, re-assigning the node to another project.
Having validated that the user is authorized to view the console, the show_console request handler gets a secure URL, and redirects the user to it (or proxies it).
The user now has a live connection to a node they are not supposed to have access to anymore.

The project parameter prevents this, since in step (3), the project would no longer check out, and the request would be rejected by the console daemon.
Advantages
The biggest advantage, and the reason for the whole thing, is to make the console setup actually robust. That said there are another of other advantages:

It opens the door to moving more of the OBM support out of the API server; if we moved the rest of the methods to this daemon, we wouldn't even need the API server to be on the same network with the IPMI controllers. We can discuss whether this actually makes sense, but it becomes an option.
It takes complex control flow out of the API server, which is mostly otherwise doing simple CRUD operations. We already have the switch management in a separate daemon. This has similar advantages.
It means less stuff in the same address space, containing the scope of vulnerabilites.
It provides a clean api that can be implemented on top of things other than IPMI, without having to add even more complexity to the API server.

If folks agree this is a good approach, I can put it together pretty quick.
//cc @naved001, @knikolla

So I decided to just go ahead and do this, then talk about it. I wrote a prototype of the daemon:
https://github.com/zenhack/console-service
Not a bad way to spend an evening.
It mostly works -- need to call ipmitool instead of just making a network connection, and there's an imporant FIXME in there that needs dealing with. And we'll likely want to persist the data for resarts. But, other than that, we mostly just need the tweaks to the API server.
It also probably needs some more documentation.
You'll note I wrote it in Go, not Python.

@zenhack I like the idea of having a separate daemon mainly because it makes the API server simple and the console robust.
I'll need to take some time to look at the current code and the issues it has. Additionally, since I am not familiar with Go it will take me some time to comment on it.

Of course. Don't hesitate to pick my brain/tell me something needs documenting.

A couple of thoughts/questions

I like the event-y type design

I like that we could potentially hide OBM creds and connectivity from the API by splitting the console service off.

I'm concerned that keeping state in memory means one process crash causes the entire thing to lose state/synchronization with the HIL server and means there's no ability to connect until someone forces the HIL server to sync the state of every node over again.

Was your thought to eventually use the DB?
Maybe a pull-model for state could fix this? See the next suggestion.

Another option to the console-specific token mechanism that reduces the state the console service would need to keep would be to have the console service accept the user's token (user/pass or a keystone token), then check with the API server if that user should have access (maybe using a mechanism like #692).

This could eliminate needing to notify the console service on node allocations.
We could even optimize the node deallocation notification away when unnecessary if HIL kept a console_accessed metadata flag on the node that was checked on node free.
Note that services calling other services in OpenStack have a mechanism by which they can include their own service token in addition to the user's token, though in the above case, having a user set the console_accessed flag shouldn't be a problem.

Do you have an idea on how this design could be extended in the future to multiple hosts for horizontal scaling and redundancy?

Does this handle bi-directional traffic (reading from and writing to the remote console)? We've had at least one request for write access.

What would the client look like for that? As in, would reading/writing be easy for normal REST-y applications, without having to do a separate HTTP request for each keystroke?

Another way to do the token mechanism would be to use something like OpenStack's Fernet tokens (something encrypted and HMAC'd with a shared secret), though protecting against race conditions could be tricky.

Quoting Jason Hennessey (2017-06-01 20:17:59)

 * I'm concerned that keeping state in memory means one process crash
   causes the entire thing to lose state/synchronization with the HIL
   server and means there's no ability to connect until someone forces
   the HIL server to sync the state of every node over again.
      + Was your thought to eventually use the DB?
      + Maybe a pull-model for state could fix this? See the next
        suggestion.

This is something I was still waffling on. It might be a good idea to
persist node/ownership info to a db at the very least. I think keeping
the tokens in memory is fine, since user can easily get a new one
(provided they are still authorized to do so).
Putting everything in memory was mostly because this was a prototype.

 * Another option to the console-specific token mechanism that reduces
   the state the console service would need to keep would be to have
   the console service accept the user's token (user/pass or a
   keystone token), then check with the API server if that user should
   have access (maybe using a mechanism like [1]#692).
      + This could eliminate needing to notify the console service on
        node allocations.
      + We could even optimize the node deallocation notification away
        when unnecessary if HIL kept a console_accessed metadata flag
        on the node that was checked on node free.
      + Note that services calling other services in OpenStack have a
        mechanism by which they can include their own service token in
        addition to the user's token, though in the above case, having
        a user set the console_accessed flag shouldn't be a problem.

This sounds like additional complexity for no real benefit. As I
describe above, the token can be entirely ephemeral, so keeping the
state isn't too much of a burden, and it's a lot simpler than
integrating with the kind of stuff you're talking about.

 * Do you have an idea on how this design could be extended in the
   future to multiple hosts for horizontal scaling and redundancy?

One observation is that not every node has to have the same base api
endpoint -- we could just have the console daemon url/admin token be
part of the body of node_register, and have separate instances of the
console daemon for different parts of the network.
Re: redundancy, that's a bit tricker, since we need to somehow
synchronize them. Beyond standard replicated-state-machine stuff I'd
need to think about it, but I don't know that we need more than that --
1 console server per node isn't problematic from a scalability
perspective since we're only allowing 1 connection per console anyway.

 * Does this handle bi-directional traffic (reading from and writing
   to the remote console)? We've had at least one request for write
   access.

No, but it would be a trivial extension. The main reason we haven't
implemented it so far is that we were worried about implications re: low
level access to the BIOs and such.

 * What would the client look like for that? As in, would
   reading/writing be easy for normal REST-y applications, without
   having to do a separate HTTP request for each keystroke?

There are a number of ways of getting bi-directional streams with HTTP.
One is to use websocket, which has the nice advantage of making
browser-based clients possible.
The CLI client is the sort of thing I've written in 10-15 minutes on a
number of occasions.

 * Another way to do the token mechanism would be to use something
   like OpenStack's Fernet tokens (something encrypted and HMAC'd with
   a shared secret), though protecting against race conditions could
   be tricky.

This sounds more complicated, and I don't see a clear benefit. It also
makes clients harder to write -- with the current solution you're
basically talking netcat plus a websocket library. I noted earlier that
nova does something similar to what I proposed for its VNC consoles.

@henn, curious to your further thoughts.

I've been thinking a bit more about the data sync issue. I have a slight tweak in mind for the current console serer API, that I think solves the sticking points with the current mechanism.
Instead of the console tracking an owner per node, it tracks a version number, which is incremented every time the node is modified, and can be incremented manually via an api call. Incrementing the version invalidates any tokens.
When getting a token to pass to the client, instead of passing the owner for synchronization purposes, HIL passes the version. Otherwise, this step works as before -- if the version doesn't match, the operation fails. We could return the correct current version, making it easy for HIL to update the info it has on file.
When doing project_{connect,detach}_node, HIL would increment the version, to invalidate any tokens and prevent the previously described race condition.
This solves the problem of keeping owners  in sync, since it kills the owner field entirely. The version field is easier, since being out of sync just means one failed operation (which can happen normally), after which the database is updated.
This also feels like it would be easier to generalize to other things.
This still leaves us with redundant node metadata -- impi user/pass/host are still duplicated. One way to solve this is to just move the power toggling into this daemon as well, so it doesn't have to be in HIL's database. Furthermore, this isn't nearly as much of a problem, since it won't in general cause anything to fail.
@henn, @naved001, curious as to your thoughts?

sorry but I don't understand the data sync issue. What's wrong with tracking the owner per node? Could you describe a scenario where this would be a problem? Thanks!

This still leaves us with redundant node metadata -- impi user/pass/host are still duplicated. One way to solve this is to just move the power toggling into this daemon as well

There's bunch of other stuff as well, like power cycle, changing boot device. We might as well move all of OBM stuff into this daemon. And if it has it's own database then this would need it's own migration scripts too I guess.

Quoting Naved Ansari (2017-08-23 16:24:36)

sorry but I don't understand the data sync issue. What's wrong with
tracking the owner per node? Could you describe a scenario where this
would be a problem? Thanks!

During a project_connect_node or project_detach_node, the API server
needs to update the owner of the node with the console daemon. Because
the call to set the owner in the console daemon isn't protected by a
transaction, if either daemon dies between updating the owner in the
console daemon, and committing to the HIL api server's database, then
when they come back up, they will disagree about the owner of the node.
This happens regardless of the order in which these operations are done.
Using versions instead avoids the console needing to care about the
owner, so this doesn't come up.
Does that make sense?

There's bunch of other stuff as well, like power cycle, changing boot
device. We might as well move all of OBM stuff into this daemon. And if
it has it's own database then this would need it's own migration
scripts too I guess.

Yeah, that's what I meant.

Does that make sense?

Yes. Now I have some more questions.

it tracks a version number, which is incremented every time the node is modified,

how does the console service know that a node was modified? Does HIL call the console service to update the version number when it does a project_connect/detach_node?

When getting a token to pass to the client, instead of passing the owner for synchronization purposes, HIL passes the version.

It's not very clear how this works. As a user who wants to request a new token, what do I pass to the console service?

how does the console service know that a node was modified? Does HIL call the console service to update the version number when it does a project_connect/detach_node?

That's the idea.

It's not very clear how this works. As a user who wants to request a new token, what do I pass to the console service?

The whole thing works exactly as before, except that when the api server creates a token for the user to use, it supplies the expected version number, instead of the expected owner.
Basically, everything that used to manipulate the owner now just bumps the version. The rest of the process is the same.

Cool. Seems fine to me.
@henn you have any comments on this?

A note, I went ahead and made the version change update in the console-service repo.
I can see two ways of proceeding:

Do things as described originally; gut the existing console code from HIL, and replace it with calls to this daemon. We'll still have to have the node info duplicated though.
Go ahead with moving the rest of the impi driver's functionality into this daemon, then swap in a new obm driver that just takes a base URL and an admin token in node_register.

It occurs to me that we only have one obm driver right now; we could possibly deprecate the drivertized obm interface, and just have the rest api exposed by the new daemon be how we talk to obms. Just a thought.
I'd like to come to a decision on this so I can get to work without too much risk of having to throw stuff out.
//cc @naved001.
@henn hasn't been terribly responsive on this issue, and it's been slowing things down. I'd like to have a second person (besides naved) to be weighing in on stuff; is there someone who has the time to commit to better response times on this that I could be bugging?

@knikolla can you weigh in on this please? Thanks!

I have classes and other workload, but I will have a look at it too.
On Wed, Sep 6, 2017 at 11:32 AM Naved Ansari<EMAIL_ADDRESS>wrote:

@knikolla https://github.com/knikolla can you weigh in on this please?
Thanks!
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/CCI-MOC/hil/issues/417#issuecomment-327522242, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ACSZ_hUfKg92CFmsMsjQIb35tAbtYQ1aks5sfrsNgaJpZM4EKn9y
.

--
--Sahil

@knikolla, ping.

Do things as described originally; gut the existing console code from HIL, and replace it with calls to this daemon. We'll still have to have the node info duplicated though.

The ipmi information (hostname, user, passwords)  might not change often in real life, but we can't make that assumption. So I am not sure how I feel about duplicating that because if it does change we would have to worry about keeping it in sync.

Go ahead with moving the rest of the impi driver's functionality into this daemon, then swap in a new obm driver that just takes a base URL and an admin token in node_register.

This seems more reasonable.
It looks like the ipmi stuff is gonna be it's own thing. It would have its own database (and related code), driverization etc. Feels like a lot of work!

Quoting Naved Ansari (2017-09-12 14:42:07)

 Go ahead with moving the rest of the impi driver's functionality
 into this daemon, then swap in a new obm driver that just takes a
 base URL and an admin token in node_register.

This seems more reasonable.
It looks like the ipmi stuff is gonna be it's own thing. It would have
its own database (and related code), driverization etc. Feels like a
lot of work!

This was my instinct as well. I don't think it will be that bad
actually. I'm inclined to try to get the daemon part mostly
feature-complete by the end of the week. It would be nice to get an
additional opinion first, but I'm not inclined to wait around forever.

Status update: I've modified the daemon so that it stores the node information inside of a database. console tokens are still ephemeral, and my intention is for them to stay that way -- if the in-memory state is lost you need to call show console again anyway.
Most likely my immediate approach to the rest of this will be to just replicate the rest of the HIL power management api, which should be straight-forward enough. Once this is set, we can write a HIL obm driver where the extra info we store is just the URL/admin token for the console daemon, and the Obm methods just call out to the daemon.

cc @Izhmash

More of an administrative question here: @zenhack do you have an idea about how we'll want to package the console daemon with HIL in the future?

The master branch on my repo now handles the power_off, power_cycle, and set_bootdev api calls, which work exactly as in HIL, except that they take the token as a query parameter (as in the console streaming call). So you do e.g:
PUT /node/node4/boot_device?token=9832t3857faed9382...
Could you test it with some real machines to make sure I got the implementation right? I can only easily test against the dummy drivers.

@Izhmash, haven't spend much time thinking about it. I think it probably makes sense to keep the packaging somewhat separate for the time being, as being able to just do pip install hil would be nice.

If you want to bounce off of one more person, someone grab me tomorrow and will try to get up to speed.
Sent from my iPad

On Sep 12, 2017, at 6:29 PM, Ian Denhardt<EMAIL_ADDRESS>wrote:
Quoting Naved Ansari (2017-09-12 14:42:07)

Go ahead with moving the rest of the impi driver's functionality
into this daemon, then swap in a new obm driver that just takes a
base URL and an admin token in node_register.
This seems more reasonable.
It looks like the ipmi stuff is gonna be it's own thing. It would have
its own database (and related code), driverization etc. Feels like a
lot of work!

This was my instinct as well. I don't think it will be that bad
actually. I'm inclined to try to get the daemon part mostly
feature-complete by the end of the week. It would be nice to get an
additional opinion first, but I'm not inclined to wait around forever.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

So, I spent a bit more time thinking about this, and I'm not sure the versioning actually makes this any better. The question not addressed is, when does HIL update what version it has on file? I can't think of an answer that doesn't have one of these problems:

Allows for some kind of race condition with equivalent consequences to the above.
Potentially allows things to get out of sync in a way that won't correct itself without manual intervention.

Perhaps we need to have some sort of start-up/recovery logic. I have some rough thoughts on how that might work, but piecing through this is giving me some worries about the micro services approach in general. I don't think not doing this as a separate service really solves anything in this particular case, but I'd like not to have to pick through this kind of problem in an ad-hoc fashion with any regularity.

So, I spent a bit more time thinking about this, and I'm not sure the versioning actually makes this any better. The question not addressed is, when does HIL update what version it has on file? I

a few weeks ago we thought this would work

how does the console service know that a node was modified?
Does HIL call the console service to update the version number when it does a
project_connect/detach_node?

That's the idea

So HIL updates the version number it has on file when it does a project_connect/detach_node and asks the console daemon to update it too.
Could you describe a scenario that could lead to a race condition?

I did some more puzzling, and I think I do have a full solution, but there's some subtlety to be dealt with, and I could use an extra pair of eyes. I'm going to move forward with the implementation in the interest of not blocking on this, but @okrieg, @pjd-nu, @henn (and everyone else), I would really like it if you guys would pick this apart.
here's the thing that I was puzzling over: We can't do the database update and the version number update in the console daemon atomically, so we need to pick an order.
If we update the console daemon first, and the handler for project_detach_node then dies before committing, the version number is now out of sync with the state; calls to show_console will fail, even though the database still says they're ok. Even without the project_detach_node handler dying, this can happen transiently, but that's not a huge deal since the inconsistency will self-correct quickly. But if the handler fails in between, the inconsistency is durable. If we do things in this order we somehow have to deal with that. Avoiding this sort of thing was the point of switching to version numbers in the first place.
This could also end up with the version being multiple times, but that's easy enough to solve: just have the bump-version call take an expected current version, just like the other calls do.
If we update the database first, then bump the version in the daemon, The same thing can happen, except that the version in the database will be newer than the one on the daemon. This is probably easier to cope with, since it's a dead-giveaway something has gone wrong. But what should show_console do if it sees a version number that is too new?
I think just bumping the version number again works, with a few subtleties:

We'll want to make sure we don't double-bump; see above for the solution to that.
We should start the call all over once we've done this, abandoning the current database transaction and re-checking permissions, etc. The easy way to handle this is to just return a (transient) error to the client, and have them try again.
Calls to project_detach/connect_node should check the version number first, so they don't bump the db ver and end up two versions out of date.

So there are a few tweaks to the daemon I need to make, which I'll get started on. Again, would appreciate folks staring at this a bit.

Also, @naved001 I would still appreciate it if you would test the extra calls I added (power cycling etc). I just pushed a couple commits that tweak the API according to the strategy I described above, including updating the README, but I don't think any of the changes should really affect your testing anyway.

all the new ipmitool commands work correctly.
any active connection is dropped if a new token is requested, or the version number is updated.
starting a second connection causes both connection to fail.

preexisting connection ends with this

HTTP/1.1 200 OK
Content-Type: application/octet-stream
Date: Thu, 05 Oct 2017 21:18:59 GMT
Content-Length: 45

[SOL Session operational.  Use ~? for help]
[naved001@rhel-tgt-base console-service]$

and the new connection fails with this
HTTP/1.1 200 OK
Content-Type: application/octet-stream
Date: Thu, 05 Oct 2017 21:19:00 GMT
Content-Length: 53

Info: SOL payload already active on another session
[naved001@rhel-tgt-base ~]$

looks like ipmitool is handling it?

Quoting Naved Ansari (2017-10-05 17:30:44)

 * starting a second connection causes both connection to fail.
      + preexisting connection ends with this

HTTP/1.1 200 OK
Content-Type: application/octet-stream
Date: Thu, 05 Oct 2017 21:18:59 GMT
Content-Length: 45
[SOL Session operational.  Use ~? for help]
[naved001@rhel-tgt-base console-service]$
and the new connection fails with this
HTTP/1.1 200 OK
Content-Type: application/octet-stream
Date: Thu, 05 Oct 2017 21:19:00 GMT
Content-Length: 53
Info: SOL payload already active on another session
[naved001@rhel-tgt-base ~]$
looks like ipmitool is handling it?

What I suspect is happening is that  the second ipmitool is starting
before we've finished shutting down the first one, so it gets the busy
message, and then we shut down the other one, so they both get
disconnected. What should happen is that the first one is completely
shut down before the next one is started, so the first connection is
booted and replaced by the second. I'll dig into the details.

Hm, is it possible that there's some kind of explicit shutdown that we need to be doing but aren't? @naved001, what happens if, after trying to start a second connection and having them both break, you try to connect again?

For posterity, @naved001 and I talked about a few things via IRC:
(02:23:07 PM) naved: ian, I was thinking about the console server stuff today.
Why does the console daemon need to who owns the node at all?
(02:23:24 PM) naved: like the HIL API server does the authentication, and then
just proxies the connection
(02:24:13 PM) naved: or if you are worried about the URL, then we can just
generate one every time a connection is made. never keep it the same
(02:29:21 PM) isd: The race condition was the whole reason.
(02:29:43 PM) isd: With the version scheme, the console daemon doesn't store
ownership info at all.
(02:30:08 PM) isd: Or do you just mean the tokens?
(02:30:32 PM) naved: i meant the token, generate a new token everytime a new
connection is made
(02:30:49 PM) isd: That's effectively what we're doing.
(02:31:28 PM) isd: unfortunately http is connectionless, so we can either proxy
or we can have the token persist at least until the *next* connection.
(02:31:43 PM) isd: Either way, it doesn't solve the race condition.
(02:32:12 PM) isd: And proxying complicates the api server, since now it has to
tie up a request handler.
(02:32:18 PM) naved: okay
(02:33:06 PM) isd: ...so you start worrying about whether that means a greenlet,
an OS thread, a process... has implications for web-server setup etc. Part of
why I didn't want to write a daemon like this in python.
(02:33:30 PM) naved: I see,
(02:34:21 PM) naved: let me step back a little, the issue was opened to limit
the console processes to 1 and then you changed the title to say that's the
console code generally sucks
(02:34:37 PM) isd: Yeah.
(02:34:42 PM) naved: does the current console code still have the same race
conditions ?
(02:34:47 PM) isd: It also doesn't limit log size
(02:35:28 PM) isd: No, the current design doesn't do streaming, so you don't
wind up with the potential for a dangling connection.
(02:35:32 PM) isd: Which is a plus
(02:35:44 PM) isd: But it also means managing the backlog, which right now it
does badly.
(02:36:04 PM) isd: Whereas with the new design, we don't remember any state, we
just stream what's there when the user connects
(02:36:20 PM) naved: okay
(02:36:25 PM) isd: There are trade-offs.
(02:37:05 PM) isd: I think the streaming design results in a better product from
the user's perspective, and it's not clear to me that it's actually any harder
than managing the state with the other design.
(02:37:36 PM) isd: The current design also has problems with stray ipmitool
processes, and a bunch of other resource management issues
(02:37:45 PM) naved: yeah, i didn't realize the current code couldn't stream.
(02:38:01 PM) isd: No, it just logs and when you do show_console it dumps the
log.
(02:38:07 PM) isd: Which, right now, is unbounded in size
(02:38:16 PM) isd: though I think the intention was to have it be basically a
ring-buffer
(02:38:16 PM) naved: oh, so i can just keep logging to it forever
(02:38:24 PM) naved: and it's not "live"
(02:38:51 PM) isd: There are start/stop console calls that manage the logging
(02:39:05 PM) naved: i see; let me think about it more; and I'll hit you up
again.
(02:39:11 PM) isd: OK.
(02:39:33 PM) naved: on a related note; this daemon is very ipmi centric, right?
(02:39:43 PM) isd: It doesn't need to be.
(02:40:07 PM) isd: The HTTP API doesn't have much ipmi-specific going on; you
could generalize it without much trouble.
(02:40:24 PM) isd: We'd have to do a bit of refactoring of the internals, but it
wouldn't be much work.
(02:40:50 PM) naved: okay. so HIL talks to the HTTP API of the console daemon,
and then the internals will be driveritized
(02:40:56 PM) isd: Might make sense to do that  before deploying it, just so we
don't have to worry about migration.
(02:41:08 PM) isd: That's the notion.
(02:41:13 PM) naved: cool
(02:42:00 PM) isd: It's half drivertized already, just for testing purposes.
We'd just have to change the IpmiInfo type to something more general, and change
the names of things.
(02:42:53 PM) naved: okay
(02:45:33 PM) isd: I'm debating how to go about making the changes in HIL
proper. In particular, whether it's worth keeping the existing OBM
drivertization; we don't actually *have* any other OBM drivers. It might be
easier to implement a mock daemon than maintain the abstraction layer.
(02:46:11 PM) isd: Also, since it's managing all of the obm stuff,
'console-service' isn't really an accurate name, so we should change it
(02:46:15 PM) isd: (it's not much of a name anyway)
(02:46:23 PM) naved: obm daemon
(02:46:23 PM) isd: I'm thinking obmd. opinions?
(02:46:34 PM) naved: yep
(02:46:40 PM) isd: Done. I will rename the repo.
(02:47:06 PM) naved: yeah, we don't need to have two sets of code doing the same
thing.
(02:47:53 PM) isd: Cool. I think I'll submit a blueprint re: internal changes to
HIL; I'd like to hash that out before starting to hack on it.
(02:48:23 PM) isd: Also, is it cool if I post this conversation on the bug
tracker somewhere? Good to have a paper trail for this stuff.
(02:48:28 PM) naved: of course
(02:48:38 PM) isd: Great, will do.

I did go ahead and rename the repo.

Hm, is it possible that there's some kind of explicit shutdown that we need to be doing but aren't?

I don't think so, looked up the man page for ipmitool here and it had some commands and none of those worked. I think it depends on the type of node.
        Special escape sequences are provided to control the SOL session:

~. Terminate connection
~^Z Suspend ipmitool
~^X Suspend ipmitool, but don't restore tty on restart
~B Send break
~~ Send the escape character by typing it twice
~? Print the supported escape sequences

Then I came across this guide at symantec which just asks to deactivate sol. And this page about Cisco says this:
"To end the SoL session, you must close the CLI session. For example, to end an SoL session over an SSH connection, disconnect the SSH connection."

what happens if, after trying to start a second connection and having them both break, you try to connect again?

It complains saying "SOL payload already active on another session". To get around this, I toggle sol
sol deactivate
sol set enabled false
sol set enabled true

now a new session can activate sol.
Also, I think it was discussed how we should give write access to console, just keep in mind that giving write access means giving access to the BIOS as well where I could mess up anything I want. Although there was an option to set privilege-level when using sol privilege-level             user | operator | admin | oem  it didn't work at all. it always defaulted to admin Info: SOL parameter 'Payload Channel (7)' not supported - defaulting to 0x0e

Opened a PR with a possible fix, tagged you in it.

@zenhack Any updates on this? Also, do you plan to open a PR with the specs for this anytime soon? Thanks!

Sorry, this kindof slipped through the cracks. I'll try to find some time for the spec late this week.
That said, I'm a bit unsatisfied with the subtletly of the algorithms here; I wish I knew of a way to make this easier to get right.
I did a bit of refactoring of OBMd and was in the middle of debugging a failing test when I apparently got sidetracked... that needs to get fixed too.

cool, no worries. Thanks for tackling this! Let me know if there's something you want me to look into. @mosayyebzadeh @razaaliraza should be able to help too!

The more I think about this the more troubled I am by the complexity of the interaction. If it were just the one thing, I'd be OK with having thought very carefully about it and come to a solution, but I'm worried about splititng things out into microservices if we can't come up with a more generalizable strategy for getting these kinds of things right. I have a pretty clear sense of what changes need to happen in HIL to make the current thing work, but I'm really hesitant to just plow ahead.
I'm going to spend some more time over the weekend thinking about what to do, but I have a couple of rough thoughts/observations/instincts:

Half the reason we're tending towards splitting things up into separate services is that doing this kind of concurrent design inside of python (and in particular using wsgi) is clumsy.

The constraints of wsgi make it very difficult to have any kind of threading going on in-process besides the request handlers.
Go makes this kind of stuff super easy, which is one of the reasons it's so popular for this kind of software.
Dropping generic wsgi support in python would make this easier; we could potentially write a daemon whose main() we control, and can use greenlets to get a lot of the nice Go stuff.
Either of those strategies would allow us to do this kind of design but with the "daemons" being just greenlets/goroutines. This simplifes things a lot, since:

We no longer have to worry about independent failures; we can't have a situation where half a process dies and the other half keeps going.
We don't have to worry about authenticating communication between daemons.
We can assume that our unit of concurrency (greenlets or goroutines) is light weight, and that we insist on a web server that can handle a huge number of concurrent connections. This would allow doing things synchronously in the request handler, rather than tossing them off to a backend daemon, which opens up new possibilities for how to structure our code.
We're able to keep things inside of one transaction, which simplifies recovery immensely. Distributed transactions exist (e.g. postgres has a PREPARE TRANSACTION), but are complex and have problems in and of themselves.

The big concern with the above this is "what about scale?" If we insist on single-process implementation, we seriously limit our options for scaling. It's not clear to me that that's ever likely to be a concern though:

Most of our operations, by their nature are overwhelmingly dominated by the fact that we're operating on physical machines:

Power management options aren't likely need to be very fast or scalable; the bottleneck there is REBOOTING A SERVER, and the request handler itself does almost nothing to achieve this. Assuming ~300W power consumption per machine, the MGHPCC is a 15MW data center, that works out to about 50,000 machines. They take several minutes to boot vs a second or so for HIL to issue the command (which isn't terribly resource intensive; it's mostly network latency). That's a tiny level of demand, and it's unlikely we're ever going to have the whole datacenter directly managed by one instance of HIL anyway.
console streaming is a bit more expensive, but you're still talking about one greenlet/goroutine per physical server. It seems silly to slow ourselves down now
planning for the kind of scale that would actually be a problem.
It's still feasable to scale horizontally just by having different pods/racks managed by separate instances of HIL. there's some administrative overhead making sure the projects are synchronized (to the extend they need to be), but that strikes me as much easier to deal with than fine-grained concurrency issues like what we're hitting with the console stuff.

The other big concern is redundancy; this is a much more credible reason to want to have more than one machine. But for that we may be able to get away with just using RAFT and having a master & backup machines, which strikes me as much more tractable to program with than to fuss about every interaction.

Curious to others' thoughts. @pjd-nu, @okrieg, it would be really valuable to have someone with some more experience weigh in here.

Feels good to close this one now.


use max_stable_version in rust [crates] badge

Refs #8666
Refs #8667
This PR switches us to using max_stable_version if present, or max_version otherwise, as suggested in #8666
While I was looking at this, I realised returning json.version.num makes no sense here and we should never take this branch. It is a hangover from a really really old implementation https://github.com/badges/shields/blob/302c8606ff4c975b6310fe2cdfe58f92cede290b/server.js#L459-L528 and we can get rid of it. We only ever call the /api/v1/crates/:crate endpoint when we render this badge - never the /api/v1/crates/:crate/:version endpoint, so we don't need to handle that response.

Warnings

:warning:
This PR modified service code for crates but not its test code. That's okay so long as it's refactoring existing code.

Messages

:book:
:sparkles: Thanks for your contribution to Shields, @chris48s!

  Generated by :no_entry_sign: dangerJS against 86b8a5447190cd55a7efa7ffee239cdd4ce52f0a

@chris48s +1.

@chris48s just wanted to check in on this?

@chris48s just wanted to check in on this?

This is pending on me, and through a mixture of forgetfulness and not having adequate bandwidth, I haven't gotten round to it yet.
Will try to soon though :crossed_fingers:


Localization of my app

I've an app with 6 languages (EFIGS + NL) but unfortunately, the app is always running in English,
even if my lproj folders are included in the right way in my VS project.

When submitting the binary to the Store, only English is detected as supported language.
So I can't write the description and upload my screenshots in French (for example).

We're looking into this. We do not support multiple languages right now so that's a new feature we have to implement. We do not have an ETA by when this will be supported yet, we'll keep you informed soon.

Hi Arnaud,
Thanks for the update.
Internationalisation is quite a critical point for us as we support at
least 5 languages in all our apps,
and as having native language is important for kid apps.
Regards,
Alexandre
On Fri, Dec 4, 2015 at 5:14 AM, Arnaud Montembault<EMAIL_ADDRESS>
wrote:

We're looking into this. We do not support multiple languages right now so
that's a new feature we have to implement. We do not have an ETA by when
this will be supported yet, we'll keep you informed soon.
—
Reply to this email directly or view it on GitHub
https://github.com/Microsoft/WinObjC/issues/249#issuecomment-161869828.


@fiberplane/ui: Add lightswitch as input's type property

Description

Checklist

- [ ] The changes have been tested to be backwards compatible.
- [ ] The OpenAPI schema and generated client have been updated.
- [ ] New models module has been added to api generator xtask
- [ ] New types/fields are well-documented and annotated.
- [ ] The CHANGELOG is updated.

Please link any related PRs in other repositories that depend on this:

After merging, please merge related PRs ASAP, so others don't get blocked.

What does this do exactly?

@arendjr as the screenshot implies it adds lightswitch as an option of the input's type attribute. Figured it would make sense as we provide the light switch as a component. Just a small improvement for intellisense 😄
Also, thanks for the title change @flenter 🧹


mfs chain

This is a buffered channel that will result in sequence errors during the entire method runtime. It is not as expected, so it needs to be refactored

Complete the module based on reconstruction and rectify the buffered channels


It seems that Ursine couldn't handle the flowchart of the mermaid.

Here is my test codes:
```mermaid
graph LR
%% LR: left2right, TD/TB: top2down, RL/BT
	subgraph 2
    a == d ==> c
    c --> d((Decision))
    end
	subgraph 1
	A[Hard edge] -->re(Round edge)
	A -.-a
	re -.->C{circle}
    C --- X[X]
    C -->|Two| B[B]
    C -.Three .-> D[C]
    end
    style a fill:#f9f,stroke:#333,stroke-width:4px
    style C fill:#ccf,stroke:#f66,stroke-width:2px,stroke-dasharray: 5, 5
```

Problems  found:

the arrow of directed line is missing
the color of font and background need to be rendered slightly. I test another theme, "Night", and here is the comparison of results.

Please help to solve this problem.

Mm yeah, mermaid diagrams are a bit finicky for now, so they'll slowly get a bit of refinement overtime. I'll get working on fixing these ones when I can

After playing around with it for a while, I think this is the best I can do. Found a way to style the arrows more accurately too.

As for the text color for "a" & "circle" in Umbra, I noticed you styled them with custom fill colors in the diagram code. Since the theme has to accommodate for both black and white text colors, it might be a bit tricky using a set node fill color if you switch between themes.
Not sure if the default node colors have any significance, but hopefully it looks alright now

Great job! 👍Thank you for your effort on this tricky problem.

Sorry for the long delay for that release, but the fix for this (and a few others) should be ready to download in the releases tab!


Distal vs. proximal myopathy with early respiratory failure

Trying to determine if both of these terms are still necessary?
MONDO:0011362   hereditary proximal myopathy with early respiratory failure; Links to OMIM:603689  &  OrphaNet: 178464   MONDO:0011859   Distal myopathy with early respiratory muscle involvement ; Links to OMIM:607569 &  Orphanet:34521; UMLS:C4518808 (MONDO:equivalentTo)
OMIM entry 607569  is now merged with 603689: "Myopathy, myofibrillar, 9, with early respiratory failure"
ORPHA:34521 points to UMLS: C1843633, which appears to be a dead CUI. (last active in UMLS release 2019AA)

Hi,
ORPHA:34521 Distal myopathy with early respiratory muscle involvement has been deprecated and moved to ORPHA:178464 Hereditary myopathy with early respiratory failure in September 2018.
Just wondering if you are using the latest Orphanet version.

Thanks @annieolry!


Compiling error: relocation R_X86_64_32

When building Boost.NumPy using CMake, I get the following compiling error when running the make command:
Linking CXX shared library ../../../lib/libboost_numpy.so
/usr/bin/ld: /hpc/sw/python-2.7.5/lib/libpython2.7.a(abstract.o): relocation R_X86_64_32 against `.rodata.str1.8' can not be used when making a shared object; recompile with -fPIC
/hpc/sw/python-2.7.5/lib/libpython2.7.a: could not read symbols: Bad value
collect2: ld returned 1 exit status
make[2]: *** [lib/libboost_numpy.so] Error 1
make[1]: *** [libs/numpy/src/CMakeFiles/boost_numpy.dir/all] Error 2
make: *** [all] Error 2

This is after creating a build directory and running cmake.
This means that there are some static libraries which have to be recompiled into dynamic ones. How should I proceed?

I'm guessing (just from the fact that I see libpython2.7.a, not libpython2.7.so) you just don't have a shared-library version of Python installed.  Most OSs and metapackages that ship Python build the shared library by default, but my recollection is that if you build Python from source you have to explicitly ask for the shared library.

Something was indeed wrong with the shared library. Since I ran on a computer where I had no admin rights whatsoever, I sadly cannot tell why it does work now. I just restarted everyting and loaded the desired python (Python 2.7.9), after which the make command functioned as it should.

Glad you got it worked.  I'm closing this issue now; please feel free to reopen if necessary.


Add the ability to change axisDirection in scrollController

Proposal
Hi, Please add the ability to change axisDirection in scrollController, because textField with textAlign.right just behaves weird. Unless it can be resolved in another way.

@Lukas249
Can you try something like below and see if it helps to achieve your case?
 final ScrollController _scrollController = ScrollController();
  _scrollController.position.userScrollDirection == ScrollDirection.forward;  // same for ScrollDirection.reverse

@darshankawar
Sorry but I don't know how it should help if it's type boolean and change nothing. The problem is the effect when I start deleting numbers. On delete, numbers (33255) shouldn't move but they are going to the left.

Thanks for the update.


Credits

Please include the following names in the developers list

Tatyana Goldberg

Susanna Lewis

Jim Procter

Robert Sheridan

Ian Sillitoe

Guy Yachdav

Our team for GitHub:
Sebastian Wilzbach (Technical University of Munich; TUM), Ian Sillitoe (University College London), Benedikt Rauscher (TUM), Robert Sheridan (Harvard Medical School),  James Procter (University of Dundee), Suzanna Lewis (Berkeley), Burkhard Rost (TUM), Tatyana Goldberg(TUM), Guy Yachdav (TUM)

Done with #171


⚠ Bofrost.lu has degraded performance

In fdc8035, Bofrost.lu (https://www.bofrost.lu) experienced degraded performance:

HTTP code: 200
Response time: 1068 ms

Resolved: Bofrost.lu performance has improved in 110b200.


Update sentence selection model to use dynamic padding

Currently getting a weird error on model loading, but after that's fixed, this will hopefully just work as-is.

This is now ready to review.  It's updating the sentence selection model to be compatible with the new dynamic padding stuff that I've been working on.  This should make training these models a lot faster.  @haniesedghi, FYI.

Ok, I fixed those comments, @pdasigi, and I've run some timing benchmarks.  Without dynamic padding, I was truncating to 40 words per sentence.  The max sentence length is ~260 words, though I don't know the average sentence length.  One epoch with this truncation took about 45 minutes.  When I switched to dynamic padding I removed all truncation.  It was on track to finish in about 1.25 hours per epoch, but it ran out of memory on a batch with really long sentences.
If we assume a linear relationship between sentence length and runtime (which may not be accurate), we'd get maybe ~3 hours per epoch without any truncation (though it also would run out of memory, so we'd have to decrease the batch size, which would make it slower).  Dynamic padding, then, gives us a ~2-3x speedup in this model.


[Backport - newton-14.0] Remove ssl_impossible from console services

Traffic to this service is now expected to be SSL-terminated
at the load balancer, which means a public, ssl virtual server
is needed.
This commit removes ssl_impossible from the console service's
POOL_PARTS. This will tell the script to create a public ssl
virtual server for the services.
Connects https://github.com/rcbops/rpc-openstack/issues/1977
(cherry picked from commit 62b07d58d4f48e171c3b205be3f43b47745496f3)

Alex and I attempted this in IAD3-1 and were successful. I believe this should resolve a defect reported in relation to NoVNC console being accessible over https.


pull request for e2e test at 12/24/2016 22:45:09

:white_check_mark: Validation status: passed
For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


Rename project to pymc-marketing

Closes #101
Closes #112
Clases #79
Regarding the import name, I think in most cases we can show:
from pymc_marketing import mmm
from pymc_marketing import clv

Commits have semantic meaning, so feel free to see one at a time if it helps with review


Sample API response + kwargs

This PR is more of a bandaid patch to fix the Samples.search functionality. Until this goes through the client will always throw an error when parsing the API response.
This should address #75 and #74

Documentation change from organism to organism__name and organism__taxonomy_id
Parse missing keys that were added to Sample serializer on API
Update comments to reflect recent changes

There will need to be more changes made here as there are still some loose ends that need to be accounted for, namely missing tests, and cleaning up the attributes to have them match the API. I will make a separate issue or two to make sure we track them.

Part of me feels like the organism keyword ought to be made to work (and automatically switch between name and taxonomy id based on whether it is an int) but that would require a lot more effort (at the API end?), and this seems the right approach for now.

Yes, in short you're right.
The organism keyword ideally would always represent the model / object for an organism across all endpoints. I think the inconsistency is due to how each endpoint was designed independently and is not an isolated issue. I do think that for now this PR addresses the issue in the best way possible. The object__object_attribute / organism__name convention is inherited from django and moving forward, in a v2 API, we would want to rethink this to conform to the default django behavior. The real obstacle is that organisms primary key is the organism name and not the taxonomy_id on other endpoints.


Feat/44309 be integration create expensify card

Details

Fixed Issues

$ https://github.com/Expensify/App/issues/44309
PROPOSAL:
Tests

PREREQUISITES: all betas/workspaceFeed beta enabled

Go to workspace, enable Expensify Card if not enabled and add bank account
Go through the flow, issue new card
Verify that the request returns a proper response

[x] Verify that no errors appear in the JS console

Offline tests

QA Steps

PREREQUISITES: all betas/workspaceFeed beta enabled

Go to workspace, enable Expensify Card if not enabled and add bank account
Go through the flow, issue new card
Verify that the request returns a proper response

[x] Verify that no errors appear in the JS console

PR Author Checklist

[x] I linked the correct issue in the ### Fixed Issues section above
[x] I wrote clear testing steps that cover the changes made in this PR

[x] I added steps for local testing in the Tests section
[x] I added steps for the expected offline behavior in the Offline steps section
[x] I added steps for Staging and/or Production testing in the QA steps section
[x] I added steps to cover failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
[x] I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
[x] I tested this PR with a High Traffic account against the staging or production API to ensure there are no regressions (e.g. long loading states that impact usability).

[x] I included screenshots or videos for tests on all platforms
[x] I ran the tests on all platforms & verified they passed on:

[x] Android / native
[x] Android / Chrome
[x] iOS / native
[x] iOS / Safari
[x] MacOS / Chrome / Safari
[x] MacOS / Desktop

[x] I verified there are no console errors (if there's a console error not related to the PR, report it or open an issue for it to be fixed)
[x] I followed proper code patterns (see Reviewing the code)

[x] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick)
[x] I verified that the left part of a conditional rendering a React component is a boolean and NOT a string, e.g. myBool && <MyComponent />.
[x] I verified that comments were added to code that is not self explanatory
[x] I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
[x] I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method

[x] If any non-english text was added/modified, I verified the translation was requested/reviewed in #expensify-open-source and it was approved by an internal Expensify engineer. Link to Slack message:

[x] I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
[x] I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is approved by marketing by adding the Waiting for Copy label for a copy review on the original GH to get the correct copy.
[x] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[x] I verified the JSDocs style guidelines (in STYLE.md) were followed

[x] If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
[x] I followed the guidelines as stated in the Review Guidelines
[x] I tested other components that can be impacted by my changes (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar are working as expected)
[x] I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
[x] I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
[x] I verified that if a function's arguments changed that all usages have also been updated correctly
[x] If a new component is created I verified that:

[x] A similar component doesn't exist in the codebase
[x] All props are defined accurately and each prop has a /** comment above it */
[x] The file is named correctly
[x] The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
[x] The only data being stored in the state is data necessary for rendering and nothing else
[x] If we are not using the full Onyx data that we loaded, I've added the proper selector in order to ensure the component only re-renders when the data it is using changes

[x] Any internal methods bound to this are necessary to be bound (i.e. avoid this.submit = this.submit.bind(this); if this.submit is never passed to a component event handler like onClick)

[x] All JSX used for rendering exists in the render method
[x] The component has the minimum amount of code necessary for its purpose, and it is broken down into smaller components in order to separate concerns and functions

[x] If any new file was added I verified that:

[x] The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory

[x] If a new CSS style is added I verified that:

[x] A similar style doesn't already exist
[x] The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(themeColors.componentBG))

[x] If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
[x] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[x] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[x] If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
[x] If the PR modifies the form input styles:

[x] I verified that all the inputs inside a form are aligned with each other.
[x] I added Design label so the design team can review the changes.

[x] If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
[x] If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.
[x] I have checked off every checkbox in the PR author checklist, including those that don't apply to this PR.

Screenshots/Videos

Android: Native

Android: mWeb Chrome

iOS: Native

iOS: mWeb Safari

MacOS: Chrome / Safari

MacOS: Desktop

@mountiny let me know if I can open this PR for review

@MariaHCD @mountiny I'm getting this error while sending limitType monthly

@koko57 fixing that in BE

Here is a PR to fix the param issue https://github.com/Expensify/Web-Expensify/pull/43037

response 200

@koko57 Perfect, I think we can make this ready for a review

strange, but in other places where cardSettings is used ts doesn't complain 😭

@koko57 Also please add videos for this PR (at least one)

Can anyone help me add an eligible bank account to Card Settings? Currently, I'm getting a 404 error, and I suspect it's because I haven't set up a bank account.
cc @mountiny @koko57

@MariaHCD @koko57
Pre-condition: I haven't set up a bank account
In creating physical card flow, the API returns status code 200 with this error:
 Auth::createExpensifyCard(): Argument #4 ($limitType) must be of type string, null given, called in /git/releases/expensify.com/322d720/api.php on line 4375
https://github.com/user-attachments/assets/0dd53d3e-1785-4cb6-8b36-2359885cdca6

Ops, I think we should complete this PR first 😄

@koko57 Also please add videos for this PR (at least one 😄 )

@DylanDylann can it be a screenshot with the Network tab? 😃

Can anyone help me add an eligible bank account to Card Settings? Currently, I'm getting a 404 error when creating a virtual card, and I suspect it's because I haven't set up a bank account. (Note: I must hard code to go to issue new card page)

I'll check it once again but I was able to add a bank account through VBBA with this data https://expensify.slack.com/archives/C01GTK53T8Q/p1711049892429129?thread_ts=1711049879.962529&cid=C01GTK53T8Q and it appeared in my eligible accounts (I'll check for sure if the filtering worked back then, bc for some time we had it commented out)

Pre-condition: I haven't set up a bank account for card (note: I must hard code to go to issue new card page)
In creating physical card flow, the API returns status code 200 with this error:  Auth::createExpensifyCard(): Argument #4 ($limitType) must be of type string, null given, called in /git/releases/expensify.com/322d720/api.php on line 4375

@DylanDylann I was getting the same error but when using a random bank account and probably without ConfigureCardsForPolicy

@koko57 Let's focus on https://github.com/Expensify/App/pull/46564 first

@DylanDylann you need to add the account throuhg Plaid using the Regions bank. Otherwise there are details in this thread

@DylanDylann conflicts resolved after https://github.com/Expensify/App/pull/46564

@koko57 The API is successful but the data differs from the current mock data. But It seems it will be handled here

Reviewer Checklist

[ ] I have verified the author checklist is complete (all boxes are checked off).
[ ] I verified the correct issue is linked in the ### Fixed Issues section above
[ ] I verified testing steps are clear and they cover the changes made in this PR

[ ] I verified the steps for local testing are in the Tests section
[ ] I verified the steps for Staging and/or Production testing are in the QA steps section
[ ] I verified the steps cover any possible failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
[ ] I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)

[ ] I checked that screenshots or videos are included for tests on all platforms
[ ] I included screenshots or videos for tests on all platforms
[ ] I verified tests pass on all platforms & I tested again on:

[ ] Android: Native
[ ] Android: mWeb Chrome
[ ] iOS: Native
[ ] iOS: mWeb Safari
[ ] MacOS: Chrome / Safari
[ ] MacOS: Desktop

[ ] If there are any errors in the console that are unrelated to this PR, I either fixed them (preferred) or linked to where I reported them in Slack
[ ] I verified proper code patterns were followed (see Reviewing the code)

[ ] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick).
[ ] I verified that the left part of a conditional rendering a React component is a boolean and NOT a string, e.g. myBool && <MyComponent />.
[ ] I verified that comments were added to code that is not self explanatory
[ ] I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
[ ] I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method
[ ] I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
[ ] I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is either coming verbatim from figma or has been approved by marketing (in order to get marketing approval, ask the Bug Zero team member to add the Waiting for copy label to the issue)
[ ] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[ ] I verified the JSDocs style guidelines (in STYLE.md) were followed

[ ] If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
[ ] I verified that this PR follows the guidelines as stated in the Review Guidelines
[ ] I verified other components that can be impacted by these changes have been tested, and I retested again (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar have been tested & I retested again)
[ ] I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
[ ] I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
[ ] If a new component is created I verified that:

[ ] A similar component doesn't exist in the codebase
[ ] All props are defined accurately and each prop has a /** comment above it */
[ ] The file is named correctly
[ ] The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
[ ] The only data being stored in the state is data necessary for rendering and nothing else
[ ] For Class Components, any internal methods passed to components event handlers are bound to this properly so there are no scoping issues (i.e. for onClick={this.submit} the method this.submit should be bound to this in the constructor)
[ ] Any internal methods bound to this are necessary to be bound (i.e. avoid this.submit = this.submit.bind(this); if this.submit is never passed to a component event handler like onClick)
[ ] All JSX used for rendering exists in the render method
[ ] The component has the minimum amount of code necessary for its purpose, and it is broken down into smaller components in order to separate concerns and functions

[ ] If any new file was added I verified that:

[ ] The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory

[ ] If a new CSS style is added I verified that:

[ ] A similar style doesn't already exist
[ ] The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(theme.componentBG)

[ ] If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
[ ] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[ ] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[ ] If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
[ ] If the PR modifies the UI (e.g. new buttons, new UI components, changing the padding/spacing/sizing, moving components, etc) or modifies the form input styles:

[ ] I verified that all the inputs inside a form are aligned with each other.
[ ] I added Design label and/or tagged @Expensify/design so the design team can review the changes.

[ ] If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
[ ] If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.
[ ] I have checked off every checkbox in the PR reviewer checklist, including those that don't apply to this PR.

Screenshots/Videos

Android: Native

Android: mWeb Chrome

iOS: Native

iOS: mWeb Safari

MacOS: Chrome / Safari

MacOS: Desktop

Reviewer Checklist

[ ] I have verified the author checklist is complete (all boxes are checked off).
[ ] I verified the correct issue is linked in the ### Fixed Issues section above
[ ] I verified testing steps are clear and they cover the changes made in this PR

[ ] I verified the steps for local testing are in the Tests section
[ ] I verified the steps for Staging and/or Production testing are in the QA steps section
[ ] I verified the steps cover any possible failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
[ ] I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)

[ ] I checked that screenshots or videos are included for tests on all platforms
[ ] I included screenshots or videos for tests on all platforms
[ ] I verified tests pass on all platforms & I tested again on:

[ ] Android: Native
[ ] Android: mWeb Chrome
[ ] iOS: Native
[ ] iOS: mWeb Safari
[ ] MacOS: Chrome / Safari
[ ] MacOS: Desktop

[ ] If there are any errors in the console that are unrelated to this PR, I either fixed them (preferred) or linked to where I reported them in Slack
[ ] I verified proper code patterns were followed (see Reviewing the code)

[ ] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick).
[ ] I verified that the left part of a conditional rendering a React component is a boolean and NOT a string, e.g. myBool && <MyComponent />.
[ ] I verified that comments were added to code that is not self explanatory
[ ] I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
[ ] I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method
[ ] I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
[ ] I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is either coming verbatim from figma or has been approved by marketing (in order to get marketing approval, ask the Bug Zero team member to add the Waiting for copy label to the issue)
[ ] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[ ] I verified the JSDocs style guidelines (in STYLE.md) were followed

[ ] If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
[ ] I verified that this PR follows the guidelines as stated in the Review Guidelines
[ ] I verified other components that can be impacted by these changes have been tested, and I retested again (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar have been tested & I retested again)
[ ] I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
[ ] I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
[ ] If a new component is created I verified that:

[ ] A similar component doesn't exist in the codebase
[ ] All props are defined accurately and each prop has a /** comment above it */
[ ] The file is named correctly
[ ] The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
[ ] The only data being stored in the state is data necessary for rendering and nothing else
[ ] For Class Components, any internal methods passed to components event handlers are bound to this properly so there are no scoping issues (i.e. for onClick={this.submit} the method this.submit should be bound to this in the constructor)
[ ] Any internal methods bound to this are necessary to be bound (i.e. avoid this.submit = this.submit.bind(this); if this.submit is never passed to a component event handler like onClick)
[ ] All JSX used for rendering exists in the render method
[ ] The component has the minimum amount of code necessary for its purpose, and it is broken down into smaller components in order to separate concerns and functions

[ ] If any new file was added I verified that:

[ ] The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory

[ ] If a new CSS style is added I verified that:

[ ] A similar style doesn't already exist
[ ] The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(theme.componentBG)

[ ] If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
[ ] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[ ] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[ ] If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
[ ] If the PR modifies the UI (e.g. new buttons, new UI components, changing the padding/spacing/sizing, moving components, etc) or modifies the form input styles:

[ ] I verified that all the inputs inside a form are aligned with each other.
[ ] I added Design label and/or tagged @Expensify/design so the design team can review the changes.

[ ] If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
[ ] If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.
[ ] I have checked off every checkbox in the PR reviewer checklist, including those that don't apply to this PR.

Screenshots/Videos

Android: Native

Android: mWeb Chrome

iOS: Native

iOS: mWeb Safari

MacOS: Chrome / Safari

MacOS: Desktop

:hand: This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release.

🚀 Deployed to staging by https://github.com/mountiny in version: 9.0.20-0 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅

FYI I believe this was deployed to prod yesterday, from this checklist - #47356


Support plug renaming in Expression node

Currently if you rename the plugs (or their parents) referenced by an expression, the expression breaks. We need to keep the expressions text up to date with respect to such name changes.

Fixed in #1473.


i want to improve desgin of this

okay can you assigned me this task i make it beautiful

check  my changes and review me


Timelines recording sends some long messages that hit the buffer limit of write method, so fallback to dispatch_io_write

run ci


Notes open scrolled down

In v2.3.1, all notes long enough to be scrollable open scrolled to the bottom. The switch for "Remember scroll position" is set to off, BTW.
Didn't have an opportunity to check that in v2.3.0, but I'm quite sure that was not in the previous betas already.

Thanks for the fix! 😀

You're very welcome!


adding test cases for cache init errors

Fix coverage decrement introduced by central cache PR.
Signed-off-by: Chengxuan Xing<EMAIL_ADDRESS>

Codecov Report

Merging #1044 (58105ef) into main (75fc92d) will increase coverage by 0.13%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##             main    #1044      +/-   ##
==========================================
+ Coverage   99.83%   99.97%   +0.13%
==========================================
  Files         307      307
  Lines       20264    20264
==========================================
+ Hits        20230    20258      +28
+ Misses         19        4      -15
+ Partials       15        2      -13

Impacted Files
Coverage Δ

internal/blockchain/ethereum/ethereum.go
100.00% <0.00%> (+0.38%)
:arrow_up:

internal/blockchain/fabric/fabric.go
100.00% <0.00%> (+0.39%)
:arrow_up:

internal/events/aggregator.go
100.00% <0.00%> (+0.51%)
:arrow_up:

internal/privatemessaging/privatemessaging.go
100.00% <0.00%> (+1.22%)
:arrow_up:

internal/identity/identitymanager.go
100.00% <0.00%> (+1.26%)
:arrow_up:

internal/operations/manager.go
100.00% <0.00%> (+1.38%)
:arrow_up:

internal/data/data_manager.go
100.00% <0.00%> (+1.42%)
:arrow_up:

internal/orchestrator/orchestrator.go
100.00% <0.00%> (+1.89%)
:arrow_up:

internal/events/event_manager.go
100.00% <0.00%> (+3.36%)
:arrow_up:

internal/blockchain/ethereum/address_resolver.go
100.00% <0.00%> (+3.57%)
:arrow_up:

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.


Swiping vertically cause carousal to scroll horizontally

Hello,
First of all Slick carousal works like a charm. One issue i was having is when swiping vertically in carousal cause to scroll horizontally. Please help!!

Could you provide some code so we can try to look what is wrong ?

If you're still facing this issue, please create a demo on codesandbox.


[WFLY-14880] Upgrade bouncycastle to 1.69 (new transitive dependency)

Fixes https://issues.redhat.com/browse/WFLY-14880
Requires https://issues.redhat.com/browse/WFCORE-5461

Corresponding PR in WFCore https://github.com/wildfly/wildfly-core/pull/4628

Hello @yersan thanks for your reply.

1. We need to create a new PR, it could be linked to the same WFLY-14880 Jira. This new PR will ignore the test cases that are at the moment failing for WFCORE-5461. The complete list is shown on the latest wildfly-core full integration test Job:  https://ci.wildfly.org/viewLog.html?buildId=260719&buildTypeId=WildFlyCore_PullRequest_WildFlyCoreFullIntegration

Done with PR https://github.com/wildfly/wildfly/pull/14398

2. We need to add to this PR [[WFLY-14880] Upgrade bouncycastle to 1.69 (new transitive dependency) #14357](https://github.com/wildfly/wildfly/pull/14357) a reverse commit that unignores the ignored tests done on the other PR. We will have two commits.

I will provide that after merge of 14398.

@yersan Hello Yeray, I have provided step 2, the reverse commit here. The tests in WFCORE are still running right now.

/retest

@yersan
Error from Dependency Tree Input Builder:

Error: ] Some problems were encountered while processing the POMs:
Error:  'dependencies.dependency.version' for org.bouncycastle:bcutil-jdk15on:jar is missing. @ line 1849, column 21

I have checked the effective POM in Eclipse, the version is present. Why do the other builds not fail?

I put a hold label on this as I want to see if the additional commit I added in #14461 resolves the "Dependency Tree Builder" test failure.

@yersan @bstansberry Thanks for investing time and energy in this topic. I have learned a lot. I'm sure users will profit.

@boris-unckel Thanks to you for the contribution and for keeping it on track until getting it done.
@bstansberry Thanks for taking care of the final steps and pending cleanups. I thought the PR would need to be rebased to fix the "Dependency Tree Builder".


Fix bug scripts in Mitmweb

Description
This PR should fix issue: #6002
Checklist

[ ] I have updated tests where applicable.
[ ] I have added an entry to the CHANGELOG.

yes I agree, initially my idea was to put a check in the component Option.jsx, but for some implementation reasons it didn't work and I couldn't insert more than 1 path (basically I wasn't able to start a new line). Is that what you mean?

Hello @mhils , is this acceptable ?

Hello @mhils , I tried again to integrate the check in Option.jsx but it's not straightforward since here we simply propagate the value and call updateOptions. I found another solution: basically put the check in the function update in options.ts. Is it acceptable?
Something like this:
export function update(name: Option, value: any): AppThunk {     return (dispatch) => {         console.log(value);         dispatch(optionsEditorActions.startUpdate(name, value));         if (value[value.length - 1] !== "") { //we send the value to the backend only if it is not empty             console.log("send value to backend");             sendUpdate(name, value, dispatch);         }     }; }

sorry I misclicked the button , and I accidentally closed the pr

but it's not straightforward since here we simply propagate the value and call updateOptions

Yeah, I think that's what we need to change! How about we change StringSequenceOption so that it keeps some internal state but only propagates non-empty strings? That feels cleanest to me.

but it's not straightforward since here we simply propagate the value and call updateOptions

Yeah, I think that's what we need to change! How about we change StringSequenceOption so that it keeps some internal state but only propagates non-empty strings? That feels cleanest to me.

yes I totally agree with you, but I'm still having issues and I am not able to add more than one line(that's is due to the fact that we modify the value by removing the ""). So, basically it works if we don't filter for empty strings (but the initial bug is still there) or if remove value={value.join("\n")} (but of course in this case we don't have persistence).
it's quite challenging :) maybe my approach is wrong but I couldn't find a way to solve the problem in this component, at least without changing the logic behind it.
That's my change now:
`function StringSequenceOption({ value, onChange, ...props }) {
const height = Math.max(value.length, 1);
return (
    <textarea
        rows={height}
        value={value.join("\n")}
        onChange={(e) =>
            onChange(
                e.target.value
                    .split("\n")
                    .map((line) => line.trim())
                    .filter((line) => line !== "")
            )
        }
        {...props}
    />
);

}`

I probably found a solution :) I'll push later


Explain why we need Python 3.9 to me like im 5 yrs old

Trying to remember, but if this is based on the Coinbase API that is able to use anything newer than 3.6

The official Coinbase wrapper uses a cryptography library. The cryptography library needs to be compiled on a certain version of python or it won't run in AWS. I arbitrarily chose Python 3.9 when I compile the layer. You could choose some other Python version (and I will probably update it sometime in the future) but we'll need to specifically compile for that version of python


Procedure for coe cluster creation not work

Hi, im trying to use the procedure you describe for create coe cluster but i see this issues:
2024-03-20 00:54:41.932 18 ERROR oslo_messaging.rpc.server [None req-f3c68b4e-db88-4da9-b8a6-1c71db75b340 e2a1f54c86914966b4ca014324799832 01adb0aae1b94bd493311c94456643a4 - - default -] Exception during message handling: KeyError: 'kube_tag'
When i add the tag for image that you recomend (1.28 based) i see this error in magnum log:
2024-03-19 23:47:45.794 18 ERROR oslo_messaging.rpc.server ValueError: Unsupported Kubernetes version: 1.28.3. Please specify a supported version in the cluster template.
As a workaround i change de tag version to a supported (1.27 based) but the cluster failed to create after control-plane boot.
Im using Kolla-ansible as osp deployment
Thanks!

Hello @mathgonzlez - the repository has been moved to official OpenStack governance, please ask that question again either on #openstack-containers on OFTC IRC or raise a bug request under https://bugs.launchpad.net/magnum


Add GAIA as a benchmark - much more suited for Agents, IMO

:-)
https://huggingface.co/gaia-benchmark
https://arxiv.org/abs/2311.12983

Please generate a pull request specifying the file where you'd like to include this.


Language tags on metadata should be preserved on edit

Can't to replicate this issue. I've tried all variations on saving/updating, and the language metadata persists. Could you give an example?

I tried creating a record with bib 4785597.  But when I look at the data in Fedora (before making any updates), I don't see language tags on the title:
ns008:title "تضيح المقال في الرد على من انكر الاخذ من اللحية واكتحال"^^<http://www.w3.org/2001/XMLSchema#string> ,
   "Tawḍīḥ al-maqāl fī al-radd ʻalá man ankara al-akhdh min al-liḥiyah wa-al-iktiḥāl."^^<http://www.w3.org/2001/XMLSchema#string> ;

So I think we may not be bringing in the language tags currently.

I see now. Tags. Not the language attribute.

Huh, good catch @escowles. I'll poke at it

Right, in an ideal world, we'd have language tags with script suffixes to differentiate Arabic in Arabic script from Arabic in Latin script:
ns008:title "تضيح المقال في الرد على من انكر الاخذ من اللحية واكتحال"@ara-Arab^^<http://www.w3.org/2001/XMLSchema#string> ,
   "Tawḍīḥ al-maqāl fī al-radd ʻalá man ankara al-akhdh min al-liḥiyah wa-al-iktiḥāl."@ara-Latn^^<http://www.w3.org/2001/XMLSchema#string> ;

Alright, looks like they're lost in the JSONLD record because AF#attributes doesn't return literals. Trying out the new AT to see if that fixes the problem.

Yup, the AT branch fixes that issue - but breaks a LOT of our tests (we're assuming there's strings, and really they're literals..)

Resolved with #712


Update for latest version of RN.

@phil-r: do you mind taking a look at this PR? Currently, the whole package is broken for anybody on the latest version of RN.

Superceeded by #7.


Raise minimum version for distrib launch

Closes https://github.com/huggingface/accelerate/issues/847
TL;DR there was a neat bug in torch 1.9.0 where torchrun wouldn't always actually run. This PR changes the flag for checking to be 1.9.1, which I found did work after successfully recreating the 1.9.0 issue.
It also modifies the if/else flag as it was always going to raise if the value was < 1.9.0 but gives it a much more clear answer as to what is truly happening here.

The docs for this PR live here. All of your documentation changes will be reflected on that endpoint.


Local dev setup documentation and investigate strategies to make it easier

User Need
As a developer
I want to be able to setup my local development environment as easily as possible
so that I can onboard onto the team faster and share the same tooling as everyone else
Functional Requirements:

[ ]  Investigate methods of packaging up and sharing tooling and configuration required for local dev environment e.g., Docker image

[ ] Runbook to cover key tooling and configuration of said tooling that is required for local dev environment.

Non-Functional Requirements:
Any method to share tooling and configuration must be easy to share, robust, well documented, and must not negatively affect developer experience
Acceptance Criteria:

Runbook for local dev setup is added to https://runbooks.operations-engineering.service.justice.gov.uk/#what-we-don-39-t-support.
Potentially a shared resource allowing for easy setup of local dev environment.

Gary's team use this (https://github.com/ministryofjustice/data-platform-control-panel) devcontainer (https://containers.dev/)

Devcontainer cli - https://code.visualstudio.com/docs/devcontainers/devcontainer-cli

Volume mounting:

Example using Dockerfile - https://benmatselby.dev/post/vscode-dev-containers/

Using prebuilt container https://containers.dev/guide/prebuild

Data platform docs - https://technical-documentation.data-platform.service.justice.gov.uk/documentation/platform/infrastructure/developing.html#prerequisites

Got container up and running, next steps:

Show PoC to team
Decide what team want in container - Use a Google Doc for this?
Secret integration - take a look at data platform docs


Update docs - How to Use Webhooks

The example below doesn't contains all info about how dev can setup webhooks. Would be nice to provide more clear example for this:

for example:
import express from 'express';
import { Bot, webhookCallback } from 'grammy';

const app = express();
app.use(express.json());

const bot = new Bot(process.env.TELEGRAM_BOT_TOKEN);
await bot.api.setWebhook('https://base_server_url');

bot.on('message', async (ctx) => { ... });

app.use(webhookCallback(bot, 'express'));
app.listen(8080);

I think at that point we need to provide code examples for every adapter. That would be reasonable anyway, as it's a common question.
It would be incorrect to call setWebhook the way you do, since many people use serverless deployments which would call that method way too many times. We can elaborate on setting the URL in a different way.

I'm quite new in Telegram bot development and dont sure on 100% about how to setup webhook in the proper way. Just saw the similar approuch in other libs like node-telegram-bot-api. This is why I posted this issue - would be helpfull to see the proper approuch in the lib docs.

"The proper way" depends on the exact framework you are using, and on where you host it. There is no one-size-fits-all solution, which is why the docs currently only give an example that is mostly relevant for a large audience, and that leaves the rest to the developer.
A few more examples can be found in the example bots repository, although it isn't exactly tailored towards your question.


Temporarily prefix package names with cardano- for CHaP publication.

To prevent name clashes in the future when we publish fs-sim and fs-api to Hackage, we prefix the package names with cardano-, and they will published to CHaP under that name.

We decided not to use prefixed names


[BUG] server crash on docker-compose.yml parse error

Describe the bug
With a particular docker-compose.yml file in my workspace directory, exo new process causes exo server to crash.
To Reproduce
Steps to reproduce the behavior:

create a workspace
put a docker-compose.yml file with following contents in the workspace dir

version: 2

x-defaults: &defaults
  sysctls:
    net.ipv6.conf.all.disable_ipv6: 1
  mem_swappiness: 0

services:
  kibana:
    image: docker.elastic.co/kibana/kibana:7.6.1
    <<: *defaults
    mem_limit: 300m
    ports:
      - 5601:5601 # The HTTP UI Port
    environment:
      ELASTICSEARCH_URL: http://elasticsearch:9200
      ELASTICSEARCH_HOSTS: http://elasticsearch:9200
    profiles: ["elasticsearch"]

run exo new process foo -- bash -c hello
See error:

Job URL: http://localhost:43643/#/jobs/x51rc0t9n0wmxdns9s2gjar8y0
Error: describing tasks: posting: Post "http://localhost:43643/_exo/kernel/describe-tasks": EOF
describing tasks: posting: Post "http://localhost:43643/_exo/kernel/describe-tasks": EOF

See error in ~/.exo/var/exod.stderr

cat ~/.exo/var/exod.stderr                                                                                panic: unexpected yaml node tag: "!!int"

goroutine 71 [running]:
github.com/deref/exo/internal/manifest/compose.yamlToHCL({0x49c02c0, 0xc0001ee6e0})
        /go/src/github.com/deref/exo/internal/manifest/compose/import.go:364 +0x14f3
github.com/deref/exo/internal/manifest/compose.yamlToHCL({0x49bee80, 0xc00007c280})
        /go/src/github.com/deref/exo/internal/manifest/compose/import.go:309 +0xbd5
github.com/deref/exo/internal/manifest/compose.yamlToHCL({0x4a24d40, 0xc0000c8000})
        /go/src/github.com/deref/exo/internal/manifest/compose/import.go:400 +0xf2d
github.com/deref/exo/internal/manifest/compose.makeComponentBlock({0x4a2ab11, 0x9}, {0xc00051e670, 0x6}, {0x4a24d40, 0xc0000c8000}, {0xc00007a840, 0x1, 0x1})
        /go/src/github.com/deref/exo/internal/manifest/compose/import.go:249 +0x7c
github.com/deref/exo/internal/manifest/compose.(*Importer).Import(0xc00007a160, 0xc00041ea50, {0xc0003d61a0, 0x19d, 0x1a0})
        /go/src/github.com/deref/exo/internal/manifest/compose/import.go:229 +0xe58
github.com/deref/exo/internal/manifest.(*Loader).Load(0xc00069b8e0, 0xc0003d6000)
        /go/src/github.com/deref/exo/internal/manifest/manifest.go:74 +0x266
github.com/deref/exo/internal/core/server.(*Workspace).loadManifest(0xc000378000, {0x557de68, 0xc000486180}, {0xc00051e038, 0x8}, 0xc00069b970)
        /go/src/github.com/deref/exo/internal/core/server/config.go:91 +0x414
github.com/deref/exo/internal/core/server.(*Workspace).tryLoadManifest(0x1, {0x557de68, 0xc000486180})
        /go/src/github.com/deref/exo/internal/core/server/config.go:43 +0x72
github.com/deref/exo/internal/core/server.(*Workspace).getEnvironment(0xc000378000, {0x557de68, 0xc000486180})
        /go/src/github.com/deref/exo/internal/core/server/environment.go:19 +0x46
github.com/deref/exo/internal/core/server.(*Workspace).newController(0xc000378000, {0x557de68, 0xc000486180}, {{0xc00003a100, 0x1a}, {0xc00042a168, 0x3}, {0xc00042a170, 0x7}, {0xc0005c8000, ...}, ...})
        /go/src/github.com/deref/exo/internal/core/server/workspace.go:384 +0x105
github.com/deref/exo/internal/core/server.(*Workspace).control(0xc000378000, {0x557de68, 0xc000486180}, {{0xc00003a100, 0x1a}, {0xc00042a168, 0x3}, {0xc00042a170, 0x7}, {0xc0005c8000, ...}, ...}, ...)
        /go/src/github.com/deref/exo/internal/core/server/workspace.go:1116 +0x7f
github.com/deref/exo/internal/core/server.(*Workspace).createComponent(0xc000378000, {0x557de68, 0xc000486180}, 0xc00007e140, {0xc00003a100, 0x1a})
        /go/src/github.com/deref/exo/internal/core/server/workspace.go:501 +0x4da
github.com/deref/exo/internal/core/server.(*Workspace).CreateComponent.func1()
        /go/src/github.com/deref/exo/internal/core/server/workspace.go:459 +0xa9
created by github.com/deref/exo/internal/core/server.(*Workspace).CreateComponent
        /go/src/github.com/deref/exo/internal/core/server/workspace.go:456 +0x18f

Expected behavior

I don't expect exo to read the docker-compose.yml file.
I expect the server to continue running

System Info (please complete the following information):

OS: macOS
Component server
Version 2021.10.28-2

I cut a release along with one other small bug fix. Will leave this ticket open to track work on making the docker-compose file handling much more robust. This is presently somewhat difficult to test, but the work in https://github.com/deref/exo/pull/426 should make it much easier to work with & so test coverage will go way up here.

Going to close this issue because the crash was already fixed and the next major release of exo has completely rewritten the docker-compose handling logic. Thanks again for the report!