[adelie-project] Re: Proposal: Replacing Integricloud with Scaleway

2019-07-13 Thread Molly Miller

All,

I have a couple of things I'd like to say in response to both the 
original post and some of the points raised in the replies by Kiyoshi 
and Luis. I've been using Scaleway's virtualised services for nearly two 
years now (first with a pair of small x86_64 machines for personal use, 
and more recently an aarch64 machine for Adélie development work), so I 
have some operational experience which I'd like to share, and I also 
broadly agree with the points regarding shared tenancy of physical 
hardware.


Please excuse the thread-breaking, but I wanted to make sure this gets 
copied to adelie-infra properly. I'm also a bit over-caffeinated as I'm 
writing this, so apologies if it gets a bit rambly or hard to follow.


-

First, the OP:

On 2019-07-13 10:56, A. Wilcox wrote:

Scaleway offers a similar level of reliability, and has a higher level
of availability based on our current account with them.  They
additionally offer servers that are not based on the x86 architecture,
so we are still protected from the numerous issues that plague x86.


Scaleway's business focus has shifted over the past year or so; they are 
no longer pushing ARM cloud services anywhere near as much as they used 
to, and now seem to be more interested in providing managed services in 
a similar vein to AWS. As such, there's limited capacity on their ARM 
cloud (which I believe they are no longer expanding), which could 
potentially cause issues in securing the resources necessary for a 
migration.


We have had a working relationship with Scaleway for almost a year and 
a

half.  We launched our 32-bit ARM builder on the Scaleway ARM cloud in
March 2018, and have had no downtime in that time:


I assume this is one of the dedicated ARMv7 machines (as all of 
Scaleway's other ARM services are ARMv8 from what I know). I haven't 
ever used any of those machines, but I'm pretty sure they are very 
different beasts from the virtualised ARMv8 services.



The network has never suffered any outages, either.  Since the Scaleway
cloud features ARM servers, we would additionally still be able to 
avoid

the x86 architecture and all of its failings.


I can't recall any particular dates, but from offhand experience 
Scaleway's network (at least the virtual machine estate in Amsterdam) 
has *definitely* suffered availability issues. (I can't speak for 
Scaleway's Paris network, which I'm assuming is more substantial.) I 
must stress, however, that these issues are nowhere near as bad as 
Integricloud's -- just don't expect perfection, because you'll be 
disappointed. For what it's worth, in my experience any of the brief 
network issues have disrupted IPv6 connectivity more than they have 
disrupted IPv4 connectivity.



We have continually been limited by our lack of IPv4 space at
Integricloud.  Currently, we "proxy" every server via athdheise, a
virtual server on our Integricloud dedicated system that has both an
IPv4 and IPv6 address.


(This is an aside, but I've worked in an environment which has 
successfully operated services from an IPv6-only network, with a 
dual-stacked reverse proxy at the network border to handle connections 
from IPv4-only clients. The border gateway ran Haproxy, which is capable 
of selecting backends based on server name indication in TLS handshakes; 
as the SNI is sent before any key exchange is performed, the gateway 
machine did not need access to any private key material, and could be 
used for any protocol which runs over TLS and uses SNI.)



If we use Scaleway virtual servers, every system gets its own dedicated
IPv4 address, which drastically simplifies our administration.


Scaleway's network configuration is weird for virtual machines -- I'll 
get to that in my operational experience spiel in a bit.



Additionally, we would receive a lot more RAM per virtual server.


More RAM is always better -- the RAM which our Integricloud machines 
currently have is eye-wateringly small.



Finally, we would save a dramatic amount of money.  We currently pay
225$/mo pre-tax for Integricloud.


Saving money is also good.


The current systems we run on Integricloud are:



I agree strongly with Kiyoshi here -- though I'm not so keen on having 
personal resources under the adelielinux.org banner, I won't object if 
they're made available for use by other contributors.


-

I have some points to add to what Luis said:

On 2019-07-13 16:58, Luis Ressel wrote:
I strongly agree with Aerdan here. In my opinion, the risks of moving 
to

VPSes on hardware shared with other tenants outweight all (perceived or
real) benefits of using aarch64 instead of x86.


The place I mentioned above with the IPv4-to-IPv6 gateway also provided 
virtualised hosting services, and I interacted with their systems for 
provisioning and managing customer VM's on a number of occasions. It's 
*really easy* for the party which controls the host to reboot a guest 
into a rescue 

[adelie-project] Re: Splitting debug packages into separate repositories

2019-07-01 Thread Molly Miller

On 2019-07-01 17:08, A. Wilcox wrote:

I would like to formally suggest that we take our -dbg packages and put
them in a split repository, such as system-debug and user-debug.

Non-stratum 1 mirrors could choose whether or not to mirror these as
well.  This would take a significant amount of disk space pressure off
of stratum 2/3 mirrors.


+1.


So, the overall size reduction would be about 20 GB per architecture.


Reducing e.g. the 1.0-beta3 package set by 80GB (as a low-ball estimate) 
would reduce the repository to about 40GB in size, which makes hosting 
multiple different versions concurrently a much more feasible prospect 
for potential stratum 2/3 mirror providers.


--mm.
___
Adélie Open Governance mailing list -- adelie-project@lists.adelielinux.org
To unsubscribe send an email to adelie-project-le...@lists.adelielinux.org


[adelie-project] Re: Project Proposal: Infrastructure Group

2019-06-18 Thread Molly MIller

On 2019-06-17 23:31, A. Wilcox wrote:

This is a formal request for the creation of a new Project, as defined
in the Organisation Charter.


+1

--mm.
___
Adélie Open Governance mailing list -- adelie-project@lists.adelielinux.org
To unsubscribe send an email to adelie-project-le...@lists.adelielinux.org