Re: [openstack-dev] [tc][appcat] The future of the App Catalog

[Christopher Aedo]

On Fri, Mar 10, 2017 at 6:20 PM, Clint Byrum  wrote:
> Excerpts from Fox, Kevin M's message of 2017-03-10 23:45:06 +:
>> So, this is the kind of thinking I'm talking about... OpenStack today is
>> more then just IaaS in the tent. Trove (DBaaS), Sahara (Hadoop,Spark,etc
>> aaS), Zaqar (Messaging aaS) and many more services. But they seem to be
>> treated as second class citizens, as they are not "IaaS".
>>
>
> It's not that they're second class citizens. It's that their community
> is smaller by count of users, operators, and developers. This should not
> come as a surprise, because the lowest common denominator in any user
> base will always receive more attention.
>
>> > Why should it strive to be anything except an excellent building block
>> for other technologies?
>>
>> You misinterpret my statement. I'm in full agreement with you. The
>> above services should be excellent building blocks too, but are suffering
>> from lack of support from the IaaS layer. They deserve the ability to
>> be excellent too, but need support/vision from the greater community
>> that hasn't been forthcoming.
>>
>
> You say it like there's some over arching plan to suppress parts of the
> community and there's a pack of disgruntled developers who just can't
> seem to get OpenStack to work for Trove/Sahara/AppCatalog/etc.
>
> We all have different reasons for contributing in the way we do.  Clearly,
> not as many people contribute to the Trove story as do the pure VM-on-nova
> story.
>
>> I agree with you, we should embrace the container folks and not treat
>> them as separate. I think thats critical if we want to allow things
>> like Sahara or Trove to really fulfil their potential. This is the path
>> towards being an OpenSource AWS competitor, not just for being able to
>> request vm's in a cloudy way.
>>
>> I think that looks something like:
>> OpenStack Advanced Service (trove, sahara, etc) -> Kubernetes ->
>> Nova VM or Ironic Bare Metal.
>>
>
> That's a great idea. However, AFAICT, Nova is _not_ standing in Trove,
> Sahara, or anyone else's way from doing this. Seriously, try it. I'm sure
> it will work.  And in so doing, you will undoubtedly run into friction
> from the APIs. But unless you can describe that _now_, you have to go try
> it and tell us what broke first. And then you can likely submit feature
> work to nova/neutron/cinder to make it better. I don't see anything in
> the current trajectory of OpenStack that makes this hard. Why not just do
> it? The way you ask, it's like you have a team of developers just sitting
> around shaving yaks waiting for an important OpenStack development task.
>
> The real question is why aren't Murano, Trove and Sahara in most current
> deployments? My guess is that it's because most of our current users
> don't feel they need it. Until they do, Trove and Sahara will not be
> priorities. If you want them to be priorities _pay somebody to make them
> a priority_.

This particular point really caught my attention.  You imply that
these additional services are not widely deployed because _users_
don't want them.  The fact is most users are completely unaware of
them because these services require the operator of the cloud to
support them.  In fact they often require the operator of the cloud to
support them from the initial deployment, as these services (and
*most* OpenStack services) are frighteningly difficult to add to an
already deployed cloud without downtime and high risk of associated
issues.

I think it's unfair to claim these services are unpopular because
users aren't asking for them when it's likely users aren't even aware
of them (do OVH, Vexxhost, Dreamhost, Raskspace or others provide a
user-facing list of potential OpenStack services with a voting option?
 Not that I've ever seen!)

I bring this up to point out how much more popular ALL of these
services would be if the _users_ were able to enable them without
requiring operator intervention and support.

Based on our current architecture, it's nearly impossible for a new
project to be deployed on a cloud without cloud-level admin
privileges.  Additionally almost none of the projects could even work
this way (with Rally being a notable exception).  I guess I'm kicking
this dead horse because for a long time I've argued we need to back
away from the tightly coupled nature of all the projects, but
(speaking of horses) it seems that horse is already out of the barn.
(I really wish I could work in one more proverb dealing with horses
but it's getting late on a Friday so I'll stop now.)

-Christopher


>> Not what we have today:
>> OpenStack Advanced Service -> Nova VM or Ironic Bare Metal
>>
>> due to the focus on the api's of VM's being only for IaaS and not for
>> actually running cloud software on.
>>
>
> The above is an unfounded and unsupported claim. What _exactly_ would
> you want Nova/Neutron/Cinder's API to do differently to support "cloud
> software" better? Why is everyone dodging that 

Re: [openstack-dev] [devstack] A few questions on configuring DevStack for Neutron

[Christopher Aedo]

On Thu, Oct 8, 2015 at 5:41 PM, Monty Taylor <mord...@inaugust.com> wrote:
> On 10/08/2015 07:13 PM, Christopher Aedo wrote:
>>
>> On Thu, Oct 8, 2015 at 9:38 AM, Sean M. Collins <s...@coreitpro.com>
>> wrote:
>>>
>>> Please see my response here:
>>>
>>>
>>> http://lists.openstack.org/pipermail/openstack-dev/2015-October/076251.html
>>>
>>> In the future, do not create multiple threads since responses will get
>>> lost
>>
>>
>> Yep, thank you Sean - saw your response yesterday and was going to
>> follow-up this thread with a "please ignore" and a link to the other
>> thread.  I opted not to in hopes of reducing the noise but I think
>> your note here is correct and will close the loop for anyone who
>> happens across only this thread.
>>
>> (Secretly though I hope this thread somehow becomes never-ending like
>> the "don't -1 for a long commit message" thread!)
>
>
> (I think punctuation should go outside the parenthetical)?

Apologies for the late reply to this Monty but a response is required
considering the importance of proper punctuation as regards
parenthesis.

According to the Internet[1] (which is widely regarded as the
authority in such matters), the original usage of punctuation in this
case is the appropriate usage when the entire sentence is inside the
parenthesis.

Hopefully this diversion from the topic does not warrant a new thread.

[1]: http://www.grammarbook.com/punctuation/parens.asp

-Christopher

__
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] [tc][appcat][murano][app-catalog] The future of the App Catalog

[Christopher Aedo]

On Thu, Mar 9, 2017 at 4:08 AM, Thierry Carrez <thie...@openstack.org> wrote:
> Christopher Aedo wrote:
>> On Mon, Mar 6, 2017 at 3:26 AM, Thierry Carrez <thie...@openstack.org> wrote:
>>> [...]
>>> In parallel, Docker developed a pretty successful containerized
>>> application marketplace (the Docker Hub), with hundreds of thousands of
>>> regularly-updated apps. Keeping the App Catalog around (including its
>>> thinly-wrapped Docker container Murano packages) make us look like we
>>> are unsuccessfully trying to compete with that ecosystem, while
>>> OpenStack is in fact completely complementary.
>>
>> Without something like Murano "thinly wrapping" docker apps, how would
>> you propose current users of OpenStack clouds deploy docker apps?  Or
>> any other app for that matter?  It seems a little unfair to talk about
>> murano apps this way when no reasonable alternative exists for easily
>> deploying docker apps.  When I look back at the recent history of how
>> we've handled containers (nova-docker, magnum, kubernetes, etc) it
>> does not seem like we're making it easy for the folks who want to
>> deploy a container on their cloud...
>
> I'd say there are two approaches: you can use the container-native
> approach ("docker run" after provisioning some container-enabled host
> using Nova or K8s cluster using Magnum), or you can use the
> OpenStack-native approach (zun create nginx) and have it
> auto-provisioned for you. Those projects have a narrower scope, and
> fully co-opt the container ecosystem without making us appear as trying
> to build our own competitive application packaging/delivery/marketplace
> mechanism.
>
> I just think that adding the Murano abstraction in the middle of it and
> using an AppCatalog-provided Murano-powered generic Docker container
> wrapper is introducing unnecessary options and complexity -- options
> that are strategically hurting us when we talk to those adjacent
> communities...

OK thank you for making it clearer, now I understand where you're
coming from.  I do agree with this sentiment.  I don't have any
experience with zun but it sounds like it's the least-cost way to
deploy a docker at for the environments where it's installed.

I think overall the app catalog was an interesting experiment, but I
don't think it makes sense to continue as-is.  Unless someone comes up
with a compelling new direction, I don't see much point in keeping it
running.  Especially since it sounds like Mirantis is on board (and
the connection to a murano ecosystem was the only thing I saw that
might be interesting).

-Christopher

__
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] [tc][appcat][murano][app-catalog] The future of the App Catalog

[Christopher Aedo]

On Mon, Mar 6, 2017 at 3:26 AM, Thierry Carrez  wrote:
> Hello everyone,
>
> The App Catalog was created early 2015 as a marketplace of pre-packaged
> applications that you can deploy using Murano. Initially a demo by
> Mirantis, it was converted into an open upstream project team, and
> deployed as a "beta" as apps.openstack.org.
>
> Since then it grew additional categories (Glance images, Heat & Tosca
> templates), but otherwise did not pick up a lot of steam. The website
> (still labeled "beta") features 45 glance images, 6 Tosca templates, 13
> heat templates and 94 murano packages (~30% of which are just thin
> wrappers around Docker containers). Traffic stats show around 100 visits
> per week, 75% of which only read the index page.
>
> In parallel, Docker developed a pretty successful containerized
> application marketplace (the Docker Hub), with hundreds of thousands of
> regularly-updated apps. Keeping the App Catalog around (including its
> thinly-wrapped Docker container Murano packages) make us look like we
> are unsuccessfully trying to compete with that ecosystem, while
> OpenStack is in fact completely complementary.

Without something like Murano "thinly wrapping" docker apps, how would
you propose current users of OpenStack clouds deploy docker apps?  Or
any other app for that matter?  It seems a little unfair to talk about
murano apps this way when no reasonable alternative exists for easily
deploying docker apps.  When I look back at the recent history of how
we've handled containers (nova-docker, magnum, kubernetes, etc) it
does not seem like we're making it easy for the folks who want to
deploy a container on their cloud...

Please understand I am not pleading to keep the Community App Catalog
alive in perpetuity.  This just sounds like an unfair point of
comparison.  One of the biggest challenges we've faced with the app
catalog since day one is that there is no such thing as a simple
definition of an "OpenStack Application".  OpenStack is an IaaS before
anything else, and to my knowledge there is no universally accepted
application deployment mechanism for OpenStack clouds.  Heat doesn't
solve that problem as its very operator focused, and while being very
popular and used heavily, it's not used as a way to share generic
templates suitable for deploying apps across different clouds.  Murano
is not widely adopted (last time I checked it's not available on any
public clouds, though I hear it is actually used on a several
university clouds, and it's also used on a few private clouds I'm
aware of.)

As a place to find things that run on OpenStack clouds, the app
catalog did a reasonable job.  If anything, the experiment showed that
there is no community looking for a place to share OpenStack-specific
applications.  There are definitely communities for PaaS layers (cloud
foundry, mesosphere, docker, kubernetes), but I don't see any
community for openstack-native applications that can be deployed on
any cloud, nor a commonly accepted way to deploy them.

> In the past we have retired projects that were dead upstream. The App
> Catalog is not in this case: it has an active maintenance team, which
> has been successfully maintaining the framework and accepting
> applications. If we end up retiring the App Catalog, it would clearly
> not be a reflection on that team performance, which has been stellar
> despite limited resources. It would be because the beta was arguably not
> successful in building an active marketplace of applications, and
> because its continuous existence is not a great fit from a strategy
> perspective. Such removal would be a first for our community, but I
> think it's now time to consider it.
>
> Before we discuss or decide anything at the TC level, I'd like to
> collect everyone thoughts (and questions) on this. Please feel free to
> reply to this thread (or reach out to me privately if you prefer). Thanks !

As the former PTL I am obviously a little bit biased.  Even though my
focus has shifted and I've stepped away from the app catalog, I had
been spending a lot of time trying to figure out how to make
applications an easy to run thing on OpenStack.  I've also been trying
to find a community of people who are looking for that, and it doesn't
seem like they've materialized; possibly because that community
doesn't exist?  Or else we just haven't been able to figure out where
they're hiding ;)

The one consideration that is pretty important here is what this would
mean to the Murano community.  Those folks have been contributed time
and resources to the app catalog project.  They've also standardized
on the app catalog as the distribution mechanism, intending to make
the app catalog UI a native component for Murano. We do need to make
sure that if the app catalog is retired, it doesn't hamper or impact
people who have already deployed Murano and are counting on finding
the apps in the app catalog.

-Christopher

>
> --
> Thierry Carrez (ttx)
>
> 

Re: [openstack-dev] [all][tc] Exposing project team's metadata in README files

[Christopher Aedo]

On Fri, Nov 25, 2016 at 3:38 AM, Flavio Percoco  wrote:
> Greetings,
>
> Just a heads up for everyone. The work on this front has moved forward and
> the
> badges are now being generated as part of the governance CI[0].
>
> You can find the list of badges here[1] and the pattern is quite obvious,
> the
> name of the image is based on the project repo name.
>
> I've edited the README files for all repositories listed in the
> projects.yaml
> file and I've started to submit these patches[2]. I'm not a fan of "viral
> changes" but I've done my best to explain what's changing, provide
> references
> and examples on the commit message. These changes are being submitted using
> the
> tag 'project-badges'[2].
>
> Note that these badges are *JUST* a graphical representation of what's in
> the
> governance repo. If you don't want to have them in the README file, I guess
> it's
> fine. I'd, however, encourage everyone to add them to provide consistency
> and a
> more immediate information of what the project is about, what some of the
> project capabilities are and what its status is.
>
> Ideally this should also be added in projects documentation as well but I'll
> leave that to every team to do.

Thanks for doing the work to get this automated Flavio!  As a few
others have noted, I did not like the placement at the very top but I
understand it's not reasonably possible to automate this in a way that
find the idea insertion point.  For me at any rate, I've moved them
down to just under the first paragraph explaining the project.

One other important thing that's missing however is the :alt: tag
underneath the image.  For accessibility purposes (and considering
this is all automated anyway) I don't think these badges should be
merged without text describing the image.

-Christopher

> Happy to answer questions,
> Flavio
>
> P.S: The current layout is being improved[3], if you have better ideas
> please
> help out.
>
> [0] https://review.openstack.org/#/c/391588/
> [1] http://governance.openstack.org/badges/
> [2] https://review.openstack.org/#/q/topic:project-badges
> [3] https://review.openstack.org/#/c/399278/
>
>
> On 12/10/16 14:50 +0200, Flavio Percoco wrote:
>>
>> Greetings,
>>
>> One of the common complains about the existing project organization in the
>> big
>> tent is that it's difficult to wrap our heads around the many projects
>> there
>> are, their current state (in/out the big tent), their tags, etc.
>>
>> This information is available on the governance website[0]. Each official
>> project team has a page there containing the information related to the
>> deliverables managed by that team. Unfortunately, I don't think this page
>> is
>> checked often enough and I believe it's not known by everyone.
>>
>> In the hope that we can make this information clearer to people browsing
>> the
>> many repos (most likely on github), I'd like to propose that we include
>> the
>> information of each deliverable in the readme file. This information would
>> be
>> rendered along with the rest of the readme (at least on Github, which
>> might not
>> be our main repo but it's the place most humans go to to check our
>> projects).
>>
>> Rather than duplicating this information, I'd like to find a way to just
>> "include it" in the Readme file. As far as showing the "official" badge
>> goes, I
>> believe it'd be quite simple. We can do it the same way CI tags are
>> exposed when
>> using travis (just include an image). As for the rest of the tags, it
>> might
>> require some extra hacking.
>>
>> So, before I start digging more into this, I wanted to get other
>> opinions/ideas
>> on this topic and how we can make this information more evident to the
>> rest of
>> the community (and people not as familiar with our processes as some of us
>> are).
>>
>> Thanks in advance,
>> Flavio
>>
>> [0] http://governance.openstack.org/reference/projects/index.html
>>
>> --
>> @flaper87
>> Flavio Percoco
>
>
>
>
> --
> @flaper87
> Flavio Percoco
>
> __
> 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] [app-catalog] App Catalog IRC meeting Thursday November 17th

[Christopher Aedo]

Join us tomorrow (Thursday) for our weekly meeting, scheduled for
November 17th at 17:00UTC in #openstack-meeting-3

The agenda can be found here, and please add to if you want to discuss
something with the Community App Catalog team:
https://wiki.openstack.org/wiki/Meetings/app-catalog

Now that the dust has settled from the summit we'll pick up where we
left off - that will be discussing the transition to using Glare for
the backend.  We have a test server launched by infra now and are at
the point where we are down to fine tuning.  If you can join the
meeting to discuss further, please do!

