Currently in the UI, there is no way to promote content outside of the
given sequence. This is leading to inability to utilize version control.
Specifically, say I have 3 lifecycle environments: Dev, QA, Production. I
have Version 1 promoted to all 3 environments, then promote Version 2 to
Dev. Now Version 1 is in QA and Production, and Version 2 is in Dev. In the
UI, I cannot get back to Version 1 in the Dev environment unless I delete
it from every environment and re-promote it to library.
In the API, you are able to bypass this restriction by passing in the
'force' option. I think the UI should suggest a promotion path, but allow a
user to promote to whatever path they would like, perhaps with a warning
and verification of intention before completion of task.
if there is no real technical risk to adding this option I think the
users would be pleased.
I think today most people get annoyed at the restrictions and wish we
could be a bit more lax with the ability to promote things as the user
sees fit.
Having warnings but allowing the user to continue would be a good
alternative to complete blockage.
Mike
···
On 04/28/2015 01:18 PM, Christine Fouant wrote:
> Currently in the UI, there is no way to promote content outside of the
> given sequence. This is leading to inability to utilize version control.
> Specifically, say I have 3 lifecycle environments: Dev, QA, Production.
> I have Version 1 promoted to all 3 environments, then promote Version 2
> to Dev. Now Version 1 is in QA and Production, and Version 2 is in Dev.
> In the UI, I cannot get back to Version 1 in the Dev environment unless
> I delete it from every environment and re-promote it to library.
>
> In the API, you are able to bypass this restriction by passing in the
> 'force' option. I think the UI should suggest a promotion path, but
> allow a user to promote to whatever path they would like, perhaps with a
> warning and verification of intention before completion of task.
>
> Thoughts/suggestions?
>
–
Mike McCune
mmccune AT redhat.com
Red Hat Engineering | Portland, OR
Systems Management | 650-254-4248
> Currently in the UI, there is no way to promote content outside of the
> given sequence. This is leading to inability to utilize version control.
> Specifically, say I have 3 lifecycle environments: Dev, QA, Production. I
> have Version 1 promoted to all 3 environments, then promote Version 2 to
> Dev. Now Version 1 is in QA and Production, and Version 2 is in Dev. In the
> UI, I cannot get back to Version 1 in the Dev environment unless I delete
> it from every environment and re-promote it to library.
>
Not sure I completely follow your example. Why would you have to delete
Version 1 from every environment? Just promote Version 1 to Library and
then to Dev. Which is currently two steps but I would be in favor of
allowing users to speed that up by promoting from archive to first
environment in a path.
Eric
···
On Tue, Apr 28, 2015 at 4:18 PM, Christine Fouant wrote:
In the API, you are able to bypass this restriction by passing in the
’force’ option. I think the UI should suggest a promotion path, but allow a
user to promote to whatever path they would like, perhaps with a warning
and verification of intention before completion of task.
···
On 04/28/2015 04:18 PM, Christine Fouant wrote:
> Currently in the UI, there is no way to promote content outside of the
> given sequence. This is leading to inability to utilize version control.
> Specifically, say I have 3 lifecycle environments: Dev, QA, Production.
> I have Version 1 promoted to all 3 environments, then promote Version 2
> to Dev. Now Version 1 is in QA and Production, and Version 2 is in Dev.
> In the UI, I cannot get back to Version 1 in the Dev environment unless
> I delete it from every environment and re-promote it to library.
>
> In the API, you are able to bypass this restriction by passing in the
> 'force' option. I think the UI should suggest a promotion path, but
> allow a user to promote to whatever path they would like, perhaps with a
> warning and verification of intention before completion of task.
>
> Thoughts/suggestions?
I'll reiterate my desire for CV versions to always which lifecycle env they are in and/or their description/comment. If, as the UI is improved and altered for topics such as this one, this could be kept in mind and included, that would be much appreciated.
Given the above, where versions are not isolated numbers but retain some context, I would be in favor of some more flexibility.
···
----- Original Message -----
> On 04/28/2015 01:18 PM, Christine Fouant wrote:
> > Currently in the UI, there is no way to promote content outside of the
> > given sequence. This is leading to inability to utilize version control.
> > Specifically, say I have 3 lifecycle environments: Dev, QA, Production.
> > I have Version 1 promoted to all 3 environments, then promote Version 2
> > to Dev. Now Version 1 is in QA and Production, and Version 2 is in Dev.
> > In the UI, I cannot get back to Version 1 in the Dev environment unless
> > I delete it from every environment and re-promote it to library.
> >
> > In the API, you are able to bypass this restriction by passing in the
> > 'force' option. I think the UI should suggest a promotion path, but
> > allow a user to promote to whatever path they would like, perhaps with a
> > warning and verification of intention before completion of task.
> >
> > Thoughts/suggestions?
> >
>
> if there is no real technical risk to adding this option I think the
> users would be pleased.
>
> I think today most people get annoyed at the restrictions and wish we
> could be a bit more lax with the ability to promote things as the user
> sees fit.
>
> Having warnings but allowing the user to continue would be a good
> alternative to complete blockage.
>
> Mike
>
> --
> Mike McCune
> mmccune AT redhat.com
> Red Hat Engineering | Portland, OR
> Systems Management | 650-254-4248
>
> --
> You received this message because you are subscribed to the Google Groups
> "foreman-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to foreman-dev+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
If you try to promote Version 1 to Library, it fails and requests a force
parameter to be passed, which is not currently available in the UI. This is
the case in the example I gave, where say Production has Version 1 attached
to it, and Library and Dev have Version 2… if Version 2 is removed, there
is no way to go back to Version 1 without removing Version 1 from all
environments so that the promotion path begins again at Library.
···
On Tuesday, April 28, 2015 at 6:00:03 PM UTC-4, Eric Helms wrote:
>
>
>
> On Tue, Apr 28, 2015 at 4:18 PM, Christine Fouant > wrote:
>
>> Currently in the UI, there is no way to promote content outside of the
>> given sequence. This is leading to inability to utilize version control.
>> Specifically, say I have 3 lifecycle environments: Dev, QA, Production. I
>> have Version 1 promoted to all 3 environments, then promote Version 2 to
>> Dev. Now Version 1 is in QA and Production, and Version 2 is in Dev. In the
>> UI, I cannot get back to Version 1 in the Dev environment unless I delete
>> it from every environment and re-promote it to library.
>>
>
> Not sure I completely follow your example. Why would you have to delete
> Version 1 from every environment? Just promote Version 1 to Library and
> then to Dev. Which is currently two steps but I would be in favor of
> allowing users to speed that up by promoting from archive to first
> environment in a path.
>
> Eric
>
>
>>
>> In the API, you are able to bypass this restriction by passing in the
>> 'force' option. I think the UI should suggest a promotion path, but allow a
>> user to promote to whatever path they would like, perhaps with a warning
>> and verification of intention before completion of task.
>>
>> Thoughts/suggestions?
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "foreman-dev" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to foreman-dev...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
Hey Tom - could you complete your first sentence? Your desire for CV
versions to always… ? I will definitely try to incorporate.
···
On Tuesday, April 28, 2015 at 5:35:42 PM UTC-4, Tom McKay wrote:
>
>
>
> ----- Original Message -----
> > On 04/28/2015 01:18 PM, Christine Fouant wrote:
> > > Currently in the UI, there is no way to promote content outside of the
> > > given sequence. This is leading to inability to utilize version
> control.
> > > Specifically, say I have 3 lifecycle environments: Dev, QA,
> Production.
> > > I have Version 1 promoted to all 3 environments, then promote Version
> 2
> > > to Dev. Now Version 1 is in QA and Production, and Version 2 is in
> Dev.
> > > In the UI, I cannot get back to Version 1 in the Dev environment
> unless
> > > I delete it from every environment and re-promote it to library.
> > >
> > > In the API, you are able to bypass this restriction by passing in the
> > > 'force' option. I think the UI should suggest a promotion path, but
> > > allow a user to promote to whatever path they would like, perhaps with
> a
> > > warning and verification of intention before completion of task.
> > >
> > > Thoughts/suggestions?
> > >
> >
> > if there is no real technical risk to adding this option I think the
> > users would be pleased.
> >
> > I think today most people get annoyed at the restrictions and wish we
> > could be a bit more lax with the ability to promote things as the user
> > sees fit.
> >
> > Having warnings but allowing the user to continue would be a good
> > alternative to complete blockage.
> >
> > Mike
> >
> > --
> > Mike McCune
> > mmccune AT redhat.com
> > Red Hat Engineering | Portland, OR
> > Systems Management | 650-254-4248
> >
> > --
> > You received this message because you are subscribed to the Google
> Groups
> > "foreman-dev" group.
> > To unsubscribe from this group and stop receiving emails from it, send
> an
> > email to foreman-dev...@googlegroups.com .
> > For more options, visit https://groups.google.com/d/optout.
> >
>
> I'll reiterate my desire for CV versions to always which lifecycle env
> they are in and/or their description/comment. If, as the UI is improved and
> altered for topics such as this one, this could be kept in mind and
> included, that would be much appreciated.
>
> Given the above, where versions are not isolated numbers but retain some
> context, I would be in favor of some more flexibility.
>
This is a bug. You should be able to promote version 1 to Library and Dev without having to remove it from QA and Production. I've opened an issue for this:
···
----- Original Message -----
> From: "Christine Fouant"
> To: foreman-dev@googlegroups.com
> Sent: Friday, May 1, 2015 4:46:54 PM
> Subject: Re: [foreman-dev] Content View Version restrictions
>
> If you try to promote Version 1 to Library, it fails and requests a force
> parameter to be passed, which is not currently available in the UI. This is
> the case in the example I gave, where say Production has Version 1 attached
> to it, and Library and Dev have Version 2... if Version 2 is removed, there
> is no way to go back to Version 1 without removing Version 1 from all
> environments so that the promotion path begins again at Library.
>
> On Tuesday, April 28, 2015 at 6:00:03 PM UTC-4, Eric Helms wrote:
> >
> >
> >
> > On Tue, Apr 28, 2015 at 4:18 PM, Christine Fouant > > wrote:
> >
> >> Currently in the UI, there is no way to promote content outside of the
> >> given sequence. This is leading to inability to utilize version control.
> >> Specifically, say I have 3 lifecycle environments: Dev, QA, Production. I
> >> have Version 1 promoted to all 3 environments, then promote Version 2 to
> >> Dev. Now Version 1 is in QA and Production, and Version 2 is in Dev. In
> >> the
> >> UI, I cannot get back to Version 1 in the Dev environment unless I delete
> >> it from every environment and re-promote it to library.
> >>
> >
> > Not sure I completely follow your example. Why would you have to delete
> > Version 1 from every environment? Just promote Version 1 to Library and
> > then to Dev. Which is currently two steps but I would be in favor of
> > allowing users to speed that up by promoting from archive to first
> > environment in a path.
> >
> > Eric
> >
> >
> >>
> >> In the API, you are able to bypass this restriction by passing in the
> >> 'force' option. I think the UI should suggest a promotion path, but allow
> >> a
> >> user to promote to whatever path they would like, perhaps with a warning
> >> and verification of intention before completion of task.
> >>
> >> Thoughts/suggestions?
> >>
> >> --
> >> You received this message because you are subscribed to the Google Groups
> >> "foreman-dev" group.
> >> To unsubscribe from this group and stop receiving emails from it, send an
> >> email to foreman-dev...@googlegroups.com .
> >> For more options, visit https://groups.google.com/d/optout.
> >>
> >
> >
>
> --
> You received this message because you are subscribed to the Google Groups
> "foreman-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to foreman-dev+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
