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

[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 inputs in the Swift data forms.

Having the backward compatibility would also give Sahara a way to react in 
situations where the proxy domain is not available or the administrator doesn't 
wish to use it. I'm not sure this is the behavior we want, but I don't know if 
it is proper for Sahara to exit if no proxy domain can be found.

If we choose not to remain backward compatible then we are requiring Sahara 
operators to create the new proxy domain needed, and they must update all 
virtual machine images.

Thoughts?

regards,
mike

[1]: https://review.openstack.org/#/c/113591/

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[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 merged )
> https://github.com/apache/spark/pull/1010
> 
> I sent information about this patch to this mailing list about two months
> ago.
> 
> All the best,
> Gil.
> 
> 
> 
> 
> 
> From:   Trevor McKay 
> To: OpenStack Development Mailing List
> 
> Date:   28/08/2014 06:22 PM
> Subject:[openstack-dev] [sahara] Notes on developing Sahara Spark
> EDP to work with swift:// paths
> 
> 
> 
> Hi folks,
> 
>   I've updated this etherpad with notes from an investigation of
> Spark/Swift and the hadoop-openstack plugin carried in the sahara-extra
> repo.
>  
>   Following the notes there, I was able to access swift:// paths from
> Spark jobs on a Spark standalone cluster launched from Sahara and then
> fixed up by hand.
> 
>   Comments welcome.  This is a POC at this point imho, we have work to
> do to fully integrate this into Sahara.
> 
> https://etherpad.openstack.org/p/sahara_spark_edp
> 
> Best,
> 
> Trevor
> 
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[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 monday.

This feature is initially implemented as optional and as such will have minimal 
impact on current user deployments. By default it is disabled and requires no 
additional configuration or management from the end user.

My feeling is that there has been vigorous debate and discussion surrounding 
the implementation of this blueprint and there is consensus among the team that 
these changes are needed. The code reviews for the bulk of the work have been 
positive thus far and I have confidence these patches will be accepted within 
the next week.

thanks for considering this exception,
mike


[1]: 
https://blueprints.launchpad.net/sahara/+spec/edp-swift-trust-authentication
[2]: 
https://review.openstack.org/#/q/status:open+topic:bp/edp-swift-trust-authentication,n,z

___
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

[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 schedules


My proposal:
 18:00UTC: Moscow (9pm)China(2am) US West(10am)
 00:00UTC: Moscow (3am)China(8am) US West(4pm)



this works for me, but i realize it might be difficult for the folks in 
Russia. not sure if there is a better option though.


thanks for putting this forward Zhidong

regards,
mike

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[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 instead of floating IPs.

My questions are:
- Can that particular configuration setting (netns/proxy) be assessed
via saharaclient?


i don't think so. these are configured through the conf file associated 
with the controller(s) and i don't think we expose an endpoint for 
querying them.



- What would be the result of providing floating_ip_pool when Sahara is
indeed configured with netns/proxy?


i think it will accept the floating_ip_pool values during cluster creation.


   Is it going to function normally, having just wasted several floating
IPs from quota?


if sahara is configured for netns/proxy then it should use that method 
for accessing the nodes. that being said, i think if you provide 
floating ip pools then those will get sent along to the provisioning 
engine, so it may waste the IPs.


this is a case where we could probably check for these values and either 
produce an error or sanitize them. i'll have to test this in a live 
environment.



- And more crucial, what would happen if Sahara is _not_ configured to
use netns/proxy and not provided with floating_ip_pool?


if sahara is configured to _not_ use netns/proxy, but _is_ configured 
for floating pool then you will get an error for not providing the 
floating pool id.



   Can that lead to cluster being created (at least VMs for it spawned)
but Sahara would not be able to access them for configuration?


i don't think so. i think you will get an error when creating the 
cluster(not the template).



   Would Sahara in that case kill the cluster/shutdown VMs or hang in
some cluster failed state?


i don't think it would get that far, you should see an error when 
creating the cluster.



neutron_management_network:
I understand the point that it is redundant to use it in both resources
(although we are stuck with deprecation period as those are part of Juno
release already).

Still, my questions are:
- would this property passed during creation of Cluster override the one
passed during creation of Cluster Template?


in this case, i think the new value will override the original value in 
the template.



- what would happen if I set this property (pass it via saharaclient)
when Nova-network is in use?


i might need a little clarification on this question. but, if you have 
sahara configured to _not_ use neutron and you supply a 
neutron_management_network during cluster template creation, then i 
think sahara will record the network but it won't actually try to 
connect over that network.


this may be another area where we could produce an error if the network 
is supplied.



- what if I _do not_ pass this property and Neutron has several networks
available?


i think this will result in an error during the cluster creation. i know 
sahara will produce an error in this case, i'm just unsure as to when it 
will be generated.



The reason I'm asking is that in Heat we try to follow "fail-fast"
approach, especially for billable resources,
to avoid situation when a (potentially huge) stack is being created and
breaks on last or second-to-last resource,
leaving user with many resources spawned (even if for a short time if
the stack rollback is enabled)
which might cost a hefty sum of money for nothing. That is why we are
trying to validate the template
as thoroughly as we can before starting to create any actual resources
in the cloud.


i totally agree with the "fail-fast" approach, and in general i think 
that sahara will attempt to follow that. in the cases you have described 
above i think the most likely fail conditions will be when attempting 
cluster creation. but, i don't think that the provisioning engine will 
be called unless we can validate these networks.


hopefully this helps,
mike


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[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) versions to help bridge the gap between
going from vN.* to vN+1.0. As a group, we’re looking for feedback from the
developers on the following topics:

- Does this seem preferable?


i think it's a really nice idea to have some sort of guidelines to 
assist with the development of compatibility version. i know i would use 
it =)



- Does it sound reasonable and maintainable?


good question, my fear would be that we would start strong but fade once 
more than a few versions were published. having a clear procedure for 
updating and maintaining the guidelines might help.



- Does it seem reasonable as a way of improving user experience and
upgradability?


for me, yes.


If you have a positive feeling for this idea, there are a couple
follow-ups:

- Should the API WG recommend a strategy for this versioning path?
- If so, should the versioning path work like:

   - vN.M -> vN.99 -> vN+1.0
 We would use .99 to indicate that you it’s compatible with vN.* but
also provides information/endpoints in vN+1)
   - or vN.M -> vN+1.0 -> vN+2.0
 In this case we would make N+1 be the compatibility version (perhaps
do not allow increments of the minor version) and N+2 would be the version
of the API that is fully in-compliance with the Working Group’s final
recommendations.


this is an interesting idea. i think it would be nice if we could 
develop something that would be a clear indication to developers exactly 
which version and capabilities an api is presenting.


of those two options, i'm leaning more towards the vN.99 approach.

thanks for bringing it up Ian!

mike


__
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] [sahara] bug triage day after summit

[Michael McCune]

+1

- Original Message -
> Hey sahara folks,
> 
> let's make a Bug Triage Day after the summit.
> 
> I'm proposing the May, 26 for it.
> 
> Any thoughts/objections?
> 
> Thanks.
> 
> --
> Sincerely yours,
> Sergey Lukjanov
> Sahara Technical Lead
> (OpenStack Data Processing)
> Mirantis Inc.
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[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 reviews have demonstrated
> a good knowledge of Sahara internals. Trevor has a valuable knowledge
> of EDP part and Hadoop itself. He's working on both bugs and new
> features implementation.
> 
> Some links:
> 
> http://stackalytics.com/report/contribution/sahara-group/30
> http://stackalytics.com/report/contribution/sahara-group/90
> http://stackalytics.com/report/contribution/sahara-group/180
> https://review.openstack.org/#/q/owner:tmckay+sahara+AND+-status:abandoned,n,z
> https://launchpad.net/~tmckay
> 
> Sahara cores, please, reply with +1/0/-1 votes.
> 
> Thanks.
> 
> --
> Sincerely yours,
> Sergey Lukjanov
> Sahara Technical Lead
> (OpenStack Data Processing)
> Mirantis Inc.
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[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 make the following day(May 27) triage 
day instead?

regards,
mike

- Original Message -
> Hey sahara folks,
> 
> let's make a Bug Triage Day after the summit.
> 
> I'm proposing the May, 26 for it.
> 
> Any thoughts/objections?
> 
> Thanks.
> 
> --
> Sincerely yours,
> Sergey Lukjanov
> Sahara Technical Lead
> (OpenStack Data Processing)
> Mirantis Inc.
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[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, keystone) it looks like the preference to 
make the version endpoint able to return information about the specific version 
implemented. I think going forward, if we choose to bump the minor version for 
small features we can just change what the version endpoint returns. Any client 
would then be able to decide if they can use newer features based on the 
version reported from the return value. If we maintain a consistent version api 
endpoint then I don't see an issue with increasing the minor version based on 
new features being added. But, I only endorse this if we decide to solidify the 
version endpoint (e.g. /v2, not /v2.1).

I realize this creates some confusion as we already have /v1 and /v1.1. I'm 
guessing we might subsume v1.1 at a point in time where we choose to deprecate.

> 2. For which period of time should we keep deprecated API and client for it?

Not sure what the standard for OpenStack project is, but I would imagine we 
keep the deprecated API version for one release to give users time to migrate.

> 3. How to publish all images and/or keep stability of building images
> for plugins?

This is a good question, I don't have a strong opinion at this time. My gut 
feeling is that we should maintain official images somewhere, but I realize 
this introduces more work in maintenance.

regards,
mike

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[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.  Some of those
> examples we use in the integration tests anyway -- why have them
> duplicated?

+1

i think having the examples in the sahara repo makes it much easier for new 
users.

mike

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[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, so, we could make
> sahara-image-elements in dib-style and publish it to pypi in the same
> style. It makes us able to add some sanity tests for images checking
> and add gate jobs for running them (it could be done anyway, but this
> approach with separated repo looks more consistent). Developing
> sahara-image-elements as a pip-installable project we could add
> diskimage-builder to the requirements.txt of it and manage it's
> version, it'll provide us good flexibility - for example, we'll be
> able to specify to use "latest release dib".
> - all scripts and dib will not be installed with sahara (50/50)

I think if we are going to make sahara-image-elements into a full-fledged pypi 
package we should refactor diskimage-create.sh into a python script. It will 
give up better options for argument parsing and I feel more control over the 
flow of operations.

mike

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[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

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[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
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[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
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[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  sahara-juno-vanilla-1.2.1-fedora-20.qcow2
b218e236be9f95cc86073afa6b248b06  sahara-juno-vanilla-2.4.1-fedora-20.qcow2

i'll create a bug and submit a cr to the doc change with the sahara-files.m.c 
as the location.

thanks,
mike

- Original Message -
> 
> - 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
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[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

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[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 validation clients should
> expect the server to perform in general. For example, I would expect a
> service to return an error code and not perform any action if I called
> "Create server" but did not include a request body, but the actual manner in
> which that error is generated within the service does not matter from the
> client's perspective.
> 
> This is not to say the API Working Group wouldn't help you evaluate the
> potential of Stoplight to meet the needs of a service. To the contrary, by
> clearly defining the expectations of a service's responses to requests,
> you'll have a great idea of exactly what to look for in your evaluation, and
> your final decision would be based on objective results.
> 
> Thank you,
> Sam Harwell

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[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 think it's also important to ensure that these recommendations live in a
place that is easy to find. it would be really nice to have example design
recipes that are commonly used across projects, but i'm not sure if that
gets too far into dictating or mandating certain usage patterns.

regards,
mike

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[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

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

[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 have tried to keep the 
changes as low impact as possible so as not to create incompatible commits. I 
will continue this for as long as makes sense, but we are approaching the point 
at which disruptive changes will be introduced.

Currently, I am working on delegating and revoking trusts for job executions. 
The next steps will be to finish the periodic updater that will distribute 
authentication tokens to cluster instances. After this I plan to start 
integrating the job binaries to use the authentication tokens as this will all 
be contained within Sahara.

Once these pieces are done I will focus on the Swift-Hadoop component and 
finalize the workflow creation to support the new Swift references. I will hold 
these changes until we are ready to switch to this new style of authentication 
as this will be disruptive to our current deployments. I would like to get some 
assistance understanding the Swift-Hadoop component, any guidance would be 
greatly appreciated.

That's the status update, I'm confident that over the next few weeks much of 
this will be implemented and getting ready for review.

I do have concerns around how we will integrate and release this update. Once 
the trust authentication is in place we will be changing the way Swift 
information is distributed to the cluster instances. This means that existing 
vm images will need to be updated with the new Swift-Hadoop component. We will 
need to create new public images for all plugins that use Hadoop and Swift. We 
will also need to update the publicly available versions of the Swift-Hadoop 
component to ensure that Sahara-image-elements continues to work.

We will also need to upgrade the gate testing machines to incorporate these 
changes and most likely I will need to be able to run these tests on a local 
cluster I can control before I push them for review. I am soliciting any advice 
about how I could run the gate tests from my local machine or cluster.

For the new Swift-Hadoop component I propose that we bump the version to 2.0 to 
indicate the incompatibility between it and the 1.0 version.

regards,
mike


[1]: 
https://blueprints.launchpad.net/sahara/+spec/edp-swift-trust-authentication

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[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.

http://5d100f09242e1d85fe65-9262bad2bd2ce9d805c21cb30838f376.r18.cf1.rackcdn.com/os-security-project-logo.png
Thanks and have a great day.


hi Michael, thanks to Rachel for putting this together. i like the 
general concept of the openstack logo as a lock. i think the "lock 
parts" could have a little more depth on them.


you had asked in irc about usage of the openstack logo, i'm not sure. 
but this page, https://www.openstack.org/brand/openstack-logo/ , seems 
to indicate that the usage is pretty limited. in specific, this section 
"You agree that you will not (i) alter or modify the OpenStack Logo as 
provided by the OpenStack Foundation; " seems to indicate that we may 
not be able to use the logo like this. we should probably ask someone 
from the foundation.


all in all though, a nice effort. many thanks =)

mike


__
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] [security] The first version of the Logo for Openstack Security Project

[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 feedback.


+1, i like the look of this flyer. especially the flag logo thingie, 
nicely done!


mike


__
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] [security] The first version of the Logo for Openstack Security Project

[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 feedback.


i think my only suggestion on the text would be to slightly alter the 
second sentence of the "What's the OSSP?" section.


currently it is:

"The Security Project undertakes both technical and governance 
activities within OpenStack, aiming to provide guidance, information and 
code that enhances the overall security of the OpenStack ecosystem"


i would change the beginning to:

"The Security Project undertakes both technical and governance 
activities for the OpenStack community, aiming to provide guidance, 
information and code that enhances the overall security of the OpenStack 
ecosystem"


but i think this is a pretty minor nit.

regards,
mike

__
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] [all][api][tc][perfromance] API for getting only status of resources

[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 little more.


as for changing the get request to return only the status, can't you 
have a filter on the get url that instructs it to return only the status?


mike

__
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] [api] consolidate IRC change with #openstack-sdk?

[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 decision.

I'd like to propose we drop the channel entirely and make #openstack-sdk
the home of API working group conversations. That's where all the
openstackclient, openstackclientconfig, and sdk conversations are
happening. It's where the end consumers of any API WG effort are, so are
incredibly good sounding boards for things we are doing. There is
already a large overlap between the two channels, so just pushing
forward on that means more critical mass for conversations around the
whole space of a more usable API for users.

This came up at the last API WG meeting, but those are pretty low quorum
events, so this is a thing we should definitely decide over ML instead.

Please express your feelings here and lets make it happen. :)


i don't necessarily have an outright objection to this, but i would like 
explore the future possibilities of this change.


i think there is possibility for the api-wg to grow and take on more 
responsibility within the openstack community and i'm curious about the 
net effect down the road if that expansion were to occur. are there any 
side-effects we should be aware of as we merge the two 
channels/communities into one namespace?


i realize there is some overlap of engineering/design that takes place 
on these channels, i'm just concerned about the idea of merging the two 
and then at some point in the future wanting to separate them. i'm not 
proposing these thoughts to quash the idea of joining, i'd just like to 
more fully understand the longer term implications of a merge.


anyone with more experience in this community-oriented side of things 
have some light to shed?


thanks,
mike


__
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] [api] consolidate IRC change with #openstack-sdk?

[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 been guilty of that). Plus we don't always have the
right people in a conversation to make a decision.

I'd like to propose we drop the channel entirely and make #openstack-sdk
the home of API working group conversations. That's where all the
openstackclient, openstackclientconfig, and sdk conversations are
happening. It's where the end consumers of any API WG effort are, so are
incredibly good sounding boards for things we are doing. There is
already a large overlap between the two channels, so just pushing
forward on that means more critical mass for conversations around the
whole space of a more usable API for users.

This came up at the last API WG meeting, but those are pretty low quorum
events, so this is a thing we should definitely decide over ML instead.

Please express your feelings here and lets make it happen. :)


i don't necessarily have an outright objection to this, but i would like
explore the future possibilities of this change.

i think there is possibility for the api-wg to grow and take on more
responsibility within the openstack community and i'm curious about the
net effect down the road if that expansion were to occur. are there any
side-effects we should be aware of as we merge the two
channels/communities into one namespace?

i realize there is some overlap of engineering/design that takes place
on these channels, i'm just concerned about the idea of merging the two
and then at some point in the future wanting to separate them. i'm not
proposing these thoughts to quash the idea of joining, i'd just like to
more fully understand the longer term implications of a merge.

anyone with more experience in this community-oriented side of things
have some light to shed?


Typically the only real reason to spin off another channel is that there
are now too many conversations happening all at once that are unrelated
and people are finding it is impeding their ability to get work done. I
can't imagine this happening any time within the next couple of years.
An average day in #openstack-api is < 20 messages (from a quick spot
check in IRC logs).

I feel there is a lot of benefits in having these groups that do related
work all doing it in one channel. Even though it's a number of discreet
outputs, the "hallway track" of having api producers and consumers doing
their business all in front of each other should quite help in ensuring
that we all make something better.


thanks for the clarifications Sean, i appreciate the extra resolution 
and i agree that having both these groups able to comment on similar 
issues in a common place seems ideal.


regards,
mike


__
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] [security][sahara] creating a threat analysis to aid operators

[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 can create an 
example threat analysis for our installers and operators to use as a 
reference in their deployments.


my goal in this is not to create a roadmap of current vulnerabilities 
within sahara, but to produce a working document that can be used as a 
guide for any users wishing to secure their sahara installations. i 
think there is value in creating these type of guides for all openstack 
projects, and i'm hopeful that the sahara team could take the lead in 
this process.


i'm reaching out in this email to help renew interest in the threat 
analysis work, and to possibly collate the material that is available 
and help define some spaces online where we might coordinate these efforts.


regards,
mike

__
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] [api] link definitions guideline to help align differing styles

[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 
with respect to link usage.


i think we should discuss the differences and create a guideline for 
link style, and then fixup whichever guideline(s) may be out of 
alignment with regards to our decision.


with that said, there appears to be two main implementations that we are 
looking at; the json hyper-schema link description objects[3] (hereafter 
referred to as the LDO approach), and the json hypertext application 
language link objects[4] (hereafter referred to the HAL approach).


on first inspection it would appear that the HAL approach provides more 
options for decorating the link with metadata. i'm not sure if this 
makes it a win in and of itself, but we should juxtapose that against 
the idea that we currently have several examples of the LDO style in use[5].


i'm curious to open this topic up for discussion to help forge a path 
forward.


thoughts?

regards,
mike

[1]: http://specs.openstack.org/openstack/api-wg/guidelines/errors.html
[2]: https://review.openstack.org/#/c/190743
[3]: http://json-schema.org/latest/json-schema-hypermedia.html#anchor17
[4]: https://tools.ietf.org/html/draft-kelly-json-hal-07#section-5
[5]: https://wiki.openstack.org/wiki/API_Working_Group/Current_Design/Links

__
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] [api] consolidate IRC change with #openstack-sdk?

[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 documentation that refer to 
openstack-api. we can start the process of adjusting all those to 
openstack-sdks.


mike


__
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] [cross-project] Cross-project Liaisons

[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 making sure everyone is happy.

Today we have the following problems:

* Authors of specs can't progress forward with specs because of lack of
   attention. Eventually getting frustrated and giving up.
* Some projects could miss a cross-project spec being approved by the TC.

It has been expressed to me at the previous Cross-Project Communication Tokyo
summit session that PTLs don't have time for cross-project issues. I agree, as
being a previous PTL your time is thin. However, I do think someone from each
project needs to be aware and involved with cross-project initiatives.

I would like to propose cross-project liaisons which would have the following
duties:

* Watching the cross-project spec repo [1].
   - Comment on specs that involve your project. +1 to carry forward for TC
 approval.
 -- If you're not able to provide technical guidance on certain specs for
your project, it's up to you to get the right people involved.
 -- Assuming you get someone else involved, it's up to you to make sure they
keep up with communication.
   - Communicate back to your project's meeting on certain cross-project specs
 when necessary. This is also good for the previous bullet point of sourcing
 who would have technical knowledge for certain specs.
* Attend the cross-project meeting when it's called for [2].


[1] - 
https://review.openstack.org/#/q/project:+openstack/openstack-specs+status:+open,n,z
[2] - https://wiki.openstack.org/wiki/Meetings/CrossProjectMeeting



this sounds like a nice idea. it will still be an added layer of work to 
get visibility/approval for cross-project specs, but defining the 
process a little more thoroughly might help with the visibility issues.


it does seems like there might be an ever-expanding list of project 
liaisons to work with as the openstack community grows, do you envision 
any mechanisms outside the usual channels of communication to aid this 
effort?


regards,
mike

__
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] [all] making project_id optional in API URLs

[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 in the url for the v1 and v1.1 apis, but we are planning 
to remove it for the v2 api[1].


mike

[1]: https://review.openstack.org/#/c/212172/


__
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] [all] making project_id optional in API URLs

[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 fetching the object from the
database; you should, however, confirm that the object return belongs to
the project at a later point.


from the policy standpoint does it matter if the project id appears in 
the url or in the headers?


mike


__
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] [sahara] Nominating new members to Sahara Core

[michael mccune]

On 05/13/2016 11:33 AM, Vitaly Gridnev wrote:

I'd like to bring the following folks to Sahara Core:

1. Lu Huichun


+2


2. Nikita Konovalov


+2


3. Chad Roberts


+2

regards,
mike

__
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] [all][api] New guidelines ready for cross project review

[michael mccune]

The following proposed API guidelines are available for broader
review by interested parties.

* https://review.openstack.org/#/c/301846
  Description of how to use etags to avoid lost updates

* https://review.openstack.org/#/c/281511
  Delete multiple metadata items with a single request

these will be merged on May 26 id there is no further feedback.

regards,
mike

__
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] [all][api] POST /api-wg/news

[michael mccune]

Greetings OpenStack community,

Welcome to another edition of the API working group's weekly newsletter.

# Recently merged guidelines

These guidelines have been recently merged by the group.

* Description of how to use etags to avoid lost updates
  https://review.openstack.org/#/c/301846
* Delete multiple metadata items with a single request
  https://review.openstack.org/#/c/281511

# API guidelines proposed for freeze

The following guidelines are available for broader review by interested 
parties. These will be merged in one week if there is no further feedback.


* None this week

# Guidelines currently under review

These are guidelines that the working group are debating and working on 
for consistency and language. We encourage any interested parties to 
join in the conversation.


* Actions guideline
  https://review.openstack.org/234994
* Add description of pagination parameters
  https://review.openstack.org/190743
* Add guideline for Experimental APIs
  https://review.openstack.org/273158
* Add version discovery guideline
  https://review.openstack.org/254895

# APIImpact reviews currently open

Reviews marked as APIImpact are meant to help inform the working group 
about changes which would benefit from wider inspection by group members 
and liaisons. While the working group will attempt to address these 
reviews whenever possible, it is highly recommended that interested 
parties attend the API-WG meetings [1] to promote communication 
surrounding their reviews.


https://review.openstack.org/#/q/status:open+AND+(message:ApiImpact+OR+message:APIImpact),n,z

Thanks for reading and see you next week!

[1] https://wiki.openstack.org/wiki/Meetings/API-WG#Agenda


__
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] [all][api] POST /api-wg/news

[michael mccune]

Greetings OpenStack community,

This week there are no new merged guidelines nor guidelines proposed for 
freeze but there is a new guideline discussing ways to ensure that URIs 
are semantically consistent: https://review.openstack.org/#/c/322194/


# Recently merged guidelines

These guidelines have been recently merged by the group.

* Delete multiple metadata items with a single request
  https://review.openstack.org/281511
* Description of how to use etags to avoid lost updates
  https://review.openstack.org/301846

# API guidelines proposed for freeze

The following guidelines are available for broader review by interested 
parties. These will be merged in one week if there is no further feedback.


* None this week

# Guidelines currently under review

These are guidelines that the working group are debating and working on 
for consistency and language. We encourage any interested parties to 
join in the conversation.


* Add the beginning of a set of guidlines for URIs
  https://review.openstack.org/#/c/322194/
* Add description of pagination parameters
  https://review.openstack.org/190743
* Add guideline for Experimental APIs
  https://review.openstack.org/273158
* Add version discovery guideline
  https://review.openstack.org/254895

Note that some of these guidelines were introduced quite a long time ago 
and need to either be refreshed by their original authors, or adopted by 
new interested parties.


# API Impact reviews currently open

Reviews marked as APIImpact [1] are meant to help inform the working 
group about changes which would benefit from wider inspection by group 
members and liaisons. While the working group will attempt to address 
these reviews whenever possible, it is highly recommended that 
interested parties attend the API-WG meetings [2] to promote 
communication surrounding their reviews.


Thanks for reading and see you next week!

[1] 
https://review.openstack.org/#/q/status:open+AND+(message:ApiImpact+OR+message:APIImpact),n,z

[2] https://wiki.openstack.org/wiki/Meetings/API-WG#Agenda


__
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] [all][api] POST /api-wg/news

[michael mccune]

Greetings OpenStack community,

No new guidelines have been merged or proposed for freeze this week, but 
we have cleaned up some of the language in the guideline pages and have 
had some productive discussions initiated by the Glance team about 
changes they are working towards.


# Recently merged guidelines

No new guidelines in the last two weeks but the following fixes were merged:

* Get rid of the DRAFT warning at the top of guidelines
  https://review.openstack.org/#/c/330687/
* Remove "Conveying error/fault information" section
  https://review.openstack.org/#/c/330876/

# API guidelines proposed for freeze

The following guidelines are available for broader review by interested 
parties. These will be merged in one week if there is no further feedback.


None this week

# Guidelines currently under review

These are guidelines that the working group are debating and working on 
for consistency and language. We encourage any interested parties to 
join in the conversation.


* Add the beginning of a set of guidlines for URIs
  https://review.openstack.org/#/c/322194/
* Add description of pagination parameters
  https://review.openstack.org/190743

Note that some of these guidelines were introduced quite a long time ago 
and need to either be refreshed by their original authors, or adopted by 
new interested parties. If you're the author of one of these older 
reviews, please come back to it or we'll have to mark it abandoned.


# API Impact reviews currently open

Reviews marked as APIImpact [1] are meant to help inform the working 
group about changes which would benefit from wider inspection by group 
members and liaisons. While the working group will attempt to address 
these reviews whenever possible, it is highly recommended that 
interested parties attend the API-WG meetings [2] to promote 
communication surrounding their reviews.


To learn more about the API WG mission and the work we do, see OpenStack 
API Working Group [3].


Thanks for reading and see you next week!

[1] 
https://review.openstack.org/#/q/status:open+AND+(message:ApiImpact+OR+message:APIImpact),n,z

[2] https://wiki.openstack.org/wiki/Meetings/API-WG#Agenda
[3] http://specs.openstack.org/openstack/api-wg/



__
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] [security] threat analysis, tags, and the road ahead

[michael mccune]

hey all,

at the most recent ossp meeting[1], there was some extended discussion 
about threat analysis and the work that is being done to push this forward.


in this discussion, there were several topics brought up around the 
process for doing these analyses on current projects and how the ossp 
should proceed especially with respect to the "vulnerability:managed" 
tag[2].


as for the threat analysis process, there are still several questions 
which need to be answered:


* what is the process for performing an analysis

* how will an analysis be formally recognized and approved

* who will be doing these analyses

* does it make sense to keep the analysis process strictly limited to 
the vmt


* how to address commonalities and differences between a developer 
oriented analysis and a deployer oriented analysis


these questions all feed into another related topic, which is the 
proposed initial threat analysis for kolla which has been suggested to 
start at the upcoming austin summit.


i wanted to capture some of the discussion happening around this topic, 
and continue the ball rolling as to how we will solve these questions as 
we head to summit.


one of the big questions seems to be who should be doing these analysis, 
especially given that the ossp has not formally codified the practice 
yet, and the complexity involved. although currently the 
vulnerability:managed tag suggests that a third party review should be 
done, this may prove difficult to scale in practice. i feel that it 
would be in the best interests of the wider openstack community if the 
ossp works towards creating instructional material that can empower the 
project teams to start their own analyses.


ultimately, having a third-party review of a project is worthy goal, but 
this has to be tempered with the reality that a single team will not be 
able to scale out and provide thorough analyses for all projects. to 
that extent, the ossp should work, initially, to help a few teams get 
these analyses completed and in the process create a set of useful tools 
(docs, guides, diagrams, foil-hat wearing pamphlets) to help further the 
effort.


i would like to propose that the threat analysis portion of the 
vulnerability:managed tag be modified with the goal of having the 
project teams create their own analyses, with an extended third-party 
review to be performed afterwards. in this respect, the scale issue can 
be addressed, as well as the issue of project domain knowledge. it makes 
much more sense to me to have the project team creating the initial work 
here as they will know the areas, and architectures, that will need the 
most attention.


as the ossp build better tools for generating these analyses they will 
be in a much better position to guide project teams in their initial 
analyses, with the ultimate goal of having the ossp, and/or vmt, perform 
the third-party audit for application of the tag. i have a feeling we 
will also discover much overlap between the developer and deployer 
oriented analyses, and these overlaps will help to strengthen the 
process for all involved.


finally, the austin summit, and proposed kolla review, provide a great 
opportunity for the ossp to put "rubber on the road" with respect to 
this process. although a full analysis may not be accomplished during 
the summit, we can definitely achieve the goal of defining this process 
much better and creating more guidance for all projects that wish to 
follow this path, as well as having kolla solidly on the way to having a 
full threat analysis ready for third-party review.


thoughts?


regards,
mike


[1]: 
http://eavesdrop.openstack.org/meetings/security/2016/security.2016-03-31-17.00.log.txt


[2]: 
http://governance.openstack.org/reference/tags/vulnerability_managed.html


[3]: https://review.openstack.org/#/c/220712/

__
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] [sahara][release] missing build artifacts

[michael mccune]

On 04/01/2016 04:48 PM, Doug Hellmann wrote:

Excerpts from Doug Hellmann's message of 2016-04-01 16:27:42 -0400:

Sahara team,

We noticed in our audit of the links on
http://releases.openstack.org/mitaka/index.html that the links to
the build artifacts for sahara-extras point to missing files. The
repository doesn't seem to have any real build jobs configured in
openstack-infra/project-config/zuul/layout.yaml, so it's not clear
how tagging is producing a release for you.

For now, we are disabling links to the artifacts for those repos
via https://review.openstack.org/300457 but we're also planning to
remove them from the official Mitaka page since there don't appear
to be any actual related deliverables
(https://review.openstack.org/300647).

It would be good to understand what your intent is for builds. Can
you follow up here on this thread with some details?


the sahara-extras repository holds mainly examples for working with 
sahara. it does, however, contain a crucial part of our image 
deployments, namely the hadoop-openstack connector for accessing swift 
with keystone v3 authentication from within hadoop.


with that said though, i think you are correct that we do not actually 
produce a build from this repo. i'm not 100% sure on that, and would 
like to hear from our build wizards. this repository is useful to our 
users though, i'm just not sure how we should be fitting it into the 
larger picture of releases.




Thanks,
Doug



I forgot to mention that https://review.openstack.org/#/c/300474
includes some changes to add the simple server publishing jobs. If you
want to use those, please +1 the patch.

Doug

__
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] [sahara][release] missing build artifacts

[michael mccune]

On 04/05/2016 03:56 AM, Thierry Carrez wrote:

We seem to have a sahara-extra build alright:
http://tarballs.openstack.org/sahara-extra/

Please ignore the noise :)



ah, excellent!

thanks for the clarification Thierry


regards,
mike

__
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] [all][api] Recently accepted API-WG guidelines

[michael mccune]

hello all,

this is a friendly update about guidelines that the API working group 
has recently accepted:


1. version discover guideline for API microversions
https://review.openstack.org/243429

2. client interaction guideline for API microversions
https://review.openstack.org/243414

3. versioning guideline for API microversions
https://review.openstack.org/243041

4. unexpected attribute guideline
https://review.openstack.org/260292


additionally, we have updated our process slightly to better reflect 
ownership of merges.

https://review.openstack.org/#/c/299416/

thanks,
mike

__
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] [neutron] [API]Make API errors conform to the common error message without microversion