__
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] Useful tool for easier viewing of IRC logs online

[Christopher Aedo]

On Mon, Nov 7, 2016 at 7:09 AM, Jimmy McArthur  wrote:
> Hi all - Wanted to circle back on this now that we're clear of the Summit
> madness. Someone had asked for assistance on getting OpenStackID up and
> running on this. Is that still a need? If so, let me know how we can help.

Jimmy, I know you and I briefly discussed something else relating to
IRC and authenticating with OpenStack ID.  It has to do with infra
hosting an instance of "The Lounge" IRC client, as outlined in this
spec[1].

If that's what you were thinking of, I'm definitely still interested
in getting your view on whether or not integrating auth via OpenStack
ID is something you could help with :)

[1]: https://review.openstack.org/319506

-Christopher



> Thank you,
> Jimmy
>
> Chris Dent
> September 21, 2016 at 3:47 PM
> On Wed, 21 Sep 2016, Boden Russell wrote:
>
>
> For channels that are configured to have purplerbot running, you can
> get that with p!spy. See https://anticdent.org/purple-irc-bot.html
>
> If you want the bot added to a channel let me know, or run your own;
> the code is linked from the blog post.
>
> __
> 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
> Boden Russell
> September 21, 2016 at 1:22 PM
>
> Nice thanks!
>
> I've always wanted a tool that could alert me of "missed mentions" when
> I'm offline IRC rather than having to manually parse the IRC logs for
> those times I'm offline. However I'm guessing that falls outside the
> scope of this tool or could be done with some other tool (I haven't
> investigated yet)?
>
> __
> 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
> Asselin, Ramy
> September 19, 2016 at 11:54 AM
>
> Very nice, thanks!
>
> Only change I’ll suggest is to allow it to be enabled by default J
>
> Ramy
>
>
>
> From: Bashmakov, Alexander [mailto:alexander.bashma...@intel.com]
> Sent: Friday, September 16, 2016 2:26 PM
> To: OpenStack Development Mailing List (not for usage questions)
> 
> Subject: [openstack-dev] [all] Useful tool for easier viewing of IRC logs
> online
>
>
>
> Hello Stackers,
>
>
>
> If you ever find yourself needing to peruse OpenStack IRC logs online
> (http://eavesdrop.openstack.org/irclogs/) and if you use the Chrome browser
> to do it, then the following tool may come in handy:
>
>
>
> https://chrome.google.com/webstore/detail/openstack-eavesdrop-irc-f/lcmadadicbflcamibnpplpgdcdahkade
>
>
>
> It’s a simple extension to filter messages of the type: “ has quit”
> and “ has joined”, which makes the log much more compact and readable.
>
>
>
> Source code is here: https://github.com/abashmak/chrome-irc-filter
>
>
>
> Comments, suggestions are welcome.
>
> __
> 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

[openstack-dev] [app-catalog] Work session etherpad

[Christopher Aedo]

Thanks for joining and having another great conversation - just wanted
to share the link to the etherpad for reference.  Looking forward to
continuing to work with you all in the months ahead!

https://etherpad.openstack.org/p/app-catalog-ocata-summit

-Christopher

__
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] [app-catalog] Barcelona summit planning

[Christopher Aedo]

Let's start noting session plans for our working sessions in
Barcelona.  I've started an etherpad here:
https://etherpad.openstack.org/p/app-catalog-ocata-summit

-Christopher

__
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] App Catalog IRC meeting Thursday September 22nd

[Christopher Aedo]

Join us tomorrow (Thursday) for our weekly meeting, scheduled for
September 22nd at 17:00UTC in #openstack-meeting-3

The agenda can be found here, and please add to if you want to discuss
something with the Community App Catalog team:
https://wiki.openstack.org/wiki/Meetings/app-catalog

As has been for the last few weeks, the focus tomorrow will be on our
implementation of Glare for our backend and v2 API.  There's a bunch
of work left to do just on the review side so if anyone has a few
space cycles and wants to get involved, please join us tomorrow (or
look through https://review.openstack.org/#/q/topic:bp/glare-work if
you can't make the meeting).

-Christopher

__
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] App Catalog IRC meeting Thursday September 15th

[Christopher Aedo]

Join us Thursday for our weekly meeting, scheduled for September 15th
at 17:00UTC in #openstack-meeting-3

The agenda can be found here, and please add to if you want to discuss
something with the Community App Catalog team:
https://wiki.openstack.org/wiki/Meetings/app-catalog

Tomorrow we will be talking more about the next steps we will be
taking in implementing GLARE as a back-end for the Community App
Catalog.  We are very close to merging a bunch of patches that will
make this possible, which will be a big benefit to the App Catalog.

Hope to see you there tomorrow!

__
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] App Catalog IRC meeting Thursday August 25th

[Christopher Aedo]

Join us Thursday for our weekly meeting, scheduled for August 25th at
17:00UTC in #openstack-meeting-3

The agenda can be found here, and please add to if you want to discuss
something with the Community App Catalog team:
https://wiki.openstack.org/wiki/Meetings/app-catalog

Tomorrow we will be talking more about the next steps we will be
taking in implementing GLARE as a back-end for the Community App
Catalog.  We've seen some really rapid progress the last few weeks so
hopefully we'll be flipping the switch soon!

Hope to see you there tomorrow!

__
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] App Catalog IRC meeting Thursday August 11th

[Christopher Aedo]

Join us Thursday for our weekly meeting, scheduled for August 11th at
17:00UTC in #openstack-meeting-3

The agenda can be found here, and please add to if you want to discuss
something with the Community App Catalog team:
https://wiki.openstack.org/wiki/Meetings/app-catalog

Tomorrow we will be talking more about the next steps we will be
taking in implementing GLARE as a back-end for the Community App
Catalog.

Hope to see you there tomorrow!

__
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] App Catalog IRC meeting Thursday August 4th

[Christopher Aedo]

Join us Thursday for our weekly meeting, scheduled for August 4th at
17:00UTC in #openstack-meeting-3

The agenda can be found here, and please add to if you want to discuss
something with the Community App Catalog team:
https://wiki.openstack.org/wiki/Meetings/app-catalog

Tomorrow we will be talking more about our review and merge policies,
and the next steps we will be taking in implementing GLARE as a
back-end for the Community App Catalog.

Hope to see you there tomorrow!

__
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] [app-catalog] App Catalog mascot

[Christopher Aedo]

On Thu, Jul 14, 2016 at 11:20 AM, Christopher Aedo <d...@aedo.net> wrote:
> Today we decided to set up an etherpad for picking a mascot for the
> Community App Catalog.  If you'd like to propose an idea or vote on
> one of the ones already up there, please check out the etherpad -
> thanks!
>
> https://etherpad.openstack.org/p/app-catalog-mascot

It seems our etherpad disappeared into the ether, so let's just finish
the voting here on the mailing list.  I'll list what I remember seeing
on the pad, and if you're interested in voting on the app-catalog
mascot please respond to this thread with your favorite creature.

Quokka - cute but pretty obscure

Kangaroo - could have a pouch full of apps

Cat - for "cat"alog

I personally vote for Kangaroo :)

-Christopher

__
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] App Catalog IRC meeting Thursday July 21st

[Christopher Aedo]

Join us Thursday for our weekly meeting, scheduled for July 21st at
17:00UTC in #openstack-meeting-3

The agenda can be found here, and please add to if you want to discuss
something with the Community App Catalog team:
https://wiki.openstack.org/wiki/Meetings/app-catalog

Tomorrow we will be talking more about our plan to implement GLARE as
a back-end for the Community App Catalog, and what we'll need to merge
in the next few weeks to make this a reality.  We will hopefully agree
on a mascot for the Community App Catalog as well.

Hope to see you there tomorrow!

__
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] [app-catalog] App Catalog mascot

[Christopher Aedo]

Today we decided to set up an etherpad for picking a mascot for the
Community App Catalog.  If you'd like to propose an idea or vote on
one of the ones already up there, please check out the etherpad -
thanks!

https://etherpad.openstack.org/p/app-catalog-mascot

-Christopher

__
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] [app-catalog] App Catalog IRC meeting Thursday July 14th

[Christopher Aedo]

Join us Thursday for our weekly meeting, scheduled for July 14th at
17:00UTC in #openstack-meeting-3

The agenda can be found here, and please add to if you want to discuss
something with the Community App Catalog team:
https://wiki.openstack.org/wiki/Meetings/app-catalog

Tomorrow we will be talking more about our plan to implement GLARE as
a back-end for the Community App Catalog, and what we'll need to merge
in the next few weeks to make this a reality.

Hope to see you there tomorrow!

__
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] [app-catalog] App Catalog IRC meeting Thursday July 7th

[Christopher Aedo]

Join us Thursday for our weekly meeting, scheduled for July 7th at
17:00UTC in #openstack-meeting-3

The agenda can be found here, and please add to if you want to discuss
something with the Community App Catalog team:
https://wiki.openstack.org/wiki/Meetings/app-catalog

Tomorrow we will be talking more about our plan toimplement GLARE as a
back-end for the Community App Catalog, and what we'll need to merge
in the next few weeks to make this a reality.

Hope to see you there tomorrow!

__
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] [app-catalog] App Catalog IRC meeting Thursday June 30th

[Christopher Aedo]

Join us Thursday for our weekly meeting, scheduled for June 30th at
17:00UTC in #openstack-meeting-3

The agenda can be found here, and please add to if you want to discuss
something with the Community App Catalog team:
https://wiki.openstack.org/wiki/Meetings/app-catalog

Tomorrow we expect to talk in some detail about our next steps with
implement GLARE as a back-end for the Community App Catalog.
(Mirantis has thrown several resources at making this happen, thanks!)

Hope to see you there tomorrow!

__
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] [app-catalog] App Catalog IRC meeting Thursday June 16th

[Christopher Aedo]

Join us Thursday for our weekly meeting, scheduled for June 16th at
17:00UTC in #openstack-meeting-3

The agenda can be found here, and please add to if you want to discuss
something with the Community App Catalog team:
https://wiki.openstack.org/wiki/Meetings/app-catalog

In addition to status updates, we will continue the conversation
around the Application Development improvement effort being led by
Igor Marnat.

Hope to see you there tomorrow!

__
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] [app-catalog] App Catalog IRC meeting Thursday June 9th

[Christopher Aedo]

Join us Thursday for our weekly meeting, scheduled for June 9th at
17:00UTC in #openstack-meeting-3

The agenda can be found here, and please add to if you want to discuss
something with the Community App Catalog team:
https://wiki.openstack.org/wiki/Meetings/app-catalog

Tomorrow in addition to status updates, we plan to talk more about the
Application Development improvement effort being led by Igor Marnat.
Please join us if you have any thoughts or opinions on that front (and
read these two previous messages for the background:
http://lists.openstack.org/pipermail/user-committee/2016-May/000854.html
and http://lists.openstack.org/pipermail/openstack-dev/2016-May/095917.html).

-Christopher

__
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] [app-catalog] [heat] [murano] App Catalog IRC meeting Thursday May 26th

[Christopher Aedo]

Join us Thursday for our weekly meeting, scheduled for May 26th at
17:00UTC in #openstack-meeting-3

The agenda can be found here, and please add to if you want to discuss
something with the Community App Catalog team:
https://wiki.openstack.org/wiki/Meetings/app-catalog

This week we will see some updates from the folks working on the Glare
backend in addition to discussing the application developer community
building thread Igor Marnat kicked off
(http://lists.openstack.org/pipermail/user-committee/2016-May/000854.html).

Looking forward to seeing you all there tomorrow!

-Christopher

__
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] [app-catalog] App Catalog IRC meeting Thursday May 12th

[Christopher Aedo]

Join us Thursday for our weekly meeting, scheduled for May 12th at
17:00UTC in #openstack-meeting-3

The agenda can be found here, and please add to if you want to discuss
something with the Community App Catalog team:
https://wiki.openstack.org/wiki/Meetings/app-catalog

It might be a short meeting as I (and I suspect others) have not fully
caught back up from all the fun during the summit :)  Just the same,
looking forward to seeing you there tomorrow!

-Christopher

__
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] [app-catalog] [glare] [murano] [mistral] Austin summit summary: Community App Catalog

[Christopher Aedo]

On Wed, May 4, 2016 at 9:15 PM, Renat Akhmerov <renat.akhme...@gmail.com> wrote:> Cool, feel free to communicate with us on adding Mistral assets into the> catalog.Of course!  We started a blueprint for the related tasks[1] and hopefully myself or someone from the Mistral team will be able to take a few of the first steps soon.  I think Mistral workflows would be a really useful addition to the Community App Catalog so I'm excited to drive this effort.One of the sessions I saw at the summit really impressed me.  "Using OpenStack to clean up after itself"[2] was really cool to see.  Is that example worflow used during the demo available somewhere?[1]: https://blueprints.launchpad.net/app-catalog/+spec/add-mistral-assets[2]: http://www.openstack.org/videos/video/using-openstack-to-clean-up-after-itself-automatically-run-mistral-workflows-in-response-to-openstack-notifications-Christopher> Renat Akhmerov> @Nokia>> On 05 May 2016, at 06:43, Nikhil Komawar <nik.koma...@gmail.com> wrote:>> Thanks Christopher for a really nice summary!>>> On 5/4/16 7:37 PM, Christopher Aedo wrote:>> Hello!  At the summit I was excited to have many conversations with> folks who are already using the Community App Catalog regularly, and> many others who plan to increase their level of participation in the> months to come - I'm really happy to see the continued interest in> this effort.  For those that were unable to join us in Austin, I> wanted to provide a brief summary of what we covered and discussed> during our fishbowl and design sessions.  We tracked everything on an> etherpad[1] which captures the details.>> During the fishbowl session we talked about some of the new things we> implemented in the last cycle including the addition of TOSCA assets> to the catalog and a bunch of new tests that we added to the Horizon> plugin.  We also had an opportunity to discuss our plans to integrate> Glare as a backend for the catalog and everything that will allow us> to do. The most visible bits will be the ability for users to provide> feedback and ratings for assets in addition to subscribing to an asset> so they can be notified when the asset is updated.  We are planning to> complete implementation of the Glare backend within the next four months.>> Following the fishbowl session we had two work sessions during which> we agreed on a few notable things, and the one which will have the> most impact is closer coordination and integration with Murano.  This> will include coordinated efforts on the UI side as well as the OSC> work we've been doing.  The broader intention is to disambiguate the> two projects in order to make it clear the Community App Catalog is> the community run central repository for "things that run on OpenStack> clouds" while still aiming for tight integration where appropriate.>> We will have two cross-project specs coming in the next month to> detail these efforts and make clear our intentions and where things> will overlap.> Thanks again to everyone who was able to attend our sessions, and to> all those who continue to help us build up the Community App Catalog!>> -Christopher> [1]: https://etherpad.openstack.org/p/AUS-app-catalog>>>>> __> 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>>> -->> Thanks,> Nikhil>>> __> 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

[openstack-dev] [app-catalog] [glare] [murano] [mistral] Austin summit summary: Community App Catalog

[Christopher Aedo]

Hello!  At the summit I was excited to have many conversations with folks who are already using the Community App Catalog regularly, and many others who plan to increase their level of participation in the months to come - I'm really happy to see the continued interest in this effort.  For those that were unable to join us in Austin, I wanted to provide a brief summary of what we covered and discussed during our fishbowl and design sessions.  We tracked everything on an etherpad[1] which captures the details.
 
During the fishbowl session we talked about some of the new things we implemented in the last cycle including the addition of TOSCA assets to the catalog and a bunch of new tests that we added to the Horizon plugin.  We also had an opportunity to discuss our plans to integrate Glare as a backend for the catalog and everything that will allow us to do. The most visible bits will be the ability for users to provide feedback and ratings for assets in addition to subscribing to an asset so they can be notified when the asset is updated.  We are planning to complete implementation of the Glare backend within the next four months.
 
Following the fishbowl session we had two work sessions during which we agreed on a few notable things, and the one which will have the most impact is closer coordination and integration with Murano.  This will include coordinated efforts on the UI side as well as the OSC work we've been doing.  The broader intention is to disambiguate the two projects in order to make it clear the Community App Catalog is the community run central repository for "things that run on OpenStack clouds" while still aiming for tight integration where appropriate.
 
We will have two cross-project specs coming in the next month to detail these efforts and make clear our intentions and where things will overlap.
Thanks again to everyone who was able to attend our sessions, and to all those who continue to help us build up the Community App Catalog!
 
