[openstack-dev] [Sahara] Swift trust authentication, status and concerns

2014-08-07 Thread Michael McCune
hi Sahara folks, This serves as a detailed status update for the Swift trust authentication spec[1], and to bring up concerns about integration for the Juno cycle. So far I have pushed a few reviews that start to lay the groundwork for the infrastructure needed to complete this blueprint. I

[openstack-dev] [Sahara] Swift authentication and backwards compatibility

2014-08-14 Thread Michael McCune
hello Sahara folks, I am working to get the revamped spec[1] finalized and I'd like to know the group's thoughts on the idea of backward compatibility. It is possible to implement the new authentication method and remain backward compatible, but we will need to keep the username and password

Re: [openstack-dev] [sahara] Notes on developing Sahara Spark EDP to work with swift:// paths

2014-08-28 Thread Michael McCune
hi Gil, that's cool about the patch to Spark, has there been any talk about upgrading that patch to include Keystone v3 operations? - Original Message - Hi, In case this is helpful for you, this is the patch i submitted to Spark about Swift and Spark integration ( about to be

[openstack-dev] [Sahara][FFE] Requesting exception for Swift trust authentication blueprint

2014-09-05 Thread Michael McCune
hey folks, I am requesting an exception for the Swift trust authentication blueprint[1]. This blueprint addresses a security bug in Sahara and represents a significant move towards increased security for Sahara clusters. There are several reviews underway[2] with 1 or 2 more starting today or

Re: [openstack-dev] [sahara] Juno release images

2014-09-23 Thread Michael McCune
- Original Message - If someone uses Fedora images I can add their. I can generate Fedora images, I'll post here when they are ready. mike ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org

Re: [openstack-dev] [sahara] Juno release images

2014-09-23 Thread Michael McCune
- Original Message - Mike, please, propose a CR to our docs w/ Fedora images when it'll be ready. will do mike ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org

Re: [openstack-dev] [sahara] Juno release images

2014-09-24 Thread Michael McCune
here are the updated fedora images, could we get them hosted at sahara-files.mirantis.com please https://mimccune.fedorapeople.org/sahara-juno-vanilla-1.2.1-fedora-20.qcow2 https://mimccune.fedorapeople.org/sahara-juno-vanilla-2.4.1-fedora-20.qcow2 md5sum 7e8a39bb4d43ebf07ceeaf66670d8726

Re: [openstack-dev] [sahara] Nominate Trevor McKay for sahara-core

2014-05-13 Thread Michael McCune
+1 - Original Message - Hey folks, I'd like to nominate Trevor McKay (tmckay) for sahara-core. He is among the top reviewers of Sahara subprojects. Trevor is working on Sahara full time since summer 2013 and is very familiar with current codebase. His code contributions and

Re: [openstack-dev] [sahara] bug triage day after summit

2014-05-20 Thread Michael McCune
I think in our eagerness to triage bugs we might have missed that May 26 is a holiday in the U.S. I know some of us have the day off work and while that doesn't necessarily stop the effort, it might throw a wrench in people's holiday weekend plans. I'm wondering if we should re-evaluate and

Re: [openstack-dev] [sahara] summit wrap-up: backward compat

2014-05-28 Thread Michael McCune
- Original Message - Open questions 1. How should we handle addition of new functionality to the API, should we bump minor version and just add new endpoints? I think we should not include the minor revision number in the url. Looking at some of the other projects (nova,

Re: [openstack-dev] [sahara] summit wrap-up: subprojects

2014-05-29 Thread Michael McCune
- Original Message - sahara-extra Keep it as is, no need to stop releasing, because we're not publishing anything to pypi. No real need for tags. Even if we keep the repo for now, I think we could simplify a little bit. The edp-examples could be moved to the Sahara repo.

Re: [openstack-dev] [sahara] summit wrap-up: subprojects

2014-05-29 Thread Michael McCune
- Original Message - Re sahara-image-elements we found a bunch of issues that we should solve and that's why I think that keeping current releasing is still the best option. - we should test it better and depend on stable diskimage-builder version The dib is now published to pypi,

Re: [openstack-dev] [sahara] summit wrap-up: subprojects

2014-05-29 Thread Michael McCune
- Original Message - the image-elements is too unstable to be used by anyone but an expert at this point. imho we should make sure the experts produce working images first, it's what our users will need in the first place, then make the image generation more stable. +1 mike

Re: [openstack-dev] [api] API recommendation

2014-10-15 Thread Michael McCune
- Original Message - Thoughts? I like this idea. From my experience with the Sahara project I think there is definite opportunity for this mechanic especially with regards to cluster creation and job executions. regards, mike ___

Re: [openstack-dev] [api] Request Validation - Stoplight

2014-10-20 Thread Michael McCune
+1 that's a great way to state it Sam. regards, mike - Original Message - Hi Amit, Keeping in mind this viewpoint is nothing but my own personal view, my recommendation would be to not mandate the use of a particular validation framework, but to instead define what kind of

Re: [openstack-dev] [api] Request Validation - Stoplight

2014-10-20 Thread Michael McCune
- Original Message - However I don't think we should be mandating specific libraries, but we can make recommendations (good or bad) based on actual experience. This will be especially useful to new projects starting up to benefit from the pain other projects have experienced. +1 i

Re: [openstack-dev] [sahara] Nominate Michael McCune to sahara-core

2014-11-14 Thread michael mccune
On 11/14/2014 03:55 AM, Sergey Lukjanov wrote: Congrats! Welcome to the core team! thanks =) mike ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [sahara] Asia friendly IRC meeting time

