deploy fedipanel #201
No reviewers
Labels
No labels
0 points
0.5 points
1 point
13 points
2 points
21 points
3 points
34 points
5 points
55 points
8 points
ambition
application-offering
ambition
configure-applications
ambition
front-end
ambition/install-applications
ambition
security
ambition
switch-host
ambition
update-applications
ambition
user-management
api service
blocked
component: fediversity panel
component: nixops4
documentation
estimation high: >3d
estimation low: <2h
estimation mid: <8h
infinite points
productisation
project-management
question
role: application developer
role: application operator
role: hosting provider
role: maintainer
security
technical debt
testing
type unclear
type: bug
type: deliverable
type: key result
type: objective
type: task
type: user story
user experience
No milestone
No project
No assignees
3 participants
kevin
lois
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
fediversity/fediversity!201
Loading…
Reference in a new issue
No description provided.
Delete branch "kiara/fediversity:deploy-panel"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Closes #101
deploy fedipanelto WIP: deploy fedipanelI haven't looked at whether it was a good configuration of the panel service, but the use of
infra/looks good to me!@ -2,2 +2,4 @@fediversityVm = {# domain = "demo.fediversity.eu";domain = "abundos.eu";# domain = "fedi201.abundos.eu";This is supposed to be the root domain of the group of machines. I think
abundos.euis correct, making the FQDNfedi201.abundos.eu. This doesn't mean that it cannot serverdemo.fediversity.euafterwards.Tbf I feel a bit weird using
abundos.eufor that, but maybe that's normal. I'd be curious to know how exactly things are done at Procolix; I know there are domainsvm02186.procolix.comor something like that, and then the actual semantic domains point to that?maybe @koen has an opinion on what domains we might use internally for the VMs? should we use e.g.
fediversity.netboth for internal VM sub-domains as well as public-facing demo deployments? or would it be preferable to separate these?Yeah, the semantics of
fediversity.eu,fediversity.netandabundos.euis unclear to me too. My understanding:fediversity.eu: production machines, mostly hosted on the Procolix Proxmoxfediversity.net: ??????abundos.eu: playground for @NiolsSo I have for now been giving a subdomain to all VMs under abundos.eu because it feels I can do whatever I want there. But maybe we should have:
fediversity.eufor user-facing stufffediversity.netfor our internal infra (that's where we'd put subdomains for each VM)abundos.eufor playing with deployments, and in particular soon playing with updating the DNS fields and everythingMoved to Fediversity/Fediversity#210.
@ -0,0 +8,4 @@panel = (import ../../panel/default.nix { }).package;in# panel = (import ../../panel/default.nix { inherit pkgs; }).package;# pkgs' = pkgs.extend (_final: _prev: { panel = package; });I guess the difference between those two options is where
pkgscomes from? Thepkgsat the beginning of this file is injected by NixOps4 and comes from the flake. I suppose../../panel.default.nixgrabs nixpkgs from thenpins/directory? Doesn't really matter, though, and I think the currently uncommented version is just fine!@ -0,0 +29,4 @@production = true;# domain = "demo.fediversity.eu";domain = "abundos.eu";# domain = "fedi201.abundos.eu";I'm not sure what
services.panel.domainis for, but if it has to do with reverse proxying or things like that, then I suppose you wantdemo.fediversity.euhere?e4fb5f289c0cf3ffdd2e0cf3ffdd2e0665a70b7cstatus: error on read-only file system i'm tryna trace
the trace seems unclear as to what it tried to write and why; will investigate.
/cc @fricklerhandwerk
I know nothing about Django, but it is a classic of recent frameworks (eg. Laravel) to have one or a few subdirectories in the project that they write their state to, generate thumbnails, etc. It's always a PITA to package properly, and often the solution that I've seen is that the package takes a
stateDiras argument and makes a symlink to thatstateDir. The downside of this is that there is a not-necessarily-live symlink in the Nix store, and that there is one version of the package perstateDir. Cleaner would be to have the package accept a configuration of where to find this directory, such that the service could set it up accordingly.thanks, think i got that one now.
the reported offending dir above is
/nix/store/...-python3.12-panel-0.0.0/lib/python3.12/site-packages/static, which matches oursettings.py'sSTATIC_ROOT = os.path.join(BASE_DIR, "static/"), which our nix module only overrode bymkDefault, presumably to facilitate overrides.new issue: `ModuleNotFoundError: No module named 'panel'`
/cc @fricklerhandwerk
edit:
WSGI_APPLICATION = 'panel.wsgi.application'seems related?d1d25117e0d5264a52a1it appears my new issue is about not having the
PYTHONPATHset, which in the shell seems covered byinputsFrom = [ package ];.for the panel module itself for example i can fix this by adding:
however, this does not yet address adding the remaining dependencies.
i tried to look for deps in
"${pkgs.python3.withPackages (_: cfg.package.propagatedBuildInputs)}/lib/python3.12/", but this seems not to cover e.g. django, which still seems reported missing.checking the nix-security-tracker codebase for further inspiration.
WIP: deploy fedipanelto deploy fedipanel@ -32,1 +38,4 @@django_4setuptools]++ cfg.package.propagatedBuildInputsThis and the above list should be equivalent
try it, i did 😭
LGTM! Have you tried deploying?
@Niols wrote in Fediversity/Fediversity#201 (comment):
yep! during the standup it was available at
demo.fediversity.eu- since then we'venixops4 apply'd other stuff. 🙈Bad Niols; bad!
This was merged, but I see nothing behind demo.fediversity.eu; is that normal? Are we missing stuff? Deployment? DNS entries?
@niols CD is a separate story, and so is separating environments
Oh, I didn't necessarily mean CD, I just meant manually - shouldn't we push the configuration to the machine, if it reaches main?
@niols sure, tho I can't prevent people from invoking it during dev for testing
Of course!