-Christopher
[1]: https://etherpad.openstack.org/p/AUS-app-catalog
 


__
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] [app-catalog] App Catalog IRC meeting Thursday May 5th

[Christopher Aedo]

Join us Thursday for our weekly meeting, scheduled for May 5th at
17:00UTC in #openstack-meeting-3

The agenda can be found here, and please add to if you want to get
something on the agenda:
https://wiki.openstack.org/wiki/Meetings/app-catalog

Looking forward to seeing you there tomorrow!

-Christopher

__
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] Community App Catalog IRC meeting Thursday April 14th

[Christopher Aedo]

Join us Thursday for our weekly meeting, scheduled for April 14th at
17:00UTC in #openstack-meeting-3

The agenda can be found here, and please add to if you want to get
something on the agenda:
https://wiki.openstack.org/wiki/Meetings/app-catalog

One topic that might be of interest if you are not a regular attendee
will be our summit plans.  Since the Community App Catalog (which is
not Murano - different things!) crosses over into many different
spaces in OpenStack we would love to get more conversations going with
different projects and working groups.  ESPECIALLY around the subject
of developing applications for OpenStack.  Join us if you can!

Looking forward to seeing everyone there tomorrow!

-Christopher

__
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] [User-committee] [all] [app-catalog] Newton summit schedule

[Christopher Aedo]

On Sat, Apr 9, 2016 at 8:41 AM, Yih Leong, Sun. <yihle...@gmail.com> wrote:
> I think it needs to relate to 'workload'.
> The Enterprise WG is working on a series of workload reference architecture.
> These architecture documents will include sample Heat template for each type
> of workload. We can work together and include Murano if resources permitted.
> These will be published in conjunction with the OpenStack Sample Config.
> http://www.openstack.org/software/sample-configs/

I like the of focusing on workloads and associating them with the
right reference architecture to support them.  That however seems like
the intended application(s) would be very closely tied to the
configuration of the cloud itself.  That scenario does not lend itself
to re-distributing an application for use by other users (i.e. a
portable app that can be used by multiple different clouds).  Unless
I'm misunderstanding?

You mention Murano here as well - why?  Hopefully you have not
conflated the Community App Catalog with Murano :)  They're different
animals entirely!

-Christopher


>
> On Friday, April 8, 2016, Christopher Aedo <d...@aedo.net> wrote:
>>
>> Hello!  I'm tagging "all" in hopes of getting more attention and some
>> good attendance and conversations going in Austin.  The sessions are
>> on the schedule[1] so please join us!
>>
>> In addition to the time we hope to spend with the Horizon team, we'll
>> also talk about what I think is one of the biggest things holding back
>> growth of the catalog - the question of how to develop an app meant
>> for OpenStack (and how best to package and distribute them).  This
>> impacts the larger OpenStack ecosystem as well, and I'm hoping to
>> solicit more opinions and views either in person or via the mailing
>> list[2].
>>
>> Looking forward to some great conversations in Austin!
>>
>> [1]
>> https://www.openstack.org/summit/austin-2016/summit-schedule/global-search?t=App%20Catalog
>> [2]
>> http://lists.openstack.org/pipermail/user-committee/2016-April/000722.html
>>
>> -Christopher
>>
>> ___
>> User-committee mailing list
>> user-commit...@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/user-committee

__
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] [app-catalog] Newton summit schedule

[Christopher Aedo]

Hello!  I'm tagging "all" in hopes of getting more attention and some
good attendance and conversations going in Austin.  The sessions are
on the schedule[1] so please join us!

In addition to the time we hope to spend with the Horizon team, we'll
also talk about what I think is one of the biggest things holding back
growth of the catalog - the question of how to develop an app meant
for OpenStack (and how best to package and distribute them).  This
impacts the larger OpenStack ecosystem as well, and I'm hoping to
solicit more opinions and views either in person or via the mailing
list[2].

Looking forward to some great conversations in Austin!

[1] 
https://www.openstack.org/summit/austin-2016/summit-schedule/global-search?t=App%20Catalog
[2] http://lists.openstack.org/pipermail/user-committee/2016-April/000722.html

-Christopher

__
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] [Horizon][app-catalog] Discussions in Austin

[Christopher Aedo]

Greetings Horizon team!  We'd like to find time at the design summit
to cover a few of the things that impact both Horizon and the
Community App Catalog.  I think many of these topics will be of
interest to other teams working on plugins using angular as well.  If
you've already got these on your agenda for conversations in Austin,
please let me know (especially if they're already covered under a
broader topic).

The main points we'd like to spend time discussing in Austin are:
* Need to understand what integration testing framework will look like
for angular
* Sharing widgets via xstatic
* Horizon plugins that depend on extra xstatic packages.
* Can/will Horizon provide some of the widget pop up functions as
angular modules instead of us poking around at the internals? This
simplifies testing and multiversion support.
* Long term direction for Community App Catalog UI dialog integration
(roadmap for native inclusion)

I'll be able to attend the next weekly meeting (5/13) if you want to
discuss anything in detail, or else drop by #openstack-app-catalog on
IRC any other time.  Thanks!

-Christopher

__
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] [app-catalog] IRC Meeting Thursday April 7th

[Christopher Aedo]

Join us Thursday for our weekly meeting, scheduled for April 7th at
17:00UTC in #openstack-meeting-3

The agenda can be found here, and please add to if you want to get
something on the agenda:
https://wiki.openstack.org/wiki/Meetings/app-catalog

We'll include status updates on the Glare PoC implementation for App
Catalog along with details of the OSC plugin that's got a great start
from Paul Van Eck.  We'll also talk about the session we'll have at
the summit, and hopefully sort out which other teams we'd like to get
time with.

Looking forward to seeing everyone there tomorrow!

-Christopher

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] FYI: Removing default flavors from nova

[Christopher Aedo]

On Wed, Apr 6, 2016 at 9:29 AM, Fox, Kevin M  wrote:
> It feels kind of like a defcore issue though. Its harder for app developers 
> to create stuff like heat templates intended for cross cloud that recommend a 
> size, m1.small, without a common reference.

For most deployments thought, the flavor definition is a function of
their compute node design.  Trying to standardize (and force that
standard via defcore) would likely drive away the biggest consumers of
OpenStack.

In my opinion this just shines a light on something missing from heat
(or maybes it exists and I'm just unaware) - the ability to discover
flavor details and find one that matches the minimum should be all
that's necessary in this case.  I think in general though, choosing
heat as a cross-cloud compatible application packaging tool is always
going to lead to problems.  Otherwise I think we would have seen an
emergence of people sharing heat templates that deploy applications
and work across many different OpenStack clouds.

> We keep making it hard for app developers to target openstack, so they don't 
> join, and then don't complain about when openstack makes their life harder. 
> we need to encourage ease of development on top of the platform.

I absolutely feel this pain point, but I'm still wondering what
applications people *are* developing for OpenStack (and how they're
packaging and distributing them - opinions welcome![1])

[1]: http://lists.openstack.org/pipermail/user-committee/2016-April/000722.html

-Christopher

>
> Thanks,
> Kevin
> 
> From: Sean Dague [s...@dague.net]
> Sent: Wednesday, April 06, 2016 3:47 AM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [nova] FYI: Removing default flavors from nova
>
> On 04/06/2016 04:19 AM, Sylvain Bauza wrote:
>>
>>
>> Le 06/04/2016 06:44, Qiming Teng a écrit :
>>> Not an expert of Nova but I am really shocked by such a change. Because
>>> I'm not a Nova expert, I don't have a say on the *huge* efforts in
>>> maintaining some builtin/default flavors. As a user I don't care where
>>> the data have been stored, but I do care that they are gone. They are
>>> gone because they **WILL** be supported by devstack. They are gone with
>>> the workflow +1'ed **BEFORE** the devstack patch gets merged (many
>>> thanks to the depends-on tag). They are gone in hope that all deployment
>>> tools will know this when they fail, or fortunately they read this email,
>>> or they were reviewing nova patches.
>>>
>>> It would be a little nicer to initiate a discussion on the mailinglist
>>> before such a change is introduced.
>>
>>
>> It was communicated accordingly to operators with no strong arguments :
>> http://lists.openstack.org/pipermail/openstack-operators/2016-March/010045.html
>
> Not only with no strong arguments, but with a general - "yes please,
> that simplifies our life".
>
>> You can also see that https://review.openstack.org/#/c/300127/ is having
>> three items :
>>  - a DocImpact tag creating a Launchpad bug for documentation about that
>>  - a reno file meaning that our release notes will provide also some
>> comments about that
>>  - a Depends-On tag (like you said) on a devstack change meaning that
>> people using devstack won't see a modified behavior.
>>
>> Not sure what you need more.
>
> The default flavors were originally hardcoded in Nova (in the initial
> commit) -
> https://github.com/openstack/nova/commit/bf6e6e718cdc7488e2da87b21e258ccc065fe499#diff-5ca8c06795ef481818ea1710fce91800R64
>  and moved into the db 5 years ago to be a copy of the EC2 flavors at
> the time -
> https://github.com/openstack/nova/commit/563a77fd4aa80da9bddac5cf7f8f27ed2dedb39d.
> Those flavors were meant to be examples, not the final story.
>
> All the public clouds delete these and do their own thing, as do I
> expect many of the products. Any assumption that software or users have
> that these will exist is a bad assumption.
>
> It is a big change, which is why it's being communicated on Mailing
> Lists in addition to in the release notes so that people have time to
> make any of their tooling not assume these flavors by name will be
> there, or to inject them yourself if you are sure you need them (as was
> done in the devstack case).
>
> -Sean
>
> --
> Sean Dague
> http://dague.net
>
> __
> 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] [defcore][glance] Glare not defcore ready

[Christopher Aedo]

On Fri, Apr 1, 2016 at 8:02 AM, Flavio Percoco  wrote:
> Greetings,
>
> I missed yday's Glance meeting but I went ahead and read the logs. While I
> was
> at it, I read a sentence from Erno (under the Glare updates topic) that
> caught
> my eye:
>
> 14:06:27  About that. I got couple of pings last night
> asking wtf is
> going on. Could we please stop selling Glare as replacement for
> Glance at
> least until we have a) stable API and b) some level of track
> record/testing
> that it actually is successfully working
>
> I went ahead and looked for the defcore meeting logs[0] (btw, seems like the
> bot
> died during the meeting) to get a better understanding of what Erno meant (I
> assumed the pings he mentioned came from the meeting and then confirmed it).
>
> From the small piece of conversation I could read, and based on the current
> status of development, priorities and support, I noticed a few "issues" that
> I
> believe are worth raising:
>
> 1. Glare's API is under discussion and it's a complementary service for
> Glance.
> [1] 2. Glare should not be a required API for every cloud, whereas Glance is
> and
> it should be kept that way for now. 3. Glare is not a drop-in replacement
> for
> Glance and it'll need way more discussions before that can happen.
>
> I do realize that I missed both meetings and that logs from one of them are
> not
> complete. I apologize if I've misinterpreted the intentions here. I do think
> engaiging with DefCore as early in the process as possible is good but I'd
> also
> like to clarify the intentions here before this escalates (again) into more
> confusion about what Glance's future looks like.
>
> So, to summarize, I don't think Glare should be added in DefCore in the near
> future. The Glance team should focus on fixing the current interoperability
> issues before we'll be able to actually try to build on top of the current
> API.

I was just about to type a response to this but saw Mikhail already
responded.  As he said the team was seeking guidance and wanted to be
sure they were proceeding in the right direction long term, not
pushing for an immediate inclusion.

I've shared my logs from the meeting here[1] which are complete, so
you can see the conversation in it's entirety.

[1]: http://paste.openstack.org/show/492753/

-Christopher


> Hope the above makes sense,
> Flavio
>
> [0]
> http://eavesdrop.openstack.org/meetings/defcore/2016/defcore.2016-03-30-16.00.log.txt
> [1] https://review.openstack.org/#/c/283136
>
> --
> @flaper87
> Flavio Percoco
>
> __
> 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] [app-catalog] App Catalog IRC meeting cancelled this week

[Christopher Aedo]

Due to a very light agenda (and everyone being pretty busy at the
moment) we're going to skip the meeting this week.

Our next meeting is scheduled for April 7th, the agenda can be found here:
https://wiki.openstack.org/wiki/Meetings/app-catalog

-Christopher

__
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] [app-catalog] IRC Meeting Thursday March 24th at 17:00UTC

[Christopher Aedo]

Join us Thursday for our weekly meeting, scheduled for March 24th at
17:00UTC in #openstack-meeting-3

The agenda can be found here, and please add to if you want to get
something on the agenda:
https://wiki.openstack.org/wiki/Meetings/app-catalog

Looking forward to seeing everyone there tomorrow!

-Christopher

__
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] [Horizon] How do we move forward with xstatic releases?

[Christopher Aedo]

On Sun, Mar 20, 2016 at 1:26 PM, Richard Jones  wrote:
> Unfortunately none of this discussion solves the substantive issue which is
> that we cannot release an xstatic package without breaking the gate.
>
> We currently have one solution that's a close to viable as we've been able
> to get: move the version pinning for xstatic packages out of
> upper-constraints and into Horizon's repository, and hope that the
> app-catalog server and Horizon stay in step or that they're never installed
> on the same debian/redhat system (or if they *are* then one of them is
> installed in a virtualenv).

The Horizon plugin for the app catalog[1] should have no problem
staying in step with Horizon.  Ultimately our intention is to make
this plugin so desirable it becomes a native part of Horizon so
enabling in a cloud becomes as simple as a config switch.  We're not
ready for that yet of course, so please don't let that comment
distract the thread :)  I am looking forward to discussing this with
more people in Austin though!

Regardless, we will work with you to make sure our efforts proceed to
be tightly coupled to Horizon.  This approach makes the most sense to
me.

[1]: http://git.openstack.org/cgit/openstack/app-catalog-ui/

-Christopher

__
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] [app-catalog] IRC Meeting Thursday March 17th at 17:00UTC

[Christopher Aedo]

Join us Thursday for our weekly meeting, scheduled for March 17th at
17:00UTC in #openstack-meeting-3
NOTE: The time may be different for you due to US daylight savings
time (it's probably an hour later for you if you're in the US)

The agenda can be found here, and please add to if you want to get
something on the agenda:
https://wiki.openstack.org/wiki/Meetings/app-catalog

Looking forward to seeing everyone there tomorrow!

__
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] [app-catalog] PTL Candidacy

[Christopher Aedo]

It's time again for the PTL elections, and I'm throwing my hat in the
ring to lead the Community App Catalog project (https://apps.openstack.org).

During the last election cycle I made a few promises which I believe
I've delivered on.  We've continued to operate entirely in the open
including holding weekly meetings on IRC along with bringing a few
issues to the mailing list when I felt we could benefit from opinions
of a broader audience. Another bit of success is that we've adjusted
the schema to support additional asset types, and have received our
first in this category in the form of a TOSCA template[1].  We still
have work to do on the web site in order to actually show additional
asset types in addition to adding that capability to the App Catalog
Horizon plugin, but that work is in progress.

The other significant effort was to implement a legitimate API, which
is now showing promise via the work to implement GLARE as the back
end[2].  In fact we will have a working PoC by the summit in Austin -
and we'll certainly complete that work before the following summit. I
will do everything I can to make sure the folks working on this get
all the support they need.

Looking ahead to the next cycle, the two biggest things the Community
App Catalog needs are a clarified mission and a whole lot more
publicity.  I'm guilty of living in my own bubble here, assuming
everybody must wake up thinking about the catalog after dreaming about
it all night long (just like me!)  But it turns out there are plenty
of people in the community who haven't even *heard* of the Community
App Catalog. I realize I need to work a lot harder to bring attention
to our efforts here.  What we've built can benefit most OpenStack
projects, and should become the standard place to host assets noted in
our documentation. There are many other ways we can all be using the
Community App Catalog to benefit OpenStack as a whole, and I'll start
to discuss and debate my ideas on the mailing lists in the weeks and
months to come.

Speaking of clarified mission, I intend to work within our own
community to build consensus around what we mean when we say "an
OpenStack App".  I believe if we can start to agree on that, and agree
on the best way(s) to package and distribute such things, the
Community App Catalog will become much more valuable to a larger
audience very quickly.

I think the Community App Catalog has tremendous potential; if you'll
have me as PTL again I'll keep working my hardest to deliver!

[1]: https://review.openstack.org/289132
[2]: https://review.openstack.org/276857

The official elections PR is here BTW:
https://review.openstack.org/#/c/291496/

-Christopher

__
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] [app-catalog] IRC Meeting Thursday March 10th at 17:00UTC