2014-11-25 Thread michael mccune
On 11/25/2014 02:37 AM, Zhidong Yu wrote: I know it's difficult to find a time good for both US, Europe and Asia. I suggest we could have two different meeting series with different time, i.e. US/Europe meeting this week, US/Asia meeting next week, and so on. i'd be ok with alternating week

Re: [openstack-dev] [api] API Definition Formats

2015-02-02 Thread michael mccune
On 02/02/2015 10:26 AM, Chris Dent wrote: pecan-swagger looks cool but presumably pecan has most of the info you're putting in the decorators in itself already? So, given an undecorated pecan app, would it be possible to provide it to a function and have that function output all the paths?

Re: [openstack-dev] The API WG mission statement

2015-02-03 Thread michael mccune
On 02/02/2015 08:58 AM, Chris Dent wrote: This is pretty good but I think it leaves unresolved the biggest question I've had about this process: What's so great about converging the APIs? If we can narrow or clarify that aspect, good to go. +1, really good point The implication with your

Re: [openstack-dev] The API WG mission statement

2015-02-03 Thread michael mccune
On 02/02/2015 02:51 PM, Stefano Maffulli wrote: To improve developer experience converging the OpenStack API to a consistent and pragmatic RESTful design. The working group creates guidelines that all OpenStack projects should follow, avoids introducing

Re: [openstack-dev] The API WG mission statement

2015-02-03 Thread michael mccune
On 02/03/2015 01:49 PM, Everett Toews wrote: I think where we want to focus our attention is: * strict adherence to correct HTTP * proper use of response status codes * effective (and correct) use of a media types * some guidance on how to deal with change/versioning * and _maybe_ a standard

Re: [openstack-dev] [API] Upgrading to API WG Recommendations

2015-01-15 Thread michael mccune
On 01/14/2015 08:40 PM, Ian Cordasco wrote: The point was brought up that some recommendations that the working group forms will be jarring for APIs to implement when going from vN.* to vN+1.0 for both developers and consumers. Client libraries often provide compatibility (or upgrade-path)

Re: [openstack-dev] [api] API Definition Formats

2015-01-29 Thread michael mccune
On 01/28/2015 12:56 PM, Max Lincoln wrote: tl;dr: I wanted to be able to see what OpenStack APIs might look like in Swagger and starting experimenting with Swagger in projects for things like stubbing services, API test coverage, and code generation. In order to do that I created wadl2swagger

Re: [openstack-dev] [API] Do we need to specify follow the HTTP RFCs?

2015-02-13 Thread michael mccune
On 02/12/2015 02:20 PM, Ryan Brown wrote: +1 I think the way to go would be: We suggest (pretty please) that you comply with RFCs 7230-5 and if you have any questions ask us. Also here are some examples of usage that is/isn't RFC compliant for clarity +1, i like the idea of pointing readers

Re: [openstack-dev] [sahara] Shell Action, Re: Running HBase Jobs (was: About Sahara Oozie plan)

2015-02-13 Thread michael mccune
On 02/12/2015 05:15 PM, Trevor McKay wrote: Hi folks, Here is another way to do this. Lu had mentioned Oozie shell actions previously. Sahara doesn't support them, but I played with it from the Oozie command line to verify that it solves our hbase problem, too. We can potentially create a

Re: [openstack-dev] [Sahara] [Heat] validating properties of Sahara resources in Heat

2015-01-07 Thread michael mccune
hi Pavlo, i'm not sure i can answer all these questions but i'll give it my best shot and hopefully others will chime in =) On 01/05/2015 08:17 AM, Pavlo Shchelokovskyy wrote: floating_ip_pool: I was pointed that Sahara could be configured to use netns/proxy to access the cluster VMs

