fuel-dev team mailing list archive

[Igor Kalnitsky <ikalnitsky@xxxxxxxxxxxx>]

Hi Lukasz,

> If this doesn't convince you I don't know what can :)

Actually, I understand your points and agree with some of them, but
still think that we're doing that wrong way. But as I see, nobody
cares and the team is ok with current approach. Let's keep things as
they are, then.


> we also will use keystone as service/endpoint discovery tool.

Indeed, it's a cool possible usercase.


> Do you now, that you are proposing to introduce backward
> incompatible change?

No, I don't know why it's backward incompatible change. If we add
Nailgun auth logic which will use keystone inside - there's no
incompatible changes, since we will still use keystone auth token.


> Why do you need this in the first place? If you want to know when user is
> using UI you can do it by adding special header in JavaScript client.
> You can easly detect when user started and stopped using UI.
> You can do the same with fuelclient.

I'd prefer to refuse to count such metrics rather than use hacks in headers. :)


Thanks,
Igor

On Wed, Sep 24, 2014 at 10:44 PM, Lukasz Oles <loles@xxxxxxxxxxxx> wrote:
> Hi Igor,
>
> On Wed, Sep 24, 2014 at 8:58 AM, Igor Kalnitsky <ikalnitsky@xxxxxxxxxxxx>
> wrote:
>>
>> In Fuel we need authentication only for Nailgun and we don't need it
>> for other parts of Fuel, right?
>
>
> Actually no. Currently nailgun and ostf are using keystone for
> authentication/authorization.
> In next release we will introduce Plugin Manager which will be separate
> service. It will also require
> keystone.
> So for now I know about 3 services.
> Some advanced plugins with their own API will also require keystone.
> Currently we are also working[1] on testing Fuel on large scale and we may
> use Rally[2] for this. Rally requires keystone.
> It uses it to discover nailgun service.
> In future we may add to fuelclient  OSTF and Plugin support and we also will
> use keystone as service/endpoint discovery tool. Anyone can use it this way,
> as in OpenStack.
> Also if someone comes to us from OpenStack world  he already knows what to
> do. After all we are building OpenStack installation tool here.
>
> If this doesn't convince you I don't know what can :)
>
>>
>>  For example, if we will decide
>> to use Keystone v3 the only thing we will have to do is to change only
>> Nailgun, not all clients.
>
> Actually keystone here is better than nailgun here  because it can support
> many API versions. Do you now, that you are proposing to introduce backward
> incompatible change?
>
> Why do you need this in the first place? If you want to know when user is
> using UI you can do it by adding special header in JavaScript client. You
> can easly detect when user started and stopped using UI. You can do the same
> with fuelclient.
> I don't see any reason to make such change.
>
> [1] https://review.openstack.org/#/c/119400/
> [2] https://github.com/stackforge/rally
>
> Regards,
>
>> > We are currently fixing some small issues with our implementation[1]
>>
>> Thank you for the link! I'll take a look.
>>
>>
>> Thanks,
>> Igor
>>
>> On Wed, Sep 24, 2014 at 12:48 AM, Lukasz Oles <loles@xxxxxxxxxxxx> wrote:
>> > Hi Igor,
>> >
>> > When we were designing this future (access control for Fuel) there was a
>> > discussion about this. We decided to follow OpenStack approach where you
>> > authenticate using keystone and then use only token to talk  with
>> > services.
>> > If you are using fuelclient or UI it's hidden from you as in OpenStack.
>> >
>> > We are currently fixing some small issues with our implementation[1].
>> > Please
>> > read the spec. You may suggest some changes which will help you with
>> > statistics. Maybe cookies will help?  Vitaly can comment on it. Changing
>> > nailgun API for me is the worst solution.
>> >
>> > [1] https://review.openstack.org/#/c/118284/
>> >
>> > Regards,
>> >
>> >
>> > On Tue, Sep 23, 2014 at 9:28 PM, Igor Kalnitsky
>> > <ikalnitsky@xxxxxxxxxxxx>
>> > wrote:
>> >>
>> >> Hi Lukasz,
>> >>
>> >> Thank you for the input. Actually I agree with you, but still I think
>> >> there's something wrong with our current approach.
>> >>
>> >> I don't like that we work with keystone directly from UI and Fuel CLI.
>> >> I believe there should be a Nailgun API for authenticating users. In
>> >> deep of Nail Gun we can use Keystone for authenticating users and
>> >> validating tokens, but not vice-versa.
>> >>
>> >> I mean there's something wrong if we don't provide authentication
>> >> abstraction and use keystone directly in both server and client sides
>> >> (Nailgun, CLI, UI, Upgrade Script, etc).
>> >>
>> >> What do you think about it?
>> >>
>> >> Thanks,
>> >> Igor
>> >>
>> >> On Tue, Sep 23, 2014 at 8:07 PM, Lukasz Oles <loles@xxxxxxxxxxxx>
>> >> wrote:
>> >> > Guys,
>> >> >
>> >> > there is no "logout issue". This is REST API. It is stateless.
>> >> > There is no such thing like login or logout in REST API. You can only
>> >> > get
>> >> > authentication token. This token is only valid for a while. After
>> >> > some
>> >> > time
>> >> > it will be outdated and you need to get new one. It doesn't mean that
>> >> > user
>> >> > login and logout every time, it only means that token is not valid
>> >> > anymore
>> >> > and you need new one.
>> >> >
>> >> > In 6.0 token will be valid for 24h, so when you will see new token it
>> >> > means
>> >> > user started using API again. That's all. You can easily calculate
>> >> > when
>> >> > user
>> >> > started using API and when he ended. You don't need to add
>> >> > login/logut
>> >> > handlers. It's broken. REST API doesn't work this way.
>> >> >
>> >> > If we need add new handlers to API because of collecting data it
>> >> > means
>> >> > you
>> >> > are doing something wrong.  Your code should't change anything in API
>> >> > workflow.
>> >> >
>> >> > Regards,
>> >> >
>> >> > On Mon, Sep 22, 2014 at 12:59 PM, Igor Kalnitsky
>> >> > <ikalnitsky@xxxxxxxxxxxx>
>> >> > wrote:
>> >> >>
>> >> >> Hi folks,
>> >> >>
>> >> >> Today I took a look over "logout issue" [1] and figured out that we
>> >> >> cannot implement it with current approach.
>> >> >>
>> >> >> In current approach both login and logout actions are handled by Web
>> >> >> UI with direct requests to Keystone server [2].
>> >> >>
>> >> >> As far as I know, we want to track login/logout actions as a part of
>> >> >> anonymous statistic [3], so we need to decide how to avoid this
>> >> >> issue
>> >> >> and make it fly.
>> >> >>
>> >> >> I think we need to implement login/logout handlers as a part of
>> >> >> Nailgun API. A login handler should receive user credentials and
>> >> >> make
>> >> >> request to Keystone server in order to retrieve an auth token. A
>> >> >> logout handler should mark the token as invalid and forbid any
>> >> >> actions
>> >> >> with this token.
>> >> >>
>> >> >> Fuel Web UI should work with login/logout handlers which are part of
>> >> >> Nailgun, instead of working with Keystone directly.
>> >> >>
>> >> >> What do you think about it? Any ideas and suggestions are welcome!
>> >> >>
>> >> >>
>> >> >> [1]: https://bugs.launchpad.net/fuel/+bug/1370964
>> >> >> [2]:
>> >> >>
>> >> >>
>> >> >> https://github.com/stackforge/fuel-web/blob/master/nailgun/static/js/app.js#L70
>> >> >> [3]: https://blueprints.launchpad.net/fuel/+spec/send-anon-usage
>> >> >>
>> >> >>
>> >> >> - Igor
>> >> >>
>> >> >> --
>> >> >> Mailing list: https://launchpad.net/~fuel-dev
>> >> >> Post to     : fuel-dev@xxxxxxxxxxxxxxxxxxx
>> >> >> Unsubscribe : https://launchpad.net/~fuel-dev
>> >> >> More help   : https://help.launchpad.net/ListHelp
>> >> >
>> >> >
>> >> >
>> >> >
>> >> > --
>> >> > Łukasz Oleś
>> >
>> >
>> >
>> >
>> > --
>> > Łukasz Oleś
>
>
>
>
> --
> Łukasz Oleś