staging and dev environments

[Regina Obe]

> On Thu, Sep 11, 2025 at 11:22:13AM -0400, Regina Obe wrote:
> > Sandro Santilli wrote:
> > >
> > > I'll rephrase: do we need 2 stages in OSGeo infrastructure ( DNS/Ansible ) ?
> > >
> > > DNS:
> > >
> > >   *.staging.osgeo.org
> > >   *.dev.osgeo.org
> >
> > We can have just one is fine with me and we'd use it both for development
> and staging.
> 
> +1, so can we drop *.dev.osgeo.org DNS records as soon as
> https://trac.osgeo.org/osgeo/ticket/3419 is completed ?
> 
> At the moment we have these:
> 
>   *.dev
>   dev.geodata (proxied but missing an SSL certificate, says Cloudflare warning)
>   dev-nextcloud
> 

Fine I don't even recognize the above items.

> > It is only an issue if we have two things going on at the same time.
> > E.g. we are trying to make major changes to the theme and also need to
> test upgrades for current.
> 
> We could have many things going on at the same time...
> That's where I think the "local" dev environment should be used.
> A local dev env could probably also have a local DNS (LXD allows for this I
> think?)
> 
> Having multiple staging at the same time I don't think is a good idea, as staging
> serves the purpose of testing if something is ready to become production.
> 

That's why I wanted one to be called dev cause having two stagings would be confusing😊

> > I can't see a reason why I'd ever want a dev inside an even osgeo4-ansible-
> dev.
> 
> To test deployments, I'd say. Ansible allows you to define *WHERE* to deploy
> things, so it's good to test that your changes in the deployment file would
> work...

Deployments of what?  How would I test it truly works if it has no site associated with it.
Wouldn't I still want to use staging?

> 
> > 1) Remember we tried nested nesting nesting and last we tried it
> > didn't work too well
> 
> When I first implemented the dev environment it did work for me.
> It's failing now because Debian-10 is not available anymore as an
> image: https://trac.osgeo.org/osgeo/ticket/3434
> 
> > Cause you need 3 levels of nesting for the local computer setup you were
> proposing.
> 
> There is a way to make it work (worked for me), we just need to document it
> in the README.
> 
> > This case we can probably work around by creating ansible-dev as a VM
> rather than as a container then I think the nesting issue goes away.
> 
> Fine with me to use a VM on the OSGeo infra, if really needed (to be
> confirmed).
>

It worked for you I think because you had one less level of nesting than I did as I recall.
You had lxd installed on your dev box directly and then you had your deployment of dev hosts on that and then the containers within that.

Level 1: Strk box 

Level 2: Dev-osgeo-4, dev-osgeo-3
  
Level 3:  C1, c2              c3, c4

I had 4 levels of nesting

Level 1: Osgeo4 host
Level 2: ansible-dev 

Level 3: dev-osgeo-4, dev-osgeo-3
  --- oops can't do
Level 4:  C1, c2              c3, c4

So I think the ultimate issue was I had one extra level of nesting than you had.


Again I really don't see the joy in having skeleton containers that have nothing useful in them.
So your whole dev idea was totally lost on me.  E.g. your fake osgeo-whatever doesn't mirror the true host with the various zfs partitions etc.


> > 2) Wordpress without data is pretty useless for most development and even
> upgrade testing.
> 
> I disagree on this, I can think of many things that can be tested without data

Like what?  All the tests I've ever cared about, e.g. replicating issues that were happening in production could not be replicated without data.
And restoring takes way longer to do than copying a snapshot of a container and I won't be missing anything if I copy the container and the process
As copying a snapshot of a container/vm is pretty much exactly the same regardless of service (save for port opening etc).


> in any case the ability to copy data from one running service to another would
> be very useful to implement somehow, for various needs
> (testing/mirroring/migrations).
> 
For testing we had that on wordpress-dev container that it could copy data from live using a mysql backup and rsync.  In that case it made sense because we were doing development and only wanted to copy some things, not everything.  E.g. just the data.

There is a feature in lxd/incus we haven't really explored for doing live migrations which would seem to be a better fit for mirroring / migrations.
I tried once but was missing some configs to do in place migration properly.  I'd rather we focus on getting that working  and leveraging that functionality, perhaps folding that into some ansible-playbook.
The live migrations stuff is already doing much of what we would be doing ourselves.