Re: [openstack-dev] [OSSG] Announcement: I'll be transitioning away from OpenStack

2015-03-16 Thread michael mccune
On 03/16/2015 05:52 PM, Bryan D. Payne wrote: I have about one more week working with OpenStack full time. After that, I am still planning on coming to the summit in May, and would be happy to help with any final transition pieces at that time. And I'll continue being available at this email

Re: [openstack-dev] [Sahara] Question about Sahara API v2

2015-03-30 Thread michael mccune
On 03/30/2015 07:02 AM, Sergey Lukjanov wrote: My personal opinion for API 2.0 - we should discuss design of all object and endpoint, review how they are used from Horizon or python-saharaclient and improve them as much as possible. For example, it includes: * get rid of tons of extra optional

Re: [openstack-dev] [api] API WG Meeting Time

2015-04-01 Thread michael mccune
On 04/01/2015 08:35 AM, Jay Pipes wrote: On 03/31/2015 10:13 PM, Everett Toews wrote: Ever since daylight savings time it has been increasing difficult for many API WG members to make it to the Thursday 00:00 UTC meeting time. Do we change it so there’s only the Thursday 16:00 UTC meeting

Re: [openstack-dev] [API] #openstack-api created

2015-03-04 Thread michael mccune
huzzah! thanks Ian =) mike __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

Re: [openstack-dev] [all] creating a unified developer reference manual

2015-02-25 Thread michael mccune
On 02/25/2015 02:54 PM, Doug Hellmann wrote: During yesterday’s cross-project meeting [1], we discussed the Eventlet Best Practices” spec [2] started by bnemec. The discussion of that spec revolved around the question of whether our cross-project specs repository is the right place for this

Re: [openstack-dev] [api] [glance] conclusion needed on functional API

2015-02-24 Thread michael mccune
On 02/24/2015 03:09 AM, Flavio Percoco wrote: On 22/02/15 22:43 -0500, Jay Pipes wrote: On 02/18/2015 06:37 PM, Brian Rosmaita wrote: Thanks for your comment, Miguel. Your suggestion is indeed very close to the RESTful ideal. However, I have a question for the entire API-WG. Our (proposed)

Re: [openstack-dev] [api] API WG Meeting Time

2015-04-23 Thread michael mccune
On 03/31/2015 10:13 PM, Everett Toews wrote: Ever since daylight savings time it has been increasing difficult for many API WG members to make it to the Thursday 00:00 UTC meeting time. Do we change it so there’s only the Thursday 16:00 UTC meeting time? this topic was brought up again at

Re: [openstack-dev] [nova][api] API working group liaisons and responsibilities

2015-04-30 Thread michael mccune
+1, i think this is really nice mike On 04/30/2015 10:54 AM, Jay Pipes wrote: Hi Stackers, OK, so Matthew Gilliard and Alex Xu have volunteered to be the Nova team's liaisons to the API working group. Big thank you to Matthew and Alex for volunteering for this important role. I've created a

Re: [openstack-dev] [api] Proposing Michael McCune as an API Working Group core

2015-05-14 Thread michael mccune
On 05/14/2015 12:58 PM, Everett Toews wrote: Top posting to make it official...Michael McCune (elmiko) is an API Working Group core! Cheers, Everett thanks everybody! =) mike __ OpenStack Development Mailing List

Re: [openstack-dev] [api] API WG Meeting Time

2015-04-17 Thread michael mccune
On 04/16/2015 05:25 PM, Everett Toews wrote: It would be good to hear from those in Asia, Australia, and Europe on the subject. +1 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe:

[openstack-dev] [all][api] 3 new guidelines entering freeze period

2015-06-04 Thread michael mccune
The API working group has three new guidelines that are entering the 1 week freeze period. We would like to ask all PTLs and CPLs, and other interested parties, to take a look at these reviews. We will use lazy consensus at the end of the freeze to merge them if there are no objections.

[openstack-dev] [all][api] 1 new guideline entering freeze period

2015-06-09 Thread michael mccune
The API working group has one new guidelines that is entering the freeze period. We would like to ask all PTLs and CPLs, and other interested parties, to take a look at these reviews. We will use lazy consensus at the end of the freeze to merge them if there are no objections. The guideline

[openstack-dev] [sahara] Migrating to use Keystone Session objects

2015-06-09 Thread michael mccune
hi saharans, i have been doing some research into converting our current authentication to use the Keystone Session objects[1] instead of the various methods that are now used with the openstack clients. this effort has some wide-ranging implications as we will need to convert our usage of

[openstack-dev] [all][api] API working group proposed guideline merge process