[Christopher Aedo]

Join us Thursday for our weekly meeting, scheduled for March 10th at
17:00UTC in #openstack-meeting-3

The agenda can be found here, and please add to if you want to get
something on the agenda:
https://wiki.openstack.org/wiki/Meetings/app-catalog

Looking forward to seeing everyone there tomorrow!

-Christopher

__
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] [app-catalog] Nominating Kirill Zaitsev to App Catalog Core

[Christopher Aedo]

On Thu, Mar 3, 2016 at 1:10 PM, Christopher Aedo <d...@aedo.net> wrote:
> I'd like to propose Kirill Zaitsev to the core team for app-catalog
> and app-catalog-ui.
> Kirill has been actively involved with the Community App Catalog since
> nearly the beginning of the project, and more recently has been doing
> the heavy lifting around implementing GLARE for a new backend.
>
> I think he would be an excellent addition - please vote, thanks!

I failed to set a deadline here, but expected no one would object to
this proposal.  It's been nearly a week so I feel safe in welcoming
Kirill as an app-catalog core - congrats!

-Christopher

__
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] [app-catalog] Nominating Kirill Zaitsev to App Catalog Core

[Christopher Aedo]

I'd like to propose Kirill Zaitsev to the core team for app-catalog
and app-catalog-ui.
Kirill has been actively involved with the Community App Catalog since
nearly the beginning of the project, and more recently has been doing
the heavy lifting around implementing GLARE for a new backend.

I think he would be an excellent addition - please vote, thanks!

-Christopher

__
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] [app-catalog] App Catalog IRC meeting minutes - 3/3/2016

[Christopher Aedo]

During our meeting this morning we touched on some of the excellent
stuff markvan is doing with Horizon integration testing (thanks!)  We
also talked some more about transition/implementation details around
using GLARE as the backend for the app catalog.  kzaitsev_mb is making
some excellent progress with help from a few others, but the next big
challenge we're likely to hit will be creating the auth middleware to
allow catalog contributors to authenticate with their OpenStack ID.
Once we have that sorted out, there won't be too much left to do in
order to put GLARE into production as the backend/API for the
Community App Catalog.

Thanks as always to everyone working with us to continually improve
the App Catalog!

=
#openstack-meeting-3: app-catalog
=
Meeting started by docaedo at 17:00:24 UTC.  The full logs are available
at
http://eavesdrop.openstack.org/meetings/app_catalog/2016/app_catalog.2016-03-03-17.00.log.html
.

Meeting summary
---
* LINK: https://wiki.openstack.org/wiki/Meetings/app-catalog  (docaedo,
  17:01:41)
* Status updates  (docaedo, 17:01:48)
  * LINK: https://review.openstack.org/286807  (docaedo, 17:02:26)
  * LINK: https://review.openstack.org/286927  (docaedo, 17:03:00)
  * LINK: https://review.openstack.org/#/c/276440/  (docaedo, 17:03:55)
  * LINK: https://review.openstack.org/#/c/276438/  (docaedo, 17:04:11)
  * LINK: https://review.openstack.org/#/c/283202/  (markvan, 17:06:32)
  * LINK: https://review.openstack.org/#/c/283201/  (markvan, 17:06:43)
* Glare transition review  (docaedo, 17:10:38)
* Open discussion  (docaedo, 17:36:15)

Meeting ended at 17:42:03 UTC.

People present (lines said)
---
* docaedo (70)
* kzaitsev_mb (27)
* markvan (7)
* openstack (3)

Generated by `MeetBot`_ 0.1.4

__
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] [app-catalog] IRC Meeting Thursday March 3rd at 17:00UTC

[Christopher Aedo]

Join us Thursday for our weekly meeting, scheduled for March 3rd at
17:00UTC in #openstack-meeting-3

The agenda can be found here, and please add to if you want to get
something on the agenda:
https://wiki.openstack.org/wiki/Meetings/app-catalog

Looking forward to seeing everyone there tomorrow!

-Christopher

__
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] [app-catalog] App Catalog IRC meeting minutes - 2/25/2016

[Christopher Aedo]

Today we had a good meeting which included updates on the great work
markvan is doing to add integration tests to app-catalog-ui as well as
an update on the GLARE implementation kzaitsev has been heading up.
We also agreed that for Austin, we've got enough to do to need two
work sessions in addition to the fishbowl session.

Next week we're planning to talk in more detail about the transition
to using glare for our backend, and hash out the steps we'll be taking
in the near term.


=
#openstack-meeting-3: app-catalog
=
Meeting started by docaedo at 17:00:34 UTC.  The full logs are available
at
http://eavesdrop.openstack.org/meetings/app_catalog/2016/app_catalog.2016-02-25-17.00.log.html
.

Meeting summary
---
* Status updates  (docaedo, 17:02:19)
  * ACTION: add "glare transition review" to next weeks agenda
(docaedo, 17:10:34)
  * ACTION: docaedo to create "add tests" blueprint for markvan's many
work items  (docaedo, 17:19:44)
* Space considerations for Austin summit (docaedo)  (docaedo, 17:22:12)
  * ACTION: docaedo to remember to get some generic icon for assets that
don't include their own  (docaedo, 17:25:28)
* Open discussion  (docaedo, 17:35:25)

Meeting ended at 17:40:46 UTC.

Action items, by person
---
* docaedo
  * docaedo to create "add tests" blueprint for markvan's many work
items
  * docaedo to remember to get some generic icon for assets that don't
include their own
* markvan
  * docaedo to create "add tests" blueprint for markvan's many work
items

People present (lines said)
---
* docaedo (57)
* kfox (19)
* kzaitsev_mb (17)
* markvan (15)
* openstack (3)

Generated by `MeetBot`_ 0.1.4

__
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] [app-catalog] IRC Meeting Thursday February 25th at 17:00UTC

[Christopher Aedo]

Join us Thursday for our weekly meeting, scheduled for February 25th
at 17:00UTC in #openstack-meeting-3

The agenda can be found here, and please add to if you want to get
something on the agenda:
https://wiki.openstack.org/wiki/Meetings/app-catalog

One topic we'll cover will be space needs at the Austin summit.  In
Tokyo we had one fishbowl session and one workroom slot.  Will we need
more than that in Austin?  If you've got any opinions on that, please
either respond on the mailing list here or join us on IRC tomorrow!

-Christopher

__
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] [app-catalog] IRC Meeting Thursday February 18th at 17:00UTC

[Christopher Aedo]

Join us Thursday for our weekly meeting, scheduled for February 18th
at 17:00UTC in #openstack-meeting-3

The agenda can be found here, and please add to if you want to get
something on the agenda:
https://wiki.openstack.org/wiki/Meetings/app-catalog

Looking forward to seeing all interested parties there!

-Christopher

__
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] [app-catalog] IRC Meeting Thursday February 11th at 17:00UTC

[Christopher Aedo]

Join us Thursday for our weekly meeting, scheduled for February 11th
at 17:00UTC in #openstack-meeting-3

The agenda can be found here, and please add to if you want to get
something on the agenda:
https://wiki.openstack.org/wiki/Meetings/app-catalog

Looking forward to seeing all interested parties there!

-Christopher

__
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] [app-catalog] App Catalog IRC meeting minutes - 2/4/2016

[Christopher Aedo]

This week we had a really great meeting, including some folks from the
Horizon team stepping in to help make the Horizon plugin better.  We
discussed some of the work relating to the UI piece, and adding tests
to app-catalog-ui to ensure future changes are tested properly against
Horizon.

We also had a good update on the Glare work and the next day saw a WIP
commit with the first steps.  Hopefully we'll have a working PoC using
Glare as the backend and API for the Community App Catalog.

=
#openstack-meeting-3: app-catalog
=
Meeting started by docaedo at 17:00:23 UTC.  The full logs are available
at
http://eavesdrop.openstack.org/meetings/app_catalog/2016/app_catalog.2016-02-04-17.00.log.html
.
Meeting summary
---
* LINK: https://wiki.openstack.org/wiki/Meetings/app-catalog  (docaedo,
  17:00:38)
* rollcall  (docaedo, 17:00:40)
* Status updates  (docaedo, 17:02:18)
  * LINK: https://review.openstack.org/#/c/270579/  (docaedo, 17:03:01)
* Integration with Horizon, using form parms may not work in near future
  (docaedo, 17:07:19)
  * LINK:
https://blueprints.launchpad.net/horizon/+spec/angularize-images-table
(doug-fish, 17:09:56)
  * LINK:
https://blueprints.launchpad.net/horizon/+spec/angularize-images-table
(kzaitsev_mb, 17:10:17)
  * LINK: https://review.openstack.org/#/c/251670/  (docaedo, 17:11:08)
  * LINK: https://review.openstack.org/#/c/251670/  looks like a
sustainable approach, but I'd like to review more carefully
(doug-fish, 17:14:53)
* Integration with Horizon, how about a stab at integration tests?
  (docaedo, 17:18:51)
* Resource commitments for Glare/API work  (docaedo, 17:25:00)
* Open discussion  (docaedo, 17:29:39)
Meeting ended at 17:33:34 UTC.

People present (lines said)
---
* docaedo (60)
* doug-fish (23)
* markvan (17)
* kzaitsev_mb (9)
* openstack (3)

Generated by `MeetBot`_ 0.1.4

__
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] [app-catalog] IRC Meeting Thursday February 4th at 17:00UTC

[Christopher Aedo]

Join us tomorrow for our next weekly meeting, scheduled for February
4th at 17:00UTC in #openstack-meeting-3

The agenda can be found here, and please add to if you want to get
something on the agenda:
https://wiki.openstack.org/wiki/Meetings/app-catalog

One thing on the agenda for the 2/4/2016 meeting is the topic of
implementing an API for the App Catalog, and whether we'll have a
strong commitment of the necessary resources to continue in the
direction agreed upon during the Tokyo summit.  If you have anything
to say on that subject please be sure to join us!

-Christopher

__
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] [app-catalog] App Catalog IRC Meeting CANCELLED this week

[Christopher Aedo]

Due to scheduling conflicts and a very light agenda, there will be no
Community App Catalog IRC meeting this week.

Our next meeting is scheduled for February 4th, the agenda can be found here:
https://wiki.openstack.org/wiki/Meetings/app-catalog

One thing on the agenda for the 2/4/2016 meeting is the topic of
implementing an API for the App Catalog, and whether we'll have a
strong commitment of the necessary resources to continue in the
direction agreed upon during the Tokyo summit.  If you have anything
to say on that subject please be sure to join us NEXT week!

-Christopher

__
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] [app-catalog] App Catalog IRC meeting minutes - 1/21/2016

[Christopher Aedo]

Yesterday we had a good conversation about including TOSCA assets in
the Community App Catalog, as well as covered some updates on work we
recently merged.  One of the nicest bits is extracting "last updated"
date for assets so the "recently added/modified" banner on the web
site will be more accurate once we make a few small javascript tweaks.

In the next few weeks we plan to add Mistral and TOSCA assets to the
catalog, and we'll end up re-factoring the web site a bit at the same
time.  If you're reading this and want to help with some of the design
elements please let us know!


=
#openstack-meeting-3: app-catalog
=
Meeting started by docaedo at 17:01:51 UTC.  The full logs are available
at
http://eavesdrop.openstack.org/meetings/app_catalog/2016/app_catalog.2016-01-21-17.01.log.html
.

Meeting summary
---

* rollcall  (docaedo, 17:02:11)
  * LINK: https://wiki.openstack.org/wiki/Meetings/app-catalog
(docaedo, 17:02:46)
* Adding TOSCA to the catalog  (docaedo, 17:03:13)
  * LINK:

https://git.openstack.org/cgit/openstack/app-catalog/tree/openstack_catalog/web/static/assets.schema.yaml
(docaedo, 17:11:56)
  * LINK:

https://git.openstack.org/cgit/openstack/app-catalog/tree/openstack_catalog/web/static/assets.yaml
(docaedo, 17:12:15)
  * LINK:
https://wiki.openstack.org/wiki/App-Catalog#Structure_of_Heat_entry
(docaedo, 17:12:44)
  * LINK:
https://blueprints.launchpad.net/app-catalog/+spec/add-mistral-assets
(docaedo, 17:16:39)
* Status updates  (docaedo, 17:20:56)
  * LINK: https://review.openstack.org/267087  (docaedo, 17:21:51)
  * LINK: https://review.openstack.org/269935  (docaedo, 17:23:49)
  * LINK: https://review.openstack.org/270579  (docaedo, 17:24:01)
* Discuss Glare outline/glare implementation  (docaedo, 17:27:51)
  * LINK: https://etherpad.openstack.org/p/app-cat-glare  (docaedo,
17:27:58)

Meeting ended at 17:41:22 UTC.

People present (lines said)
---
* docaedo (66)
* spzala (28)
* kzaitsev_mb (10)
* openstack (3)
* ativelkov (1)
* kzaitsev_ws (1)

Generated by `MeetBot`_ 0.1.4

__
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] [app-catalog][TOSCA] IRC Meeting Thursday January 21st at 17:00UTC

[Christopher Aedo]

Join us tomorrow for our weekly meeting, January 14th at 17:00UTC in
#openstack-meeting-3.

The agenda can be found here, and please add to it if you want to get
something on the agenda:
https://wiki.openstack.org/wiki/Meetings/app-catalog

This week we hope to have someone working on TOSCA join us to talk
about the metadata around their assets, and agree to a plan to add
TOSCA elements to the App Catalog.

Hope to see you there on Thursday!

-Christopher

__
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] [app-catalog] Automating some aspects of catalog maintenance

[Christopher Aedo]

While we are looking forward to implementing an API based on Glare, I
think it would be nice to have a few aspects of catalog maintenance be
automated.  For instance discovering and removingt/agging assets with
dead links, updating the hash for assets that change frequently or
exposing when an entry was last modified.

Initially I thought the best approach would be to create a very simple
API service using Flask on top of a DB.  This would provide output
identical to the current "v1" API.  But of course that "simple" idea
starts to look too complicated for something that would eventually be
abandoned wholesale.  Someone on the infra team suggested a dead-link
checker that would run as a periodic job similar to other proposal-bot
jobs, so I took a first pass at that [1].

As expected that resulted in a VERY large initial change[2] due to
"normalizing" the existing human-edited assets.yaml file.  I think the
feedback that this is un-reviewable without some external tools is
reasonable (though it's possible to verify the 86 assets are
unmolested, only slightly reformatted).  One thing that would help
would be forcing all entries to meet a specific format which would not
need adjustment by proposal-bot.  But even that change would require a
near-complete rewrite of the assets file, so I don't think it would
help in this case.

I'm generally in favor of this approach because it keeps all the
information on the assets in one place (the assets.yaml file) which
makes it easy for humans to read and understand.

An alternate proposed direction is to merge machine-generated
information with the human-generated assets.yaml during the creation
of the JSON file[3] that is used by the website and Horizon plugin.
The start of that work is this script to discover last-modified times
for assets based on git history[4].

While I think the approach of merging machine-generated and
human-generated files could work, it feels a lot like creating a
relational database out of yaml files glued together with a bash
script.  If it works though, maybe it's the best short term approach?

Ultimately my goal is to make sure the assets in the catalog are kept
up to date without introducing a great deal of administrative overhead
or obfuscating how the display version of the catalog is created.  How
are other projects handling concerns like this?  Would love to hear
feedback on how you've seen something like this handled - thanks!

[1]: https://review.openstack.org/#/c/264978/
[2]: https://review.openstack.org/#/c/266218/
[3]: https://apps.openstack.org/api/v1/assets
[4]: https://review.openstack.org/#/c/267087/

-Christopher

__
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] [app-catalog] App Catalog IRC meeting minutes - 1/14/2016

[Christopher Aedo]

This morning we had a quick status update regarding some automation
within the catalog followed by a good chat about adding Mistral
workflow templates to the catalog.  We're going to work out what
metadata the assets will need to include and start discussing the
changes we'll need to make to the website to accommodate additional
asset types.

We also touched on adding TOSCA bits to the catalog, as the effort to
modify the web site to support additional asset types will benefit
those wishing to include TOSCA stuff as well.  Further discussion on
that topic has been added to next weeks agenda.

=
#openstack-meeting-3: app-catalog
=
Meeting started by docaedo at 17:00:34 UTC.  The full logs are available
at
http://eavesdrop.openstack.org/meetings/app_catalog/2016/app_catalog.2016-01-14-17.00.log.html
.
Meeting summary
---
* rollcall  (docaedo, 17:00:50)
  * LINK: https://wiki.openstack.org/wiki/Meetings/app-catalog