[michael mccune]

please forgive my lack of direct knowledge about the neutron process and 
how this fits in. i'm just commenting from the perspective of someone 
looking at this from the api-wg.


On 04/11/2016 09:52 AM, Duncan Thomas wrote:

So by adding the handling of a header to change the behaviour of the
API, you're basically implementing a subset of microversions, with a
non-standard header (See the API WG spec on non-proliferation of
headers). You'll find it takes much of the work that implementing
microversions does, and explodes your API test matrix some more.

Sounds like something that should go on hold until microversions is
done, assuming that microversions are desired anyway. Standard error
messages are not such a big win that they're worth non-standard headers
and yet more API weirdness that needs to sit around potentially for a
very long time (see the API WG rules on removing APIs, which is
basically never)



i think this advice sounds reasonable. adding a side-channel around 
microversions sounds like work that would itself need a microversion 
bump when it is finally removed ;)


i also agree with the reasoning about the benefit from the standardized 
error messages. it is nice to get a standard error message produced, but 
i think adding microversions is probably a bigger win in the near term 
because it will make these other transitions smoother.



On 8 April 2016 at 11:23, Xie, Xianshan mailto:xi...@cn.fujitsu.com>> wrote:

Hi, all,

We are attempting to make the neutron API conform to the common
error message format recommended by API-WG [1]. As this change will
introduce a new error format into neutron which is different from
existing  format [2], we should think of some solutions to preserve
the backward compat.

