el
please ?
In the source package of the kernel, I can read in:
debian/config/config.cloud:
## file: fs/ocfs2/Kconfig
##
# CONFIG_OCFS2_FS is not set
how do I change this?
Cheers,
Thomas Goirand (zigo)
]
+ * Fix copy_exec /bin/udevadm /sbin (Closes: #1035920).
+
+ -- Thomas Goirand Wed, 24 May 2023 13:16:27 +0200
+
cloud-initramfs-tools (0.18.debian12) unstable; urgency=medium
[ Martin Pitt ]
diff --git a/growroot/hooks/growroot b/growroot/hooks/growroot
index 5d06aa8..a8ee1ab 100644
I'll upload it soonish...
(from my phone)On Feb 18, 2023 06:49, Martin Pitt wrote:
>
> Hello Santiago,
>
> Santiago Vila [2023-02-18 0:26 +0100]:
> > Martin Pitt wrote:
> > > The "flock: not found" is #1014662, but that is already present in our
> > > current
> > > image with
cat we install
grub-efi-amd64-signed on the image then?
Bastian, I'm sure you have the info, especially concerning grub...
Cheers,
Thomas Goirand (zigo)
/cloud-init/pull/1490
and we would love to get this in the next version of cloud-init,
especially if it can reach Stable. If so, then we can make a working
rescue image for Debian.
Could we wait until upstream accepts the patch, maybe?
Cheers,
Thomas Goirand (zigo)
that I'll be able to join, as I'll be at the
OpenInfra summit (the new name for OpenStack summit).
Cheers,
Thomas Goirand (zigo)
, looking forward to
hearing your thoughts.
-Jonathan
Thanks for your input.
Cheers,
Thomas Goirand (zigo)
. Excluding them from
consideration for our DPL delegations removes key members from our pool
of candidates for this role and does not provide any benefit that can't
be attained using less drastic measures.
noah
Agreed. Ross, can you reconsider? Johnathan, your thoughts?
Cheers,
Thomas Goirand
. There's also a hook for it (see the
end of the man page for that).
These days, I use it mostly for setting-up bare-metal servers, but it's
perfectly valid for building images. I use it also for automating the
process of building images for Octavia and Manila.
I hope this helps,
Cheers,
Thomas
paying me for the meeting, though it's harder to explain the
off-hours work time), like 16:00 (French time), but it likely doesn't
fit Bastian's preference.
Cheers,
Thomas Goirand (zigo)
.
Cheers,
Brett Holman
Hi Brett,
Reading the source of cloud-init (ie: debian/control), prettytable and
six are only build-dependencies. Was this what you meant?
Cheers,
Thomas Goirand (zigo)
explanation of what was going on, which is the bare minimum in any
standard...).
Waldi, if it's you who triggered the current events, thanks for it,
indeed, it was kind of dangerous to keep things as they were.
Let's hope this all solve soon.
Cheers,
Thomas Goirand (zigo)
? Maybe we should set a deadline for ourselves?
Cheers,
Thomas Goirand (zigo)
P.S: Sorry I missed the last meetings, I'll make sure not to miss the
next one.
shlist". Please
note that this has no consequence on if, how or when we are going to
address this bug.
Cheers,
Thomas Goirand (zigo)
1 criticalmakes unrelated software on the system (or the whole
system) break, or causes serious data loss, or
eam/cloud-initramfs-tools
then ping me again in this bug.
Cheers,
Thomas Goirand (zigo)
with something unrelated in tests... :(
I don't think I'd mind so much removing heat-cfntools from Debian. I'm
not sure if it's still even maintained upstream. The last release was in
2016 ... I've just asked the OpenStack mailing list.
Cheers,
Thomas Goirand (zigo)
On 11/8/21 7:27 PM, Noah Meyerhans wrote:
> On Mon, Nov 08, 2021 at 02:58:55PM +0100, Thomas Goirand wrote:
>>> Our next team meeting is scheduled for Wed, Nov 10. But there's been a
>>> request
>>> for adjusting the time to 20:00UTC. Is anyone *unab
I've uploaded the fix to
unstable already. However, I'm not sure why oldstable should be updated.
Can you share your view?
Cheers,
Thomas Goirand (zigo)
4.qcow2
Hi,
Do not use that image, it's known to be broken. Please use something
newer than this one, where the commit was reverted.
Cheers,
Thomas Goirand (zigo)
n user. But permissions can be specified on
>> separate projects. That might work.
>
> Good.
>
> Paul
>
Hi,
Huawei should be using OpenStack. Could we use such an account to test
the OpenStack (ie: Generic / Genericcloud) images of the cloud team?
This would mean having the possibility to upload Glance images and boot
them up...
Cheers,
Thomas Goirand (zigo)
Hi Bastian,
Thanks for replying.
On 7/30/21 10:03 AM, Bastian Blank wrote:
> Hi
>
> On Wed, Jul 28, 2021 at 05:22:43PM +0200, Thomas Goirand wrote:
>> - Initial boot:
>> 2021-07-28T12:26:38.804683+00:00 pub1-network-3 dnsmasq-dhcp[3765807]:
>> DHCPSOLICIT(tap67fa8c
On 7/30/21 3:57 PM, Jeremy Stanley wrote:
> On 2021-07-30 11:00:02 +0200 (+0200), Thomas Goirand wrote:
> [...]
>> By default, OpenStack will, through cloud-init, populate /etc/hostname
>> with the server name you choose when doing:
>>
>> openstack server c
t discuss the severity: let's try to fix it.
Cheers,
Thomas Goirand (zigo)
osed, so I thought it was fine to do
it without more discussion.
Do you guys still think it should be reverted? I don't...
Aren't the other cloud providers affected by the same kind of behavior?
Cheers,
Thomas Goirand (zigo)
Hi Noah,
Thanks for your answer.
On 7/30/21 1:54 AM, Noah Meyerhans wrote:
> Control: severity -1 important
>
> Please see https://www.debian.org/Bugs/Developer#severities
>
> On Wed, Jul 28, 2021 at 05:22:43PM +0200, Thomas Goirand wrote:
>> After spawning a VM, it tak
ably need to get ifupdown to use the -D LL option
explicitely, but I'm not sure how to do this... Does ifupdown even has
an option for forcing that? It doesn't seem to be the case. :/
Any help or comment would be welcome.
Cheers,
Thomas Goirand (zigo)
ly/-/merge_requests/33
Cheers,
Thomas Goirand (zigo)
On 7/22/21 2:49 PM, Noah Meyerhans wrote:
> On Thu, Jul 22, 2021 at 11:15:23AM +0200, Thomas Goirand wrote:
>> In commit 522055bf, I added
>> config_space/files/etc/cloud/cloud.cfg.d/01_debian_cloud.cfg/GENERICCLOUD
>> and
>> config_space/files/etc/cloud/cloud.cfg.d/
generated OpenStack images. However,
after checking the last build, this file still doesn't exist in our
daily image.
What am I missing?
Cheers,
Thomas Goirand (zigo)
On 7/1/21 5:19 PM, Bastian Blank wrote:
> Control: forcemerge 942325 -1
>
> Hi
>
> On Thu, Jul 01, 2021 at 05:07:26PM +0200, Thomas Goirand wrote:
>> As per the subject line, /etc/hosts isn't updated
>> when the machine boots on OpenStack. However,
>>
,
Thomas Goirand (zigo)
On 5/15/21 3:19 PM, Thomas Goirand wrote:
> On 5/12/21 11:20 AM, Thomas Lange wrote:
>>>>>>> On Wed, 28 Apr 2021 09:53:02 +0200, Thomas Lange
>>>>>>> said:
>>
>> > Hi,
>> > I've created a proposal for updati
/
>
> The text is now updated.
Thanks for it.
I opened this MR to explain how to upload to OpenStack the best way:
https://salsa.debian.org/images-team/setup/-/merge_requests/1
Cheers,
Thomas Goirand (zigo)
t this will ever be done.
There's a lot of room from improvement in what I wrote, which I feel is
very hackish. For example, openstack-debian-images-updater would need to
check for the artifact's GPG signatures. Though it's doing the job, and
it's good enough for what I need. I just hope it will hel
On 4/29/21 7:37 AM, Ross Vandegrift wrote:
> On Wed, Apr 28, 2021 at 10:14:15PM +0200, Thomas Goirand wrote:
>> Could you guys read the patch, at:
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=868875#33
>>
>> Do you think it should be merged ASAP, a
it without a 2nd opinion on this. Your thoughts?
Cheers,
Thomas Goirand (zigo)
the
> average user today is probably only going to have an account in a
> single provider and/or will otherwise likely be fine with the image
> that provider spoon-feeds them, "multi-cloud" is becoming a hot
> topic and normal users are turning into power users who will need
> similar solutions in the long run.
That's also a use case for such automatic image upload/update. :)
Cheers,
Thomas Goirand (zigo)
On 4/28/21 9:53 AM, Thomas Lange wrote:
> Hi,
>
> I've created a proposal for updating the header seen in
> https://cloud.debian.org/cdimage/cloud/
>
> You can see it here
> https://public.cs.uni-koeln.de/lange/images-cloud-HEADER.html
>
> Any comments welcome.
Hi Thomas,
Thanks for this.
Is
ut this (yet?).
Finally, I'm still unsure what I should do, but I know I must something
for this. I'll keep the team posted.
Cheers,
Thomas Goirand
st because I don't agree with the rest
> of the team and the current setup?
Or what if you where using your salsa admin hat to remove some of the
cloud team members of their privilege, and unilaterally reject new
members from coming in? Oh shit, you did that 2 years ago... :)
Cheers,
Thomas Goirand (zigo)
Hi Ross,
Thanks for your very nice answer.
On 4/27/21 8:22 AM, Ross Vandegrift wrote:
> Hello,
>
> Sorry you're feeling frustrated - your message raises some good points, and
> some things that I think are worth a second look.
>
> On Mon, Apr 26, 2021 at 10:40:25PM +0200, Th
the octavia-agent package
has wrong dependencies. I do not contest this, I'm saying that the
timing is very bad, and that at this point in the Bullseye release
cycle, I will *not* be able to fix this. Apart from the "hey too many
dependencies", I haven't heard any other critics.
I cannot afford to wait for another Debian release cycle, so either this
happens within the team (then great), or I *must* (as in: my boss wants
this...) fix it another way. I do not want that "other way" to be done
in private, and I will share it as free software.
Again, I feel very uncomfortable to write all the things in this
message, and feel like it's showing personal failure. I hope I could
figure out how to fix things, but years are passing, and I'm not. So
it's probably the time to investigate taking other actions. Please rest
assured that I have only good intentions, and that the years with things
stalled regarding what my objectives is showing it.
Cheers,
Thomas Goirand (zigo)
a? Or open a new debian.net hostname,
and do it unofficially? Or generate only unofficial Octavia images? As
Bullseye is coming, I'm leaning toward doing everything by my own.
Your thoughts? Nothing is written into a stone yet, I will try (again)
to listen to advice, as I really feel lost in the team at the moment.
Cheers,
Thomas Goirand (zigo)
y, just send a patch, and someone (probably me) will add it to
the current package, then ping the Stable release team to ask if they
find it acceptable for Buster.
Cheers,
Thomas Goirand
ive shell.
That's why many are using Terraform.
Cheers,
Thomas Goirand (zigo)
All this being said, it's very nice from Google to propose some compute
power sponsorship. Thanks a lot.
Cheers,
Thomas Goirand (zigo)
me that won't have a significant impact on the cost.
>
> Jelmer
Did you try asking the DSA team?
Did you ask the DPL for funding this?
Cheers,
Thomas Goirand (zigo)
ess.
As for Generic vs Genericcloud, indeed, what changes is the kernel. The
idea behind the Generic image is that the image can be used with Ironic,
on baremetal hardware, where the Genericcloud may not.
I hope this helps,
Cheers,
Thomas Goirand (zigo)
rity. The most important part: there's
no way to tell when one needs to upload a new image, we just got daily,
with no clue to what point release they match, and security fix they
address. A folder named "20210208-542" gives no information...
If we address that, then I don't mind dropping my old images.
Cheers,
Thomas Goirand (zigo)
SD I use for the system
can be /dev/sdc and /dev/sde if I reboot...
So grub should adopt a new strategy. Like for example, accepting device
UUIDs or block device serial numbers as identifiers.
This could well be in another bug report, if someone hasn't opened it yet.
Cheers,
Thomas Goirand (zigo)
installing "real" systems. So in the
> cloud.d.o context that's safe, but probably not as a generic default in
> FAI and other tools.
Unfortunately, the image *must* be able to work with multiple drivers
(see my example with virtio-blk and virtio-scsi). The safest approach
was to ha
> Thanks
> noah
>
Hi Noah,
Thanks for this work. I'll try to test the new image when it's there.
Cheers,
Thomas Goirand (zigo)
We could build and distribute Debian images ourselves, but Official
> ones would be ones that you publish?
Yes, and built within our infrastructure.
If your system is using the s3 API, I believe there's some s3 clients in
Debian already (s4cmd, for example), so publishing shouldn't be a problem.
Cheers,
Thomas Goirand (zigo)
wrong with this thinking, let me know.
Cheers,
Thomas Goirand (zigo)
Hi,
To me it looks like an issue in python-httpretty. I'll try to fix
httpretty and rebuild cloud-init, then probably close this bug.
Cheers,
Thomas Goirand (zigo)
therefore, the hostname couldn't be resolved even within the VM
itself. I'm not sure if this is related or not, however.
IMO, this is of severity grave, because the image is not usable without a
tweak (ie: impossible to login).
Cheers,
Thomas Goirand (zigo)
u don't understand as
well why the db-sync isn't working?
Cheers,
Thomas Goirand (zigo)
anifest and compare it to what's
in security.debian.org, to make sure we filter produced images for
stable and get them published only when needed.
Hopefully, this isn't just a letter to father Christmas and I'll manage
to get this a higher priority than other
also-super-important-stuff-at-work... :/
Cheers,
Thomas Goirand (zigo)
e to do. :)
Again, I wont be able to try before Victoria is released upstream.
Cheers,
Thomas Goirand (zigo)
for DHCP over IPv4 before reading the
metadata?
Anyway, once OpenStack Victoria is out (mid-october), and I get it
packaged, I'll be able to test all of this.
Cheers,
Thomas Goirand (zigo)
On 8/23/20 11:49 PM, Thomas Goirand wrote:
> Hi,
>
> Please write items of the agenda of the BoF in here:
> https://pad.online.debconf.org/p/15-cloud-images-bof
>
> My idea was to push most important items first, then we see how far we
> can go.
>
> Can someone volu
wrote a bit, but that's clearly not enough.
I wrote other stuff on that etherpad, but feel free to add more, and
move things downward if you think they are less important.
I'm not really sure I want to be the talk master, maybe that's the role
of the delegates?
Cheers,
Thomas Goirand (zigo)
On 8/14/20 8:02 AM, Ross Vandegrift wrote:
> Could it be the GPT partition table at the end of the disk?
Right, that's probably the issue. I wonder, what is the way around this.
Thomas
e_all()
db.session.commit()
have no effect, and I don't understand why. Arthur hasn't follow-up on
this. Does any of you has the time to look?
Cheers,
Thomas Goirand (zigo)
Hi Ross,
Thanks for your reply. If everyone is ok with Salsa's CI, good then, I
wont complain about it again. Though still this point:
On 8/11/20 1:04 AM, Ross Vandegrift wrote:>> the most blocking>> point
being that it is impossible to save an artifact bigger than 256MB.>>
This prevents me from
On 8/10/20 11:21 AM, Thomas Lange wrote:
>>>>>> On Fri, 7 Aug 2020 18:49:14 +0200, Thomas Goirand said:
>
> > I don't think we need image as small as possible, to the last bits.
> > Quite the opposite, to make the resize-at-boot possible, we need to
On 8/7/20 8:28 PM, Jeremy Stanley wrote:
> On 2020-08-07 18:49:14 +0200 (+0200), Thomas Goirand wrote:
> [...]
>> At this point, we see that it is bad in many regards, the most blocking
>> point being that it is impossible to save an artifact bigger than 256GB.
>> This p
g was because of Serpent, who's not part of
the team anymore. Is there anyone else for who a late afternoon (to be
US timezone inclusive...) meeting wouldn't be convenient?
Cheers,
Thomas Goirand (zigo)
On 8/2/20 1:15 PM, Bastian Blank wrote:
> On Sun, Aug 02, 2020 at 12:49:43PM +0200, Thomas Goirand wrote:
>> The last point release of Buster was released with cloud-init
>> 20.2-2~deb10u1. So it doesn't make sense to keep 20.2-2~bpo10+1 in
>> official backports anymore.
>
Hi,
The last point release of Buster was released with cloud-init
20.2-2~deb10u1. So it doesn't make sense to keep 20.2-2~bpo10+1 in
official backports anymore.
What's the procedure to get it removed?
Cheers,
Thomas Goirand (zigo)
, that being
with MySQL or postgress.
Can someone have a look and see why it's not working? I've tried to
trace it, and it goes up to connecting the db (so the config file
parsing thing works), but I couldn't go further...
Arthur, do you have any idea what I missed?
Cheers,
Thomas Goirand (zigo)
Hi,
As per the subject line, I've done it.
Thomas Goirand (zigo)
On 6/9/20 3:46 PM, Bastian Blank wrote:
> On Tue, Jun 09, 2020 at 02:57:14PM +0200, Thomas Goirand wrote:
>> In OpenStack, there's the possibility to rescue instances with a special
>> image made for it.
>
> You mean this? https://docs.openstack.org/nova/latest/user/rescue.h
arted, mbr,
kpartx, dosfstools, e2fsprogs, qemu-utils, scrub, testdisk, scalpel,
gpart, gddrescue, foremost, ddrutility. Anything else?
Your thoughts? Should this be discuss in our meeting?
Cheers,
Thomas Goirand (zigo)
how productive they'll be.
> Rehashing mailing list discussions is not interesting, but if we can
> discuss specific details or unsolved problems, that could be worth it.
Indeed.
> And I guess delegation stuff...
Also.
Cheers,
Thomas Goirand (zigo)
On 6/8/20 2:55 PM, Thomas Lange wrote:
>>>>>> On Sun, 7 Jun 2020 00:26:10 +0200, Thomas Goirand said:
>
> > It'd be really great if you could implement this. I tried quickly to do
> > that on images produced by the team, but also failed quickly and ga
tion 1 which is always at the end of the raw disk.
Cloud-init takes care of resizing when time image boots, so it's safe to
have a smaller image. We still need a bit of free space to allow:
- the resize itself
- the VM to boot while the resize isn't finished
Cheers,
Thomas Goirand (zigo)
On 6/6/20 12:11 PM, Bastian Blank wrote:
> On Wed, May 27, 2020 at 09:43:01AM +0200, Thomas Goirand wrote:
>> On 5/26/20 9:26 PM, Bastian Blank wrote:
>>> Please show me this existing 512MB image you are talking about. At
>>> least right now it does not exist. T
ph (ephemeral backend or boot
> | from volume), please use the raw image format within Glance.
If you've read this, then you got the point. I don't get why you're
continuing to reply then.
Cheers,
Thomas Goirand (zigo)
ct of
interest. Even more, if we were to say: let's break the rule
temporarily, until we have a better option, then I'd find it more
acceptable.
For the record, I would trust someone like Noah, because I've seen who
he is, and trust him. But that's *not* what we're discussing here.
Cheers,
Thomas Goirand (zigo)
On 6/4/20 12:54 AM, Noah Meyerhans wrote:
> On Thu, Jun 04, 2020 at 12:42:47AM +0200, Thomas Goirand wrote:
>>> IMHO, this requirement makes more difficult to find as someone from the
>>> people, as AFAIK many of us are working in a way for a cloud provider,
>>> or
e have Debian Developpers working for Ubuntu, Redhat, Prodigy, Kali in
> the past and present, and it mostly goes fine.
And? I don't see how this relates to the discussion.
Cheers,
Thomas Goirand (zigo)
On 5/29/20 7:14 PM, Brian King wrote:
> Hello Jeremy,
>
> Thanks for pointing us in the right direction!
>
> On 2020-05-29 15:07:10 +0200 (+0200), Thomas Goirand wrote:
>> Isn't the DNS search thing coming from DHCP rather than cloud-init?
>
>>> Last I
rather than the
OpenStack list.
Anyways...
Isn't the DNS search thing coming from DHCP rather than cloud-init?
Cheers,
Thomas Goirand (zigo)
On 5/27/20 12:18 PM, Yanhui He wrote:
> Package: cloud-init
> Version: 18.3
> X-Debbugs-CC: h...@vmware.com, pengpe...@vmware.com, yanh...@vmware.com
>
> Perl GOSC & Cloud-init GOSC have been tested in Debian 10.4.0 Desktop &
> Non-Desktop. And Debian 10.4.0 Non-Desktop cloud-init GOSC are
On 5/26/20 9:26 PM, Bastian Blank wrote:
> On Tue, May 26, 2020 at 10:29:17AM +0200, Thomas Goirand wrote:
>>> The images have 700-800MB of space used, which is still three times the
>>> size of the qcow2 file. Why do you refuse to use what's already there?
>>
>
On 5/27/20 4:50 AM, Ross Vandegrift wrote:
> On Mon, May 25, 2020 at 07:12:15PM +0200, Thomas Goirand wrote:
>> On 5/25/20 5:43 PM, Ross Vandegrift wrote:
>>> I don't think it's obvious how to do better. The only ways I know to
>>> make a raw image smaller than its fs
On 5/25/20 7:36 PM, Bastian Blank wrote:
> On Mon, May 25, 2020 at 02:21:48AM +0200, Thomas Goirand wrote:
>>>> So I was wondering if we could:
>>>> 1/ Make the resulting extracted disk smaller. That'd be done in FAI, and
>>>> I have no idea how that would
On 5/25/20 5:43 PM, Ross Vandegrift wrote:
> On Mon, May 25, 2020 at 02:21:48AM +0200, Thomas Goirand wrote:
>> On 5/24/20 11:39 PM, Bastian Blank wrote:
>>> On Sun, May 24, 2020 at 11:26:40PM +0200, Thomas Goirand wrote:
>>>> So I was wondering if we could:
>&g
On 5/24/20 11:39 PM, Bastian Blank wrote:
> On Sun, May 24, 2020 at 11:26:40PM +0200, Thomas Goirand wrote:
>> The bigger the image is, the longer it will take to copy, which is an
>> operation that OpenStack can do before spawning an instance.
>
> And you setup instance t
How can we fix this?
Your thoughts?
Cheers,
Thomas Goirand (zigo)
sure if boto3 is still a thing these days. If
I'm not mistaking, it used to be a fork for supporting Py3, but now,
boto itself supports it. Can someone confirm what I'm saying as I am not
100% sure of that?
Cheers,
Thomas Goirand (zigo)
P.S: Thanks for the work Noah.
On 5/16/20 12:35 PM, Debian FTP Masters wrote:
>
>
> python-boto_2.49.0-3.dsc: Invalid size hash for
> python-boto_2.49.0.orig.tar.gz:
> According to the control file the size hash should be 1478237,
> but python-boto_2.49.0.orig.tar.gz has 1478104.
>
> If you did not include
something like this work?
octavia bullseye amd64 build:
extends: .generic build
variables:
CLOUD_ARCH: amd64
CLOUD_RELEASE: bullseye
CLOUD_VENDOR: octavia
Cheers,
Thomas Goirand (zigo)
On 4/4/20 5:42 PM, Noah Meyerhans wrote:
>> So, when I'm being asked about it, my answer from an OpenStack operator
>> point of view, is always a big "NO !". I want to be able to service my
>> compute nodes. This means being able to live-migrate the workload away,
>> otherwise, customers may
l modules we generate for 9P and VHOST_SCSI.
>
> So, I think the answer for these specific requests can be affirmative.
> The cost is small enough that if these features are useful to somebody,
> then we might as well enable them.
>
> noah
Thanks for taking the time to investigate.
+1 to what you wrote.
Cheers,
Thomas Goirand (zigo)
O !". I want to be able to service my
compute nodes. This means being able to live-migrate the workload away,
otherwise, customers may notice.
Cheers,
Thomas Goirand (zigo)
ge is very
much welcomed, as we decided during the sprint?
Cheers,
Thomas Goirand (zigo)
not only limited to growpart).
Cheers,
Thomas Goirand (zigo)
On 3/7/20 11:53 PM, Thomas Goirand wrote:
> So in case we'd be removing this dependency to satisfy your container
> use case (which is IMO very valid), we should carefully re-add a
> dependency on cloud-utils in our VM images.
If I may add if it wasn't obvious with what I wrote: our
1 - 100 of 335 matches
Mail list logo