(docaedo, 17:02:59)
* Updates  (docaedo, 17:03:11)
  * LINK: https://review.openstack.org/266218  (docaedo, 17:04:19)
  * LINK: https://review.openstack.org/267087  (docaedo, 17:08:07)
* Adding Mistral workflow templates to the catalog  (docaedo, 17:11:08)
* Open discussion  (docaedo, 17:43:34)

Meeting ended at 17:59:24 UTC.

People present (lines said)
---
* docaedo (82)
* rakhmerov (51)
* spzala (23)
* toddjohn (12)
* kzaitsev_mb (7)
* ativelkov (3)
* openstack (3)

Generated by `MeetBot`_ 0.1.4

__
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] [app-catalog] IRC Meeting Thursday January 14th at 17:00UTC

[Christopher Aedo]

Join us tomorrow for our weekly meeting, January 14th at 17:00UTC in
#openstack-meeting-3.

The agenda can be found here, and please add to it if you want to get
something on the agenda:
https://wiki.openstack.org/wiki/Meetings/app-catalog

Tomorrow we hope to have someone from Mistral joining to discuss how
we can add workflow templates to the Community App Catalog.  We'll
also discuss the work around using Glare for the backend if anyone
from that team is able to join.

Thanks!

-Christopher

__
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] [app-catalog] App Catalog IRC meeting minutes - 1/7/2016

[Christopher Aedo]

We had a good meeting this morning, and mainly focused on resolving
the work around checking for dead links in the Community App Catalog.
This will also include updating the hash for any entry that includes a
"hash_url".

As soon as this work lands and is in the period pipeline to run daily,
I'll send a note with more details.  In the mean time, the related
commits are here:
https://review.openstack.org/#/c/260198/
https://review.openstack.org/#/c/264523/
https://review.openstack.org/#/c/264978/

-Christopher

=
#openstack-meeting-3: app-catalog
=
Meeting started by docaedo at 17:00:30 UTC.  The full logs are available
at
http://eavesdrop.openstack.org/meetings/app_catalog/2016/app_catalog.2016-01-07-17.00.log.html
.

Meeting summary
---
* rollcall  (docaedo, 17:00:43)
  * LINK: https://wiki.openstack.org/wiki/Meetings/app-catalog
(docaedo, 17:04:07)
* Resolve direction and plans for dead-link checking  (docaedo,
  17:06:56)
  * LINK:
https://blueprints.launchpad.net/app-catalog/+spec/detect-stale-entries
(docaedo, 17:07:00)
  * LINK: https://etherpad.openstack.org/p/app-catalog-hash-update
(docaedo, 17:16:02)
* Open discussion  (docaedo, 17:34:08)

Meeting ended at 17:39:03 UTC.

People present (lines said)
---
* docaedo (49)
* kfox (40)
* openstack (3)
* j_king (1)

Generated by `MeetBot`_ 0.1.4

__
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] [app-catalog] IRC Meeting Thursday January 7th at 17:00UTC

[Christopher Aedo]

Please join us this Thursday for our first meeting of 2016, January
7th at 17:00UTC in #openstack-meeting-3.

The agenda can be found here:
https://wiki.openstack.org/wiki/Meetings/app-catalog

Please add agenda items if there's anything specific you would like to
discuss (or of course if the meeting time is not convenient for you
join us on IRC #openstack-app-catalog).

-Christopher

__
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] [app-catalog] App Catalog IRC meeting minutes - 12/17/2015

[Christopher Aedo]

This morning we had a nice meeting which included an update on Glare
from Alexander Tivelkov. They're making really good progress on the
glance artifact repository work and it will be a big benefit to the
App Catalog soon.  We also discussed the dead-link checking that we
will implement in the next few days (links to related reviews are
below, plus this one that was just submitted to the project-config
repo: https://review.openstack.org/259232).

Hopefully before the end of the year we'll finish that work which also
lays out the pieces I'll need in order to add in automated asset
updating (like keeping the hash up to date for frequently updated
images).

This was our last meeting of the year, due to overlap with holidays.
Our next meeting will be January 7th, 2016 - hope to see you there!
(in the mean time, hope you all enjoy the holidays!)

-Christopher

=
#openstack-meeting-3: app-catalog
=
Meeting started by docaedo at 17:00:43 UTC.  The full logs are available
at
http://eavesdrop.openstack.org/meetings/app_catalog/2015/app_catalog.2015-12-17-17.00.log.html
.

Meeting summary
---
* LINK:
  
https://wiki.openstack.org/wiki/Meetings/app-catalog#Proposed_Agenda_for_December_17th.2C_2015_.281700_UTC.29
  (docaedo, 17:00:57)
* rollcall  (docaedo, 17:01:04)
* Status updates  (docaedo, 17:02:00)
  * LINK: https://review.openstack.org/#/c/257663/  (docaedo, 17:02:34)
  * LINK: https://review.openstack.org/#/c/254710/  - the api
refactoring spec  (ativelkov, 17:09:54)
  * LINK: https://review.openstack.org/#/q/topic:bp/move-v3-to-glare -
patches to move the glare api to separate process / keystone
endpoint  (ativelkov, 17:10:28)
* Dead link check script  (docaedo, 17:13:38)
  * LINK: http://paste.openstack.org/show/482152  (docaedo, 17:13:58)
  * LINK: http://paste.openstack.org/show/482151  (docaedo, 17:14:03)
  * LINK: http://cdimage.debian.org/cdimage/openstack/testing/
(docaedo, 17:15:00)
  * LINK: https://etherpad.openstack.org/p/app-cat-glare  (docaedo,
17:27:28)
* Open discussion  (docaedo, 17:29:14)

Meeting ended at 17:44:16 UTC.

People present (lines said)
---
* docaedo (70)
* ativelkov (29)
* kfox (14)
* olaph (4)
* openstack (3)

Generated by `MeetBot`_ 0.1.4

__
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] [app-catalog] IRC Meeting Thursday December 17th at 17:00UTC

[Christopher Aedo]

Greetings! Our next OpenStack Community App Catalog meeting will take
place this ThursdayDecember 17th at 17:00 UTC in #openstack-meeting-3

The agenda can be found here:
https://wiki.openstack.org/wiki/Meetings/app-catalog

Please add agenda items if there's anything specific you would like to
discuss (or of course if the meeting time is not convenient for you
join us on IRC #openstack-app-catalog).

This will be our last meeting for 2015 as the next two Thursdays fall
on dates which make attendance a challenge for some attendees.  Please
join us if you can!

-Christopher

__
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] [app-catalog] IRC Meeting Thursday December 10th at 17:00UTC

[Christopher Aedo]

Greetings! Our next OpenStack Community App Catalog meeting will take
place this ThursdayDecember 10th at 17:00 UTC in #openstack-meeting-3

The agenda can be found here:
https://wiki.openstack.org/wiki/Meetings/app-catalog

Please add agenda items if there's anything specific you would like to
discuss (or of course if the meeting time is not convenient for you
join us on IRC #openstack-app-catalog).

Please join us if you can!

-Christopher

__
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] [app-catalog] App Catalog IRC meeting minutes - 12/3/2015

[Christopher Aedo]

This morning we had a brief meeting but did have a chance to touch on
a little bit of the Glare back-end work for the App Catalog.
Additionally I mentioned we're going to start working to include TOSCA
elements in the catalog soon.

We could still really use a volunteer to chair a meeting time
convenient to our friends in Asia/Australia/New Zealand :)  If you
could spare 30 minutes or an hour every other week for this, please
let me know!

See you on #openstack-app-catalog!

-Christopher

=
#openstack-meeting-3: app-catalog
=
Meeting started by docaedo at 17:00:27 UTC.  The full logs are available
at
http://eavesdrop.openstack.org/meetings/app_catalog/2015/app_catalog.2015-12-03-17.00.log.html
.
Meeting summary
---
* rollcall  (docaedo, 17:00:46)
* Status updates  (docaedo, 17:03:46)
  * LINK: https://review.openstack.org/#/c/250061/  (docaedo, 17:04:49)
* TOSCA in the App Catalog  (docaedo, 17:09:06)
  * LINK: https://github.com/openstack/heat-translator  (kzaitsev_mb,
17:11:20)
* open discussion  (docaedo, 17:18:17)
  * LINK: https://etherpad.openstack.org/p/app-cat-glare  (kzaitsev_mb,
17:18:27)

Meeting ended at 17:29:10 UTC.

People present (lines said)
---
* docaedo (38)
* kfox (25)
* kzaitsev_mb (21)
* j^2 (3)
* openstack (3)
* vahidh_ (1)
* spzala (1)

Generated by `MeetBot`_ 0.1.4

__
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] [app-catalog] IRC Meeting Thursday December 3rd at 17:00UTC

[Christopher Aedo]

Hi there! Tomorrow we'll have our next OpenStack Community App Catalog
meeting (Dec 3rd) at 1700UTC in #openstack-meeting-3

The agenda can be found here:
https://wiki.openstack.org/wiki/Meetings/app-catalog

Please add agenda items if there's anything specific you would like to
discuss (or of course if the meeting time is not convenient for you
join us on IRC #openstack-app-catalog).

Join us if you can!

-Christopher

__
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] [app-catalog] Weekly IRC meeting cancelled

[Christopher Aedo]

We will not be holding our weekly IRC meeting this week due to the
Thanksgiving holiday.  Our regular meeting will resume Thursday,
December 3rd.

As always, you can find the meeting schedule and agenda here:
https://wiki.openstack.org/wiki/Meetings/app-catalog

Hope everyone (celebrating or not) has a great week, and hope you can
join us on December 3!

-Christopher

__
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] [app-catalog] IRC Meeting Thursday November 12th at 17:00UTC

[Christopher Aedo]

Greetings! Our next OpenStack Community App Catalog meeting will take
place this Thursday November 12th at 17:00 UTC in #openstack-meeting-3

The agenda can be found here:
https://wiki.openstack.org/wiki/Meetings/app-catalog

Please add agenda items if there's anything specific you would like to
discuss (or of course if the meeting time is not convenient for you
join us on IRC #openstack-app-catalog).

Please join us if you can!

-Christopher

__
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] [app-catalog] App Catalog IRC meeting minutes - 11/5/2015

[Christopher Aedo]

We had a nice meeting this morning, though it was a touch light on
attendance (likely due to the combined  joys of daylight savings time
and jet lag).  In addition to a recap from the summit sessions and
talking a bit about taking next steps with the API work, we talked
about setting a second time for the IRC meeting.

In the next week or so I'll work on finding someone who can chair a
meeting in an Australia/Asian time zone, and we'll transition to
switching between the two meeting times.  If you have the spare
capacity to chair an IRC meeting, please let me know!

Please join us on #openstack-app-catalog - thanks!

-Christopher

=
#openstack-meeting-3: app-catalog
=
Meeting started by docaedo at 17:00:49 UTC.  The full logs are available
at
http://eavesdrop.openstack.org/meetings/app_catalog/2015/app_catalog.2015-11-05-17.00.log.html
.
Meeting summary
---
* rollcall  (docaedo, 17:01:24)
  * LINK:

https://wiki.openstack.org/wiki/Meetings/app-catalog#Proposed_Agenda_for_November_5th.2C_2015_.281700_UTC.29
(docaedo, 17:02:38)
* Tokyo Summit update (docaedo)  (docaedo, 17:05:18)
  * LINK:
http://lists.openstack.org/pipermail/openstack-dev/2015-November/078217.html
(docaedo, 17:07:17)
  * LINK: https://etherpad.openstack.org/p/TYO-app-catalog  (docaedo,
17:13:21)
  * LINK:
https://etherpad.openstack.org/p/murano-mitaka-contributors-meetup
(docaedo, 17:13:24)
* status updates  (docaedo, 17:17:28)
* Alternating times/regions for IRC meeting  (docaedo, 17:19:34)
* Next steps for API work  (docaedo, 17:31:59)
* Open discussion  (docaedo, 17:42:47)

Meeting ended at 18:01:26 UTC.

People present (lines said)
---
* docaedo (96)
* kzaitsev_mb (37)
* drwahl (27)
* j_king (7)
* openstack (3)
* kfox_ (2)
* kfox (1)

Generated by `MeetBot`_ 0.1.4

__
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][glance] Summary from the Mitaka summit

[Christopher Aedo]

On Tue, Nov 3, 2015 at 1:48 AM, Flavio Percoco  wrote:
> [...]
> Glance Artifacts REpository (Glare)
> ===
>
> Do you remember the Glance *EXPERIMENTAL* Glance V3 API? We had that
> famous discussion again, the one we had in Vancouver, Paris and
> Atlanta :) This time, however, we were able to reason about this with
> the implementation in mind and, for the sake of backwards
> compatibility, DefCore support and not having another major API
> release, we've agreed to pull it out into its own endpoint/process.
>
> In addition to the above, the experimental version of this API will be
> refactored a bit to be compliant with DefCore requirements. Or better,
> the team has engaged with the API WG team and asked them to review the
> API implementation. There was quite some feedback that will be
> addressed during Mitaka. It's still unsure whether it'll be considered
> stable at the end of the cycle. This will be revisited when the time
> comes.
>
> As far as the python bindings go, we'll pull into glanceclient the
> work that was done during liberty. Therefore, glanceclient will be the
> python library to use, whereas the CLI will be in openstackclient.
>
> We also participated in Murano's and App Catalog's meetup to discuss
> how we can move forward with this. The result of that discussion is
> that these teams will look into using Glare. They had several
> questions and we went through all of them. I'm personally super happy
> about this collaboration.

I'm really happy we had the chance to get a much closer look at all
the great work Alexander Tivelkov and others have put in to Glare.
Thank you for making time to come to our sessions, demonstrate the
potential ways we could come together on this, and discuss the path
forward.  I'm hopeful this is going to work out and will turn out to
be something we can implement for our use-case in the next few months
:)

-Christopher

__
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] [app-catalog] IRC Meeting Thursday November 5th at 17:00 UTC

[Christopher Aedo]

This is just a reminder announcement of the Community App Catalog
meeting we are planning for Thursday of this week at 17:00UTC.  It
will include a recap of the App Catalog related meetings from the
Tokyo Summit, as well as other status updates.

We are also working on setting up a second meeting time to make it
easier for folks in Asian time zones to participate via IRC.  Expect
more details on that shortly.

-Christopher


On Mon, Oct 19, 2015 at 10:41 AM, Christopher Aedo <d...@aedo.net> wrote:
> Hello all!  Due to the summit we will cancel the next two weeks of IRC
> meetings for the App Catalog.
>
> The next meeting will be Thursday November 5th at 17:00UTC on
> #openstack-meeting-3
>
> The agenda can be found here:
> https://wiki.openstack.org/wiki/Meetings/app-catalog
>
> I expect we'll have a lot to talk about after Tokyo so expect some
> agenda items to be updated before the meeting.
>
> Hopefully I'll see most of you in Tokyo!
>
> -Christopher

__
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] [app-catalog] Community App Catalog in Tokyo

[Christopher Aedo]

I want to start with a big thank you to everyone who made it to the
Community App Catalog fishbowl and working sessions last Thursday in
Tokyo.  Those of us who have been working at making the App Catalog
deliver on it's potential really appreciate your attention and input -
thanks!

Though we had several great discussions in a few different sessions, I
wanted to highlight the things I took away as being the most important
features/considerations we need to take into account for the next
cycle.

Trusted Content - Several people highlighted the importance of
guaranteeing any given content in the App Catalog was not modified at
any point.  Additionally there should be some assurance the asset was
in fact added by the user or organization indicated.  We will work on
providing a method of verifiable signatures for all assets, likely
similar to GPG signatures on Debian packages.

Approved/Supported Content - In addition to providing a mechanism to
guarantee the integrity of assets in the App Catalog, cloud operators
also asked for a way to easily highlight specific content for THEIR
users.  The use case would be a public or private cloud that wants to
provide some supported assets (apps, or app components) in that
environment.  This will allow an operator to indicate clearly which
apps in the catalog they will provide support for, while
distinguishing those assets from others in the catalog.  I was
especially happy to hear several operators were interested in this
approach as I believe this will go a long way towards allowing
different OpenStack clouds to provide "supported" content without
needing to create their own private catalogs.  The obvious broader
benefit here is that all users of OpenStack gain when multiple
operators are sharing their apps with the community.

