[openstack-dev] [kolla] New Meeting Times Wednesday 1600UTC (even)/2200UTC (odd)
I have closed the doodle poll for our new meeting times. We will be meeting in #openstack-meeting-3 (yes there is that much contention for our time slots – must be a reason ;). The times are: Weekly Wednesday 1600 UTC (even weeks) Weekly Wednesday 2200 UTC (odd weeks) To determine if it is an even or odd week run: date +%U” Our next meeting will be May 13th at 1600 UTC. Regards -steve __ 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] [Murano] [Mistral] SSH workflow action
Kevin, I do agree that lack of RabbitMQ multi-tenancy is a problem. However as this is developers mailing list I would suggest to contribute and make Murano guest agent secure for the benefit of all users and all existing applications instead of spending comparable amount of time developing intricate solutions that will make everything way more complex. If Murano application developers need to write additional Mistral workflow for each deployment step that would make application development be extremely harder and Murano be mostly useless. There are several approaches that can be taken to solve agent isolation problem and all of them are relatively easy to implement. This task is one of out top priorities for the Liberty and will be solved very soon anyway. Another approach that IMO also better than SSH is to use HOT software config that uses HTTP polling and doesn't suffer from lack of tenant isolation. I do want to see better Mistral integration in Murano as well as many other tools like puppet etc. And there are some good use cases for Mistral. But when it comes to the most basic things that Murano was designed to do from the foundation I want to make sure that Murano can do them the best way possible without requiring users to learn additional DSLs/tools or go extra step and involve additional services where not necessary. If something important is missing in Murano that makes usage of Mistral for deployment more attractive I'd rather focus on improving Murano and bringing those features to Murano. We can even use Mistral under the hood as long as we not make users to write both MuranoPL and Mistral DSL code for trivial things like service restart. Sincerely yours, Stan Lagun Principal Software Engineer @ Mirantis sla...@mirantis.com On Sun, May 10, 2015 at 8:44 PM, Fox, Kevin M kevin@pnnl.gov wrote: Im planning on deploying murano but wont be supporting the murano guest agent. The lack of multi tenant security is a big problem I think. Thanks, Kevin -- *From:* Stan Lagun *Sent:* Saturday, May 09, 2015 7:21:17 PM *To:* OpenStack Development Mailing List (not for usage questions) *Subject:* Re: [openstack-dev] [Murano] [Mistral] SSH workflow action Filip, If I got you right the plan is to have Murano application execute Mistral workflow that SSH to VM and executes particular command? And alternative is Murano-Mistral-Zaquar-Zaquar agent? Why can't you just send this command directly from Murano (to Murano agent on VM)? This is the most common use case that is found in nearly all Murano applications and it is battle-proven. If you need SSH you can contribute SSH plugin to Murano (Mistral will require similar plugin anyway). The more moving parts you involve the more chances you have for everything to fail Sincerely yours, Stan Lagun Principal Software Engineer @ Mirantis sla...@mirantis.com On Fri, May 8, 2015 at 11:22 AM, Renat Akhmerov rakhme...@mirantis.com wrote: Generally yes, std.ssh action works as long as network infrastructure allows access to a host using specified IP, it doesn’t provide anything on top of that. On 06 May 2015, at 22:26, Fox, Kevin M kevin@pnnl.gov wrote: This would also probably be a good use case for Zaqar I think. Have a generic run shell commands from Zaqar queue agent, that pulls commands from a Zaqar queue, and executes it. The vm's don't have to be directly reachable from the network then. You just have to push messages into Zaqar. Yes, in Mistral it would be another action that puts a command into Zaqar queue. This type of action doesn’t exist yet but it can be plugged in easily. Should Mistral abstract away how to execute the action, leaving it up to Mistral how to get the action to the vm? Like I mentioned previously it should be just a different type of action: “zaqar.something” instead of “std.ssh”. Mistral engine itself works with all actions equally, they are just basically functions that we can plug in and use in Mistral workflow language. From this standpoint Mistral is already abstract enough. If that's the case, then ssh vs queue/agent is just a Mistral implementation detail? More precisely: implementation detail of Mistral action which may not be even hardcoded part of Mistral, we can rather plug them in (using stevedore underneath). Renat Akhmerov @ Mirantis Inc. __ 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 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] global-requirements not co-installable
On 9 May 2015 at 08:33, Sean Dague s...@dague.net wrote: On 05/08/2015 02:48 PM, Robert Collins wrote: Thats certainly possible too. Upside: if it works we know it works in pip. Downside, we'll be tracking something that is in active development and late-prototype /early alpha stage. This is likely to be in pip 8.0 (7.0 should be out inside of a week). I'm fine with that, we'll make it non-voting and just ask people to actually look at results when it fails (once we've gotten it working somewhat regularly). The throughput on requirements isn't so high that we can't spend some time on manual inspection. https://review.openstack.org/181774 https://review.openstack.org/181777 Should enable this. -Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Converged Cloud __ 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] [OpenStack-Infra] Gerrit downtime and upgrade on Saturday 2015-05-09 at 1600 UTC
On 05/10/2015 05:20 AM, James E. Blair wrote: If you encounter any problems, please let us know here or in #openstack-infra on Freenode. One minor thing is that after login you're redirected to https://review.openstack.org//; (note double //, which then messes up various relative-links when trying to use gerrit). I think this is within gerrit's openid provider; I don't see any obvious problems outside that. When I watch with firebug, Gerrit sends me off on a 401 page to launchpad with a form it POSTs -- this has a good-looking return_to input name=openid.return_to type=hidden value=https://review.openstack.org/OpenID?gerrit.mode=SIGN_IN; I go through the login, and get a 302 from https://login.launchpad.net/NUxdqUgd7EbI5Njo/+decide which correctly 302's me back to the return_to https://review.openstack.org/OpenID?gerrit.mode=SIGN_INopenid.assoc_handle=[... openid stuff follows ...] Which then further 302's back to Location: https://review.openstack.org// Which is followed to the incorrect URL. So yeah, something within the OpenID end-point I think. -i __ 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] [OpenStack-Infra] Gerrit downtime and upgrade on Saturday 2015-05-09 at 1600 UTC
On 2015-05-11 10:02:55 +1000 (+1000), Ian Wienand wrote: One minor thing is that after login you're redirected to https://review.openstack.org//; (note double //, which then messes up various relative-links when trying to use gerrit). [...] For what it's worth, I tried changing Gerrit's canonicalweburl setting to not include a trailing slash, but it doesn't help. I have a feeling this is not a misconfiguration, but something intrinsic to the OpenID implementation in Gerrit which has changed since 2.8. -- Jeremy Stanley __ 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] [keystone][clients] - Should we implement project to endpoint group?
- Original Message - From: Enrique Garcia garcianava...@gmail.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Sent: Monday, May 11, 2015 2:19:43 AM Subject: Re: [openstack-dev] [keystone][clients] - Should we implement project to endpoint group? Hi Marcos, I'm not part of the OpenStack development team but coincidently I implemented some of these actions on a fork the past week because I needed them in a project. If there is interest in these actions I could contribute them back or send a link to the repo if it would be helpful for you or someone else. Let me know if I can help. Cheers, Enrique. Absolutely there is always interest for things like this to be contributed upstream! We'd love to have it. There are fairly extensive docs on how to get started contributing https://wiki.openstack.org/wiki/How_To_Contribute and if you're not sure or need a hand there is typically people in either #openstack-dev or #openstack-keystone that can help. Jamie On Fri, 8 May 2015 at 16:03 Marcos Fermin Lobo marcos.fermin.l...@cern.ch wrote: Hi all, I would like to know if any of you would be interested to implement project to endpoint group actions ( http://specs.openstack.org/openstack/keystone-specs/api/v3/identity-api-v3-os-ep-filter-ext.html#project-to-endpoint-group-relationship ) for keystone client. Are any of you already behind this?. Cheers, Marcos. __ 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 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 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] [kolla] New Meeting Times Wednesday 1600UTC (even)/2200UTC (odd)
On Sun, May 10, 2015 at 08:49:11PM +, Steven Dake (stdake) wrote: I have closed the doodle poll for our new meeting times. We will be meeting in #openstack-meeting-3 (yes there is that much contention for our time slots – must be a reason ;). The times are: Weekly Wednesday 1600 UTC (even weeks) This conflicts with the Neutron Drivers meeting. Which starts at 15:30 in #openstack-meeting-3 If you switch to #openstack-meeting-4 That'd remove the conflict. #openstack-meeting-4 is free on your 'odd' week also. Yours Tony. pgp23xqXQQZns.pgp 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
Re: [openstack-dev] [kolla] New Meeting Times Wednesday 1600UTC (even)/2200UTC (odd)
On 5/10/15, 5:06 PM, Tony Breeds t...@bakeyournoodle.com wrote: On Sun, May 10, 2015 at 08:49:11PM +, Steven Dake (stdake) wrote: I have closed the doodle poll for our new meeting times. We will be meeting in #openstack-meeting-3 (yes there is that much contention for our time slots must be a reason ;). The times are: Weekly Wednesday 1600 UTC (even weeks) This conflicts with the Neutron Drivers meeting. Which starts at 15:30 in #openstack-meeting-3 If you switch to #openstack-meeting-4 That'd remove the conflict. #openstack-meeting-4 is free on your 'odd' week also. Yours Tony. Tony, Thanks for the heads up. I did search for 1600 UTC on the meetings page, but the neutron-drivers meeting starts at 15:30 which I didn¹t search for. Folks, we will be using openstack-meeting-4. Regards -steve __ 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] [Murano] [Mistral] SSH workflow action
Im planning on deploying murano but wont be supporting the murano guest agent. The lack of multi tenant security is a big problem I think. Thanks, Kevin From: Stan Lagun Sent: Saturday, May 09, 2015 7:21:17 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Murano] [Mistral] SSH workflow action Filip, If I got you right the plan is to have Murano application execute Mistral workflow that SSH to VM and executes particular command? And alternative is Murano-Mistral-Zaquar-Zaquar agent? Why can't you just send this command directly from Murano (to Murano agent on VM)? This is the most common use case that is found in nearly all Murano applications and it is battle-proven. If you need SSH you can contribute SSH plugin to Murano (Mistral will require similar plugin anyway). The more moving parts you involve the more chances you have for everything to fail Sincerely yours, Stan Lagun Principal Software Engineer @ Mirantis mailto:sla...@mirantis.com On Fri, May 8, 2015 at 11:22 AM, Renat Akhmerov rakhme...@mirantis.commailto:rakhme...@mirantis.com wrote: Generally yes, std.ssh action works as long as network infrastructure allows access to a host using specified IP, it doesn’t provide anything on top of that. On 06 May 2015, at 22:26, Fox, Kevin M kevin@pnnl.govmailto:kevin@pnnl.gov wrote: This would also probably be a good use case for Zaqar I think. Have a generic run shell commands from Zaqar queue agent, that pulls commands from a Zaqar queue, and executes it. The vm's don't have to be directly reachable from the network then. You just have to push messages into Zaqar. Yes, in Mistral it would be another action that puts a command into Zaqar queue. This type of action doesn’t exist yet but it can be plugged in easily. Should Mistral abstract away how to execute the action, leaving it up to Mistral how to get the action to the vm? Like I mentioned previously it should be just a different type of action: “zaqar.something” instead of “std.ssh”. Mistral engine itself works with all actions equally, they are just basically functions that we can plug in and use in Mistral workflow language. From this standpoint Mistral is already abstract enough. If that's the case, then ssh vs queue/agent is just a Mistral implementation detail? More precisely: implementation detail of Mistral action which may not be even hardcoded part of Mistral, we can rather plug them in (using stevedore underneath). Renat Akhmerov @ Mirantis Inc. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [keystone][clients] - Should we implement project to endpoint group?
Hi Marcos, I'm not part of the OpenStack development team but coincidently I implemented some of these actions on a fork the past week because I needed them in a project. If there is interest in these actions I could contribute them back or send a link to the repo if it would be helpful for you or someone else. Let me know if I can help. Cheers, Enrique. On Fri, 8 May 2015 at 16:03 Marcos Fermin Lobo marcos.fermin.l...@cern.ch wrote: Hi all, I would like to know if any of you would be interested to implement project to endpoint group actions ( http://specs.openstack.org/openstack/keystone-specs/api/v3/identity-api-v3-os-ep-filter-ext.html#project-to-endpoint-group-relationship) for keystone client. Are any of you already behind this?. Cheers, Marcos. __ 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 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