2015-06-04 Thread michael mccune
hi all, The API working group has put together a more comprehensive process for merging guidelines. This process is currently under review[1], and we would like to invite all PTLs and CPLs to take a look and tell us if we are missing something. This review will most likely stay open until

Re: [openstack-dev] [Sahara] Why Sahara request user to give username/password for accessing the job binary in Swift ?

2015-06-25 Thread michael mccune
hi Chen, i agree with Sergey has said, also i have posted a small article[1] about how i configure proxy domains. i hope this may help clear the confusion surrounding this feature. regards, mike [1]: https://elmiko.github.io/2015/06/25/configuring-sahara-with-proxy-domains.html

[openstack-dev] [all][api] New API Guidelines ready for cross project review

2015-06-26 Thread michael mccune
hi all, we have 1 API guideline that is ready for final review 1. Adds clarifications on state-conflicting requests https://review.openstack.org/#/c/180094 if the API working group hasn't received any further feedback, we'll merge this on July 3. regards, mike

Re: [openstack-dev] [Security] Nominating Travis McPeak for Security CoreSec

2015-06-16 Thread michael mccune
On 06/16/2015 05:28 AM, Clark, Robert Graham wrote: I’d like to nominate Travis for a CoreSec position as part of the Security project. - CoreSec team members support the VMT with extended consultation on externally reported vulnerabilities. Travis has been an active member of the Security

Re: [openstack-dev] [Security][VMT] Promoting Michael McCune and Travis McPeak to Security CoreSec

2015-07-01 Thread michael mccune
On 07/01/2015 06:58 AM, Clark, Robert Graham wrote: With various +1’s and no objections I’m pleased to announce that Michael and Travis are now added to the ossg-coresec team. This team assists the VMT with vulnerability metrics, triage and of course OpenStack Security Notes. Congratulations

Re: [openstack-dev] [Sahara] Why Sahara request user to give username/password for accessing the job binary in Swift ?

2015-07-06 Thread michael mccune
hi chen, responses inline On 07/06/2015 04:38 AM, Li, Chen wrote: Thanks. This is very helpful. A little more questions about how to config: 1. What should be set in [keystone_authtoken] in sahara.conf ? As code at

Re: [openstack-dev] [api] [docs] improving app Dev docs

2015-05-21 Thread michael mccune
On 05/21/2015 01:10 PM, Anne Gentle wrote: Hi all, please come to the API doc working session this morning at 11:50 in 305 if you want to work on plans for next-gen API docs in Liberty. https://libertydesignsummit.sched.org/mobile/#session:29e7d4effc10832b4d6aa50339e0c973 is there an

Re: [openstack-dev] [sahara] Proposing Ethan Gafford for the core reviewer team

2015-08-13 Thread michael mccune
+1, Ethan has been a great asset to the team. mike On 08/13/2015 10:56 AM, Sergey Lukjanov wrote: Hi folks, I'd like to propose Ethan Gafford as a member of the Sahara core reviewer team. Ethan contributing to Sahara for a long time and doing a great job on reviewing and improving Sahara.

Re: [openstack-dev] [all][api] New API Guidelines ready for cross project review

2015-08-18 Thread michael mccune
On 08/11/2015 10:28 AM, michael mccune wrote: 1. Add new guideline for HTTP Headers https://review.openstack.org/#/c/186526/ 2. Add advice on when to use POST or PUT in create https://review.openstack.org/#/c/181912/ 3. Clarify the return code when server have hard-code length limit https

Re: [openstack-dev] [all][api] New API Guidelines ready for cross project review

2015-08-18 Thread michael mccune
On 08/11/2015 10:28 AM, michael mccune wrote: 1. Add new guideline for HTTP Headers https://review.openstack.org/#/c/186526/ 2. Add advice on when to use POST or PUT in create https://review.openstack.org/#/c/181912/ 3. Clarify the return code when server have hard-code length limit https

Re: [openstack-dev] [Sahara] Why Sahara request user to give username/password for accessing the job binary in Swift ?

2015-06-26 Thread michael mccune
On 06/25/2015 09:54 PM, Li, Chen wrote: Thanks for the reply. My puzzle here is : I create containers objects by my own, why other users can access them ? As mentioned in your article[1], the domain sahara_proxy is created by user admin in project openstack. But I'm working under

[openstack-dev] [keystone] policy issues when generating trusts with different clients

2015-08-03 Thread michael mccune
hi all, i am doing some work to change sahara to make greater use of keystoneclient.session.Session objects and i am running into a strange error when issuing the trusts. the crux of this issue is that when i create Client objects by passing all the parameters directly to the client, the

[openstack-dev] [api] PATCH guidelines concerning body content

