does not namespace tickets in swift under the deployment

[Evan]

The CLI writes ticket data to ticket-1, ticket-2, ...; however, you may have multiple deployments under the same tenant, or the swift deployment may be running under radosgw and thus have no concept of tenants. We write under a virtual directory that is prefixed by the juju bucket:

juju-df32a4423598acd.ubuntu-ci/ticket-1/libpng_1.2.49.orig.tar.gz

[Evan (ev)]

I didn't suggest putting this completely under the juju control bucket because I wasn't sure if we really wanted everything going away when we did destroy-environment.

[Vincent Ladeuil (vila)]

I think we want to do that rather sooner than later.

It's ~ok to have ticket buckets reused right now, but as soon as we start putting the engine in production, this will become messy very fast.

[Vincent Ladeuil (vila)]

> I didn't suggest putting this completely under the juju control bucket because I wasn't sure if we really wanted everything going away when we did destroy-environment.

Indeed, we don't want to lose all tickets when we need to do a full deployment.

That also means we don't want to use the juju bucket name either since it will change between deployments.

[Vincent Ladeuil (vila)]

That's a bootstrap issue, the bucket name for the system needs to be persistent across deployments. That means it cannot be created inside a deployment and has to provided from outside, just like the juju bucket name is.

[Evan (ev)]

The juju bucket name ("juju-df32a4423598acd") is persistent across deployments. It only changes when you change the value in environments.yaml.

[Vincent Ladeuil (vila)]

Meh. Of course, I got confused by your earlier comment about juju-destroy and my memory that juju creates the bucket if you don't provide it.

Still, re-using the juju bucket feels... unclean so I think we should mimic juju with our own bucket ?

[Chris Johnston (cjohnston)]

Maybe something as simple as a time stamp? It would reduce it down to where
two ticket #1's would need to be created at the same minute. Otherwise just
sort of random string?

On Wed, Apr 2, 2014 at 11:13 AM, Vincent Ladeuil <<email address hidden>
> wrote:

> Meh. Of course, I got confused by your earlier comment about juju-
> destroy and my memory that juju creates the bucket if you don't provide
> it.
>
> Still, re-using the juju bucket feels... unclean so I think we should
> mimic juju with our own bucket ?
>
> --
> You received this bug notification because you are subscribed to Ubuntu
> CI Engine.
> https://bugs.launchpad.net/bugs/1295363
>
> Title:
> does not namespace tickets in swift under the deployment
>
> Status in Ubuntu CI Engine:
> Confirmed
>
> Bug description:
> The CLI writes ticket data to ticket-1, ticket-2, ...; however, you
> may have multiple deployments under the same tenant, or the swift
> deployment may be running under radosgw and thus have no concept of
> tenants. We write under a virtual directory that is prefixed by the
> juju bucket:
>
> juju-df32a4423598acd.ubuntu-ci/ticket-1/libpng_1.2.49.orig.tar.gz
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/uci-engine/+bug/1295363/+subscriptions
>

--
Chris Johnston <email address hidden>
Software Engineer - CI Engineering Team
Canonical Ltd.
www.ubuntu.com

[Andy Doan (doanac)]

On 04/02/2014 10:13 AM, Vincent Ladeuil wrote:
> mory that juju creates the bucket if you don't provide
> it.
>
> Still, re-using the juju bucket feels... unclean so I think we should
> mimic juju with our own bucket ?

I don't mind the bucket name being a prefix for the ticket. But if we
don't like that, we could add a configuration value like "ticket-prefix"
to our unit-config.

[Andy Doan (doanac)]

On 04/02/2014 10:22 AM, Chris Johnston wrote:
> Maybe something as simple as a time stamp? It would reduce it down to where
> two ticket #1's would need to be created at the same minute. Otherwise just
> sort of random string?

It shouldn't be random. It would make it nice to have a some-what
consistent naming pattern so you can just pass a ticket-id to the
data-store and it will give you the proper container each time.

[Evan (ev)]

Yes, I think we should have something `juju set` on the deployment. I think tying to the juju control bucket was the wrong approach. It should have a reasonable default, like "uci-engine". The person deploying is then responsible for giving it a different name if they don't want two deployments on the same tenant, or under radosgw, sharing the swift root container.