The easiest way to do that is microversion, just like the cinder
does [3] although which is still in progress. But unfortunately,
there are many projects in which the microversion haven't been
landed yet, e.g. neutron,  glance, keystone etc. Thus during the
interim period we have to find other approaches to keep the backward
compat.

According to the discussion, a new header would be a good idea to
resolve this issue [4], we think.
For instance:
curl -X DELETE "http://xxx:9696/v2.0/networks/xxx"; -H
"Neutron-Common-Error-Format: True"

But we haven't decided which header name will be used yet.
So how do you think which is the best appropriate one?
A: Neutron-Common-Error-Format
B: OpenStack-Neutron-Common-Error-Format
C: other (Could you please specify it? Thanks in advance)

Any comments would be appreciated.

[1] http://specs.openstack.org/openstack/api-wg/guidelines/errors.html
[2] https://review.openstack.org/#/c/113570/
[3] https://review.openstack.org/#/c/293306/
[4] https://bugs.launchpad.net/neutron/+bug/1554869

Best regards,
xiexs


__
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




--
--
Duncan Thomas


__
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][ssecurity] Threat Analysis Design Session

[michael mccune]

On 04/16/2016 02:19 PM, Steven Dake (stdake) wrote:

If the security team has a conflict  with this slot that I didn't see or
am unaware of, please speak up so I can have it corrected in the main
schedule.  Our schedule is here:


sadly, i will miss the beginning of this as i have a conflicting 
presentation.


as much as i'd like to participate, i don't think my absence should 
necessitate a reschedule. just wanted to give a heads up.


regards,
mike


__
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] [api] API-WG summit session recap

[michael mccune]

hello all,

We had a great session for the API working group in Austin, and I wanted 
to give a brief recap and extend a thank you to all who attended.


There were about 20-30 people in attendance for the double session 
fishbowl that took place on monday. This turnout was one of the larger 
we have had for the past few summits and it was exciting to see this 
level of engagement from the community. again, thank you =)


Full notes from the session can be found on the etherpad from summit[1].

The session began with a recap of the group's activities for the Mitaka 
cycle. We discussed the guidelines that have been added, as well as our 
success stories with regards to projects that have sought advice from 
the group.


With the old business out of the way, we moved on to discuss topics that 
are of importance to the group moving forward.


Promoting the guidelines


The heart of the API-WG has always been the guidelines that are 
produced, we had a nice discussion about how we can increase the 
awareness and usage of the guidelines.


One big request that came out of this discussion is the need to cleanup 
the group's guideline page to make it clearer which pages are just place 
holders and which contain guidelines.


The group talked about if, and how, we can better integrate with other 
working groups to help create a broader network for the guidelines and 
better APIs in general. The two main groups that were identified as 
possible partners are the Application Ecosystem WG and the SDK WG. 
Although these groups have different focuses than just APIs, there is 
certainly some room for collaboration and consensus among all the groups.


There was also a strong discussion about how the group could advocate 
for more projects to use the guidelines. The main result of this talk 
was the idea of an API-WG related governance tag. Having this tag would 
make a nice signal to end-users about the maturity and development 
status of a project's APIs. Although the details are still in flux, the 
main criteria of a tag were related to projects self-electing into the 
tag, and then creating a series of tests that would prove how their APIs 
follow the guidelines, as well as providing proper API documentation. 
This is still very much a work in progress.


Reviewing the guideline process
===

If the guidelines are the heart of the WG, then our review process is 
the pacemaker ;)


Within the group, a discussion had started before summit about the level 
of email we produce and if it is sufficient. When brought to the table 
at summit, this conversation continued and was well received by the 
audience.


There were several good suggestions about how we can more easily 
communicate what is happening within the group, the state of guidelines 
and reviews that need attention from the group.


the ultimate result of this discussion is that the API-WG will work over 
the Newton cycle to create a weekly email similar to the "What's Up Doc" 
emails from the doc team. These emails will include a summary of 
guidelines that are in freeze, those that have been recently merged, and 
a list of reviews with APIImpact as well as any other business the WG 
might have.


Improving WG participation
==

A constant note from many groups within the OpenStack community is 
participation. The API-WG is no stranger to this topic as we have 
continually searched for methods of improving participation from 
interested parties.


Although there were no clear solutions on this topic, there was wide 
agreement that relying on the CPLs for better engagement with the WG is 
a strong way forward. To this end, the WG will work to make it easier 
for CPLs to bring their APIImpact reviews, and their special interest 
topics, to the group. The methods for doing this will mainly center 
around being more focused in our mailings, and improving our 
communication with respect to guideline reviews.


Dropping the UTC meeting


Somewhere around the Kilo cycle, the API-WG added a second meeting time 
to help our friends in the Asian and Pacific regions join the 
discussion. Unfortunately, after a few cycles of this meeting, its 
attendance is nearly always zero. After some discussion during the 
summit, we have agreed to remove this meeting and return to a single 
weekly meeting at 1600UTC on Thursdays. If the need arises in the 
future, the API-WG will be more than happy to reinstate this meeting.



That about wraps up the review from our summit session, hopefully I 
haven't left out too many details ;)


Thanks again to everyone who attended the session, and thanks to the 
OpenStack community for another excellent summit.


regards,
mike

[1]: https://etherpad.openstack.org/p/austin-api-wg-session-plans

__
OpenStack Development Mailing List (not for usage questions)
Unsubscrib

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

[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 commit to it.


regards,
mike


__
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] [trove] [sahara] Adding support for HBase in Trove

[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 this, some of our team was on holiday during the 
last week (jan 3-8).


regards,
mike


__
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] [trove][neutron][cinder][swift][ceilometer][nova][keystone][sahara][glance][neutron-lbaas][imm] stylistic changes to code, how do we handle them?

[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 that this construct that we are seeking to eliminate, does not 
reenter the code base.


in general, i would prefer to leave these stylistic choices up to 
individual projects. the specific change that is being proposed may make 
sense for some projects but not for others.


i like the idea of a "hacking rule" or some sort of coding style guides, 
but i'm sceptical about creating some sort of openstack coding guide. 
i'm happy with us continuing to use pep8 and the individual projects' 
guidance as the bar.



For what it is worth, I agree with Vitaly Grindev [sahara, in review 
https://review.openstack.org/#/c/266230/1]. I think the code before the change 
was more intuitive and readable.


+1

regards,
mike

__
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] [api][all] api variation release by release

[michael mccune]

On 01/12/2016 09:55 PM, Matt Riedemann wrote:

Nova and Ironic already support microversioned APIs. Cinder and Neutron
are working on it I think, and there could be others.


just as a heads up, sahara is also working towards implementing 
microversions in its next api[1]


regards,
mike

[1]: https://review.openstack.org/#/c/212172/


__
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] [all][api] New API Guidelines Ready for Cross Project Review

[michael mccune]

hi all,

The following API guideline is ready for cross project review. It will 
be merged on Jan. 21 if there is no further feedback.


1. Add description of pagination parameters
https://review.openstack.org/#/c/190743

regards,
mike

__
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] [api] api working group proposed actions guideline needs input

[michael mccune]

On 01/18/2016 10:05 AM, Michael Krotscheck wrote:

Also: I like using the same word for things. Is there a meaningful
enough difference between "Actions", "Transitions", and "Tasks", that
requires different words?


not that i have detected, although i would love hear other opinions on this.

i have to admit that this is the first time i'm hearing "transitions", 
and i feel it could be looked at separately from "actions" or "tasks". 
but i think this is largely a semantic debate.


i do think it would be useful to coalesce on a standard term for what we 
are talking about.


regards,
mike


__
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] [api] service type vs. project name for use in headers

[michael mccune]

hi all,

there have been a few reviews recently where the issue of service type 
versus project name have come up for use in the headers. as usual this 
conversation can get quite murky as there are several good examples 
where service type alone is not sufficient (for example if a service 
exposes several api controllers), and as has been pointed out project 
name can also be problematic (for example projects can change name).


i'm curious if we could come to a consensus regarding the use of service 
type *or* project name for headers. i propose leaving the ultimate 
decision up to the projects involved to choose the most appropriate 
identifier for their custom headers.


i am not convinced that we would ever need to have a standard on how 
these names are chosen for the header values, or if we would even need 
to have header names that could be deduced. for me, it would be much 
better for the projects use an identifier that makes sense to them, 
*and* for each project to have good api documentation.


so, instead of using examples where we have header names like 
"OpenStack-Some-[SERVICE_TYPE]-Header", maybe we should suggest 
"OpenStack-Some-[SERVICE_TYPE or PROJECT_NAME]-Header" as our guideline.


for reference, here are the current reviews that are circling around 
this issue:


https://review.openstack.org/#/c/243429
https://review.openstack.org/#/c/273158
https://review.openstack.org/#/c/243414

and one that has already been merged:

https://review.openstack.org/#/c/196918

thoughts?

regards,
mike

__
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] [api] service type vs. project name for use in headers

[michael mccune]

On 01/28/2016 06:32 AM, Jay Pipes wrote:

Couldn't agree more, Chris.

-jay

On 01/28/2016 11:06 AM, Chris Dent wrote:

On Wed, 27 Jan 2016, Dean Troyer wrote:


I think we would be better served in selecting these things thinking
about
the API consumers first.  We already have  enough for them to wade
through,
the API-WG is making great gains in herding those particular cats, I
would
hate to see giving back some of that here.


I think it is high time we resolve the question of whether the
api-wg guidelines are evaluating existing behaviors in OpenStack and
blessing the best or providing aspirational guidelines of practices
which are considered best at a more universal level.

Within the group many of our debates pivot around the above issue.
There is some fear that if we choose the latter none of the
guidelines will be followed.

I think that's pretty weak sauce and we need to take both a more
assertive and more aggressive stance with regard to achieving
quality and consistency in the APIs[1]. Reaching consistency is the
primary mission of the group but consistent crap is still crap and
our API consumers deserve better.

The thread about Ekko which has spawned a subthread about the
collision between the ceilometer and monasca APIs should be a
good learning moment™: Having some rigor and vision in our
guidelines would allow us to state things like:

* The APIs are services (for which there could potentially be other
   implementations but the service represents a namespace)
* Identifiers used in that service are service related, not project
   related.
* More specifically: URIs are signifiers of a service, not a project.

The guidelines should be one (of several) ways in which a project
can ask itself "are we being OpenStack?". If there is a collision
with the guidelines, that provides a clue that the thing being
considered is out of alignment. It should be an excuse to change or
create new guidelines.


In this case, the use of service type as the primary identifier for
endpoints and API services is well established, and is how the service
catalog has and will always work.


For the specific issue of the headers, I think the above is the crux of
the biscuit. The service catalog is intended to be a source of truth;
that truth should be reflected in the guidelines. If the API being
considered isn't (planned to be) in the service catalog does that
API need to even be thinking about adhering to OpenStack guidelines?

[1] Choosing to be more rigorous in the guidelines puts a large
burden on the group to not simply rubberstamp incoming guidelines
and also be more selective about what actually matters in terms of
the guidelines. This is challenging because it became clear early on
that adherence to correct HTTP in existing APIs was weak and there
was an opportunity for the group to be a fount of knowledge and
wisdom and distill best practices.

That work still needs to go on, but it is also time to align
the work with some of the main themes in today's OpenStack:

* alignment with the service catalog and what it is trying to
   accomplish
* effective use of APIs when re-using real users' client code amongst a
   diversity of clouds

Just those two things can help us evaluate proposals with some
useful constraints.


i agree as well Chris, and well said.

thanks to everyone for commenting on this issue. i agree with the 
sentiments that are being voiced here, and i think the arguments for 
sticking to service type make a good deal of sense.


my main concern was that there had been some pushback on the idea of 
service type for headers. i like the notion that we are hewing closer to 
the service catalog ideals, that makes good sense to me. i just wanted 
to leave room for projects to make their own path if necessary, i guess 
this option is always there by default.


again, thanks for the insights. i will back off my concerns on the 
outstanding reviews based on this issue, and work towards helping us 
stay closer to service type for the guidelines.


regards,
mike


__
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] [all][api] New API Guidelines Ready for Cross Project Review

[michael mccune]

hi all,

The following API guideline is ready for cross project review. It will 
be merged on Feb. 9 if there is no further feedback.


1. Must not return server-side tracebacks
https://review.openstack.org/#/c/183599

regards,
mike

__
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] [all] the trouble with names

[michael mccune]

On 02/04/2016 08:33 AM, Thierry Carrez wrote:

Hayes, Graham wrote:

On 04/02/2016 13:24, Doug Hellmann wrote:

Excerpts from Hayes, Graham's message of 2016-02-04 12:54:56 +:

On 04/02/2016 11:40, Sean Dague wrote:

2) Have a registry of "common" names.

Upside, we can safely use common names everywhere and not fear
collision down the road.

Downside, yet another contention point.

A registry would clearly be under TC administration, though all the
heavy lifting might be handed over to the API working group. I still
imagine collision around some areas might be contentious.


++ to a central registry. It could easily be added to the projects.yaml
file, and is a single source of truth.


Although I realized that the projects.yaml file only includes official
projects right now, which would mean new projects wouldn't have a place
to register terms. Maybe that's a feature?


That is a good point - should we be registering terms for non tent
projects? Or do projects get terms when they get accepted into the tent?


I don't see why we would register terms for non-official projects. I
don't see under what authority we would do that, or where it would end.
So yes, that's a feature.



i have a question about this, as new, non-official, projects start to 
spin up there will be questions about the naming conventions they will 
use within the project as to headers and the like. given that the 
current guidance trend in the api-wg is towards using "service type" in 
these cases, how would these projects proceed?


(i'm not suggesting these projects should be registered, just curious)


I think solution 2 is the best. To avoid too much contention, that can
easily be delegated to the API WG, and escalated to the TC for
resolution only in case of conflict between projects (or between a
project and the API WG).



i'm +1 for solution 2 as well. as to the api-wg participation in the 
name registration side of things , i don't have an objection but i am 
very curious to hear Everett's and Chris' opinions.


regards,
mike

__
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] [all] the trouble with names

[michael mccune]

On 02/04/2016 12:57 PM, Hayes, Graham wrote:

On 04/02/2016 15:40, Ryan Brown wrote:

On 02/04/2016 09:32 AM, michael mccune wrote:

On 02/04/2016 08:33 AM, Thierry Carrez wrote:

Hayes, Graham wrote:

On 04/02/2016 13:24, Doug Hellmann wrote:

Excerpts from Hayes, Graham's message of 2016-02-04 12:54:56 +:

On 04/02/2016 11:40, Sean Dague wrote:

2) Have a registry of "common" names.

Upside, we can safely use common names everywhere and not fear
collision down the road.

Downside, yet another contention point.

A registry would clearly be under TC administration, though all the
heavy lifting might be handed over to the API working group. I still
imagine collision around some areas might be contentious.


++ to a central registry. It could easily be added to the
projects.yaml
file, and is a single source of truth.


Although I realized that the projects.yaml file only includes official
projects right now, which would mean new projects wouldn't have a place
to register terms. Maybe that's a feature?


That is a good point - should we be registering terms for non tent
projects? Or do projects get terms when they get accepted into the tent?


I don't see why we would register terms for non-official projects. I
don't see under what authority we would do that, or where it would end.
So yes, that's a feature.



i have a question about this, as new, non-official, projects start to
spin up there will be questions about the naming conventions they will
use within the project as to headers and the like. given that the
current guidance trend in the api-wg is towards using "service type" in
these cases, how would these projects proceed?

(i'm not suggesting these projects should be registered, just curious)


This isn't a perfect solution, but maybe instead of projects.yml there
could be a `registry.yml` project that would (of course) have all the
project.yml "in-tent" projects, but also merge in external project
requests for namespaces?


Where ever it is stored, could this be a solid place for the api-wg to
codify the string that should be shown in the catalog / headers /
other places by services?



this seems like a reasonable approach, the big downside might be 
grooming the "dibs" list. we could have projects that expect to go 
somewhere, register their name, then never achieve "lift-off". in these 
cases we would need to release those names back into the free pool.



Say there's an LDAP aaS project, it could ask to reserve "directory" or
whatever and have a reasonable hope that when they're tented they'll be
able to use it. This would help avoid having multiple projects expecting
to use the same name, while also not meaning we force anyone to use or
not use some name.

Effectively, it's a gerrit-backed version of "dibs".


I think solution 2 is the best. To avoid too much contention, that can
easily be delegated to the API WG, and escalated to the TC for
resolution only in case of conflict between projects (or between a
project and the API WG).



i'm +1 for solution 2 as well. as to the api-wg participation in the
name registration side of things , i don't have an objection but i am
very curious to hear Everett's and Chris' opinions.

regards,
mike

__
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] [all] the trouble with names

[michael mccune]

On 02/05/2016 07:56 AM, Chris Dent wrote:

On Thu, 4 Feb 2016, Sean Dague wrote:


2) Have a registry of "common" names.

Upside, we can safely use common names everywhere and not fear collision
down the road.


This is the only option presented thus far which meets the needs of
end users and also some of our stated goals about creating
interoperable OpenStack-based clouds.

It does, however, require some integration and orchestration between
TC, Service Catalog work, and API-WG guidelines.


Downside, yet another contention point.


What's the issue with contention? Contention is one of several tools
that humans use to resolve disagreement and reached a shared
understanding of the problem space. Without shared understanding
in a community there's zero chance a community will create and work
towards shared goals. Because even if everyone is using the same
words for the goals, if they aren't using the same meanings, it's
all bunk.

When we, as a group, start to contend over terms and identifiers
that's just a signal that we don't really know what we're trying to
do and need to work at it. A lot of people, frustrated with all this
talk, will call it bikeshedding and then go off and do their own
thing, potentially not in concert with other people's goals. Making
all that talk is sometimes necessary if we want to be headed in the
same direction[1].

The economics of our situation often make that kind of cross-project
noodling challenging. As a group of open source devs we likely need
to keep our patrons clearly aware of the value and amount of what
some would call overhead.

It is not overhead. It's a major part of the work.

The big tent, in some sense, has been an invitation to allow people
to work on a more diverse set of goals. At the edge this is
beneficial as it means more useful stuff, but it has diffused
understanding of what "OpenStack" is. For consumers of OpenStack (and
for devs who are primarily concerned with making a thing called
OpenStack that is useful for those consumers) there needs to be a
thing which is OpenStack and that thing needs to be consistent and
coherent. And limited[2].



well said


A tool we have at our disposal for creating that consistency is the
service catalog and specifically the service catalog types.

Some will argue that this will lead to people contending over who
should occupy a type, as if that were a bad thing. It is not. Having
that discussion will help identify the flaws in the proposed
occupiers and keep the discussion of "what are we" alive and
healthy[3].


A registry would clearly be under TC administration, though all the
heavy lifting might be handed over to the API working group. I still
imagine collision around some areas might be contentious.


I'm happy for the API-wg to handle some of this if mike and Everett
are as well. Making it work well will require everybody plays well
with the service catalog too[4]



i'm open to this, assuming we create a well defined process to keeping 
the names in order.



The biggest challenge I predict is when we need to change things, as
we inevitably will. Many currently hold dear that we cannot impose
change upon the existing user base. Sometimes you do and really it's
not that much of a big deal compared to the pain of running
OpenStack in the first place.

[1] It's perfectly okay for tools to not head in the same
direction, especially if they can be consumed as independent
libraries or services and are not embedded in the world of
OpenStack. This is a good thing. There's far too much stuff _in_
OpenStack that should just be _used by_ OpenStack (or used by
OpenStack users).