2015-07-30 Thread michael mccune
hi all, recently a discussion came up in irc[1] about the guidance we can provide concerning PATCH body contents. essentially the issue comes down to what we should be recommending for updating resources; rfc6902 type patching, partial resource updates on PATCH, or a different methodology

[openstack-dev] [all][api] New API Guidelines read for cross project review

2015-08-04 Thread michael mccune
hey all, we have 2 API Guidelines that are ready for final review. 1. No project uses f_ prefix in filter params https://review.openstack.org/#/c/198547/ 2. RFC 5789 doesn't specify certain uses of PUT https://review.openstack.org/#/c/199597/ if the API Working Group hasn't received any

Re: [openstack-dev] [keystone] policy issues when generating trusts with different clients

2015-08-05 Thread michael mccune
On 08/05/2015 02:34 AM, Steve Martinelli wrote: I think this is happening because the last session created was based off of trustee_auth. Try creating 2 sessions, one for each user (trustor and trustee). Maybe Jamie will chime in. thanks for the reply Steve, i will give that a try. my

Re: [openstack-dev] [keystone] policy issues when generating trusts with different clients

2015-08-05 Thread michael mccune
On 08/05/2015 02:34 AM, Steve Martinelli wrote: I think this is happening because the last session created was based off of trustee_auth. Try creating 2 sessions, one for each user (trustor and trustee). Maybe Jamie will chime in. just as a followup, i tried creating new Session objects for

[openstack-dev] [sahara] update methods

2015-08-05 Thread michael mccune
hey all, the recent discussions[1] on updating resources through the rest api has got me thinking that it might be worthwhile to convert the few methods we have implemented to use PATCH instead of PUT. we are starting to create a bifurcation in the api regarding updates. the new

Re: [openstack-dev] [sahara] update methods

2015-08-05 Thread michael mccune
On 08/05/2015 01:31 PM, Luigi Toscano wrote: Isn't this an API change, which would require an API bump? A reason more to keep it working as it is with 1.x and go fast to 2.0. thanks Luigi, that's fair. i'll hold off on this until we can bump to 2.0. it also means i need to get a move on with

[openstack-dev] [all][api] New API Guidelines ready for cross project review

2015-08-11 Thread michael mccune
hi all, we have 3 API Guidelines that are ready for final review. 1. Add new guideline for HTTP Headers https://review.openstack.org/#/c/186526/ 2. Add advice on when to use POST or PUT in create https://review.openstack.org/#/c/181912/ 3. Clarify the return code when server have hard-code

Re: [openstack-dev] [keystone] policy issues when generating trusts with different clients

2015-08-06 Thread michael mccune
On 08/05/2015 10:27 PM, Jamie Lennox wrote: Hey Mike, I think it could be one of the hacks that are in place to try and keep compatibility with the old and new way of using the client is returning the wrong thing. Compare the output of trustor.user_id and trustor_auth.get_user_id(sess). For

Re: [openstack-dev] [glance][api] Response when a illegal body is sent

2015-07-23 Thread michael mccune
On 07/23/2015 12:43 PM, Ryan Brown wrote: On 07/23/2015 12:13 PM, Jay Pipes wrote: On 07/23/2015 10:53 AM, Bunting, Niall wrote: Hi, Currently when a body is passed to an API operation that explicitly does not allow bodies Glance throws a 500. Such as in this bug report:

Re: [openstack-dev] [all][api] New API Guidelines read for cross project review

2015-07-17 Thread michael mccune
On 07/17/2015 05:50 AM, Thierry Carrez wrote: michael mccune wrote: hey all, we have 4 API Guidelines that are ready for final review. 1. Add generic name of each project for terms https://review.openstack.org/#/c/196918/ 2. Add new guideline for HTTP Headers https://review.openstack.org/#/c

Re: [openstack-dev] [Sahara] Questions about how Sahara use trust ?

2015-07-13 Thread michael mccune
On 07/13/2015 09:40 PM, Li, Chen wrote: Hi mike, Thanks, this is very helpful. Summary: 1. The purpose of admin user proxy user are the same = to work without user's own username password. sort of, the proxy user is to work without the user's credentials, whereas the admin user needs a

[openstack-dev] [all][api] New API Guidelines read for cross project review

2015-07-16 Thread michael mccune
hey all, we have 4 API Guidelines that are ready for final review. 1. Add generic name of each project for terms https://review.openstack.org/#/c/196918/ 2. Add new guideline for HTTP Headers https://review.openstack.org/#/c/186526/ 3. Adds guidance on request bodies with different Methods

[openstack-dev] [sahara] keystone session upgrade

2015-07-16 Thread michael mccune
hi all, i've been researching, and coding, about how to upgrade sahara to use keystone sessions for authentication instead of our current method. i'm running into some issues that i believe might make the current proposed approach[1] unfeasible. one issue i'm running into is the nature of