Improving the add/modify workflow - Out of necessity, the "beta"
version of the App Catalog at launch used YAML files which were
modified via the standard OpenStack gerrity review process.  This made
it easy to quickly get the first iteration of the App Catalog out the
door, but left a lot to be desired when it comes to making it quick
and easy to add content.  In order to move forward on improving this
process, we're working on a proper API that will allow content to much
more easily added.  The web site will include a way for registered
users to add content via web form in addition to using the OpenStack
CLI (or just via the REST interface).

Additional IRC meeting times - There was a great point raised when I
was making a call for better participation in our IRC meetings.  Right
now we meet Thursdays at 1700UTC, which is a really inconvenient time
for folks in Asia & Australia.  I'm going to work on adding a second
meeting time (possibly chaired by someone else) in the next few weeks.

As requested by a few folks, the slides I used are available here:
http://www.slideshare.net/aedocw/community-app-catalog-introduction-tokyo-openstack-summit
(Unfortunately the slides don't capture the best parts of the
presentation - the live demonstration of the Horizon plugin and the
discussion we had after I ran through the background and status.)

If there are other things you'd like to see us focus on during the
next cycle, or have anything to add, please speak up on the mailing
lists or join us on IRC - thank you!

-Christopher

__
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] How we can find list of medium/low bugs for nova

[Christopher Aedo]

On Sun, Nov 1, 2015 at 1:22 AM, chandraprakash mishra
 wrote:
> My concern was how i can filter bug list for a specific project like
> kilo,liberty etc
> https://bugs.launchpad.net/openstack/+bugs

Chandra, you can find bugs for specific projects under their own
launchpad sections, such as:

https://bugs.launchpad.net/nova/+bugs

A great place to start is by looking at "low-hanging-fruit" bugs which
are expected to be relatively easy to resolve, and usually already
have been triaged with the details on how to fix included in the bug
thread:

https://bugs.launchpad.net/nova/+bugs?field.tag=low-hanging-fruit

-Christopher

__
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][heat] Which repo to use in docs -- git.openstack.org or github.com?

[Christopher Aedo]

On Tue, Oct 20, 2015 at 3:43 AM, Andreas Jaeger  wrote:
> On 2015-10-20 12:17, Qiming Teng wrote:
>>
>> Hi,
>>
>> Just encountered this again in code review [1]. The question is about
>> the repository to point to when documenting things up. Between the
>> following links, which one should we use?
>>
>> - https://git.openstack.org/cgit/openstack/sqlalchemy-migrate
>> - https://github.com/openstack/sqlalchemy-migrate
>>
>> I had an impression that I saw something like 'use git.openstack.org
>> instead of github.com because the later is just a mirror ...' but cannot
>> find the link now. Maybe it is an illusion. :)
>>
>> So, seriously, any recommendations or guidelines?
>
>
> Yes, git.openstack.org is our official server, github is just a read-only
> mirror.
>
> Linking to github might also raise the expectation that we use the usual
> github workflow which is not the case,

I understand github is a read-only mirror and we don't want casual
visitors to expect the github workflow - so in most cases I agree
people should be pointed to our official server.

On the other hand, the fact that github renders the README nicely
(including images) leads to a much more inviting first impression.
For example, for the uninitiated, this git.openstack.org URL[2]
doesn't help at all if you are curious about the project, while the
github.com URL[3] tells you what the project is about and even
includes a few screenshots.  For purposes of learning about or
understanding OpenStack I would say the github.com URL is vastly
superior.

Is it crazy to suggest we do something similar with our github server?

-Christopher

[2]: http://git.openstack.org/cgit/openstack/app-catalog-ui/
[3]: https://github.com/openstack/app-catalog-ui

>
> Andreas
>
>> [1] https://review.openstack.org/#/c/237404/

__
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] [app-catalog] IRC Meeting Thursday November 5th at 17:00 UTC

[Christopher Aedo]

Hello all!  Due to the summit we will cancel the next two weeks of IRC
meetings for the App Catalog.

The next meeting will be Thursday November 5th at 17:00UTC on
#openstack-meeting-3

The agenda can be found here:
https://wiki.openstack.org/wiki/Meetings/app-catalog

I expect we'll have a lot to talk about after Tokyo so expect some
agenda items to be updated before the meeting.

Hopefully I'll see most of you in Tokyo!

-Christopher

__
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] [app-catalog][horizon] app-catalog-ui 1.0.0 release

[Christopher Aedo]

We are really excited to announce the first release of the Community
App Catalog UI for Horizon!

https://github.com/openstack/app-catalog-ui/tree/1.0.0

This is the first really big step forward for connecting the App
Catalog (https://apps.openstack.org) with individual clouds, making it
easier than ever for users to find apps and components for their
OpenStack environments.

We've got a Debian package available and will have an RDO package
available shortly as well, making it very easy for operators to
include the App Catalog panel in their Horizon deployment.  If you'd
like to check it out yourself we also have a Devstack plugin in the
repo that will let you take it for a test drive in a matter of
minutes.

Please let us know what you think!  We meet regularly on Thursdays
(1700 UTC on #openstack-meeting-3) and are always available on IRC at
#openstack-app-catalog.

-Christopher

__
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] [app-catalog] [glance] [murano] Data Assets API for App Catalog

[Christopher Aedo]

On Fri, Oct 16, 2015 at 10:39 AM, Serg Melikyan  wrote:
> Hi Kevin,
>
>>Can we get together at the summit and discuss further?
> I would be happy to add this meeting to the Murano summit schedule, we
> have table on contributors meetup for the whole Friday. Will it be
> convenient?
>
> This is very important for Murano, it would be great to seat together
> and think what actual requirements we have and how to satisfy them.

Serg, please feel free to add something to the agenda to discuss
cross-project collaboration, I think it would be great.

We also have two sessions specifically for the App Catalog which I
encourage folks from Murano, Glance, Horizon and other projects to
attend.  I'll make an effort to be involved in their respective work
sessions as well.  The two sessions I urge you and others to join are:
Status, progress and plans
http://mitakadesignsummit.sched.org/event/27bf7f9a29094cf9e96026d682db1609
Thursday in the Kotobuki room, from 1:50 to 2:30

Work session
http://mitakadesignsummit.sched.org/event/7754b46437c14cd4fdb51debebe89fb0
Thursday in the Tachibana room, from 2:40 to 3:20

-Christopher

__
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] [app-catalog] [glance] [murano] Data Assets API for App Catalog

[Christopher Aedo]

On Thu, Oct 15, 2015 at 3:04 AM, Alexander Tivelkov
 wrote:
> Hi folks,
>
> I’ve noticed that the Community Application Catalog has begun to implement
> its own API, and it seems to me that we are going to have some significant
> duplication of efforts with the code which has already been implemented in
> Glance as Artifact Repository initiative (also known as Glance V3).
> From the very beginning of the App Catalog project (and I’ve been involved
> in it since February) I’ve been proposing to use Glance as its backend,
> because from my point of view it covers like 90% of the needed
> functionality. But it looks like we have some kind of miscommunication here,
> as I am getting some confusing questions and assumptions, like the vision of
> Glance V3 being dedicated backend for Murano (which is definitely
> incorrect).
> So, I am writing the email to clarify my vision of what Glance V3 is and how
> its features may be used to provide the REST API for Community App Catalog.
>
> 1.  Versioned schema
> First of all, Glance V3 operates on entities called “artifacts”, and these
> ones perfectly map to the Data Assets of community app catalog. The
> artifacts are strongly typed: there are artifact types for murano packages,
> glance images, heat templates - and there may be (and will be) more. Each
> artifact type is represented by a plugin, defining the schema of objects’
> data and metadata and - optionally - custom logic. So, this thing is
> extensible: when a new type of asset needs to be added to a catalog it can
> be done really quickly by just defining the schema and putting that schema
> into a plugin. Also, these plugins are versioned, so the possible changes in
> the schema are handled properly.
>
> 2. Generic properties
> Next, all the artifact types in Glance V3 have some generic metadata
> properties (i.e. part of the schema which is common for all the types),
> including the name, the version, description, authorship information and so
> on. This also corresponds to the data schema of community app catalog. The
> mapping is not 1:1, but we can work together on this to make sure that these
> generic properties match the expectations of the catalog.
>
> 3. Versioning
> Versions are very important for catalogs of objects, so Glance V3 was
> initially designed keeping versioning questions in mind: each artifact has a
> semver-based version assigned, so the artifacts having the same name but
> different versions are grouped into the proper sequences. API is able to
> query artifacts based on their version spec, e.g. it is possible to fetch
> the latest artifact with the name “foo” having the version greater than 2.1
> and less than 3.5.7 - or any other version spec, similar to pip or any other
> similar tool. As far as I know, community app catalog does not have such
> capabilities right now - and I strongly believe that it is really a must
> have feature for a catalog to be successful. At least it is absolutely
> mandatory for Murano packages, which are the only “real apps” among the
> asset types right now.
>
> 4. Cross artifact dependencies
> Glance V3 also has the dependency relations from the very beginning, so they
> may be defined as part of artifact type schema. As a result, an artifact may
> “reference” any number of other artifacts with various semantic. For
> example, murano package may define a set of references to other murano
> packages and call it “requires” - and this will act similar to the
> requirements of a python package. Similar properties may be defined for heat
> templates and glance images - they may reference each other with various
> semantics.
> Of course, the definitions of such dependencies may be done internally
> inside the packages, so they may be resolved locally by the service which is
> going to use it, but letting the catalog know about them will allow us to do
> the import-export operations for any given artifacts and its dependencies
> automatically, only by the means of the catalog itself.
>
> 5. Search and filtering API
> Right now Glance V3 API is in experimental state (we plan to stabilize it
> during the Mitaka cycle), but it already provides quite good capabilities to
> discover things. It can search artifacts by their type, name and
> (optionally) aforementioned version specs, by tag or even by arbitrary set
> of metadata properties. We have plans to integrate Glance V3 with the
> Searchlight project to have even more index and search capabilities using
> its elastic search engine.
>
> 6. Data storage
> As you probably know, Glance does not own the binary data of its images.
> Instead, it provides an abstraction of the backend storage, which may be
> swift, ceph, s3 or something else. The same approach is used in Glance V3
> for artifacts data, but with more per-type control: particular artifact
> types may be configured independently to store their blobs in different
> backends. This may be of use for Community App Catalog which 

[openstack-dev] [app-catalog] Tokyo Summit Sessions

[Christopher Aedo]

Hello!  I wanted to send a note letting people know about the two
sessions we have planned for the Tokyo Summit coming up.  Both of them
are on Thursday, with a Fishbowl session followed by a working
session.

I'm eager to get feedback and input while we're in Tokyo.  We are
interested not only in adding content, but in making that content
easier to add and easier to consume.  To that end we've got an
excellent Horizon plugin that makes the App Catalog essentially a
native element of your OpenStack cloud.  Once we complete the first
pass of a real API for the site we will also write a plugin for the
unified client.  We have other plans and ideas along these lines, but
could really use your help in making sure we are headed in the right
direction.

During the Fishbowl we will go over the progress we've made in the
last six months, where things with the App Catalog stand today, and
what our plans are for the next cycle.  This will be highly
interactive, so if you care even a little bit about making OpenStack
better for the end users you should join us!

That session will be followed by a working session where we'll have a
chance to talk over some of the major design decisions we're making
and discuss improvements, concerns, or anything else related to the
catalog that comes up.

Status, progress and plans
http://mitakadesignsummit.sched.org/event/27bf7f9a29094cf9e96026d682db1609
Thursday in the Kotobuki room, from 1:50 to 2:30

Work session
http://mitakadesignsummit.sched.org/event/7754b46437c14cd4fdb51debebe89fb0
Thursday in the Tachibana room, from 2:40 to 3:20

-Christopher

__
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] [devstack] A few questions on configuring DevStack for Neutron

[Christopher Aedo]

On Thu, Oct 8, 2015 at 9:38 AM, Sean M. Collins  wrote:
> Please see my response here:
>
> http://lists.openstack.org/pipermail/openstack-dev/2015-October/076251.html
>
> In the future, do not create multiple threads since responses will get
> lost

Yep, thank you Sean - saw your response yesterday and was going to
follow-up this thread with a "please ignore" and a link to the other
thread.  I opted not to in hopes of reducing the noise but I think
your note here is correct and will close the loop for anyone who
happens across only this thread.

(Secretly though I hope this thread somehow becomes never-ending like
the "don't -1 for a long commit message" thread!)

-Christopher

__
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] [app-catalog] IRC Meeting Thursday October 8th at 17:00UTC

[Christopher Aedo]

Greetings! Our next OpenStack App Catalog meeting will take place this
Thursday October 8th at 17:00 UTC in #openstack-meeting-3

The agenda can be found here:
https://wiki.openstack.org/wiki/Meetings/app-catalog

Please add agenda items if there's anything specific you would like to
discuss (or of course if the meeting time is not convenient for you
join us on IRC #openstack-app-catalog).

Please join us if you can!

-Christopher

__
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] [devstack] A few questions on configuring DevStack for Neutron

[Christopher Aedo]

On Sun, Oct 4, 2015 at 9:16 PM, Mike Spreitzer  wrote:
> [Apologies for re-posting, but I botched the subject line the first time and
> know that people use filters.]
>
> I have been looking at
> http://docs.openstack.org/developer/devstack/guides/neutron.htmland wonder
> about a few things.
>
> In the section
> http://docs.openstack.org/developer/devstack/guides/neutron.html#using-neutron-with-a-single-interfacethere
> is a helpful display of localrc contents.  It says, among other things,
>
>OVS_PHYSICAL_BRIDGE=br-ex
>PUBLIC_BRIDGE=br-ex
>
> In the next top-level section,
> http://docs.openstack.org/developer/devstack/guides/neutron.html#using-neutron-with-multiple-interfaces,
> there is no display of revised localrc contents and no mention of changing
> either bridge setting.  That is an oversight, right?  I am guessing I need
> to set OVS_PHYSICAL_BRIDGEand PUBLIC_BRIDGEto different values, and the
> exhibited `ovs-vsctl` commands in this section apply to
> $OVS_PHYSICAL_BRIDGE.  Is that right?  Are there other revisions I need to
> make to localrc?
>
> Looking at
> http://docs.openstack.org/networking-guide/scenario_legacy_ovs.html(or, in
> former days, the doc now preserved at
> http://docs.ocselected.org/openstack-manuals/kilo/networking-guide/content/under_the_hood_openvswitch.html)
> I see the name br-ex used for $PUBLIC_BRIDGE--- not $OVS_PHYSICAL_BRIDGE,
> right?  Wouldn't it be less confusing if
> http://docs.openstack.org/developer/devstack/guides/neutron.htmlused a name
> other than "br-ex" for the exhibited commands that apply to
> $OVS_PHYSICAL_BRIDGE?
>
> The section
> http://docs.openstack.org/developer/devstack/guides/neutron.html#neutron-networking-with-open-vswitchbuilds
> on
> http://docs.openstack.org/developer/devstack/guides/neutron.html#using-neutron-with-multiple-interfacesNOT
> http://docs.openstack.org/developer/devstack/guides/neutron.html#using-neutron-with-a-single-interface---
> right?  Could I stop after reading that section, or must I go on to
> http://docs.openstack.org/developer/devstack/guides/neutron.html#neutron-networking-with-open-vswitch-and-provider-networks?
>
> The exhibited localrc contents in section
> http://docs.openstack.org/developer/devstack/guides/neutron.html#using-neutron-with-a-single-interfaceinclude
> both of these:
>
>Q_L3_ENABLED=True
>Q_USE_PROVIDERNET_FOR_PUBLIC=True
>
> and nothing gainsays either of them until section
> http://docs.openstack.org/developer/devstack/guides/neutron.html#neutron-networking-with-open-vswitch-and-provider-networks---
> where we first see
>
>Q_L3_ENABLED=False
>
> Is it true that all the other sections want both Q_L3_ENABLED and
> Q_USE_PROVIDERNET_FOR_PUBLICto be True?

I'd love to see a response from someone who can make sense of this
too.  With my evangelist hat on, I usually tell people who want to get
started with OpenStack development to start with Devstack.  More often
than not, they have trouble with the networking side.  As discussed
and hoped for in the "just get me a network" spec, there's definitely
a need for a less painful path for users.  Likewise we should be able
to share a devstack config that just works, but at the same time shows
off some of the great capabilities of neutron (and all the other good
bits of OpenStack).

Can anyone weigh in here on this issue?

-Christopher

__
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] [devstack] Is there a way to configure devstack for one flat external network using Kilo, Neutron?

[Christopher Aedo]