[2] Yes, this means we need to have an opinion about what OpenStack
is and build that opinion into the system. That's good. OpenStack is
insufficiently generic to be unopinionated. Let's just get over
that.

[3] At the moment it appears that much of the time the goal of
OpenStack is to keep the gate running. This is classic statism at
its worst. Straight out of the movie Brazil.

[4]
http://specs.openstack.org/openstack/openstack-specs/specs/service-catalog.html




__
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] [api] microversion spec

[michael mccune]

On 02/03/2016 10:23 AM, Morgan Fainberg wrote:



On Wed, Feb 3, 2016 at 3:49 AM, Sean Dague mailto:s...@dague.net>> wrote:

I've been looking through the reviews on and where it's gotten to -

https://review.openstack.org/#/c/243429/4/guidelines/microversion_specification.rst


A couple of questions / concerns.

There was major push back from API-WG on 'API' itself being in the
headers. What is the data on what services are already doing? My
understanding is this is convention for all every service so far, mostly
because that's how we did it in Nova. Forcing a header change for that
seems massively bike shed. There is zero value gained in such a change
by anyone, and just confusion.



i don't see a conflict with the guideline proposing removing API from 
the header. if nova moves to support both headers in the future that 
would be awesome, but not strictly necessary.


i think what we wanted was to make sure that new projects will be on the 
same page about this. (although, i can understand that they will cry 
"but nova doesn't do that")



On moving from code names to service types, I'm completely onboard with
that providing value. However there is a bigger issue about the fact
that service types don't really have a central registry. That's why Nova
didn't do this up front because that's a whole other thing to figure out
which has some really big implications on our community.

Code names are self namespaced because they are based on git repo -
openstack/nova, openstack/ironic. We get a registry for free that won't
have conflicts.

I actually agree these should be service types, however, that requires
understanding how service types are going to be handed out. Having a
project just start using 'monitoring' or 'policy' as a service type is
going to go poorly in the long term when they get told they have to
change that, and now all their clients are broken.


As part of the new catalog (x-project) spec we will also need the
central registry for deconflicting. If you're talking to "compute" via
the catalog, it needs to always be nova. I would like to see this be the
service types. For the projects that have used the code-names for now
they can support either/or favouring the new service type one in the
long term.

Since we already need to solve this one way, we should use the same data
that is going to be in the catalog for this header.


agreed about the need for a registry, or something, to help coordinate 
the service type names. as stated in the other thread about naming[1], 
i'm ok with starting to work on some sort of plan for the api-wg to 
assist in the registration efforts, but that will take some time.


in the short term, i think we should forge ahead with standardizing on 
service type, and when the registry, or w/e, exists we can start to 
bring things into congruence with each other.


regards,
mike

[1]: 
http://lists.openstack.org/pipermail/openstack-dev/2016-February/085748.html



__
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] [all] the trouble with names

[michael mccune]

On 02/05/2016 04:36 PM, Chris Dent wrote:

On Fri, 5 Feb 2016, Sean Dague wrote:

I'd ask for folks to try to stay on the original question:

What possible naming standards could we adopt, and what are the
preferences.


1. service type as described in option 2
2. managed by the api-wg with appeal to the TC
3. be limited to those services that (wish to/need to/should) be present
in the service catalog

As discussed elsewhere 3 is a feature not a bug. We should endeavor
to keep the service catalog clean, tidy, and limited as a control on
OpenStack itself is clean, tidy and limited.


i think this sounds very reasonable

regards,
mike


__
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] Usage of trusts with v2.0 authentication

[michael mccune]

On 02/09/2016 12:06 PM, Lance Bragstad wrote:

The keystone team is curious if there is anyone creating trusts using v3
and then using them against version 2.0. If not, we'd like to
remove/deprecate support for that case in v2.0. If so, then we'll have
to add official documentation for trusts against v2.0 and incorporate
that case into fernet.


i'm curious if this will affect the usage of trusts through the python 
keystoneclient?


the sahara projects creates several trusts through the python client, 
and this seems to work regardless of the version endpoint we use. we 
aren't specifically using these trusts against a v2 endpoint, but we do 
use whatever endpoint is provided in our configuration for the identity 
endpoint.


thanks for bringing this up.

regards,
mike


__
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] [all] RFC - service naming registry under API-WG

[michael mccune]

On 02/10/2016 03:03 PM, Sean Dague wrote:

On 02/04/2016 06:38 AM, Sean Dague wrote:

2) Have a registry of "common" names.

Upside, we can safely use common names everywhere and not fear collision
down the road.

Downside, yet another contention point.

A registry would clearly be under TC administration, though all the
heavy lifting might be handed over to the API working group. I still
imagine collision around some areas might be contentious.


We had a good discussion last week here on the list, and I think the
consensus was that:

1) We should use option #2 and have standard service types

2) The API Working Group was probably as good a place as any to own /
drive this.

I'd like to follow on with the following recommendations:

3) This be a dedicated repository 'openstack/service-registry'. The API
WG will have votes on it (I would also suggest the folks that have been
working on Service Catalog TNG - myself, Anne Gentle, Brant Knudson, and
Chris Dent be added to this). The actual registry will be some
structured file that supports comments (probably yaml).

4) We seed it with the 'well known' service types from current devstack.
Then we patch in services one at a time after that as requested.
Basically sift through all the non controversial stuff first. Let debate
happen on the more contentious ones later.

5) We'll build up guidelines in this repo about the kinds of service
types names which we think are good. We may dedicate some reserve words
that are too highly confusing in the OpenStack space to be used (policy
comes to mind).

If there are concerns with this approach let me know. Otherwise I'll
propose the repo tomorrow and try to keep this ball rolling.

-Sean



i think this sounds like a fine idea. +1

mike

__
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] [Sahara] Why Sahara request user to give username/password for accessing the job binary in Swift ?

[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 
https://github.com/openstack/sahara/blob/master/sahara/utils/proxy.py#L165.
   Looks like admin_user & admin_password & admin_tenant_name" must be set, 
and the proxy_domin must be created by the admin_user.
   But after a clean devstack installation, my sahara.conf only has:
 [keystone_authtoken]
 signing_dir = /var/cache/sahara
 cafile = /opt/stack/data/ca-bundle.pem
 auth_uri = http://192.168.6.91:5000
 project_domain_id = default
 project_name = service
 user_domain_id = default
 password = 123456
 username = sahara
 auth_url = http://192.168.6.91:35357
 auth_plugin = password

   I'm really confused, these configurations all looks very similar.



that's a good question, i'm not sure what devstack does by default when 
creating sahara's configuration. i notice that in my local configuration 
file i do have values for admin_user, admin_password, and 
admin_tenant_name, but these were not generated by devstack. i wonder if 
we have an error or perhaps there are default values for these?


as for the proxy domain options, use_domain_for_proxy_users and 
proxy_user_domain_name, these must be added by the administrator (you) 
for devstack, and they must be in the DEFAULT section. in devstack you 
could set these parameters by adjusting your local.conf to contain 
something like:



[[post-config|$SAHARA_CONF_FILE]]
[DEFAULT]
use_domain_for_proxy_users=True
proxy_user_domain_name=sahara_proxy


of course, changing "sahara_proxy" to the name of the proxy domain you 
have created for use.




2. More other configurations must be set ?
 Such as:
 [DEFAULT]
use_identity_api_v3= True


i think using v3 is a good idea with this feature. i haven't tested it 
in v2, but i probably should and make some notes to the documentation 
accordingly. thanks!



regards,
mike


__
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] [Sahara] Questions about how Sahara use trust ?

[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 this be a bp or just a 
bug ?


Thanks.
-chen


hi chen,

i think the trusts for the transient clusters serve a different purpose 
than those for the swift access.


in the case of the swift proxy users, this is a security enhancement for 
us because in order for hadoop jobs to access swift they must use a set 
of credentials that are written to the workflow properties for the job.


for example, for hadoop-swift.jar to access swift it must have values for:

fs.swift.service.sahara.username
and
fs.swift.service.sahara.password

we wanted to avoid having the user enter their name and password into 
the data source dialog, storing those values in our database, and then 
having those values written out to a file on the nodes. to get around 
this, we created the proxy user whose permissions are limited to the 
trust and their accounts will expire when the job is finished. in this 
manner, we limit the vulnerable information that is stored on the nodes.


i hope that makes sense, but please ask more if it does not =)

mike

__
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] [Sahara] Questions about how Sahara use trust ?

[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 trust to operate on the user's project 
resources (clusters).



2. For transient cluster, what sahara need is to be able to operate.


correct.


3. For swift access , using user's own credentials is not safe.  Because the credentials  
is not used by sahara only, it will appear in "user space" (on the cluster 
nodes) at end.
 Using admin user is silly, doesn't gain any benefit, but create a more 
huge risk.


correct.


=>  proxy user must(better to) use proxy user, for security reason.
=>  transient cluster can work both way, but proxy user introduce extra effect 
which is not nessary, so admin user is enough.


i would say that is accurate.

mike

__
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] [all][api] New API Guidelines read for cross project review

[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
https://review.openstack.org/#/c/184358/

4. Adding 5xx guidance
https://review.openstack.org/#/c/183698/

if the API Working Group hasn't received any further feedback, we'll 
merge them on July 23.


thanks,
mike

__
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] [sahara] keystone session upgrade

[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 how we change the context to 
the admin user at some points, and in general how we change information 
in the context as we pass it around. this creates some issues with the 
currently proposed spec.


i think we might be better served by taking an approach where the 
context will hold the an auth plugin object. which would be populated 
from the keystonemiddleware for user requests and could be changed to 
the admin when necessary.


in this manner we would create sessions as necessary for each client, 
and then associate the auth plugin object with the session as we create 
the clients. this would also allow us to drop the session cache from the 
context, and we would still be able to have specific sessions for 
clients that require unique options (for example certs).


i'm curious if anyone has thoughts on this matter?

i will also likely be rewriting the spec to encompass these changes if i 
can get them working locally.


thanks,
mike

[1]: https://review.openstack.org/#/c/197743/

__
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] [all][api] New API Guidelines read for cross project review

[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/186526/

3. Adds guidance on request bodies with different Methods
https://review.openstack.org/#/c/184358/

4. Adding 5xx guidance
https://review.openstack.org/#/c/183698/

if the API Working Group hasn't received any further feedback, we'll
merge them on July 23.


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 for an extra week...

Your call.



thanks Thierry,

i don't think it will hurt to wait an extra week.

mike

__
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] [all][api] New API Guidelines read for cross project review

[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 for an extra week...

Your call.



thanks Thierry,

i don't think it will hurt to wait an extra week.


OK, added to week after next's meeting agenda:
https://wiki.openstack.org/wiki/Meetings/CrossProjectMeeting

Cheers,



thank you kindly sir ;)

__
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] [sahara] keystone session upgrade

