Chat Logs

  1. bluehi phaleth
  2. phalethhi blue
  3. bluedreamreal: can we give phaleth access to the bytenews/nevet repo? I can't make it run on linux with docker, and porting it to nspawn has already cost me 2 hours of nothing... he's the nspawn expert here
  4. blueplus, if he gets it done, it'll be RP-ready
  5. blueI'm REALLY not good at devops
  6. phalethyou wanna deploy nevet onto the VPS?
  7. blueI wanna deploy it locally on nspawn, so I can test the primate component I'm writing for it
  8. bluebut yes, eventually, if dreamreal is fine with that, I'll have it run on RP
  9. blueI already have it building on buildkit in <90s, which isn't bad, but I just can't figure out networking
  10. bluehe's using docker compose, which is bad voodoo magic, but works for him on mac. it doesn't work for me on linux
  11. blueit uses a postgresql container, it's not a really complex setup but I can't make it work
  12. phalethdocker compose is cool, yeah
  13. phalethand did you already look at any of the postgres setup that I've documented?
  14. bluenot yet
  15. phalethI hope bytenews/nevet is not hosted on github btw
  16. blueit is, unfortunately
  17. phalethoh
  18. blueI'm currently messing around in the endless blackhole that is systemd-networkd and systemd-resolved
  19. phalethlately, I've been having trouble logging into github
  20. blueis there anything poettering didn't write a daemon for?
  21. bluesystemd-make-me-my-coffeed
  22. dreamrealphaleth: github user account? The only request that I have is that you don't merge anything to main
  23. blueI'm stuck at "java.net.UnknownHostException: nevet-db
  24. phalethsystemd-poke-me-in-the-eyed is still prolly not a thing
  25. dreamrealPR all you want, the ops side is NOT my skill area
  26. phalethdreamreal: and you want me to do any change to that nevet repo?
  27. dreamrealphaleth: Well, here's the thing: I'm good at certain things, yeah? I fake everything else. The ops side is one of those faked things.
  28. dreamrealI have it deployed on MY server successfully, but the UI is still MIA, because, well, ops.
  29. phalethnah, but if you use docker compose that means you've everything perfectly documented
  30. dreamrealSo if you look at it and go "oh, man, this is dumb from an ops perspective" or "this is incorrect" or "here's better" I'm happy to look at PRs, I just don't want changes applied without KNOWING about them
  31. dreamrealI have everything WORKING here
  32. dreamrealbut I'd like to unblock blue
  33. dreamrealand I don't know how to describe what he's doing wrong, since it works for me
  34. phalethI'm not gonna try to change anything about the repo itself
  35. dreamrealWell, I mean, you see what I said about it :D
  36. phalethbut let me have one question, why is it on github when it's private?
  37. dreamrealbecause eventually I want it to not be
  38. phalethoh, ok, makes sense
  39. dreamrealas soon as I have a fully-working deployment, I'm copying it over to a different repo, one that isn't private, and saying "have at it"
  40. dreamrealso: pm me the github user name?
  41. blueit's the same user
  42. phalethwhatever, I guess download the repo as zip and upload it to VPS to /home/phaleth and that's all that's needed, sounds like a horror right?
  43. dreamrealphaleth: should work :D
  44. blue100%
  45. bluethe only thing that drives me nuts is the network situation, like I don't get it at all
  46. blueI thought networkd should solve that, but no
  47. bluepoettering and his daemons
  48. dreamreal"phaleth?"
  49. * dreamreal is tryna confirm before guessing in any way
  50. dreamrealmy finger's hovering over the button
  51. phalethwell, just let blue download it, I won't be able to log into github anyway
  52. phalethbut yeah, I'm phaleth on github
  53. phalethas much as you think my profile looks weird
  54. blueit's this guy https://github.com/phaleth
  55. nevetphaleth - Overview
  56. bluey'know, the guy who has the primate repo pinned on his profile
  57. dreamrealphaleth: you still on discord?
  58. phalethblue: I don't see why would you need to do anything with systemd-networkd other than restart it after you change a couple of configs for the bridge, but I've already documented that
  59. bluemhm
  60. dreamrealphaleth: I just sent it to you there
  61. phalethdreamreal: you can pm me on discord if you want, yeah
  62. bluemaybe I need to stop being lazy and not try to get it down in one script
  63. bluedone*
  64. bluebut this --network-zone flag is kinda cool, I gotta admit it
  65. nevetbut this now has karma of -1.
  66. dreamrealheh
  67. dreamrealkarma has so many freaking exceptions
  68. dreamrealthat plugin is a nightmare
  69. blueindeed
  70. phalethdreamreal: ok
  71. blueif you can just help me get it set up phaleth, I'd be so happy. I feel like a total idiot
  72. dreamrealIt has the ability to ignore manual emdashes (I just don't have that on anywhere) but detecting "program arguments" is another area of problems... and sometimes people DO want to mention "C with objects"
  73. blueI just want to test my primate frontend against it, it can't be that hard
  74. blueor well, my primate app
  75. dreamrealphaleth: and if you see what makes it difficult for blue, I want to fix that, because I don't see the holes
  76. bluehopefully all this nonsense will soon go away. I started working on @rcompat/container, so I can programmatically create and start containers
  77. blueI need it for primate itself, for testing the postgresql module, but we also need it for RP
  78. blueI've been running postgresql all this directly on the host which is legit insane
  79. blueall this time*
  80. blueI want to throw it away
  81. blueI'm still on the old computer, but I'm not willing to repeat the same mistakes on the new one
  82. phalethblue: ok, but if you at least tried to deploy it to the VPS I could take a look and see what's wrong there, also just forget about --network-zone
  83. nevetblue: ok, but if you at least tried to deploy it to the VPS I could take a look and see what's wrong there, also just forget about now has karma of -1.
  84. dreamrealblue: nevet in production is using postgres in a docker container
  85. phalethheh
  86. bluehm
  87. bluedreamreal: you fine with me uploading a copy of the nevet repo to the RP gitea?
  88. bluethat way I don't even need to run it on my computer, I can CI it on RP
  89. blue(RP gitea is private, only phaleth and I have access to it)
  90. dreamrealsure.
  91. phalethI didn't have a chance to try the CI on our gitea, but I think it should just work
  92. phalethwould be curious if it does/doesn't
  93. blueya
  94. dreamrealblue: I'm going to revisit the karma plugin to see if I can fix some of that
  95. dreamrealsome of the issues are unavoidable, period, if karma's in play, but we should be able to apply some intelligence to cut down on the false positives
  96. phalethdreamreal: the deployment looks very straightforward, even package-lock.json is included, so the build of the frontend should just work
  97. bluephaleth: https://gitea.repopack.app/jottinger/bytecode.news
  98. bluebrb
  99. phalethblue: cool, well, I thought making a zip copy would be a horror, which is what I have now, but two repos of the same project, hmm
  100. bluephaleth: the ideal is a git checkout inside the container...
  101. bluebut I don't know if you care about setting that up, wouldn't work right now with the way gitea is set up
  102. bluecan you deploy the frontend on nevet.repopack.app ?
  103. bluehe's got an experimental frontend
  104. blueI think you noticed that
  105. phalethwell the repo is private on both github and gitea so just need to get PAT (token)
  106. phalethnextjs being experimental?
  107. blueno, the nextjs one is just another one
  108. bluethere's a reference one at.. let me see
  109. dreamrealphaleth: the idea is that eventually we'll have a whole suite of front ends: nextjs, primate, xhtml, jsf, thymeleaf, etc
  110. dreamrealall with different "base hostnames" so if you wanted to use a nextjs frontend you'd hit nextjs.bytecode.news, and if you wanted to COMPARE that to primate, you could SIMILARLY go to primate.bytecode.news and see the differences
  111. dreamrealthe backend server is intended to be the same in all cases
  112. blueoh, he hasn't merged it yet
  113. blueit's pr'd though
  114. dreamrealand then there's a "bytecode.news" and "www.bytecode.news" domain that resolves to whatever frontend is the best of breed
  115. bluehttps://github.com/jottinger/bytecode.news/pull/110
  116. blueI can't get you the PR branch to gitea, if you want
  117. blueI can*
  118. dreamrealblue: nobody's even commented on it yet that I've seen!
  119. phalethI can deploy the nextjs frontend, that's fine
  120. dreamrealI have LITTLE confidence in a UI, so any UI I put together is put together with spit, nerves, fear, trembling, etc
  121. dreamrealphaleth: note that the nextjs frontend was built on a prior version of the service-blog so it's not likely to be complete or right
  122. blueI'm not srue the nextjs frontend is up to date with the backend
  123. dreamrealI'm sure it's not
  124. dreamrealthe reference in 110 is the only one that is known-good with the OTP stuff
  125. bluephaleth, I can add the primate frontend, and then you can deploy that to nevet.repopack.app
  126. bluethat good? that's what I'll work with, anyway
  127. dreamrealand now that I think about it, I bet the OIDC stuff is mandatory, that's gonna be something that NEEDS to be handled
  128. dreamrealdamn it
  129. dreamrealblue: I'm swamped right now, the OIDC stuff HAS to be configured, it may be okay with faked token values
  130. bluewhat's OIDC?
  131. blueyou mean sign with google?
  132. dreamrealthe github/google login crap
  133. dreamrealyeah
  134. blueoh
  135. phalethok, then I will deploy postgres and the java backend first
  136. dreamrealphaleth: ^^^ note the .env.default
  137. blueyeah just do that. meanwhile I'll add the primate backend though I'll be mostly blindly coding until I can run the postgres/java backends
  138. dreamrealI don't think the reference hooks in the OIDC endpoints yet but the backend won't start without them being configured
  139. dreamrealblue: note that in 110 the openapi.json is generated *as an artifact of the build* - so packaging WILL update that file, the repo shoudl always be current as a result
  140. phalethblue: alright
  141. dreamrealI don't commit until a full backend test cycle passes, and that file is generated as an artifact of that process; it's sorted in processing so diffs don't show up unless the actual API changes
  142. phalethdreamreal: ok, looks like docker compose takes care of setting up a lot of those env vars
  143. bluemostly I just need the postgtes/java to run reliably on nspawn
  144. dreamrealI don't think there would be a problem providing invalid API keys for services like the LLM, weather, google, github
  145. dreamrealthey don't get verified on startup
  146. blueplease note some of this stuff is currently built outside of the container. namely `./mvnw app`. it should move inside nspawn, ideally
  147. bluephaleth: https://dpaste.com/GWFBVPGA3
  148. phalethoh, there's maven
  149. bluethis builds everything inside buildkit
  150. blueb/c obv we don't want to need mvn on the host system
  151. dreamrealyeah, mvnw will download the proper version of maven if you like
  152. dreamrealwould have used gradle but wanted the build to work
  153. bluedreamreal: the problem is the RP server has next to nothing on the host, except nspawn itself. so anything that is needed for building, needs to be inside the Containerfile
  154. dreamreal*nod* yeah, well, maven wrapper is there for a reason
  155. blueyeah, but we don't build anything directly on the host. it would be possible to run mvnw inside the container, but also the Containerfile I linked works in the same way without the wrapper
  156. blueit built locally in 90 seconds, should be faster on RP
  157. phaleththere is an ubuntu image for that java thing, so that should run without a problem on systemd-nspawn https://paste.debian.net/plainh/259f874c
  158. nevetStarvation. The same thing.
  159. phalethhuh
  160. phalethwell, actually, I should go eat something and sleep
  161. bluealright
  162. bluephaleth: nevet sums up urls.. in this case, I have no idea where it got that from, possibly an AI hallucination
  163. dreamrealThat is FASCINATING. I think debian.net needs to be added to the ignored urls for the urltitle thing - some sites respond differently based on source and client identifiers.
  164. phalethit saw podman, it proceeded to talk to a peasant
  165. dreamrealurl ignore add paste.debian.net
  166. nevetAdded paste.debian.net to ignored hosts.
  167. dreamrealurl ignore list
  168. nevetIgnored hosts include: pastebin.com, x.com, pastebin.org, paste.debian.net, dpaste.com, bpa.st, and twitter.com
  169. dreamrealLet's try it: https://paste.debian.net/plainh/259f874c
  170. dreamrealbeauty.
  171. bluedreamreal: one of the declared goals of RP is to redeploy fast enough that developres can save themselves the hassle of a local setup; you'll notice it as soon as you want to test google oauth: it is an absolute PITA to do it locally. You need weird shenaningans like ngrok
  172. bluehaving ubiquitously reachable DEV systems is a bliss
  173. bluewhether it's doable in acceptable times, is another questions. 90s is obviously too much
  174. bluequestion*
  175. dreamrealWell, I have a system that takes 17m to build...
  176. phalethat work I take care of java system that takes ~12min to build, but only when all that is not necessary is excluded from the build, dunno how long a full build would take, prolly well over half of an hour
  177. dreamrealours does a graalvm native compile, so it's pretty serious :D
  178. phaleththat one uses ant script leading to a ton of other ant scripts and also a whole bunch of groovy script, it's totally meh
  179. phalethgroovy scripts*
  180. dreamrealant + groovy, eh. Yeah, that sounds like a horror.
  181. dreamrealwhy not ant+jelly? :D
  182. bluewelp, Containerfile / Dockerfile are generally layered, so redeployments should ideally be lightning fast. next step: hooking up primate's hot-reloading to a subdomain (doable? probably)
  183. phalethnoone can be arsed changing anything about it even tho we get huge surprises on prod system lately after each deployment
  184. dreamrealphaleth: yeah. I get it - migrating an ant build can be 100% unfun
  185. bluemaybe `npx primate --proxy-via=localhost:some-port, though you'd still need a tool like ngrok :(
  186. nevetmaybe `npx primate now has karma of -1.
  187. blueweb app is such a total and absolute pain inthe butt
  188. blueweb dev*
  189. blueor maybe primate could bridge directly, hm
  190. bluethat would be sick
  191. phalethI'd understand ant, I'm that kinda person, but the groovy stuff is not to be touched
  192. bluephaleth, do you think we can build into primate the ability to reverse proxy incoming stuff? as in, someone hits my-primate-app.repopack.app, and that gets redirected to my local dev app?
  193. bluebecause that would be beautiful
  194. dreamrealblue: BTW, I'm workshopping karma improvements
  195. blueredirected is the wrong verb, tunnelled*
  196. bluedreamreal: that's AWESOME!
  197. phalethblue: sounds like a security problem, but if you have IPv6 it's prolly doable, just maybe too complicated
  198. bluewell yes it could be a security problem, but it's also te entire business model of ngrok
  199. bluengrok does exactly that. but if you want a stable subdomain, it costs money
  200. blueif you don't, you get random-1234.ngrok.app, and changing that EVERY time you test in google's oauth client, is a total pain
  201. blueI used to have to d owith socialcloud, that wan't nice
  202. blueto do it*
  203. phalethok, maybe we can think of that later
  204. bluedreamreal: with a bit of luck, he'll get it done this week and I'll be able to get moving
  205. dreamrealthat would be awesome
  206. dreamrealI figure he'll have a lot of nasty comments like "what maroon wrote this bit" etc and that'll be 100% deserved and hopefully give me a way to fix it :D
  207. blueit's likely: he's not the guy to hold back when he sees something he doesn't like
  208. bluewhich is exactly why I like working with him
  209. bluealso, I know jack about devops
  210. dreamrealRight there with you
  211. bluefyi, this gitea situation is temporary until RP can bootstrap itself, and host git repos. we just don't want to put company secrets on github
  212. bluebut gitea in itself won't be enough, it needs a bespoke implementation
  213. bluedreamreal: does mvn do incremental builds, or how does that work? what happens if you change one line in one module, do you need to recompile everything?
  214. dreamrealIt will do incremental builds, sure.
  215. dreamrealit'll build a DAG as required
  216. dreamrealyou can turn that off, but the default behavior is to compile only things that have changed
  217. blueI'm interested in that mostly for the sake of RP; I want to reach redeployment times of <10s
  218. dreamrealit's the tests that are the problem
  219. bluewouldn't it test just the component that changed?
  220. bluealso, my idea is mostly for dev: the 'did I break stuff' comes to me before the commit. in between, you could have many redeployments
  221. dreamrealno, it runs TESTS
  222. dreamreal"you want me to run tests? I'mma run your suite" and you can control what suite/tests run, but it's expecting to be thorough
  223. dreamrealfor nevet, the actual *full build* takes about 25 seconds; the actual build with tests takes around 2m
  224. dreamrealand both of thore are from clean builds; a "rebuild" is MUCH faster but the test suite still takes a while
  225. blueI get it, but the point of quick rebuilds is to get direct feedback, during development. Think about it less as of a deployment, but as if you were changing something in your code, running it locally. You don't want to waste 2m, or even 25 seconds, every time.
  226. dreamrealI know EXACTLY what you're talking about.
  227. dreamrealI'm pretty long in the tooth.
  228. dreamrealI'm just telling you the way it is.
  229. blueNow imagine you get that feedback on nevet.repopack.app; why? Because you want to change something about oauth or anything else that requires external interaction with your app -- which is historically a catastrophe if you run it locally, due to security, firewalling, inaccessibility.
  230. dreamrealAgain, totally aware.
  231. blueThis is a real painpoint I've been struggling with for years, and I'm not the only one, otherwise things like ngrok wouldn't exist
  232. blueIt's one of THE reasons I'm working on RP
  233. dreamreal*nod*