[openstack-dev] [tatu] Integration with Uber's pam-ussh module (and Stripe's KRL)
Hi Folks, I integrated Uber's pam-ussh module in Tatu. With this, if the user's SSH certificate is revoked while they're logged into the VM, they lose sudo access (btw, I don't know how to close their session, which would be even better). Here's the demo video: https://youtu.be/yjwWdYJRTM0 Here's my pull request to add KRL support (from https://github.com/stripe/krl) to pam-ussh: https://github.com/uber/pam-ussh/pull/10 And here's the Tatu code-review: https://review.openstack.org/#/c/549389/ cheers, Pino __ 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
Re: [openstack-dev] [requirements] Let's switch from pyldap to python-ldap >= 3
On 18-03-03 18:44:59, Thomas Goirand wrote: > Hi, > > Pyldap started as a fork of python-ldap. But recently, its features were > merged into the python-ldap python module >= 3, and pyldap is now > deprecated. Let's switch to python-ldap >= 3, and remove pyldap from > requirements. > > This has already been done in Debian. The python-ldap source package now > carries a python-pyldap transition package, which installs python-ldap. > > What's the procedure? Should I first send a patch to the global-reqs > repo first? > I think we should do it like this. 1. add python-ldap-3.x to requirements (though it looks like that's still a beta 2. move existing pyldap to python-ldap 3. remove pyldap -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature __ 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
[openstack-dev] [requirements] Let's switch from pyldap to python-ldap >= 3
Hi, Pyldap started as a fork of python-ldap. But recently, its features were merged into the python-ldap python module >= 3, and pyldap is now deprecated. Let's switch to python-ldap >= 3, and remove pyldap from requirements. This has already been done in Debian. The python-ldap source package now carries a python-pyldap transition package, which installs python-ldap. What's the procedure? Should I first send a patch to the global-reqs repo first? Cheers, Thomas Goirand (zigo) __ 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
Re: [openstack-dev] [Nova] [Cyborg] Tracking multiple functions
On 2 March 2018 at 14:31, Jay Pipes wrote: > On 03/02/2018 02:00 PM, Nadathur, Sundar wrote: > >> Hello Nova team, >> >> During the Cyborg discussion at Rocky PTG, we proposed a flow for >> FPGAs wherein the request spec asks for a device type as a resource class, >> and optionally a function (such as encryption) in the extra specs. This >> does not seem to work well for the usage model that I’ll describe below. >> >> An FPGA device may implement more than one function. For example, it may >> implement both compression and encryption. Say a cluster has 10 devices of >> device type X, and each of them is programmed to offer 2 instances of >> function A and 4 instances of function B. More specifically, the device may >> implement 6 PCI functions, with 2 of them tied to function A, and the other >> 4 tied to function B. So, we could have 6 separate instances accessing >> functions on the same device. >> > Does this imply that Cyborg can't reprogram the FPGA at all? > >> In the current flow, the device type X is modeled as a resource class, so >> Placement will count how many of them are in use. A flavor for ‘RC >> device-type-X + function A’ will consume one instance of the RC >> device-type-X. But this is not right because this precludes other >> functions on the same device instance from getting used. >> >> One way to solve this is to declare functions A and B as resource classes >> themselves and have the flavor request the function RC. Placement will then >> correctly count the function instances. However, there is still a problem: >> if the requested function A is not available, Placement will return an >> empty list of RPs, but we need some way to reprogram some device to create >> an instance of function A. >> > > Clearly, nova is not going to be reprogramming devices with an instance of > a particular function. > > Cyborg might need to have a separate agent that listens to the nova > notifications queue and upon seeing an event that indicates a failed build > due to lack of resources, then Cyborg can try and reprogram a device and > then try rebuilding the original request. > It was my understanding from that discussion that we intend to insert Cyborg into the spawn workflow for device configuration in the same way that we currently insert resources provided by Cinder and Neutron. So while Nova won't be reprogramming a device, it will be calling out to Cyborg to reprogram a device, and waiting while that happens. My understanding is (and I concede some areas are a little hazy): * The flavors says device type X with function Y * Placement tells us everywhere with device type X * A weigher orders these by devices which already have an available function Y (where is this metadata stored?) * Nova schedules to host Z * Nova host Z asks cyborg for a local function Y and blocks * Cyborg hopefully returns function Y which is already available * If not, Cyborg reprograms a function Y, then returns it Can anybody correct me/fill in the gaps? Matt -- Matthew Booth Red Hat OpenStack Engineer, Compute DFG Phone: +442070094448 (UK) __ 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
[openstack-dev] [tripleo] tripleo-image-elements 8.0.0.0rc1 (queens)
Hello everyone, A new release candidate for tripleo-image-elements for the end of the Queens cycle is available! You can find the source code tarball at: https://tarballs.openstack.org/tripleo-image-elements/ Unless release-critical issues are found that warrant a release candidate respin, this candidate will be formally released as the final Queens release. You are therefore strongly encouraged to test and validate this tarball! Alternatively, you can directly test the stable/queens release branch at: http://git.openstack.org/cgit/openstack/tripleo-image-elements/log/?h=stable/queens Release notes for tripleo-image-elements can be found at: http://docs.openstack.org/releasenotes/tripleo-image-elements/ __ 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
[openstack-dev] [tripleo] tripleo-puppet-elements 8.0.0.0rc1 (queens)
Hello everyone, A new release candidate for tripleo-puppet-elements for the end of the Queens cycle is available! You can find the source code tarball at: https://tarballs.openstack.org/tripleo-puppet-elements/ Unless release-critical issues are found that warrant a release candidate respin, this candidate will be formally released as the final Queens release. You are therefore strongly encouraged to test and validate this tarball! Alternatively, you can directly test the stable/queens release branch at: http://git.openstack.org/cgit/openstack/tripleo-puppet-elements/log/?h=stable/queens Release notes for tripleo-puppet-elements can be found at: http://docs.openstack.org/releasenotes/tripleo-puppet-elements/ __ 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
[openstack-dev] [tripleo] tripleo-heat-templates 8.0.0.0rc1 (queens)
Hello everyone, A new release candidate for tripleo-heat-templates for the end of the Queens cycle is available! You can find the source code tarball at: https://tarballs.openstack.org/tripleo-heat-templates/ Unless release-critical issues are found that warrant a release candidate respin, this candidate will be formally released as the final Queens release. You are therefore strongly encouraged to test and validate this tarball! Alternatively, you can directly test the stable/queens release branch at: http://git.openstack.org/cgit/openstack/tripleo-heat-templates/log/?h=stable/queens Release notes for tripleo-heat-templates can be found at: http://docs.openstack.org/releasenotes/tripleo-heat-templates/ If you find an issue that could be considered release-critical, please file it at: https://bugs.launchpad.net/tripleo and tag it *queens-rc-potential* to bring it to the tripleo-heat-templates release crew's attention. __ 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
