<dhess>
yeah I would guess that stdin is None if you're not sending any input
<adisbladis>
dhess: Looking at `passed_stdin` if I find this very confusing.
<adisbladis>
Looking at `passed_stdin` I find this very confusing.
<adisbladis>
The type signature would indicate it's never valid to be None.
<dhess>
I've never used Mypy so I don't know how robust its type system is.
<adisbladis>
dhess: Even looking at the assignments it doesn't make sense that it would be None.
<dhess>
are you looking at the devnull case?
<adisbladis>
Yeah
<dhess>
I assume devnull is None, then.
<adisbladis>
devnull = open(os.devnull, "r+")
<dhess>
does opening os.devnull in python return None?
<adisbladis>
Nope
<gchristensen>
I'd expect stdin to be None if we don't explicitly tell popen we're going to use it
<dhess>
ok but when python tries to read from /dev/null the stdin value it will return is surely None
<gchristensen>
I wonder what typeshed has to say about the type sig
<adisbladis>
gchristensen: Optional[IO[str]]
<gchristensen>
m
<gchristensen>
hm
<adisbladis>
But that's true for all stdin/stdout/stderr
<dhess>
process.stdin is supposed to be the Text value of stdin, I assume?
<dhess>
not the fd?
<adisbladis>
To the documentation mobile!
<dhess>
I'm pretty sure it's the string. You're assigning its value to a string, if I'm reading the Mypy annotation correctly
<dhess>
so that will be None, because it's the result of reading from /dev/null
<adisbladis>
dhess: No, it's supposed to be a file descriptor.
<dhess>
ok
<adisbladis>
This is very confusing.
<dhess>
Popen.stdin
<dhess>
If the stdin argument was PIPE, this attribute is a writeable stream object as returned by open(). If the encoding or errors arguments were specified or the universal_newlines argument was True, the stream is a text stream, otherwise it is a byte stream. If the stdin argument was not PIPE, this attribute is None.
<dhess>
gchristensen: thank you for the incredibly fast fix!
<dhess>
I'm wondering if it's the YubiKey/gpg-agent, though.
<gchristensen>
my thinking is we can merge often and revert often too :P
<dhess>
My network stack was actually still working. I was able to file the issue while I was waiting for NixOps to time out (which it never did -- I had to reboot). But something was locking up `ps`, Activity Monitor, and other processes.
<gchristensen>
wow.
<dhess>
gchristensen: do you know why NixOps would occasionally seem like it's using my personal SSH keys, rather than the ones it generates?
<dhess>
It definitely prompts me for the PIN that unlocks my YubiKey, after gpg-agent drops its cache.
<gchristensen>
nixops doesn't say ONLY use the key it knows about
<gchristensen>
and then ssh just does ... whatever ... order
<dhess>
ahh I thought it did. Well, that would almost certainly explain it.
<dhess>
The YubiKey probably locks up dealing with all the requests.
<gchristensen>
I wish it did, I have enough SSH keys that it breaks SSH for nixops
<dhess>
all kinds of other weird shit also happened. My desktop images switched back to the default, for example.
<dhess>
but only on some of my (virtual) desktops.
<gchristensen>
wow what
<dhess>
yeah this was a very strange issue. After a reboot, my Mac wanted to file a report that it had rebooted due to a kernel crash. Took the machine about 3-4 minutes to reboot.
<dhess>
etc.
jbgi_ has joined #nixops
<dhess>
anyway it seems like a super useful feature, but I suspect that anybody using a hardware device to manage their SSH private keys is going to run into this issue.
<dhess>
that'll teach me not to upgrade my NixOps :)
<dhess>
I only did it to be ready for your S3 state stuff.
<gchristensen>
no way I'm glad you did
<gchristensen>
I hope you continue to ... :)
<dhess>
will do, of course, NixOps is great.
<dhess>
it sounds like stateless deployments are also coming?
<gchristensen>
yeap :) just need to iron out some kinks, lke not generate an SSH key oneach deploy
<dhess>
that'll be amazing. At least half of my deployments could run that way.
<gchristensen>
nice
abathur has joined #nixops
jbgi_ has quit [Ping timeout: 256 seconds]
<dhess>
gchristensen: anyway, pretty sure that explains why I was seeing that extremely slow performance, even when I was just testing with 1 or 2 hosts at a time.
<gchristensen>
I believe that :)
<dhess>
gchristensen: did the context manager stuff make it possible for multiple SSHes to happen in parallel, even just one per host at a time?
<dhess>
because I'm *pretty* sure that NixOps is still slower than it used to be for me during a deploy, even after you reverted that parallel key copy commit.
<gchristensen>
no, that didn't change any of that -- it has always been able to SSH to many at once
<gchristensen>
open_deployment should be renamed to break plugins more thoroughly
jbgi_ has joined #nixops
johnny101 has quit [Quit: Konversation terminated!]