Hi
In my environment, i do not have a clear/linear lifecycle path of LIB -->
DEV–> TEST --> PROD. I have multiple TEST environments that could be
used, for example one of the test envs could be tied to the production
release and cant be changed while the other test environments may have
different code releases that is being testes. This makes it difficult to
fit into the lifecycle model for promoting content. It would be nice if
there was some kind of branch feature.
I was wondering if others have the same issue and how they have over come
this?
Can you you have the same content view but assigned to different lifecycle
paths to save having to create more content views or would i need separate
content views for each lifecycle? Does having multiple content views
require more disk space or anything? If i did this, i would have to make
each content view the same and manage it that way to give me the control of
when contents are changed.
- Library --> DEV
- Library --> TEST1
- Library --> TEST2
- Library -> TEST3
thoughts anyone?
Hey Eric - thanks for the reply
i'm on an old version of Katello (1.5) and 1.6 Foreman.
I didn't realise that i could "promote" the content view to multiple
environments that are in different lifecycle envs. With my current
version, if all environments are in 1 linear lifecycle, i have to promote
linearly. This means that i can promote any version of the content view
to any environment, ie the latest one could be in my DEV environment while
the stable/untouched version could be sitting in one of the TEST envs. Are
there any limitations with this approach? apart from the fact that i need
to make sure what CV version is in what TEST env. The content that would
be in the assigning would be OS and vendor packages as well as vendor
puppet modules.
So if i use multiple content views - would this consume additional disk
space/resource etc for each one?
You can put the same content view in any environment. For example, you can
put Content View A version 1.0 in Dev, Test1, Test2 and Test3. This won't
duplicate or take up more disk space as symlinks are created to what
content belongs where. That is to say, once you async a specific RPM down
to the system that is the only copy of it that will exist.
The API and in 2.3 of Katello, the UI, allows environments to be skipped
when promoting. We will still suggest a linear path, but if you made Lib ->
Dev -> Test and wanted to promote a content view from Lib to Test, you
could.
Eric
···
On Tue, Jun 2, 2015 at 12:58 AM, Matzuba wrote:
Hi
In my environment, i do not have a clear/linear lifecycle path of LIB →
DEV–> TEST → PROD. I have multiple TEST environments that could be
used, for example one of the test envs could be tied to the production
release and cant be changed while the other test environments may have
different code releases that is being testes. This makes it difficult to
fit into the lifecycle model for promoting content. It would be nice if
there was some kind of branch feature.
I was wondering if others have the same issue and how they have over come
this?
Can you you have the same content view but assigned to different lifecycle
paths to save having to create more content views or would i need separate
content views for each lifecycle? Does having multiple content views
require more disk space or anything? If i did this, i would have to make
each content view the same and manage it that way to give me the control of
when contents are changed.
- Library → DEV
- Library → TEST1
- Library → TEST2
- Library → TEST3
thoughts anyone?
–
You received this message because you are subscribed to the Google Groups
“Foreman users” group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-users+unsubscribe@googlegroups.com.
To post to this group, send email to foreman-users@googlegroups.com.
Visit this group at http://groups.google.com/group/foreman-users.
For more options, visit https://groups.google.com/d/optout.
Yes - I can promote to any environment in any lifecycle path with the
version we have now. However, i cant skip envs in the a particular library
path.
It maybe easier just to have a separate content view for each environment
until we upgrade and can manage things better - esp as it is just the admin
headache of making sure the repos etc are defined for each content view etc
thanks again
> Hey Eric - thanks for the reply
>
> i'm on an old version of Katello (1.5) and 1.6 Foreman.
>
> I didn't realise that i could "promote" the content view to multiple
> environments that are in different lifecycle envs. With my current
> version, if all environments are in 1 linear lifecycle, i have to promote
> linearly. This means that i can promote any version of the content view
> to any environment, ie the latest one could be in my DEV environment while
> the stable/untouched version could be sitting in one of the TEST envs. Are
> there any limitations with this approach? apart from the fact that i need
> to make sure what CV version is in what TEST env. The content that would
> be in the assigning would be OS and vendor packages as well as vendor
> puppet modules.
>
I can't say that this is the case for Katello 1.5 since that was quite a
while ago and the codebase has undergone a lot of changes since then. If I
recall correctly, in 1.5, you are locked to following the promotion paths
and would have to make every environment off of LIbrary.
>
> So if i use multiple content views - would this consume additional disk
> space/resource etc for each one?
>
It should not. Once the repository is synced down to library, any further
operations with content views won't duplicate the physical bits.
Eric
···
On Wed, Jun 3, 2015 at 10:11 AM, Matzuba wrote:
–
You received this message because you are subscribed to the Google Groups
“Foreman users” group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-users+unsubscribe@googlegroups.com.
To post to this group, send email to foreman-users@googlegroups.com.
Visit this group at http://groups.google.com/group/foreman-users.
For more options, visit https://groups.google.com/d/optout.