On Mon, Sep 28, 2015 at 7:08 AM, Mike Spreitzer  wrote:
> Is there a way to configure devstack to install Neutron such that there is
> just one network and that is an external network and Nova can create Compute
> Instances on it, using projects of Kilo vintage?

Mike, this might help, I have a script to make a local.conf that works
on a single-nic VM with Neutron:
https://github.com/aedocw/devstack-helper

Would just have to add the bits to specify using the Kilo release.  I
would definitely appreciate feedback on this though, especially if the
resulting config isn't quite right.

-Christopher

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [murano] [app-catalog] versions for murano assets in the catalog

[Christopher Aedo]

On Tue, Sep 22, 2015 at 12:06 PM, Serg Melikyan  wrote:
> Hi Chris,
>
> concern regarding assets versioning in Community App Catalog indeed
> affects Murano because we are constantly improving our language and
> adding new features, e.g. we added ability to select existing Neutron
> network for particular application in Liberty and if user wants to use
> this feature - his application will be incompatible with Kilo. I think
> this also valid for Heat because they HOT language is also improving
> with each release.
>
> Thank you for proposing workaround, I think this is a good way to
> solve immediate blocker while Community App Catalog team is working on
> resolving handling versions elegantly from they side. Kirill proposed
> two changes in Murano to follow this approach that I've already +2 ed:
>
> * https://review.openstack.org/225251 - openstack/murano-dashboard
> * https://review.openstack.org/225249 - openstack/python-muranoclient
>
> Looks like corresponding commit to Community App Catalog is already
> merged [0] and our next step is to prepare new version of applications
> from openstack/murano-apps and then figure out how to publish them
> properly.

Yep, thanks, this looks like a step in the right direction to give us
some wiggle room to handle different versions of assets in the App
Catalog for the next few months.

Down the road we want to make sure that the App Catalog is not closely
tied to any other projects, or how those projects handle versions.  We
will clearly communicate our intentions around versions of assets (and
how to specify which version is desired when retrieving an asset) here
on the mailing list, during the weekly meetings, and during the weekly
cross-project meeting as well.

> P.S. I've also talked with Alexander and Kirill regarding better ways
> to handle versioning for assets in Community App Catalog and they
> shared that they are starting working on PoC using Glance Artifact
> Repository, probably they can share more details regarding this work
> here. We would be happy to work on this together given that in Liberty
> we implemented experimental support for package versioning inside the
> Murano (e.g. having two version of the same app working side-by-side)
> [1]
>
> References:
> [0] https://review.openstack.org/224869
> [1] 
> http://murano-specs.readthedocs.org/en/latest/specs/liberty/murano-versioning.html

Thanks, looking forward to the PoC.  We have discussed whether or not
using Glance Artifact Repository makes sense for the App Catalog and
so far the consensus has been that it is not a great fit for what we
need.  Though it brings a lot of great stuff to the table, all we
really need is a place to drop large (and small) binaries.  Swift as a
storage component is the obvious choice for that - the metadata around
the asset itself (when it was added, by whom, rating, version, etc.)
will have to live in a DB anyway.  Given that, seems like Glance is
not an obvious great fit, but like I said I'm looking forward to
hearing/seeing more on this front :)

-Christopher

__
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] [app-catalog] App Catalog core cleanup

[Christopher Aedo]

In an effort to do some housekeeping, I plan to clean up the list of
core reviewers in the App Catalog.  Currently the members are:
Alexander Tivelkov, Angus Salkeld, Christopher Aedo, Georgy
Okrokvertskhov, Herman Narkaytis, Kevin Fox, Pavlo Shchelokovskyy,
Serg Melikyan and Tom Fifield

Based on Stackalytics[1] only Kevin Fox, Tom Fifield and myself have
maintained an ongoing effort of reviews and contributions.  Though
everyone on that list was absolutely instrumental in getting the App
Catalog off the ground, it seems like priorities have shifted since
then for many of the early contributors.

My intention is to remove the inactive members at the end of this week
unless they're interested in renewing their efforts in the very near
future.  If you do intend to get involved again, please speak up,
thanks!

[1] http://stackalytics.com/report/contribution/app-catalog/90

-Christopher

__
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] [app-catalog] App Catalog IRC meeting minutes - 9/17/2015

[Christopher Aedo]

We had a nice meeting today and caught up on some of our
plans/intentions for the web site backend.  Long ago we knew that a
basically static site with assets listed in a YAML would not last for
long.  It's already causing issues with respect to versions and
updates, and makes determining when things were added really
cumbersome.

Over the next few weeks we will be transitioning to using flask for
the backend.  Initially we'll just replicate exactly what we have now,
then can slowly start adding the additional features we are planning.
We will also be using many of the same design elements (static files
and javascript) between the Horizon plugin and the website itself.

There's lots more happening here in the months to come at any rate :)
If you ever think about ways to make OpenStack clouds more useful for
the end-users (or are just curious about what we are up to), please
join us on IRC (#openstack-app-catalog).  Thanks!

-Christopher

=
#openstack-meeting-3: app-catalog
=
Meeting started by docaedo at 17:00:30 UTC.  The full logs are available
at
http://eavesdrop.openstack.org/meetings/app_catalog/2015/app_catalog.2015-09-17-17.00.log.html

Meeting summary
---
* rollcall  (docaedo, 17:00:50)
* Status updates (docaedo)  (docaedo, 17:02:07)
  * ACTION: docaedo to get SSL cert for app catalog website  (docaedo,
17:05:52)
* Discuss "new site plans" etherpad (docaedo)  (docaedo, 17:07:48)
  * LINK: https://etherpad.openstack.org/p/app-catalog-v2-backend
(docaedo, 17:07:55)
  * ACTION: docaedo to request a new repo for common elements shared
between app-catalog and ui  (docaedo, 17:15:38)
* Open discussion  (docaedo, 17:23:19)
Meeting ended at 17:28:31 UTC.

Action items, by person
---
* docaedo
  * docaedo to get SSL cert for app catalog website
  * docaedo to request a new repo for common elements shared between
app-catalog and ui

People present (lines said)
---
* docaedo (40)
* kfox (29)
* kzaitsev_mb (7)
* pkoros (4)
* openstack (3)

Generated by `MeetBot`_ 0.1.4

__
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] [murano] [app-catalog] versions for murano assets in the catalog

[Christopher Aedo]

One big thing missing from the App Catalog right now is the ability to
version assets.  This is especially obvious with the Murano assets
which have some version/release dependencies.  Ideally an app-catalog
user would be able to pick an older version (ie "works with kilo
rather than liberty"), but we don't have that functionality yet.

We are working on resolving handling versions elegantly from the App
Catalog side but in the short term we believe Murano is going to need
a workaround.  In order to support multiple entries with the same name
(i.e. Apache Tomcat package for both Kilo and Liberty) we are
proposing the Liberty release of Murano have a new default URL, like:

MURANO_REPO_URL="http://apps.openstack.org/api/v1/murano_repo/liberty/;

We have a patch ready [1] which would redirect traffic hitting that
URL to http://storage.apps.openstack.org.  If we take this approach,
we will then retain the ability to manage where Murano fetches things
from without requiring clients of the Liberty-Murano release to do
anything.  For instance, if there is a need for Liberty versions of
Murano packages to be different from Kilo, we could set up a
Liberty-specific directory and put those versions there, and then
adjust the redirect appropriately.

What do you think?  We definitely need feedback here, otherwise we are
likely to break things Murano relies on.  kzaitsev is active on IRC
and was the one who highlighted this issue, but if there are other
compatibility or version concerns as Murano continues to grow and
improve, we could use one or two more people from Murano to stay in
touch with us wherever you intersect with the App Catalog so we don't
break something for you :)

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

-Christopher

__
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] [ptl] Troubleshooting cross-project communications

[Christopher Aedo]

On Tue, Sep 15, 2015 at 7:50 AM, Anne Gentle
 wrote:
> Hi all,
>
> What can we do to make the cross-project meeting more helpful and useful for
> cross-project communications? I started with a proposal to move it to a
> different time, which morphed into an idea to alternate times. But, knowing
> that we need to layer communications I wonder if we should troubleshoot
> cross-project communications further? These are the current ways
> cross-project communications happen:
>
> 1. The weekly meeting in IRC
> 2. The cross-project specs and reviewing those
> 3. Direct connections between team members
> 4. Cross-project talks at the Summits

5. This mailing list

>
> What are some of the problems with each layer?
>
> 1. weekly meeting: time zones, global reach, size of cross-project concerns
> due to multiple projects being affected, another meeting for PTLs to attend
> and pay attention to
> 2. specs: don't seem to get much attention unless they're brought up at
> weekly meeting, finding owners for the work needing to be done in a spec is
> difficult since each project team has its own priorities
> 3. direct communications: decisions from these comms are difficult to then
> communicate more widely, it's difficult to get time with busy PTLs
> 4. Summits: only happens twice a year, decisions made then need to be widely
> communicated

5. There's tremendous volume on the mailing list, and it can be very
difficult to stay on top of all that traffic.

>
> I'm sure there are more details and problems I'm missing -- feel free to
> fill in as needed.
>
> Lastly, what suggestions do you have for solving problems with any of these
> layers?

Unless I missed it, I'm really not sure why the mailing list didn't
make the list here?  My take at least is that we should be
coordinating with each other through the mailing list when real-time
isn't possible (due time zone issues, etc.)  At the very least, it
keeps people from holding on to information or issues until the next
weekly meeting, or for a few months until the next mid-cycle or
summit.

I personally would like to see more coordination happening on the ML,
and would be curious to hear opinions on how that can be improved.
Maybe a tag on the subject line to draw attention in this case makes
this a little easier, since we are by nature talking about issues that
span all projects?  [cross-project] rather than [all]?

-Christopher

__
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] [app-catalog] PTL Candidacy

[Christopher Aedo]

It's time for the Community App Catalog to go through an official
election cycle, and I'm putting my name in for PTL.  I've been filling
that role provisionally since before the App Catalog was launched at
the Vancouver summit, and I would like to continue service as PTL
officially.  Now that we've joined the Big Tent[1], having a committed
leader is more important than ever :) .

I believe the App Catalog has tremendous potential for helping the
end-users of OpenStack clouds find and share things they can deploy on
those clouds.  To that end, I've been working with folks on extending
the types of assets that can live in the catalog and also trying to
make finding and consuming those assets easier.

Since we announced the Community App Catalog I've done everything I
could to deliver on the "community" part.  With the help of the
OpenStack Infra team, we moved the site to OpenStack infrastructure as
quickly as possible.  All planning and coordination efforts have
happened on IRC (#openstack-app-catalog), the dev and operators
mailing list, and during the weekly IRC meetings[2].  I've also been
working to get more people engaged and involved with the Community App
Catalog project while attempting to raise the profile and exposure
whenever possible.

Speaking of community, I know being part of the OpenStack community at
a broad level is one of the most important things for a PTL.  On that
front I'm active and always available on IRC (docaedo), and do my best
to stay on top of all the traffic on the dev mailing list.  I also
work with Richard Raseley to organize the OpenStack meetup in Portland
in order to reach, educate (and entertain) people who want to learn
more about OpenStack.

The next big thing we will do for the Community App Catalog is to
build out the backend so it becomes a more engaging experience for the
users, as well as makes it easier for other projects to contribute and
consume the assets.  In addition to the Horizon plugin[3][4] (check it
out with devstack, it's pretty cool!) we are thinking through the API
side of this and will eventually contribute the code to search, fetch
and push from the OpenStack Client.

All of this is to say that I'm eager and proud to serve as the
Community App Catalog PTL for the next six months if you'll have me!

[1] https://review.openstack.org/#/c/217957/
[2] https://wiki.openstack.org/wiki/Meetings/app-catalog
[3] https://github.com/stackforge/apps-catalog-ui
[4] https://github.com/openstack/app-catalog-ui

__
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] [app-catalog] App Catalog IRC meeting minutes - 9/3/2015

[Christopher Aedo]

We had a good meeting yesterday which included a little cheer for the
Community App Catalog project being accepted into the big tent (thanks
to everyone who has been supporting our efforts all along!)  The bulk
of the meeting was then devoted to discussing our plans for the next
generation of the site.  We've started the effort by outlining on
etherpad [1] all the features we need the site to support.  Next up we
are going to start evaluating potential frameworks we can use to build
a new site quickly while still making it easy to deploy and support
(and extend down the road.)  If you have useful opinions/experience
and are interested in helping plan this, please check out the etherpad
and join us on IRC to discuss.

As always, please join us on IRC (#openstack-app-catalog), or speak up
here on the mailing list if you want to help us make this the top
destination for people using OpenStack clouds!

[1] https://etherpad.openstack.org/p/app-catalog-v2-backend

-Christopher

=
#openstack-meeting-3: app-catalog
=
Meeting started by docaedo at 17:00:15 UTC.  The full logs are available
at
http://eavesdrop.openstack.org/meetings/app_catalog/2015/app_catalog.2015-09-03-17.00.log.html
.

Meeting summary
---
* rollcall  (docaedo, 17:00:30)

* Status updates (docaedo)  (docaedo, 17:01:21)
  * LINK: https://review.openstack.org/#/c/217957/  (docaedo, 17:01:43)
  * LINK: https://review.openstack.org/#/c/219809/  (docaedo, 17:02:57)
  * LINK: http://bit.ly/1N37aMS  (docaedo, 17:03:09)
  * LINK: https://review.openstack.org/#/c/218898/  (docaedo, 17:06:31)

* Review/discuss "new site plans" etherpad (docaedo)  (docaedo,
  17:10:47)
  * LINK: https://etherpad.openstack.org/p/app-catalog-v2-backend
(docaedo, 17:10:52)

* Open discussion  (docaedo, 17:38:11)

Meeting ended at 17:43:30 UTC.

People present (lines said)
---
* docaedo (55)
* kfox (47)
* ativelkov (17)
* kzaitsev_mb (9)
* j^2 (4)
* openstack (3)

Generated by `MeetBot`_ 0.1.4

__
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] [app-catalog] IRC Meeting Thursday September 3rd at 17:00UTC

[Christopher Aedo]

Greetings! Our next OpenStack App Catalog meeting will take place this
Thursday September 3rd at 17:00 UTC in #openstack-meeting-3

The agenda can be found here:
https://wiki.openstack.org/wiki/Meetings/app-catalog

Please add agenda items if there's anything specific you would like to
discuss (or of course if the meeting time is not convenient for you
join us on IRC #openstack-app-catalog).

Please join us if you can!

-Christopher

__
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] [tc][app-catalog] Application for inclusion in big tent

[Christopher Aedo]

Hello! We put together our details and submitted a review for adding
the Community App Catalog project to the OpenStack governance projects
list [1].  We are looking forward to continuing to grow the catalog in
cooporation with the other projects, and building this showcase of all
the things that can be done with an OpenStack environment.

-Christopher

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

__
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] [app-catalog] App Catalog IRC meeting minutes - 8/20/2015

[Christopher Aedo]

We had a quick meeting today and covered the excellent progress Kevin
Fox is making on a Horizon plugin for the App Catalog, as well as a
brief update on whether the codebase for ask.o.o would be worth
considering as a backend for the catalog.

As always, please join us on IRC (#openstack-app-catalog), or speak up
here on the mailing list if you want to help us make this the top
destination for people using OpenStack clouds!


=
#openstack-meeting-3: app-catalog
=

Meeting started by docaedo at 17:00:33 UTC.  The full logs are available
at
http://eavesdrop.openstack.org/meetings/app_catalog/2015/app_catalog.2015-08-20-17.00.log.html
.

Meeting summary
---
* rollcall  (docaedo, 17:00:45)
  * LINK: http://localconspiracy.com/2015/08/regarding-irc.html
(docaedo, 17:02:52)

* Horizon plugin status update (kfox)  (docaedo, 17:03:20)

* ask.openstack codebase for backend (docaedo)  (docaedo, 17:08:26)
  * LINK: https://github.com/ASKBOT/askbot-devel  (docaedo, 17:09:02)
  * LINK:
http://lists.openstack.org/pipermail/community/2015-August/001257.html
(docaedo, 17:10:20)

* Open discussion  (docaedo, 17:25:35)

Meeting ended at 17:29:46 UTC.

People present (lines said)
---
* docaedo (46)
* kfox (21)
* kzaitsev_mb (6)
* openstack (3)

Generated by `MeetBot`_ 0.1.4

__
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] [app-catalog] IRC Meeting Thursday August 20th at 17:00UTC

[Christopher Aedo]