Re: [openstack-dev] [all][api] New API Guidelines read for cross project review

2015-07-17 Thread michael mccune
On 07/17/2015 12:33 PM, Thierry Carrez wrote: michael mccune wrote: On 07/17/2015 05:50 AM, Thierry Carrez wrote: Note that we won't be having a cross-project meeting on July 21st, so these won't get the opportunity to get discussed in that forum. So you might want to delay that final approval

Re: [openstack-dev] [sahara] keystone session upgrade

2015-07-17 Thread michael mccune
On 07/16/2015 04:31 PM, michael mccune wrote: i will also likely be rewriting the spec to encompass these changes if i can get them working locally. just wanted to follow up before i rewrite the spec. i think the most sensible approach at this point is to store an auth plugin object in our

Re: [openstack-dev] [Sahara] Questions about how Sahara use trust ?

2015-07-13 Thread michael mccune
On 07/12/2015 09:45 PM, Li, Chen wrote: Hi Andrew, Thanks for the reply. Are you mean : 1. admin user is used by transient cluster is mainly to make it work. 2. The proxy user is the more secure way to do the same thing. Should we use proxy user at all situation then ? Should

Re: [openstack-dev] [sahara] keystone session upgrade

2015-07-20 Thread michael mccune
On 07/17/2015 07:55 PM, Jamie Lennox wrote: So I'm not familiar with how Sahara handles contexts however from a theoretical stand point anything that is defined in config should be able to be cached globally. So service specific sessions, and admin auth. The context typically would contain

Re: [openstack-dev] [security] The first version of the Logo for Openstack Security Project

2015-10-22 Thread michael mccune
On 10/21/2015 05:11 PM, Michael Xin wrote: Rob and Michael: Thanks for the update. We will probably not use any Openstack Logo. Here is the first draft of the flyer: http://5a6aa6580e900b8e8020-e5e45c5cb10329ebc9fb69948bb1b1a5.r65.cf1.rackcdn.com/ossp-flag-flyer.pdf Please send us your

Re: [openstack-dev] [security] The first version of the Logo for Openstack Security Project

2015-10-21 Thread michael mccune
On 10/21/2015 03:54 AM, Michael Xin wrote: Hi, guys: Thanks for your help. We are designing a logo and a flyer for Openstack Security Project. Rachel helped us with the task. Attached is her first version of the logo. Please let us know your feedback.

Re: [openstack-dev] [security] The first version of the Logo for Openstack Security Project

2015-10-21 Thread michael mccune
On 10/21/2015 05:11 PM, Michael Xin wrote: Rob and Michael: Thanks for the update. We will probably not use any Openstack Logo. Here is the first draft of the flyer: http://5a6aa6580e900b8e8020-e5e45c5cb10329ebc9fb69948bb1b1a5.r65.cf1.rackcdn.com/ossp-flag-flyer.pdf Please send us your

Re: [openstack-dev] [api] consolidate IRC change with #openstack-sdk?

2015-11-16 Thread michael mccune
On 11/16/2015 09:42 AM, Sean Dague wrote: On 11/16/2015 09:34 AM, michael mccune wrote: On 11/13/2015 07:58 AM, Sean Dague wrote: The #openstack-api IRC channel is quite quiet most days. As such it's not something that people are regularly checking in on, or often forget about (I know I've

Re: [openstack-dev] [api] consolidate IRC change with #openstack-sdk?

2015-11-16 Thread michael mccune
On 11/13/2015 07:58 AM, Sean Dague wrote: The #openstack-api IRC channel is quite quiet most days. As such it's not something that people are regularly checking in on, or often forget about (I know I've been guilty of that). Plus we don't always have the right people in a conversation to make a

Re: [openstack-dev] [all][api][tc][perfromance] API for getting only status of resources

2015-11-03 Thread michael mccune
On 11/03/2015 05:20 PM, Boris Pavlovic wrote: What if we add new API method that will just resturn resource status by UUID? Or even just extend get request with the new argument that returns only status? Thoughts? not sure i understand the resource status by UUID, could you explain that a

Re: [openstack-dev] [sahara] Proposing Vitaly Gridnev to core reviewer team

2015-10-15 Thread michael mccune
congrats Vitaly! On 10/15/2015 10:38 AM, Sergey Lukjanov wrote: I think we have a quorum. Vitaly, congrats! On Tue, Oct 13, 2015 at 6:39 PM, Matthew Farrellee > wrote: +1! On 10/12/2015 07:19 AM, Sergey Lukjanov wrote: Hi folks,

