[Openstack-operators] [new][app-catalog] App Catalog next steps
[This message has been sent to the dev list in addition to the operators list as this project has significant value for both groups] I want to start off by thanking everyone who joined us at the first working session in Vancouver, and those folks who have already started adding content to the app catalog. I was happy to see the enthusiasm and excitement, and am looking forward to working with all of you to build this into something that has a major impact on OpenStack adoption by making it easier for our end users to find and share the assets that run on our clouds. The catalog: http://apps.openstack.org The repo: https://github.com/stackforge/apps-catalog The wiki: https://wiki.openstack.org/wiki/App-Catalog Please join us via IRC at #openstack-app-catalog on freenode. Our initial core team is Christopher Aedo, Tom Fifield, Kevin Fox, Serg Melikyan. I’ve started a doodle poll to vote on the initial IRC meeting schedule, if you’re interested in helping improve and build up this catalog please vote for the day/time that works best and get involved! http://doodle.com/vf3husyn4bdkui8w At the summit we managed to get one planning session together. We captured that on etherpad[1], but I’d like to highlight here a few of the things we talked about working on together in the near term: -More information around asset dependencies (like clarifying requirements for Heat templates or Glance images for instance), potentially just by providing better guidance in what should be in the description and attributes sections. -With respect to the assets that are listed in the catalog, there’s a need to account for tagging, rating/scoring, and a way to have comments or a forum for each asset so potential users can interact outside of the gerrit review system. -Supporting more resource types (Sahara, Trove, Tosca, others) -Discuss using glance artifact repository as the backend rather than flat YAML files -REST API, enable searching/sorting, this would ease native integration with other projects -Federated catalog support (top level catalog including contents from sub-catalogs) - I’ll be working with the OpenStack infra team to get the server and CI set up in their environment (though that work will not impact the catalog as it stands today). There were a ton of great ideas that came up and it was clear there was WAY more to discuss than we could accomplish in one short session at the summit. I’m looking forward to continuing the conversation here on the mailing list, on IRC, and in Tokyo as well! [1] https://etherpad.openstack.org/p/YVR-app-catalog-plans -Christopher ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
[Openstack-operators] Ops CI/CD, Deployments Session
Thanks to everyone who attended the CI/CD, Deployments sessions. We had a great discussion, but unfortunately etherpad was broken for the duration of the time. If anyone would like to add any notes on some of the new tools discussed during that talk, please add them. I don't recall any specific actions because this was more of a how is everyone doing things talk. https://etherpad.openstack.org/p/YVR-ops-deployment ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] Ops Keystone / Federation Session
Joe, Thanks for the notes. We had a productive discussion with the Glance folk on how to share images across clouds (https://libertydesignsummit.sched.org/event/6b4a5dbd177cde2aad7a9927a82534d0#.VWDLPpOqqko) and we’ll be working on that spec. We also had some forward looking discussions with the Keystone team on how to manage multi-cloud nested projects. As joe said, Federated identity is needed but giving users a transparent exprience will take much, much more. Are there blueprints created for this gap ? Tim From: joe j...@topjian.netmailto:j...@topjian.net Date: Friday 22 May 2015 23:26 To: openstack-operators openstack-operators@lists.openstack.orgmailto:openstack-operators@lists.openstack.org Subject: [Openstack-operators] Ops Keystone / Federation Session Hello, Better late than never, here's a summary of the Ops Keystone / Federation Session from this past Tuesday: First, I want to thank everyone from the Keystone team for attending the session -- it was very cool to have you guys on-hand to directly answer questions and give input and insight into the various items being discussed. This was the first time we had a discussion session dedicated to this topic and we could have easily spent entire sessions on each of the main items listed in the Etherpadhttps://etherpad.openstack.org/p/YVR-ops-federation. I think that shows there's a lot to be discussed with regard to federated clouds. The biggest discussion item to come out of the session was that a federated cloud means so much more than just Keystone. Allocating, restricting, automatic provisioning, reporting, and cleanup of any type of OpenStack-enabled resource in a federated cloud are all areas Operators are interested in learning about, but those areas are either not well defined (perhaps because what works for one federation won't work for another), are not possible to do yet, or are possible but Operators aren't sure how to implement them. I encourage operators who are interested in this area to keep the discussion going on this list by sharing your questions, concerns, and trials. As well, I hope to see this topic in future Ops meetups and tracks as a more formal way to touch base on this area. Etherpad: https://etherpad.openstack.org/p/YVR-ops-federation Thanks, Joe ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] Raising the degree of the scandal
George, are you willing to commit development resources to help address issues in Neutron, and improve the support for Linux Bridge, since All neutron/ovs stuff is horrible in term of performance ? Linux Bridge parity has been identified as a step towards a single network stack for OpenStack. We are in the process of enabling Linux Bridge testing at the gate to prevent bit-rot. We will need resources from the community to ensure that Linux Bridge is maintained, since Neutron's mission is to support many different networking solutions. I will also note that arp spoofing is the 3rd item on our priority list. https://etherpad.openstack.org/p/YVR-nova-network If anyone else wishes to volunteer, now is the time. Thanks -- Sean M. Collins ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
