On Sat, Sep 15, 2018 at 09:54:04PM +0200, Bastian Blank wrote:
> > ### EC2 upload
> >
> > No idea yet. There is a script in our repo to create a single image.
> > But I see nothing that would handle the whole pipeline with replicating
> > and registering AMI in all the regions.
>
> Shouldn't we
Moin
I'm a bit sad that no response showed up to stuff that actually means
work. Why do we want to meet, if no one seems to be actually prepared
to do the work?
On Wed, Aug 29, 2018 at 11:54:48AM +0200, Bastian Blank wrote:
> ## What needs to be done
>
> ### Documentation
>
> I know I'm bad
On 2018-08-29 16:22:13, Luca Filipozzi wrote:
> (fixing top-posting)
Luca,
Thx a lot for your email explaining our Pov on why we want to run builds on
Casulana as wall as thx for your patience ;-)
--
|_|0|_| |
|_|_|0| "Panta
Oh silly me this was already done in the initial post it's just a matter of
automating it...
On Thu, Aug 30, 2018, 7:57 AM Paul Dejean wrote:
> Ok.
>
> Casulana's processors are haswell and to the best of my knowledge support
> nested virtualization. So it should be possible to run a gitlab
Ok.
Casulana's processors are haswell and to the best of my knowledge support
nested virtualization. So it should be possible to run a gitlab runner VM
on Casulana that can do these builds.
There might be some tinkering required on the software side to get nested
virtualization working though.
On 08/29/2018 05:28 PM, Paul Dejean wrote:
> I honestly don't get it. Why is casulana so necessary for building these
> images going forward. What kicked off this thread was me demonstrating
> that machine images could be built in gitlab on google cloud runners
> that have nested virt support.
The misconception came from my lack of experience with non aws cloud
providers. My bad.
On Wed, Aug 29, 2018, 2:21 PM Bastian Blank wrote:
> On Wed, Aug 29, 2018 at 02:40:31PM -0400, Jimmy Kaplowitz wrote:
> > On Wed, Aug 29, 2018 at 11:53:49AM -0500, Paul Dejean wrote:
> > > Second of all I
On Wed, Aug 29, 2018 at 02:40:31PM -0400, Jimmy Kaplowitz wrote:
> On Wed, Aug 29, 2018 at 11:53:49AM -0500, Paul Dejean wrote:
> > Second of all I imagine that AMIs and Google cloud images and other offical
> > proprietary format debian images are exempt from this rule, since they can
> > only
On Wed, Aug 29, 2018 at 11:53:49AM -0500, Paul Dejean wrote:
> Second of all I imagine that AMIs and Google cloud images and other offical
> proprietary format debian images are exempt from this rule, since they can
> only really be built from within the appropriate company's cloud services.
For reference here's the thread I'm referring to, it's been a while:
https://lists.debian.org/debian-cloud/2018/05/msg7.html
On Wed, Aug 29, 2018 at 11:53 AM Paul Dejean wrote:
>
> Ok well first of all, I would have liked it if someone told me from the get
> go "that's neat but official
Ok well first of all, I would have liked it if someone told me from the get
go "that's neat but official Debian vagrant boxes will never be built on
Google cloud because it's against our policy."
Instead what happened is people started talking about integrating SSO with
google cloud and similar
The latest such write-up is
https://www.mail-archive.com/debian-cloud@lists.debian.org/msg03317.html
fine, let's do top-posting
Debian-controlled server is one that is managed by DSA and is,
typically, a physical server hosted by one of our partners.
On Wed, Aug 29, 2018 at 11:35:56AM -0500,
The confusion arises in that my definition of "control over the server"
differs from yours.
I would say that a Google cloud instance I spin up from my account is "a
server I control."
You would say "you don't control the server Google does. In theory they can
go in and gain access."
So forget
(fixing top-posting)
On Wed, Aug 29, 2018 at 11:07:24AM -0500, Paul Dejean wrote:
> On Wed, Aug 29, 2018, 10:48 AM Luca Filipozzi wrote:
>
> > On Wed, Aug 29, 2018 at 10:28:27AM -0500, Paul Dejean wrote:
> > > I honestly don't get it. Why is casulana so necessary for building these
> > > images
Ok that's understandable. Question #1 who pays for this? A datacenter rack
costs money. And whoever owns the data center has physical access. The
actual computer hardware costs money not just on a one time basis either.
Where does "hardware" begin and end? Does debian need to own the rack
rather
On Wed, Aug 29, 2018 at 10:28:27AM -0500, Paul Dejean wrote:
> I honestly don't get it. Why is casulana so necessary for building these
> images going forward. What kicked off this thread was me demonstrating that
> machine images could be built in gitlab on google cloud runners that have
> nested
I honestly don't get it. Why is casulana so necessary for building these
images going forward. What kicked off this thread was me demonstrating that
machine images could be built in gitlab on google cloud runners that have
nested virt support.
On Wed, Aug 29, 2018, 10:25 AM Luca Filipozzi wrote:
On Wed, Aug 29, 2018 at 05:07:55PM +0200, Thomas Goirand wrote:
> On 08/12/2018 02:51 AM, Luca Filipozzi wrote:
> > On Sat, Aug 11, 2018 at 03:06:53PM +0200, Bastian Blank wrote:
> >> Right now this layers are:
> >> - gitlab: repository store, job scheduler
> >> - gitlab-runner: job executor
> >>
On 08/11/2018 01:53 AM, Jimmy Kaplowitz wrote:
> Similarly, I think we're all agreed on using FAI, though I haven't
> checked to see what's in Bastian's implementation.
It looks like the only person that expressed himself against FAI was
myself, and like this since the decision (which was taken
On 08/12/2018 02:51 AM, Luca Filipozzi wrote:
> On Sat, Aug 11, 2018 at 03:06:53PM +0200, Bastian Blank wrote:
>> Right now this layers are:
>> - gitlab: repository store, job scheduler
>> - gitlab-runner: job executor
>> - docker-machine: VM handling with docker and directly supported by
>>
On Wed, Aug 29, 2018 at 12:41:47PM +0200, Steffen Möller wrote:
> Is that compatible with an outreach to our Blends that have some serious
> interest
> to have images of theirs prepared in say AWS? Debian-Med comes to mind.
I would like to get our own stuff up and running first. In theory we
can
On 8/29/18 12:32 PM, Thomas Lange wrote:
>> On Wed, 29 Aug 2018 11:54:48 +0200, Bastian Blank
>> said:
> > Official builds, which can be uploaded and released, will be built by
> > the runner on casulana.d.o. This runner is selected on specially
> > triggered official
> On Wed, 29 Aug 2018 11:54:48 +0200, Bastian Blank said:
> Official builds, which can be uploaded and released, will be built by
> the runner on casulana.d.o. This runner is selected on specially
> triggered official builds.
Is this a runner on casulana or a a runner on salsa
Hi
Another update on the way to get usable builds out of our stuff. As
usual, if something is unclear, please ask. I use a lot of that stuff
daily, so I know how it works, but others will not.
Maybe someone also wants to volunteer for some of the tasks I outline.
## What have been done
Each
Hi Luca
On Sun, Aug 12, 2018 at 12:51:28AM +, Luca Filipozzi wrote:
> casulana is also used to build the CD images. Currently, the scripts
> that build the CD images execute a number of 'build jobs' in parallel,
> effectively monopoloizing the machine.
Sadly the graphs created by munin are
On Sat, Aug 11, 2018 at 03:06:53PM +0200, Bastian Blank wrote:
> Right now this layers are:
> - gitlab: repository store, job scheduler
> - gitlab-runner: job executor
> - docker-machine: VM handling with docker and directly supported by
> gitlab-runner
> - docker: runtime environment within
On Fri, Aug 10, 2018 at 06:44:50PM -0400, Jimmy Kaplowitz wrote:
> On Thu, Aug 09, 2018 at 04:11:19PM +0200, Bastian Blank wrote:
> > On casulana it only can run qemu directly. On GCE it would just start a
> > VM on the platform.
> I notice that a lot of your instructions refer to Docker, though.
On Fri, Aug 10, 2018 at 07:53:15PM -0400, Jimmy Kaplowitz wrote:
> I think you're overestimating how much disagreement there is.
I am happy to be wrong.
--
Luca Filipozzi
On Fri, Aug 10, 2018 at 11:34:12PM +, Luca Filipozzi wrote:
> It would be so very good to stop circling the two main issues that recur
> frequently: (1) building on casulana (debian-owned and operated
> infrastructure) and (2) use of FAI. The fact that we keep circling (and
> I get to be that
It would be so very good to stop circling the two main issues that recur
frequently: (1) building on casulana (debian-owned and operated
infrastructure) and (2) use of FAI. The fact that we keep circling (and
I get to be that mostly-outside-looking-in-guy in a do-ocracy world) on
these two issues
On Thu, Aug 09, 2018 at 04:11:19PM +0200, Bastian Blank wrote:
> On casulana it only can run qemu directly. On GCE it would just start a
> VM on the platform.
Ideally the workflow would work in any VM host, whether that's qemu,
GCE, GitLab CI, or AWS. Maybe with some platform-specific details in
On Wed, Aug 08, 2018 at 05:47:06PM -0400, Jimmy Kaplowitz wrote:
> > No, the main reason it isolation. The builds take some global
> > resources, loop devices, and may not return them in case of some errors.
>
> Google builds their official GCE Debian images inside transient GCE
> instances,
On Wed, Aug 08, 2018 at 05:47:06PM -0400, Jimmy Kaplowitz wrote:
> I support the goal of isolation, but transient VMs can serve the same
> purpose
This setup uses transient VM to do isolation. Isolation is the goal,
transient VM are the way to do it.
On casulana it only can run qemu directly.
On Wed, Aug 08, 2018 at 11:07:12PM +0200, Bastian Blank wrote:
> On Wed, Aug 08, 2018 at 09:29:22PM +0100, Marcin Kulisz wrote:
> > Where is this VM running (what host)? Is it on salsa or somewhere else?
> It runs on casulana.d.o.
It should be possible to even build the images on the normal
On Wed, Aug 08, 2018 at 11:47:48AM +0200, Thomas Lange wrote:
> I do not know how we want to build this whole CI stuff. I'm only the
> FAI expert. But last year we worked on this build process a little bit
> (there was this big picture on the whiteboard) and now something
> different showed up.
I
On Wed, Aug 08, 2018 at 09:29:22PM +0100, Marcin Kulisz wrote:
> Where is this VM running (what host)? Is it on salsa or somewhere else?
It runs on casulana.d.o.
Bastian
--
There is a multi-legged creature crawling on your shoulder.
-- Spock, "A Taste of Armageddon", stardate
On 2018-08-02 16:25:52, Bastian Blank wrote:
> Moin
>
> Sorry, but it took a bit longer than I anticipated for an update.
>
> I finally setup a VM on casulana, and it builds the stuff in our
> repository:
>
> https://salsa.debian.org/cloud-team/fai-cloud-images/pipelines/15397
Looks nice, thx
> On Thu, 2 Aug 2018 18:33:26 +0200, Bastian Blank said:
> Of cause, if you want to build the VM management by hand, you can do it.
> But will it integrate or do you need to replace the whole rest of the
> stack as well?
I do not know how we want to build this whole CI stuff. I'm
On Thu, Aug 02, 2018 at 05:11:30PM +0200, Thomas Lange wrote:
> This is what luca set up for openstack to create new clean VMs. We may
> want to use this for calling fai-diskimage inside the VMs when
> building the images.
Well, I don't want another single use solution. How will you hook this
Hi Bastian,
I'm not sure if you know that we have this new repository:
https://salsa.debian.org/cloud-team/qemu-vm
This is what luca set up for openstack to create new clean VMs. We may
want to use this for calling fai-diskimage inside the VMs when
building the images.
I want to avoid that
On Wed, Mar 28, 2018 at 12:09:40AM +0200, Tomasz Rybak wrote:
> OK, it's time to start thinking about integrating
> our tests. It looks like now we have 3 testing solutions:
> 1. yours
Mine is not so much a test solution but a test environment where you can
run a vm with an arbitrary image.
>
On Mon, 2018-03-26 at 21:12 +0200, Bastian Blank wrote:
> On Sun, Mar 25, 2018 at 10:15:49PM +0200, Tomasz Rybak wrote:
> > What do you mean by that?
> > I've recently been thinking about how to test our images,
> > and how to integrate test we've been working on during
> > the spring; haven't
On Sun, Mar 25, 2018 at 10:15:49PM +0200, Tomasz Rybak wrote:
> What do you mean by that?
> I've recently been thinking about how to test our images,
> and how to integrate test we've been working on during
> the spring; haven't come to any solutions yet, though.
Okay, let's outline my solution,
On Sun, Mar 18, 2018 at 03:49:48PM +0100, Bastian Blank wrote:
> - Tests for images.
>
> I'm not sure if scheduled builds should perform detail tests on all
> platforms, or if this should be restricted to releases and explicit
> triggers.
I thought about tests again. I think we should do
Hi
I again did some work on building the cloud images. I did work on how
to schedule builds, how to perform builds and how to get data where we
need it. The whole thing uses infrastructure Debian provides, the
exception is the image release step.
The components are:
- salsa.debian.org with
45 matches
Mail list logo