Re: [openstack-dev] [sahara] Proposing Vitaly Gridnev to core reviewer team

2015-10-12 Thread michael mccune
i'm +1 for this, Vitaly has been doing a great job contributing code and reviews to the project. mike On 10/12/2015 07:19 AM, Sergey Lukjanov wrote: Hi folks, I'd like to propose Vitaly Gridnev as a member of the Sahara core reviewer team. Vitaly contributing to Sahara for a long time and

Re: [openstack-dev] [sahara] Bug triage/fix and doc update days in Liberty

2015-08-26 Thread michael mccune
hey Saharans, with Doc fix day fast approaching i wanted to send out an email with the etherpad again, https://etherpad.openstack.org/p/sahara-liberty-doc-update-day it has been updated with all the docs and we are ready to roll starting on monday aug 31. mike On 08/24/2015 09:41 AM,

Re: [openstack-dev] [Openstack] [Horizon] [Sahara] FFE request for Sahara unified job interface map UI

2015-09-04 Thread michael mccune
On 09/04/2015 10:40 AM, Ethan Gafford wrote: Hello all, I request a FFE for the change at: https://review.openstack.org/#/c/209683/ This change enables a significant improvement to UX in Sahara's elastic data processing flow which is already in the server and client layers of Sahara. Because

Re: [openstack-dev] [sahara] FFE request for heat wait condition support

2015-09-04 Thread michael mccune
makes sense to me, +1 mike On 09/04/2015 06:37 AM, Vitaly Gridnev wrote: +1 for FFE, because of 1. Low risk of issues, fully covered with current scenario tests; 2. Implementation already on review On Fri, Sep 4, 2015 at 12:54 PM, Sergey Reshetnyak

Re: [openstack-dev] [sahara] Request for Feature Freeze Exception

2015-09-03 Thread michael mccune
On 09/03/2015 02:49 PM, Vitaly Gridnev wrote: Hey folks! I would like to propose to add to list of FFE's following blueprint: https://blueprints.launchpad.net/sahara/+spec/drop-hadoop-1 Reasoning of that is following: 1. HDP 1.3.2 and Vanilla 1.2.1 are not gated for a whole release cycle,

Re: [openstack-dev] Getting Started : OpenStack

2015-09-08 Thread michael mccune
On 09/08/2015 02:05 PM, Bhagyashree Uday wrote: Hi Victoria , Thanks for the prompt reply. I go by Bee(IRC nick : bee2502) .There doesn't seem to be much information regarding this project even on the Ceilometer project page :( I will wait till the next Outreachy applications begin though to

Re: [openstack-dev] [api] [docs] Generating API samples

2015-08-25 Thread michael mccune
On 08/24/2015 11:51 AM, Anne Gentle wrote: Hi all, I'm writing to find out how teams keep API sample requests and responses up-to-date. I know the nova team has a sample generator [1] that they've maintained for a few years now. Do other teams have something similar? If so, is your approach

Re: [openstack-dev] [Barbican] Nominating Dave Mccowan for Barbican core

2015-09-09 Thread michael mccune
i'm not a core, but +1 from me. Dave has made solid contributions and would be a great addition to the core team. mike On 09/08/2015 12:05 PM, Juan Antonio Osorio wrote: I'd like to nominate Dave Mccowan for the Barbican core review team. He has been an active contributor both in doing

[openstack-dev] [Sahara] FFE request for improved secret storage

2015-09-09 Thread michael mccune
hi all, i am requesting an FFE for the improved secret storage feature. this change will allow operators to utilize the key manager service for offloading the passwords stored by sahara. this change does not implement mandatory usage of barbican, and defaults to a backward compatible

[openstack-dev] [sahara] mitaka summit session ideas

2015-09-10 Thread michael mccune
hey all, i started an etherpad for us to collect ideas about our session for the mitaka summit. https://etherpad.openstack.org/p/mitaka-sahara-session-plans please drop any thoughts or suggestions about the summit there. thanks, mike

[openstack-dev] [sahara] hadoop-openstack.jar and proxy users

2015-09-14 Thread michael mccune
hey all, in doing some work recently with proxy users and hadoop deployments, i am noticing that the modified version of the hadoop-openstack.jar we package from the sahara-extras repo is not being used in our current images. this jar file adds support for keystone v3 to the swift interface

Re: [openstack-dev] [Sahara] FFE request for improved secret storage

2015-09-17 Thread michael mccune
i am retracting this request, i think this feature would benefit from more time to test and review. thanks for the consideration, mike On 09/09/2015 12:09 PM, michael mccune wrote: hi all, i am requesting an FFE for the improved secret storage feature. this change will allow operators