[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 context. this will alleviate some of our reliance 
on the username/tenant_id/etc. authentication values that we currently 
use. this object will also be used in conjunction with the session cache 
to produce clients.


the session cache will be removed from the context and instead become a 
singleton type object in the sahara.service.sessions module. the cache 
will contain several specific functions for creating session objects for 
our different needs. for example, nova session will need to pass the 
specific nova certificate to the session. for non-specific needs the 
session object can be shared between several clients.


the clients themselves will use a combination of auth plugin object and 
session object for creation. in this manner we can associate different 
authentications with the sessions as needed and still share the 
connection pooling and caching that occurs in the session object. this 
will also allow us to continue to create admin clients as needed, we can 
either pass an admin authentication object to the client or set the 
context to have an admin authenticated plugin object.


there are still a few questions to be answered about trust scoping, but 
i think they will fit in this model. i would still be curious to hear 
any thoughts about this approach, but i will continue to test it and 
work towards rewriting the spec.


regards,
mike


__
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] [sahara] keystone session upgrade

[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 things relevant to this request, however for convenience it might 
be worth having a pointer from context to the global.

You then create clients then with the combination of session+auth. You don't 
need/want to attach the auth plugin to the session here as that makes it 
difficult to reuse.

When using sessions like this client creation is cheap (no requests are made) 
so there's no reason to hang on to the client objects themselves.

I'm not sure if that helped at all but catch me on IRC and I'll help out with 
what I can.

Jamie


hi Jamie,

yes that does help, and i think we are on the same page in terms of the 
implementation i'm exploring.


so, i have created a global object to hold the sessions we are using. 
namely a generic session and then any specific sessions we might need 
(based on using certs and what not).


the context only holds the auth info for the current user, i'm storing 
the auth plugin that comes from the keystonemiddleware out of convenience.


when we create client objects we are using a session from the global 
cache plus an auth plugin object from the context or an admin generated 
auth plugin.


it seems to be working well so far, i have a few issues to sort out with 
trusts and when to inject them in the process. but, i think this 
methodology will work for us in general.


regards,
mike

__
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] [glance][api] Response when a illegal body is sent

[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:
https://bugs.launchpad.net/glance/+bug/1475647 This is an example of
a GET however this also applies to other requests.

What should Glance do rather than throwing a 500, should it return a
400 as the user provided an illegal body


Yep, this.


+1, this should be a 400. It would also be acceptable (though less
preferable) to ignore any body on GET requests and execute the request
as normal.


Best,
-jay


i'm also +1 on the 400 band wagon

mike

__
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] [api] PATCH guidelines concerning body content

[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 
akin to sub-resource updating.


it seems reasonable that regardless of the methodology a project 
chooses, that the project should remain consistent internally. 
furthermore, it sounds like there are a number of different 
implementations in use around the openstack ecosystem which makes it 
more difficult to recommend a singular approach. although we could 
choose a direction as "most advisable".


we currently mention PATCH[2], and both 6902 and partial resource style 
updates. i'd like to open a discussion around what type of guidance we 
can provide in this area. i see a few options we could explore for 
guidelines:


* choosing a consistent updating methodology
* advising a sensible choice as the default preference of the wg (6902, 
partial resource, sub-resource)

* providing examples

what do folks think about creating some specific guidance for updating 
resources?


regards,
mike

[1]: 
http://eavesdrop.openstack.org/irclogs/%23openstack-api/%23openstack-api.2015-07-28.log.html#t2015-07-28T21:49:08


[2]: 
http://specs.openstack.org/openstack/api-wg/guidelines/http.html#http-methods


__
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] [keystone] policy issues when generating trusts with different clients

[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 trust is created as 
normal. But, if i create a Password based auth plugin object, using the 
same parameters, and the instantiate a Client by using the auth and a 
Session object, then i fail to create the trust with an error about not 
having sufficient permission.


i have put together a few python repl samples to show what is happening, 
these are also available on github[1].


the following code shows how we've been doing this, using the generic 
Client object we authenticate using the named parameters.


>>> from keystoneclient.v3 import client
>>> trustor = client.Client(
auth_url='http://192.168.122.2:5000/v3',
username='demo',
password='openstack',
project_name='demo',
user_domain_name='Default',
project_domain_name='Default')
>>> trustee = client.Client(
auth_url='http://192.168.122.2:5000/v3',
username='admin',
password='openstack',
project_name='admin',
user_domain_name='Default',
project_domain_name='Default')
>>> trustor.trusts.create(
trustor_user=trustor.user_id,
trustee_user=trustee.user_id,
project=trustor.project_id,
role_names=['Member'],
impersonation=True,
expires_at=None)
id=ac0d8f3b9e7443c2bdb0f855c2a3b9b5, impersonation=True, links={u'self': 
u'http://192.168.122.2:35357/v3/OS-TRUST/trusts/ac0d8f3b9e7443c2bdb0f855c2a3b9b5'}, 
project_id=416290f342e04a34acccafe79bb399c7, redelegation_count=0, 
remaining_uses=None, roles=[{u'id': u'433c86b705ef4656b90514ea5401469e', 
u'links': {u'self': 
u'http://192.168.122.2:35357/v3/roles/433c86b705ef4656b90514ea5401469e'}, u'name': 
u'Member'}], roles_links={u'self': 
u'http://192.168.122.2:35357/v3/OS-TRUST/trusts/ac0d8f3b9e7443c2bdb0f855c2a3b9b5/roles', 
u'next': None, u'previous': None}, 
trustee_user_id=cf45da134c76460e89b5837e07cc4b82, 
trustor_user_id=863b972dbbfd44b7bbde1b988e2b5098>


the trust is created with no issues.

next, i try to create a Client using a Session and a Password auth 
plugin object.


>>> from keystoneclient.auth.identity import v3
>>> from keystoneclient import session
>>> sess = session.Session()
>>> trustor_auth = v3.Password(
auth_url='http://192.168.122.2:5000/v3',
username='demo',
password='openstack',
project_name='demo',
user_domain_name='Default',
project_domain_name='Default')
>>> trustee_auth = v3.Password(
auth_url='http://192.168.122.2:5000/v3',
username='admin',
password='openstack',
project_name='admin',
user_domain_name='Default',
project_domain_name='Default')
>>> trustor = client.Client(session=sess, auth=trustor_auth)
>>> trustee = client.Client(session=sess, auth=trustee_auth)
>>> trustor.trusts.create(
trustor_user=trustor.user_id,
trustee_user=trustee.user_id,
project=trustor.project_id,
role_names=['Member'],
impersonation=True,
expires_at=None)
Traceback (most recent call last):
  File "", line 1, in 
  File 
"/home/mike/.venvs/openstack/lib/python2.7/site-packages/keystoneclient/v3/contrib/trusts.py", 
line 76, in create

**kwargs)
  File 
"/home/mike/.venvs/openstack/lib/python2.7/site-packages/keystoneclient/base.py", 
line 73, in func

return f(*args, **new_kwargs)
  File 
"/home/mike/.venvs/openstack/lib/python2.7/site-packages/keystoneclient/base.py", 
line 333, in create

self.key)
  File 
"/home/mike/.venvs/openstack/lib/python2.7/site-packages/keystoneclient/base.py", 
line 151, in _create

return self._post(url, body, response_key, return_raw, **kwargs)
  File 
"/home/mike/.venvs/openstack/lib/python2.7/site-packages/keystoneclient/base.py", 
line 165, in _post

resp, body = self.client.post(url, body=body, **kwargs)
  File 
"/home/mike/.venvs/openstack/lib/python2.7/site-packages/keystoneclient/adapter.py", 
line 176, in post

return self.request(url, 'POST', **kwargs)
  File 
"/home/mike/.venvs/openstack/lib/python2.7/site-packages/keystoneclient/adapter.py", 
line 206, in request

resp = super(LegacyJsonAdapter, self).request(*args, **kwargs)
  File 
"/home/mike/.venvs/openstack/lib/python2.7/site-packages/keystoneclient/adapter.py", 
line 95, in request

return self.session.request(url, method, **kwargs)
  File 
"/home/mike/.venvs/openstack/lib/python2.7/site-packages/keystoneclient/utils.py", 
line 336, in in

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

[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 further feedback, we'll
merge them on August 11.

thanks,
mike

__
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] policy issues when generating trusts with different clients

[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 understanding was 
that we could recycle the Session objects and just apply a new auth each 
time they are used.


mike


__
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] policy issues when generating trusts with different clients

[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 each client 
and i still get permission errors. i'm going to dig into the trust 
permission validation stuff a little.


mike


__
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] [sahara] update methods

[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 suspend/resume job functionality is using PATCH and the object 
updating is proposing using PUT. i agree with Andrey's thinking that we 
have been using PUT as if it were a PATCH, but i think we should just 
fix this inaccuracy before we go further.


i'm ok with leaving the scaling operation as a PUT for now as it uses 
slightly different logic in the body. but i think we should fix the node 
group template, cluster template, job binary, and data source update 
methods to be PATCH instead of PUT. is there any objection to me 
creating reviews to fix this inaccuracy?


i'm guessing the extent of the work would be in sahara and saharaclient. 
should i propose a bug for this or a spec?


thanks,
mike


[1]: https://review.openstack.org/#/c/208378/

__
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] [sahara] update methods

[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 that spec.


also, i think we should not be adding new update methods which use PUT then.

mike


__
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] policy issues when generating trusts with different clients

[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 me trustor.user_id is None which will make 
sense why you'd get permission errors.

Whether this is a bug in keystoneclient is debatable because we had to keep 
compatibility with the old options just not update them for the new paths, the 
ambiguity is certainly bad.

The command that works for me is:

trustor.trusts.create(
 trustor_user=trustor_auth.get_user_id(sess),
 trustee_user=trustee_auth.get_user_id(sess),
 project=trustor_auth.get_project_id(sess),
 role_names=['Member'],
 impersonation=True,
 expires_at=None)

We're working on a keystoneclient 2.0 that will remove all that old code.


Let me know if that fixes it for you.


hi Jamie,

this does work for me. but now i have a few questions as i start to 
refactor our code.


previously we have been handing around keystone Client objects to 
perform all of our operations. this leads to some trouble as we expected 
the user_id, and project_id, to be present in the client. so, 3 questions.


1. is it safe to set the user_id and project_id on a Client object?
(i notice that i am able to perform this operation and it would make 
things slightly easier to refactor)


2. are there plans for the new keystoneclient to automatically fill in 
user_id and project_id for Session/Auth based clients?


3. would it be better to transform our code to pass around Auth plugin 
objects instead of Client objects?


thanks again for the help,
mike


__
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] [all][api] New API Guidelines ready for cross project review

[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 length limit
https://review.openstack.org/#/c/181784/

if the API Working Group hasn't received any further feedback, we'll
merge them on August 18.

thanks,
mike

__
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] [sahara] Proposing Ethan Gafford for the core reviewer team

