12:03 p.m.
On 2017-02-23 17:40, Niels van Dijk wrote:
Hi
I think in principle we have the/a correct way of dealing with this in
the deployment of eduTEAMS Identity Hub already: its ansible deployment
scripts pull from specific repositories 3 kinds of content: (1) core
satosa, (2) consent servcie, (3) account linking service, all with
specific versions and adds platform specific configuration to that mix
to create the service. See the TEIPdeploy repo for an example:
https://dev.niif.hu/vopaas/TEIP-deploy/blob/master/playbook/teipservers.yml.
I have already had scenario of dealing with new versions of satosa and
the other microservices coming into the depoy as Rebecka made changes to
them based on our requirements and also because of bugs. This worked
just fine, as long as Rebecka told me what new configurational settings
to adopt. In the somewhat longer run I would prefer e.g. Stavros to also
take care of the Ansible deployment scripts as he will be much closer to
the actual software. One missing piece is by the way still that some
gui is not really externally configurable in SatoSa, which is something
we would want to address.
For InAcademia this is a different case as here Leifs scripst are
handling the deployment, and also the InAcademia deployement is much
more complex because it has a distributed setup. As discussed earlier in
the InAcademia meeting, we should set up a f2f meeting/workshop to get
Leif, Stavros, Ioannis and maybe also me synced on how that works.
So I think ansible and puppet deserve their own special repos -
otherwize I suspect it becomes to hard to consume them into
puppet ansible who both expect to have plugins as separate things
in git etc right?
Cheers Leif
Cheers,
Niels
On 23-02-17 16:21, Ioannis Kakavas wrote:
Sorry for the double mail, getting a bit mentally
exhausted after
TIIME. We should probably figure out a way to differentiate
discussions/feedback etc between satosa as a project and products that
use satosa (inAcademia).
This discussion for example started from a request that Lukas made for
inAcademia and the UI changes (colors etc)are specific to inAcademia
so its probably not very relevant for satosa-dev.
Maybe what could be of interest for that list/community would be a
discuss on how to make the UI of the consent module based on ie
Bootstrap and make it easy to have "themes" (inAcademia theme, etc) .
I will create an enhancement issue on github once the consent module
has been moved to satosa-contrib and we can discuss if it's worth
looking into it.
Best
Ioannis
Sent from BlueMail <http://www.bluemail.me/r?b=8872>
------------------------------------------------------------------------
*From:* Ioannis Kakavas
*Sent:* Thu Feb 23 16:05:42 GMT+01:00 2017
*To:* Stavros 0 Sachtouris
*Cc:* Niels van Dijk , "Lukas Hämmerle"
*Subject:* Re: First SaToSa change
The idea is to move all related software (microservices mostly) to a
satosa-contrib repository so that will mitigate that concern.
Ioannis
Sent from BlueMail <http://www.bluemail.me/r?b=8872>
------------------------------------------------------------------------
*From:* Stavros 0 Sachtouris
*Sent:* Thu Feb 23 14:32:48 GMT+01:00 2017
*To:* Niels van Dijk , "Lukas Hämmerle" , Ioannis Kakavas
*Subject:* Re: First SaToSa change
Hi Niels,
in this particular case, the consent module is not a part of the
SAtoSA github repository. My concern is that, if people follow the
SAtoSA repository, will they be notified about changes happening in
other related repositories if they are not notified through the list?
Stavros
On 02/23/2017 11:50 AM, Niels van Dijk wrote:
--
Niels van Dijk Technical Product Manager Trust & Security
Mob: +31 651347657 | Skype: cdr-80 | PGP Key ID: 0xDE7BB2F5
SURFnet BV | PO.Box 19035 | NL-3501 DA Utrecht | The Netherlands
www.surfnet.nl www.openconext.org
Hi Stavros,
Yesterday at the TIIME meeting we have a meeting with various teams that
work with SaToSa (SUnet, GEANT, SCG). We agreed that the satosa github
issues tracker for requesting feedback, putting in new feature requests,
and that pull requests is indeed the right way to go as well for
proposing software changes.
Cheers,
Niels
On 23-02-17 10:33, Stavros 0 Sachtouris wrote:
> Hi Lukas,
>
> thank you for the feedback, I will drop the pull request and update
> the patch with those of your observations that are not subject of
> further discussion.
>
> Just one question: what is the right list to ask for feedback?
>
> Stavros
>
> On 02/23/2017 09:49 AM, Lukas Hämmerle wrote:
>> Hi Stavros
>>
>> Great, this looks already a lot better than the current consent screen :-)
>>
>> A few quic comments/suggestions:
>> * In the mobile version, the language selection is a bit too close to
>> the InAcademia logo. Some space could help there. Even better, like in
>> the desktop version you might want to reduce the width of the drop-down
>> list as its (short) content is in no relation to its with currently.
>> * typo: "Click to see what else is sent with your consent" (you
instead
>> of your)
>> * Personally, for InAcademia I would not leave the user the confusing
>> option to define for how long the consent should be given. Instead I
>> would just set a default of 3 months and add a note "Your consent
>> decision is stored for 3 months" but that isYesterday at the TIIME meeting
we have a meeting with various teams that
>> work with SaToSa (SUnet, GEANT, SCG). We agreed that the satosa github
>> issues tracker for requesting feedback, putting in new feature requests,
>> and that pull requests is indeed the right way to go as well for
>> proposing software changes. probably something to discuss
>> * I would use the same font size for the attribute name and value. Too
>> many font-sizes are confusing.
>> * Instead of:
>> ----------------------------------------------------------------
>> Given name
>> ✓ ['Stavros']
>> ----------------------------------------------------------------
>> How about much simpler and space-saving
>> ----------------------------------------------------------------
>> Given name Stavros
>> ----------------------------------------------------------------
>> * Personally I would switch the positions of the OK and No buttons and
>> align them right.
>>
>>
>> On 22.02.17 15:11, Stavros 0 Sachtouris wrote:
>>> Should I forward this to one of the lists as well?
>> Yes, that probably would help getting more feedback on UI aspects.
>>
>> Best Regards
>> Lukas
>>
>>
>>
9:21 a.m.
On 24-02-17 13:03, Leif Johansson wrote:
--
Niels van Dijk Technical Product Manager Trust & Security
Mob: +31 651347657 | Skype: cdr-80 | PGP Key ID: 0xDE7BB2F5
SURFnet BV | PO.Box 19035 | NL-3501 DA Utrecht | The Netherlands
www.surfnet.nl www.openconext.org
On 2017-02-23 17:40, Niels van Dijk wrote:
Yes, these are deployment dependent and should not meddle with vanilla
SaToSa.
Probably should not even be in the SUNet git, but in an Inacademia or
eduTEAMS owned repo. (the latter is lready true with the niif gitlab we
are using for our deploys)
Cheers,
Niels
Hi
I think in principle we have the/a correct way of dealing with this in
the deployment of eduTEAMS Identity Hub already: its ansible deployment
scripts pull from specific repositories 3 kinds of content: (1) core
satosa, (2) consent servcie, (3) account linking service, all with
specific versions and adds platform specific configuration to that mix
to create the service. See the TEIPdeploy repo for an example:
https://dev.niif.hu/vopaas/TEIP-deploy/blob/master/playbook/teipservers.yml.
I have already had scenario of dealing with new versions of satosa and
the other microservices coming into the depoy as Rebecka made changes to
them based on our requirements and also because of bugs. This worked
just fine, as long as Rebecka told me what new configurational settings
to adopt. In the somewhat longer run I would prefer e.g. Stavros to also
take care of the Ansible deployment scripts as he will be much closer to
the actual software. One missing piece is by the way still that some
gui is not really externally configurable in SatoSa, which is something
we would want to address.
For InAcademia this is a different case as here Leifs scripst are
handling the deployment, and also the InAcademia deployement is much
more complex because it has a distributed setup. As discussed earlier in
the InAcademia meeting, we should set up a f2f meeting/workshop to get
Leif, Stavros, Ioannis and maybe also me synced on how that works.
So I think ansible and puppet deserve their own special repos -
otherwize I suspect it becomes to hard to consume them into
puppet ansible who both expect to have plugins as separate things
in git etc right? Cheers,
Niels
On 23-02-17 16:21, Ioannis Kakavas wrote:
Sorry for the double mail, getting a bit mentally
exhausted after
TIIME. We should probably figure out a way to differentiate
discussions/feedback etc between satosa as a project and products that
use satosa (inAcademia).
This discussion for example started from a request that Lukas made for
inAcademia and the UI changes (colors etc)are specific to inAcademia
so its probably not very relevant for satosa-dev.
Maybe what could be of interest for that list/community would be a
discuss on how to make the UI of the consent module based on ie
Bootstrap and make it easy to have "themes" (inAcademia theme, etc) .
I will create an enhancement issue on github once the consent module
has been moved to satosa-contrib and we can discuss if it's worth
looking into it.
Best
Ioannis
Sent from BlueMail <http://www.bluemail.me/r?b=8872>
------------------------------------------------------------------------
*From:* Ioannis Kakavas
*Sent:* Thu Feb 23 16:05:42 GMT+01:00 2017
*To:* Stavros 0 Sachtouris
*Cc:* Niels van Dijk , "Lukas Hämmerle"
*Subject:* Re: First SaToSa change
The idea is to move all related software (microservices mostly) to a
satosa-contrib repository so that will mitigate that concern.
Ioannis
Sent from BlueMail <http://www.bluemail.me/r?b=8872>
------------------------------------------------------------------------
*From:* Stavros 0 Sachtouris
*Sent:* Thu Feb 23 14:32:48 GMT+01:00 2017
*To:* Niels van Dijk , "Lukas Hämmerle" , Ioannis Kakavas
*Subject:* Re: First SaToSa change
Hi Niels,
in this particular case, the consent module is not a part of the
SAtoSA github repository. My concern is that, if people follow the
SAtoSA repository, will they be notified about changes happening in
other related repositories if they are not notified through the list?
Stavros
On 02/23/2017 11:50 AM, Niels van Dijk wrote:
> Hi Stavros,
>
> Yesterday at the TIIME meeting we have a meeting with various teams that
> work with SaToSa (SUnet, GEANT, SCG). We agreed that the satosa github
> issues tracker for requesting feedback, putting in new feature requests,
> and that pull requests is indeed the right way to go as well for
> proposing software changes.
>
> Cheers,
>
> Niels
>
>
> On 23-02-17 10:33, Stavros 0 Sachtouris wrote:
>> Hi Lukas,
>>
>> thank you for the feedback, I will drop the pull request and update
>> the patch with those of your observations that are not subject of
>> further discussion.
>>
>> Just one question: what is the right list to ask for feedback?
>>
>> Stavros
>>
>> On 02/23/2017 09:49 AM, Lukas Hämmerle wrote:
>>> Hi Stavros
>>>
>>> Great, this looks already a lot better than the current consent screen :-)
>>>
>>> A few quic comments/suggestions:
>>> * In the mobile version, the language selection is a bit too close to
>>> the InAcademia logo. Some space could help there. Even better, like in
>>> the desktop version you might want to reduce the width of the drop-down
>>> list as its (short) content is in no relation to its with currently.
>>> * typo: "Click to see what else is sent with your consent" (you
instead
>>> of your)
>>> * Personally, for InAcademia I would not leave the user the confusing
>>> option to define for how long the consent should be given. Instead I
>>> would just set a default of 3 months and add a note "Your consent
>>> decision is stored for 3 months" but that isYesterday at the TIIME
meeting we have a meeting with various teams that
>>> work with SaToSa (SUnet, GEANT, SCG). We agreed that the satosa github
>>> issues tracker for requesting feedback, putting in new feature requests,
>>> and that pull requests is indeed the right way to go as well for
>>> proposing software changes. probably something to discuss
>>> * I would use the same font size for the attribute name and value. Too
>>> many font-sizes are confusing.
>>> * Instead of:
>>> ----------------------------------------------------------------
>>> Given name
>>> ✓ ['Stavros']
>>> ----------------------------------------------------------------
>>> How about much simpler and space-saving
>>> ----------------------------------------------------------------
>>> Given name Stavros
>>> ----------------------------------------------------------------
>>> * Personally I would switch the positions of the OK and No buttons and
>>> align them right.
>>>
>>>
>>> On 22.02.17 15:11, Stavros 0 Sachtouris wrote:
>>>> Should I forward this to one of the lists as well?
>>> Yes, that probably would help getting more feedback on UI aspects.
>>>
>>> Best Regards
>>> Lukas
>>>
>>>
>>>
--
Niels van Dijk Technical Product Manager Trust & Security
Mob: +31 651347657 | Skype: cdr-80 | PGP Key ID: 0xDE7BB2F5
SURFnet BV | PO.Box 19035 | NL-3501 DA Utrecht | The Netherlands
www.surfnet.nl www.openconext.org
2637
days inactive
2640
days old
1 comments
2 participants
participants (2)
-
leifj＠sunet.se -
niels.vandijk＠surfnet.nl