Re: [openstack-dev] [sahara] FFE request for nfs-as-a-data-source

2015-09-09 Thread michael mccune
i'm +1 for this feature as long as we talking about just the sahara controller and saharaclient. i agree we probably cannot get the horizon changes in before the final release. mike On 09/09/2015 03:33 AM, Chen, Weiting wrote: Hi, all. I would like to request FFE for nfs as a data source

Re: [openstack-dev] [Security] Weekly Meeting Agenda

2015-09-23 Thread michael mccune
On 09/23/2015 02:56 PM, Clark, Robert Graham wrote: Hi All, I won’t be available to run the weekly meeting tomorrow as I’m out travelling, Michael McCune (elmiko) has volunteered to lead the meeting. There’s IRC information on our wiki page : https://wiki.openstack.org/wiki/Security Agenda

Re: [openstack-dev] [api] [wsme] [ceilometer] Replacing WSME with _____ ?

2015-08-28 Thread michael mccune
On 08/28/2015 10:36 AM, Lucas Alvares Gomes wrote: So at the present moment the [micro]framework that comes to my mind - without any testing or prototype of any sort - is Flask. just wanted to add on here, sahara is using flask. mike

Re: [openstack-dev] [all] making project_id optional in API URLs

2015-12-08 Thread michael mccune
On 12/03/2015 12:06 PM, Sean Dague wrote: So, for Cinder, Glance, Ironic, Manila, Magnum (and others I might have missed) where are you standing on this one? And are there volunteers in those projects to help move this forward? i'm +1 for removing the project_id from the url. sahara uses it

Re: [openstack-dev] [all] making project_id optional in API URLs

2015-12-09 Thread michael mccune
On 12/08/2015 05:59 PM, Adam Young wrote: I think it is kindof irrelevant. It can be there or not be there in the URL itself, so long as it does not show up in the service catalog. From an policy standpoint, having the project in the URL means that you can do an access control check without

Re: [openstack-dev] [trove] [sahara] Adding support for HBase in Trove

2016-01-09 Thread michael mccune
On 01/08/2016 08:34 AM, Amrith Kumar wrote: As Kevin suggests, I'm adding [sahara] to the subject line. Others in sahara who now see this thread, apologies for sending you a delayed invitation to the party. There's still lots of food and beer so come on in! Amrith, thanks for reposting

Re: [openstack-dev] [doc] [api] Vision and changes for OpenStack API Guides

2016-01-08 Thread michael mccune
On 01/08/2016 04:39 PM, Anne Gentle wrote: Join me next week at the first pop-up Cross Project meeting, Tuesday at 1700, in #openstack-meeting-cp. Feel free to add to the agenda at i'll definitely be there Anne, i'm very curious about this topic but sadly have not had the extra cycles to

Re: [openstack-dev] [api] consolidate IRC change with #openstack-sdk?

2015-11-30 Thread michael mccune
On 11/30/2015 08:45 AM, Sean Dague wrote: Ok, I'm going to assume with no real disagreement we're agreed here. I'm moving the api-wg notifications to #openstack-sdks now - https://review.openstack.org/#/c/251357/1/gerritbot/channels.yaml,cm ok, i think we've got a few spots in the

Re: [openstack-dev] [cross-project] Cross-project Liaisons

2015-12-01 Thread michael mccune
On 11/30/2015 08:30 PM, Mike Perez wrote: Hello all, Currently for cross-project specs, the author of the spec spends the time to explain why a certain feature makes sense to be across multiple projects. This also includes giving technical solutions for it working with a variety of services and

[openstack-dev] [security][sahara] creating a threat analysis to aid operators

2015-11-19 Thread michael mccune
hello all, during the security midcycle meetup we had a session about creating threat analysis for openstack projects. the folks at HPE were kind enough to offer their documentation and examples as an aid to creating these analysis. after talking with the sahara team, i am confident that we

[openstack-dev] [api] link definitions guideline to help align differing styles

2015-11-23 Thread michael mccune
hello all, there has recently been some activity in the guidelines surrounding the use of links embedded in response objects. it appears that with the recently merged error guideline[1] and the currently frozen pagination guideline[2], that we are on the precipice of introducing a bifurcation

Re: [openstack-dev] [trove][neutron][cinder][swift][ceilometer][nova][keystone][sahara][glance][neutron-lbaas][imm] stylistic changes to code, how do we handle them?

2016-01-12 Thread michael mccune
On 01/12/2016 08:51 AM, Amrith Kumar wrote: My question to the ML is this, should stylistic changes of this kind be handled in a consistent way across all projects, maybe with a hacking rule and some discussion on the ML first? After all, if this change is worthwhile, it is worth ensuring

  1   2   >