[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. Here are the statistics for reviews
[0][1][2] and commits [3]. BTW Ethan is already stable maint team core
for Sahara.

Existing Sahara core reviewers, please vote +1/-1 for the addition of
Ethan to the core reviewer team.

Thanks.

[0]
https://review.openstack.org/#/q/reviewer:%22Ethan+Gafford+%253Cegafford%2540redhat.com%253E%22,n,z
[1] http://stackalytics.com/report/contribution/sahara-group/90
[2] http://stackalytics.com/?user_id=egafford&metric=marks
[3]
https://review.openstack.org/#/q/owner:%22Ethan+Gafford+%253Cegafford%2540redhat.com%253E%22+status:merged,n,z

--
Sincerely yours,
Sergey Lukjanov
Sahara Technical Lead
(OpenStack Data Processing)
Principal Software Engineer
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] [all][api] New API Guidelines ready for cross project review

[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://review.openstack.org/#/c/181784/

if the API Working Group hasn't received any further feedback, we'll
merge them on August 18.


these are slated for merge today, but each has a few comments 
surrounding minor nit-type improvements. should we merge these as is and 
create fix patches, or can we add the changes and merge?


i realize that according to our process[1], these are technically good 
to merge as there is not enough -1 consensus to stop them. i just wanted 
to ask the group before pushing ahead.


mike

[1]: http://specs.openstack.org/openstack/api-wg/process.html

__
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] [all][api] New API Guidelines ready for cross project review

[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://review.openstack.org/#/c/181784/


these guidelines have been merged as per the freeze process guidelines.

guidelines #1 and #2, generated comments that should be addressed in 
follow-up patches.


thanks,
mike


__
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] [api] [docs] Generating API samples

[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 like the nova one?


sahara keeps examples for some of it's calls in our repo, although they 
are not a full example of all calls. these have all been hand-crafted, 
and could use some updating to add examples for the missing calls.


we are currently evaluating a new major version for our api[1], and are 
talking about creating an api directory in our specs repo to have more 
up-to-date samples, and a descriptive explanation, of our api. i'm 
guessing that initially these examples will be hand-crafted.



regards,
mike

[1]: https://review.openstack.org/#/c/212172/

__
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] [sahara] Bug triage/fix and doc update days in Liberty

[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, Ethan Gafford wrote:

Hello all,

Bugfix days for Liberty's Sahara release have begun! Please sign up for bug 
fixes at:
https://etherpad.openstack.org/p/sahara-liberty-bug-fix-day

Cheers,
Ethan Gafford
Senior Software Engineer
OpenStack Sahara
Red Hat, Inc.

- Original Message -
From: "Sergey Lukjanov" 
To: "OpenStack Development Mailing List" 
Sent: Thursday, August 13, 2015 11:12:33 AM
Subject: [openstack-dev] [sahara] Bug triage/fix and doc update days in Liberty

Hi folks,

on todays IRC meeting [0] we've agreed to have:

1) Bug triage day on Aug 17
We're looking for the volunteer to coordinate it ;) If someone wants to do it, 
please, reply to this email.
http://etherpad.openstack.org/p/sahara-liberty-bug-triage-day


2) Bug fix day on Aug 24
Ethan (egafford) volunteered to coordinate it.
http://etherpad.openstack.org/p/sahara-liberty-bug-fix-day


3) Doc update day on Aug 31
Mike (elmiko) volunteered to coordinate it.
http://etherpad.openstack.org/p/sahara-liberty-doc-update-day


Coordinators, please, add some initial notes to the ether pads and ensure that 
folks will be using them to sync efforts. For communication let's use 
#openstack-sahara IRC channel as always.

Thanks.

[0] 
http://eavesdrop.openstack.org/meetings/sahara/2015/sahara.2015-08-13-14.00.html




__
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] [api] [wsme] [ceilometer] Replacing WSME with _____ ?

[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


__
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] [sahara] Request for Feature Freeze Exception

[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, so it can be reason of several bugs in these versions;
  2. Minimal risk of removal: it doesn't touch versions that we already
have.
  3. All required changes was already uploaded to the review:
https://review.openstack.org/#/q/status:open+project:openstack/sahara+branch:master+topic:bp/drop-hadoop-1,n,z


this sounds reasonable to me

mike


__
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] [sahara] FFE request for heat wait condition support

[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
mailto:sreshetn...@mirantis.com>> wrote:

Hi,

I would like to request FFE for wait condition support for Heat engine.
Wait condition reports signal about booting instance.

Blueprint:
https://blueprints.launchpad.net/sahara/+spec/sahara-heat-wait-conditions

Spec:

https://github.com/openstack/sahara-specs/blob/master/specs/liberty/sahara-heat-wait-conditions.rst

Patch:
https://review.openstack.org/#/c/169338/

Thanks,
Sergey Reshetnyak

__
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




--
Best Regards,
Vitaly Gridnev
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] [Openstack] [Horizon] [Sahara] FFE request for Sahara unified job interface map UI

[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 it specifically aims at improving ease of use and comprehensibility, 
Horizon integration is critical to the success of the feature. The change 
itself is reasonably modular and thus low-risk; it will have no impact outside 
Sahara's job template creation and launch flow, and (failing unforseen issues) 
no impact to users of the existing flow who choose not to use this feature.

Thank you,
Ethan


+1 from me, this feature has received much attention and seems pretty 
low-risk of introducing critical errors.


mike


__
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] Getting Started : OpenStack

[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 check out any new developments. Thanks for
suggesting the IRC channel :) Btw, do you happen to know any other open
data analysis projects in OpenStack ?

Bee


hi Bee,

you may also be interested in the sahara project, the data processing 
service for openstack[1].


i am a developer with the project, and although we don't deal 
specifically in the analysis of data, we are addressing the issues of 
deploying popular data processing frameworks(Hadoop, Spark, Storm) into 
openstack.


if this sounds interesting, please stop by our channel, 
#openstack-sahara and chat us up. we are always looking for more people 
interested in contributing =)


regards,
mike

(elmiko on irc)

[1]: http://docs.openstack.org/developer/sahara/


__
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] [Sahara] FFE request for improved secret storage

[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 behavior that requires no change to a stack.


there is currently 1 review up which addresses the main thrust of this 
change, there will be 1 additional review which will include more 
passwords being migrated to use the mechanisms for offloading.


i expect this work to be complete by sept. 25.

review
https://review.openstack.org/#/c/220680/

blueprint
https://blueprints.launchpad.net/sahara/+spec/improved-secret-storage

spec
http://specs.openstack.org/openstack/sahara-specs/specs/liberty/improved-secret-storage.html

thanks,
mike

__
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] [Barbican] Nominating Dave Mccowan for Barbican core

[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 relevant code pieces and
making useful and thorough reviews; And so I think he would make a great
addition to the team.

Please bring the +1's :D

Cheers!

--
Juan Antonio Osorio R.
e-mail: jaosor...@gmail.com 



__
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] [sahara] FFE request for nfs-as-a-data-source

[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 for sahara.

This bp originally should include a dashboard change to create nfs as a
data source.

I will register it as another bp and implement it in next version.

However, these patches have already done to put nfs-driver into
sahara-image-elements and enable it in the cluster.

By using this way, the user can use nfs protocol via command line in
Liberty release.

Blueprint:

https://blueprints.launchpad.net/sahara/+spec/nfs-as-a-data-source

Spec:

https://review.openstack.org/#/c/210839/

Patch:

https://review.openstack.org/#/c/218637/

https://review.openstack.org/#/c/218638/



__
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-dev] [sahara] mitaka summit session ideas

[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 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] [sahara] hadoop-openstack.jar and proxy users

[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 in 
hadoop. v3 support is needed for proxy users and i'm guessing we are 
going to want this included by default in the future.


what is the current process for bundling this jar file and which images 
should it be included on?


i know that the vanilla 2.7.1 image does not contain this jar, i am 
curious if we should re-address which hadoop/swift connector jar is 
being included.


thoughts?


regards,
mike

__
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] [Sahara] FFE request for improved secret storage

[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 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 behavior that requires no change to a stack.

there is currently 1 review up which addresses the main thrust of this
change, there will be 1 additional review which will include more
passwords being migrated to use the mechanisms for offloading.

i expect this work to be complete by sept. 25.

review
https://review.openstack.org/#/c/220680/

blueprint
https://blueprints.launchpad.net/sahara/+spec/improved-secret-storage

spec
http://specs.openstack.org/openstack/sahara-specs/specs/liberty/improved-secret-storage.html


thanks,
mike

__
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] [Security] Weekly Meeting Agenda

[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 items (Please reply to add any more):

·PTL Shenanigans : https://review.openstack.org/#/c/224798/

·VMT Project Tracking : https://review.openstack.org/#/c/226869/

·Anchor (Ephemeral PKI)

·Bandit (Security Linter)

·Developer Guidance (Don’t do this)

·Security Documents (Do do this)

·Security Notes (Think about not doing this)

·Syntribos (API Fuzzing)

·Any Other Business

*//*

Have a good meeting all!

-Rob


thanks Rob


__
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] [sahara] Proposing Vitaly Gridnev to core reviewer team

[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 doing a great job on
reviewing and improving Sahara. Here are the statistics for reviews
[0][1][2] and commits [3].

Existing Sahara core reviewers, please vote +1/-1 for the addition of
Vitaly to the core reviewer team.

Thanks.

[0]
https://review.openstack.org/#/q/reviewer:%22Vitaly+Gridnev+%253Cvgridnev%2540mirantis.com%253E%22,n,z
[1] http://stackalytics.com/report/contribution/sahara-group/180
[2] http://stackalytics.com/?metric=marks&user_id=vgridnev
[3]
https://review.openstack.org/#/q/status:merged+owner:%22Vitaly+Gridnev+%253Cvgridnev%2540mirantis.com%253E%22,n,z

--
Sincerely yours,
Sergey Lukjanov
Sahara Technical Lead
(OpenStack Data Processing)
Principal Software Engineer
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] [sahara] Proposing Vitaly Gridnev to core reviewer team

[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 mailto:m...@redhat.com>> wrote:

+1!

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 doing a great
job on
reviewing and improving Sahara. Here are the statistics for reviews
[0][1][2] and commits [3].

Existing Sahara core reviewers, please vote +1/-1 for the
addition of
Vitaly to the core reviewer team.

Thanks.

[0]

https://review.openstack.org/#/q/reviewer:%22Vitaly+Gridnev+%253Cvgridnev%2540mirantis.com%253E%22,n,z
[1] http://stackalytics.com/report/contribution/sahara-group/180
[2] http://stackalytics.com/?metric=marks&user_id=vgridnev
[3]

https://review.openstack.org/#/q/status:merged+owner:%22Vitaly+Gridnev+%253Cvgridnev%2540mirantis.com%253E%22,n,z

--
Sincerely yours,
Sergey Lukjanov
Sahara Technical Lead
(OpenStack Data Processing)
Principal Software Engineer
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




--
Sincerely yours,
Sergey Lukjanov
Sahara Technical Lead
(OpenStack Data Processing)
Principal Software Engineer
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] [api] Proposing Michael McCune as an API Working Group core

[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 (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev