Open Stack

Mike,

Thanks! +1 to "Let's polish this work before the next release, merge
changes to upstream puppet-openstack, and then just use librarian in
the next release."

-- dims

On Fri, Jul 24, 2015 at 1:39 PM, Mike Scherbakov
<mscherbakov at mirantis.com> wrote:
> Thanks guys. Feature Freeze exception request is declined then. Let's polish
> this work before the next release, merge changes to upstream
> puppet-openstack, and then just use librarian in the next release.
>
> I'd like to comment Bogdan's email -
> unless we fully switch to librarian, I don't agree with:
>> Besides that, this feature seems already
>> partially supported in puppet openstack upstream [0], hence should be
>> developed and finished upstream first. Even if it wasn't at all - we
>> should follow our contribution rules and do not develop features like
>> Fernet tokens or v3 API in our forks.
>
> We can do whatever we need to do based on immediate needs for Fuel, but with
> the converging plan. We can't break something in Fuel, for example, just
> because we need to fix it puppet upstream first.
>
> On a separate note, any idea why this email appeared in a new thread in my
> inbox, not in the original one? My suspect is that Bogdan's client does
> something weird with email headers...
>
> On Fri, Jul 24, 2015 at 10:30 AM Aleksandr Didenko <adidenko at mirantis.com>
> wrote:
>>
>> Hi,
>>
>> we were not able to get a working deployment with fernet token support
>> patches, mostly due to issues with keys generation and deployment mechanism.
>> I've also spend some time debugging problems with this and I think it's too
>> risky to land it in 7.0. So I vote for postponing it till 8.0.
>>
>> Regards,
>> Alex
>>
>> On Fri, Jul 24, 2015 at 10:17 AM, Bogdan Dobrelya <bdobrelia at mirantis.com>
>> wrote:
>>>
>>> > Fuel Library team, I expect your immediate reply here.
>>> >
>>> > I'd like upgrades team to take a look at this one, as well as at the
>>> > one
>>> > which moves Keystone under Apache, in order to check that there are no
>>> > issues here.
>>> >
>>> > -1 from me for this time in the cycle. I'm concerned about:
>>> >
>>> >    1. I don't see any reference to blueprint or bug which explains
>>> > (with
>>> >    measurements) why we need this change in reference architecture, and
>>> > what
>>> >    are the thoughts about it in puppet-openstack, and OpenStack
>>> > Keystone. We
>>> >    need to get datapoints, and point to them. Just knowing that
>>> > Keystone team
>>> >    implemented support for it doesn't yet mean that we need to rush in
>>> >    enabling this.
>>> >    2. It is quite noticeable change, not a simple enhancement. I
>>> > reviewed
>>> >    the patch, there are questions raised.
>>> >    3. It doesn't pass CI, and I don't have information on risks
>>> > associated,
>>> >    and additional effort required to get this done (how long would it
>>> > take to
>>> >    get it done)
>>> >    4. This feature increases complexity of reference architecture. Now
>>> > I'd
>>> >    like every complexity increase to be optional. I have feedback from
>>> > the
>>> >    field, that our prescriptive architecture just doesn't fit users'
>>> > needs,
>>> >    and it is so painful to decouple then what is needed vs what is not.
>>> > Let's
>>> >    start extending stuff with an easy switch, being propagated from
>>> > Fuel
>>> >    Settings. Is it possible to do? How complex would it be?
>>> >
>>> > If we get answers for all of this, and decide that we still want the
>>> > feature, then it would be great to have it. I just don't feel that it's
>>> > right timing anymore - we entered FF.
>>> >
>>> > Thanks,
>>>
>>> I vote -1 for the same reasons. Besides that, this feature seems already
>>> partially supported in puppet openstack upstream [0], hence should be
>>> developed and finished upstream first. Even if it wasn't at all - we
>>> should follow our contribution rules and do not develop features like
>>> Fernet tokens or v3 API in our forks.
>>>
>>> So, the next steps as I see them are:
>>>
>>> 1) Freeze feature in fuel
>>> 2) Submit a spec to openstack puppet to make the feature completed
>>> (address revocation, expiration, rotation of the fernet tokens). This
>>> also seems related to the already existing blueprint for fuel [1] and
>>> the mail thread [2]
>>> 3) Implement the feature upstream
>>> 4) Backport this to fuel fork in 8.0, or consume it upstream
>>> directly in the case the related blueprint [3] will be already
>>> implemented by that time.
>>>
>>> [0] https://review.openstack.org/185441
>>> [1] https://blueprints.launchpad.net/fuel/+spec/fernet-tokens-support
>>> [2]
>>> http://lists.openstack.org/pipermail/openstack-dev/2015-July/069744.html
>>> [3] https://blueprints.launchpad.net/fuel/+spec/fuel-puppet-librarian
>>>
>>> --
>>> Best regards,
>>> Bogdan Dobrelya,
>>> Irc #bogdando
>>>
>>>
>>> __________________________________________________________________________
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> --
> Mike Scherbakov
> #mihgen
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Davanum Srinivas :: https://twitter.com/dims