In that case I would suggest to also use Keystone service directory for discovering services.
> 9 жовт. 2015 р. о 11:00 Evgeniy L <e...@mirantis.com> написав(ла): > > >> I’d say even if it will be a separate service it’s better to proxy > >> requests through Nailgun’s API to have a single entry point. > > I don't think that application such as Nailgun should be responsible for > proxying > requests, we solved similar problem for OSTF with adding proxy rule in Nginx. > > Thanks, > > On Fri, Oct 9, 2015 at 11:45 AM, Roman Prykhodchenko <m...@romcheg.me > <mailto:m...@romcheg.me>> wrote: > I’d say even if it will be a separate service it’s better to proxy requests > through Nailgun’s API to have a single entry point. > >> 9 жовт. 2015 р. о 10:23 Evgeniy L <e...@mirantis.com >> <mailto:e...@mirantis.com>> написав(ла): >> >> Hi, >> >> +1, but I think it's better to spawn separate service, instead of adding it >> to Nailgun. >> >> Thanks, >> >> On Fri, Oct 9, 2015 at 1:40 AM, Roman Prykhodchenko <m...@romcheg.me >> <mailto:m...@romcheg.me>> wrote: >> Folks, >> >> it’s time to speak about Fuel Plugins and the way they are managed. >> >> Currently we have some methods in Fuel Client that allow to install, remove >> and do some other things to plugins. Everything looks great except that >> functionality requires Fuel Client to be installed on a master node and be >> running under a root user. It’s time for us to grow up and realize that >> nothing can require Fuel Client to be installed on a specific computer and >> of course we cannot require root permissions for any actions. >> >> I’d like to move all that code to Nailgun, utilizing mules and hide it >> behind Nailgun’s API as soon as possible. For that I filed a bug [1] and I’d >> like to ask Fuel Enhancements subgroup of developers to take a close look at >> it. >> >> >> 1. https://bugs.launchpad.net/fuel/+bug/1504338 >> <https://bugs.launchpad.net/fuel/+bug/1504338> >> >> >> - romcheg >> >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> <http://openstack-dev-requ...@lists.openstack.org/?subject:unsubscribe> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev> >> >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-requ...@lists.openstack.org >> <mailto:openstack-dev-requ...@lists.openstack.org>?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev> > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > <http://openstack-dev-requ...@lists.openstack.org/?subject:unsubscribe> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev> > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
signature.asc
Description: Message signed with OpenPGP using GPGMail
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
