Re: Debian Cloud Team delegation updates

[Ross Vandegrift]

On Tue, Jun 02, 2020 at 06:02:24PM +0200, Jonathan Carter wrote:
> Dear Cloud Team
>
> Tomasz has resigned from the Cloud team, have you considered a
> replacement for him in the team delegation?
>
> Do you need any assistance or help with re-staffing?

I have one idea for replacement, if the person is interested.

If that does not work out, we might need assistance.  Most of our team members
are not eligible due to the no employment and arms-length relationship
requirements of the cloud team delegation.

Ross

Nightly Builds and Continous Delivery for Vagrant Boxes plans

[Emmanuel Kasper]

Hi

Now that I have working vagrant boxes with FAI, I'm starting to look at
nightly builds and continuous delivery of boxes to the vagrant cloud
(remember the "vagrant cloud" is just a disk image registry. The VMs are
run locally on your infrastructure)

Nightly Build:
--
I set a weekly build of Vagrant boxes at
https://salsa.debian.org/cloud-team/debian-vagrant-images/pipeline_schedules
which is working fine.
The only problem is that the boxes, which are gzip'ed qcow2 images, are
over the 250MB salsa artifact limit (they are around 300 MB) and thus
cannot be saved as artifacts when the build is complete.

I understand the 250MB is not something to negociate, as owtherwise
people would have already asked terabytes of artefacts, so what do you
people would advise me ?
Push those builds to https://cloud.debian.org/images/cloud/ ?
Find a VM under .debian.net to upload the boxes ?

Continuous Delivery:

I have set up a separate project, at
https://salsa.debian.org/vagrant-boxes-admin-team/debian-vagrant-boxes-release/
where the CI job will have an API key to upload testing boxes to the
Vagrant cloud.

I plan to run in these project every two week a build, which will push
testing boxes to the vagrant cloud ( Ubuntu is doing something similar)

Should I be worried when having the API key as a masked pipeline variable ?
Anything else I missed ?

Emmanuel

PS: Thanks to all involved in the gitlab setup of the cloud images, who
provided a great source of inspiration, and the bulk of the work.

-- 
You know an upstream is nice when they even accept m68k patches.
  - John Paul Adrian Glaubitz, Debian OpenJDK maintainer

Bug#956940: EC2 images should install compatibility symlinks for NVME drives

[Noah Meyerhans]

The amazon-ec2-utils package is currently in the NEW queue and will
provide the necessary tools for examining the instance NVME
configuration and creating the requested links.

Details of that package are tracked in the ITP at
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=959066.

Debian Cloud Team delegation updates

[Jonathan Carter]

Dear Cloud Team

Tomasz has resigned from the Cloud team, have you considered a
replacement for him in the team delegation?

Do you need any assistance or help with re-staffing?

Please let me know.

thanks,

-Jonathan, Debian Project Leader

-- 
  ⢀⣴⠾⠻⢶⣦⠀  Jonathan Carter (highvoltage) 
  ⣾⠁⢠⠒⠀⣿⡁  https://wiki.debian.org/highvoltage
  ⢿⡄⠘⠷⠚⠋   https://debian.org | https://jonathancarter.org
  ⠈⠳⣄  Debian, the universal operating system.

Re: Debian VM Agent Issue

[Bastian Blank]

[ The original mail was sent to use privately ]

Hi Jared

On Tue, Jun 02, 2020 at 08:25:31AM +0200, Michael Amstadt wrote:
> I'm an engineer on the Labs Services team at Microsoft. From what I can tell 
> here , Credativ is in charge of 
> the Debian images you can find on the marketplace.  Apologies in advance if 
> I'm talking to the wrong company.

You reached the right people.  However better suited would be the public
Debian list at debian-cloud@lists.debian.org.

> My team has customers that are having issues with the Debian 10 issue. When a 
> user installs gnome on Debian 10, the Azure VM Agent dies, so we can no 
> longer perform operations on the VM.
> Any idea why this may be occurring? I tested with XFCE, and it seemed to work 
> just fine.

This is the result if incompatible dependencies in the agent and Gnome.
waagent for now requires ifupdown as the network implementation, as it
calls ifup and ifdown.  The Gnome meta-package wants to install
network-manager, which conflicts with ifupdown.

Sadly tasksel does not provide any warning that it is going to deinstall
packages.  So after the call to tasksel, waagent is not longer installed
and therefor not running.  You can install waagent again afterwards.

I don't see a solution right now within the currently existing
constraints of dependencies and recommendations, with the way tasksel
uses apt.

Regards,
Bastian

-- 
Bastian Blank
Berater
Telefon: +49 2166 9901-194
E-Mail: bastian.bl...@credativ.de
credativ GmbH, HRB Mönchengladbach 12080, USt-ID-Nummer: DE204566209
Trompeterallee 108, 41189 Mönchengladbach
Geschäftsführung: Dr. Michael Meskes, Jörg Folz, Sascha Heuer
Unser Umgang mit personenbezogenen Daten unterliegt
folgenden Bestimmungen: https://www.credativ.de/datenschutz