Howdy! Our next OpenStack App Catalog meeting will take place this
Thursday August 20th at 17:00 UTC in #openstack-meeting-3

The agenda can be found here:
https://wiki.openstack.org/wiki/Meetings/app-catalog

Please add agenda items if there's anything specific you would like to
discuss (or of course if the meeting time is not convenient for you
join us on IRC #openstack-app-catalog).

Please join us if you can!

-Christopher

__
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] [app-catalog] No IRC meeting this week

[Christopher Aedo]

We are planning to push the meeting until next week.  If anyone has
any specific topic they would like to discuss though, please respond
here and we can hold the meeting as normally planned.  Otherwise, join
us on IRC (#openstack-app-catalog) any time!

-Christopher

__
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] [app-catalog][heat] Heat template contributors repo

[Christopher Aedo]

On Sun, Aug 9, 2015 at 3:32 PM, Steve Baker sba...@redhat.com wrote:
 On 07/08/15 06:56, Fox, Kevin M wrote:

 Heat templates so far seems to be a place to dump examples for showing off
 how to use specific heat resources/features.

 Are there any intentions to maintain production ready heat templates in
 it? Last I asked the answer seemed to be no.

 If I misunderstood, heat-templates would be a logical place to put them
 then.

 Historically heat-templates has avoided hosting production-ready templates,
 but this has purely been due to having the resources available to maintain
 them.

 If a community emerged who were motivated to author, maintain and support
 the infrastructure which tests these templates then I think they would
 benefit from being hosted in the heat-templates repository. It sounds like
 such a community is coalescing around the app-catalog project.

 Production-ready templates could end up somewhere like
 heat-templates/hot/app-catalog. If this takes off then heat-templates can be
 assigned its own core team so that more than just heat-core could approve
 these templates.

Steve and Kevin have both touched on what I was hoping for when I sent
the initial note.  That is to try to make a place for developing heat
templates, and a path to get there for those who might contribute.

Ryan asked a key question that was definitely not clear from what I was asking:
On Thu, Aug 6, 2015 at 11:55 AM, Ryan Brown rybr...@redhat.com wrote:
 What do you imagine these templates being for? Are people creating
 little reusable snippets/nested stacks that can be incorporated into
 someone else's infrastructure? Or standalone templates for stuff like
 here, instant mongodb cluster?

I was thinking of this from the perspective of all the people who have
access to OpenStack clouds now (whether private self-hosted clouds or
the dozens of public OpenStack clouds people can use today).  The App
Catalog is meant to be a showcase for things that you can do with that
cloud; packing it full of useful Heat templates would be excellent.  I
am thinking standalone templates, basically like the great set of
templates available on Rackspace cloud [1] but ones tailored for ALL
OpenStack clouds.

I do not believe just creating a repo will magically result in people
adding templates there (with expert guidance from unspecified core
reviewers).  But it feels to me like we are missing a place and
community for sharing the templates that are being developed (or the
ideas that could be turned into templates).  Like Kevin pointed out
for the work J^2 did for the Chef templates, there's no obvious place
to go check first to see if someone else has created and shared a
template before you start working on one.  Ideally the app-catalog
becomes that place, but I'm trying to figure out how to engage the
Heat community in making that a reality.  If making a new repo is not
the answer (and I agree with most of the points in this thread -
that's not the way forward), let's see what else we can do.

Can we agree the world of people using OpenStack would benefit from
having easy access to Heat templates that stand up applications for
users?  Given that, what would be the best way to start collecting
what already exists, and start encouraging newcomers to contribute
there?

[1]: https://github.com/rackspace-orchestration-templates

-Christopher

__
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] [app-catalog] App Catalog IRC meeting minutes - 8/6/2015

[Christopher Aedo]

Thanks again for a great meeting this week, and I'm really encouraged
to see the conversation around building up the Community App Catalog
is continuing to grow.  One thing we touched on this week was the idea
of creating a new repo for Heat contributors to host their templates
on.  I sent a note to OpenStack-dev [1] in hopes of sparking a
conversation on this.  Additionally we've been adding more blueprints
to make our roadmap intentions clearer [2].

As always, please join us on IRC (#openstack-app-catalog), or speak up
here on the mailing list if you want to help us make this the top
destination for people using OpenStack clouds!

[1]: http://lists.openstack.org/pipermail/openstack-dev/2015-August/071555.html
[2]: https://blueprints.launchpad.net/app-catalog

=
#openstack-meeting-3: app-catalog
=

Meeting started by docaedo at 17:00:33 UTC.  The full logs are available
at
http://eavesdrop.openstack.org/meetings/app_catalog/2015/app_catalog.2015-08-06-17.00.log.html

Meeting summary
---
* rollcall  (docaedo, 17:00:45)

* Status updates  (docaedo, 17:01:33)
  * LINK: https://review.openstack.org/#/c/207253/  (docaedo, 17:01:43)
  * LINK: https://blueprints.launchpad.net/app-catalog  (docaedo,
17:01:55)
  * LINK:
https://blueprints.launchpad.net/app-catalog/+spec/murano-apps-dependencies
(kfox, 17:03:46)

* App Catalog Horizon Plugin Update (kfox)  (docaedo, 17:05:49)
  * LINK: https://youtu.be/2UQ6xa6uDQY  (kfox, 17:09:45)
  * LINK: https://play.google.com/store  (kfox, 17:11:19)
  * LINK:
https://blueprints.launchpad.net/app-catalog/+spec/contributed-by-logo
(docaedo, 17:19:43)

* Open discussion  (docaedo, 17:21:26)
  * ACTION: docaedo to writ to ML regarding Heat contributors repo for
app-catalog  (docaedo, 17:38:45)

Meeting ended at 17:45:47 UTC.

Action items, by person
---
* docaedo
  * docaedo to writ to ML regarding Heat contributors repo for
app-catalog

People present (lines said)
---
* kfox (70)
* docaedo (66)
* kzaitsev_mb (21)
* openstack (3)
* j^2 (2)

Generated by `MeetBot`_ 0.1.4

__
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] [app-catalog][heat] Heat template contributors repo

[Christopher Aedo]

Today during the app-catalog IRC meeting we talked about hosting Heat
templates for contributors.  Right now someone who wants to create
their own templates can easily self-host them on github, but until
they get people pointed at it, nobody will know about their work on
that template, and getting guidance and feedback from all the people
who know Heat well takes a fair amount of effort.

What do you think about us creating a new repo (app-catalog-heat
perhaps), and collectively we could encourage those interested in
contributing Heat templates to host them there?  Ideally members of
the Heat community would become reviewers of the content, and give
guidance and feedback.  It would also allow us to hook into OpenStack
CI so these templates could be tested, and contributors would have a
better sense of the utility/portability of their templates.  Over time
it could lead to much more exposure for all the useful Heat templates
people are creating.

Thoughts?

-Christopher

__
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] [app-catalog] IRC Meeting Thursday August 6th at 17:00UTC

[Christopher Aedo]

Hello! Our next OpenStack App Catalog meeting will take place this
Thursday August 6th at 17:00 UTC in #openstack-meeting-3

The agenda can be found here:
https://wiki.openstack.org/wiki/Meetings/app-catalog

Please add agenda items if there's anything specific you would like to discuss.

Please join us if you can!

__
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] [app-catalog] App Catalog IRC meeting minutes - 7/30/2015

[Christopher Aedo]

This week we had a great meeting, and have had a lot of good
conversations flowing on the IRC channel.  We're solidifying the next
steps on our roadmap, and Kevin Fox has made great progress on
creating a Horizon panel to allow users to browse the catalog from
Horizon as well as provide a one-click fetch of assets.

One other major change we are discussing is incorporating the voting
and feedback used in ask.openstack.org in order to provide users of
the App Catalog a way to upvote their favorite assets (and downvote
problematic ones), and add comments around any specific asset.

As always, please join us on IRC (#openstack-app-catalog) or speak up
on the mailing list if there are things you would like to see, or
additions that would help improve the App Catalog!

=
#openstack-meeting-3: app-catalog
=

Meeting started by docaedo at 17:00:33 UTC.  The full logs are available
at
http://eavesdrop.openstack.org/meetings/app_catalog/2015/app_catalog.2015-07-30-17.00.log.html

Meeting summary
---
* rollcall  (docaedo, 17:00:52)
* Status updates (docaedo)  (docaedo, 17:03:33)
  * LINK: https://review.openstack.org/194875  (docaedo, 17:03:51)
  * LINK: https://review.openstack.org/#/c/207253/  (docaedo, 17:04:48)
  * LINK: https://youtu.be/9TlPhmml-T8 :)  (kfox, 17:07:26)
* All about the roadmap  (docaedo, 17:15:01)
  * LINK:
http://lists.openstack.org/pipermail/openstack-dev/2015-July/070423.html
(docaedo, 17:16:53)
  * LINK: https://github.com/kfox/apps-catalog-ui/  (kfox,
17:21:20)
  * LINK: https://en.wikipedia.org/wiki/Disqus yep, these guys
(kzaitsev_mb, 17:30:37)
  * ACTION: discuss/consider using ask.openstack.org code for
voting/comments  (docaedo, 17:39:29)
* App Catalog Horizon Plugin Update (kfox)  (docaedo, 17:44:00)
  * LINK: https://youtu.be/9TlPhmml-T8  (kfox, 17:45:56)
  * LINK: https://github.com/kfox/apps-catalog-ui/  (kfox,
17:46:10)
  * LINK: https://review.openstack.org/#/c/206773/  (kzaitsev_mb,
17:46:12)
* Other Horizon Plugins (kfox)  (docaedo, 17:55:33)

Meeting ended at 18:01:16 UTC.

Action items, by person
---
* openstack
  * discuss/consider using ask.openstack.org code for voting/comments

People present (lines said)
---
* kfox (91)
* docaedo (72)
* j^2 (26)
* rhagarty_ (26)
* kzaitsev_mb (25)
* kzaitsev_ip (3)
* openstack (3)
Generated by `MeetBot`_ 0.1.4

__
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] [app-catalog] IRC Meeting Thursday July 30th at 17:00UTC

[Christopher Aedo]

Hello! Our next OpenStack App Catalog meeting will take place this
Thursday July 20th at 17:00 UTC in #openstack-meeting-3

The agenda can be found here:
https://wiki.openstack.org/wiki/Meetings/app-catalog

Please add agenda items if there's anything specific you would like to
discuss.  For this weeks meeting my primary intention is to discuss
the roadmap, everything we'd like to accomplish before the next
summit, and determine who all will be helping get it done.

Please join us if you can!

-Christopher

__
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] [TripleO] [app-catalog] TripleO, Advanced Services, and the App Catalog

[Christopher Aedo]

On Sun, Jul 26, 2015 at 10:53 AM, Clint Byrum cl...@fewbar.com wrote:
 Excerpts from Christopher Aedo's message of 2015-07-25 19:35:24 -0700:
 My understanding of TripleO
 is that the entire model is tightly coupled such that you must take an
 all or nothing approach (i.e. you can not use one deployment method
 for your cloud, and then use TripleO to deploy other components of
 your cloud later on).  I would be happy to hear my understanding is
 wrong in this case though.


 I can understand why it might have seemed that way because we were
 driving at producing something production-like that ran in the gate,
 but you actually heard wrong. The entire thing is intended to be modular
 and one of the reasons to use OpenStack to deploy OpenStack is so that
 you can easily move components into the cloud. Any tight coupling is an
 accident and is likely only there because at this point there is only
 one implementation receiving much attention (the puppet one).

That's great and I'm glad to be corrected.  If what I said was not
completely clear, I was under the impression that if you did not start
with OpenStack on OpenStack, you would have trouble using the OoO
Heat templates in a cloud deployed differently (Juju, Fuel, or Puppet
for instance).  Sounds to me like you are saying you do not need to
start from TripleO to make use of the TripleO templates.

 Mixing and matching chef and puppet on a single box doesn't work, because
 they both make assumptions about what they own. But you can quite easily
 have two services managed by two separate sets of tools.

Yes, I should have been more clear here, I'm taking Kevin's original
question as can we use the heat templates to deploy additional
services in an already-deployed cloud.  My chef vs. puppet example
muddied things - I was really trying to highlight a situation where
you're using one of those tools to deploy and manage a service (say
your message queue), and that if you've done that with one service you
will have great difficulty trying to update/modify that service with a
different tool if it's still actively managing it.

 I would love to see some way for the App Catalog to allow OpenStack
 users or operators add additional services easily though, and I'm
 excited to see this floated here.  It's possible at least to do this
 with Rally via Murano[2] but that assumes the environment has included
 Murano and also has a Heat environment that includes everything needed
 by the resulting template.  As many have seen, it's not necessarily
 easy for users to know in advance whether this will work (another good
 thread, unfortunately with an unsatisfactory resolution).

 Hopefully we'll see some great responses here on how we can solve some
 of this together!


 This is blowing my mind a little, because I've always been told that
 Rally is a performance measuring tool. :-P I guess I should read up on
 it because it sounds like it is also a packaging or deployment tool?

I think you misunderstood me :)  I was using deploy Rally via Murano
as an example of deploying a service (Rally) that was not originally
deployed with the cloud.  It sounds like the Heat templates could be
used in the same way, that's great!

 Anyway, It should be relatively easy to take the Heat provider templates
 from TripleO and deploy them into a cloud in the same way you should
 have no trouble deploying os-ansible-deployment into a cloud. Whatever
 assumptions about real hardware are made will need to be addressed, but
 ultimately 99% of what is called advanced services is just services
 running regular binaries speaking regular protocols storing things on
 regular filesystems.

-Christopher

__
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] [TripleO] [app-catalog] TripleO, Advanced Services, and the App Catalog

[Christopher Aedo]

On Sat, Jul 25, 2015 at 1:00 PM, Fox, Kevin M kevin@pnnl.gov wrote:
 I'm not really sure how to start this conversation so I'll just start in.
 Please bare with me for a bit.

 Something of a problem description:
 With my Operator hat on, I've been quite interested in adopting TripleO. Due
 to many reasons, its been hard for me to to explore as much as I'd like.
 While time is one reason, another is its kind of monolithic. To try it out,
 the best way so far has been to try and use it all.

 We've been interested in deploying some advanced services on our clouds to
 add features for our users. Again, due to limited time limitations, I
 haven't been able to explore as many of them as I would have liked.

 Some of the advanced services we've had a chance to play with, to varying
 degrees are Sahara, Trove, Designate, and Barbican. We'd also like to play
 with Manilla, Octavia, Murano, Mistral, Magnum, etc. The majority of these
 services can be deployed in VM's (or Containers) running within the Cloud
 and then provided through the Cloud.

 Proposal:
 So that got me thinking. Could the TripleO deployment template set be broken
 up in such a way that it could be used to augment an existing cloud
 deployment instead of just deploying a fresh cloud? This would allow Clouds
 to add advanced features such as Manilla before the Cloud distribution they
 are running on supports it. Also, to make it easy for this enhancement to be
 discoverable, they could be added to the application catalog:
 http://apps.openstack.org. As the App Catalog UI gets integrated further
 with Horzion, it would make it very easy for Operators to extend their
 clouds with Advanced services. They would just do a quick search, hit
 Launch, and fill out a simple form.

 Thoughts?

I think this is a really interesting idea, but I would be surprised to
hear an approach like this is possible.  My understanding of TripleO
is that the entire model is tightly coupled such that you must take an
all or nothing approach (i.e. you can not use one deployment method
for your cloud, and then use TripleO to deploy other components of
your cloud later on).  I would be happy to hear my understanding is
wrong in this case though.

I think Kevin points out a very legitimate use case, but the only
approach I've seen that is really nicely decoupled is the Rally in a
container model [1].  The challenge all the deployment methods face
is that they legitimately want to own the configuration and deployment
from top to bottom of all components.  That's why mixing and matching
Chef and Puppet for managing your deployment doesn't tend to work out
(as many projects expect to share the message queue or DB).

I would love to see some way for the App Catalog to allow OpenStack
users or operators add additional services easily though, and I'm
excited to see this floated here.  It's possible at least to do this
with Rally via Murano[2] but that assumes the environment has included
Murano and also has a Heat environment that includes everything needed
by the resulting template.  As many have seen, it's not necessarily
easy for users to know in advance whether this will work (another good
thread, unfortunately with an unsatisfactory resolution).

Hopefully we'll see some great responses here on how we can solve some
of this together!

[1]: https://registry.hub.docker.com/u/rallyforge/rally/
[2]: http://apps.openstack.org/#tab=murano-appsasset=Rally

-Christopher

__
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