Service Catalog Intro video
by David Martin
This is a great intro for anyone not familiar with the kubernetes service
catalog & brokers.
https://www.youtube.com/watch?v=0aLqc-o256w
The service catalog calls out to a broker (e.g. the Ansible Service Broker)
to provision things.
The Ansible Service Broker kicks off an Ansible Playbook Bundle (e.g.
unifiedpush-apb, fh-sync-server-apb) to actually do the provisioning steps.
--
David Martin
Red Hat Mobile
Twitter: @irldavem
IRC: @irldavem (feedhenry, mobile-internal)
8 years
Suggestion/Discussion - Removal of AeroGear.org Production Branch
by Paul Wright
Hi Laura, All,
I'd like to follow up about the suggestion of a new site, thinking
specifically about:
* much of the existing content is out of date
* there is a lot of 'formerly feedhenry) material to be published next
year (eg mcp, sync)
* the rendering toolchain is sub-optimal (in my POV)
* big changes are happening anyway (now is the opportunity)
However I'm not sure if this means revamping aerogear.org or the
introduction of a new site docs.aerogear.org ?
So, let me propose this, which is what I'd like to see:
* Versioned docs for each component
* A doc set for combining a set of components into a release
* An asciidoc-first approach to the docs (altho I'd like to see markdown
still supported for blogs/etc)
With this in mind, I'm playing with asciibinder, for example, see the
digger docs [1], this has the advantage:
* it's what OpenShift uses
* it's geared towards complex doc sets
* it's geared to multiple version doc sets
* it's lightweight and gathering some momentum (eg fedora are now using it)
Maybe it's used for everything but the home page as per OS [2]
Or maybe the existing aerogear.org lives on, and users only hit the
asciibinder html at a lower level?
WDYT?
thanks,
Paul
[1]
https://5-114535426-gh.circle-artifacts.com/0/home/circleci/docs/_preview...
[2] https://docs.openshift.com/
Date: Fri, 15 Dec 2017 13:56:57 +0000
From: Laura Fitzgerald<lfitzger(a)redhat.com>
To: AeroGear Developer Mailing List<aerogear-dev(a)lists.jboss.org>,
feedhenry-dev(a)redhat.com
Subject: Re: [feedhenry-dev] Suggestion/Discussion - Removal of
AeroGear.org Production Branch
Message-ID:
<CA+jLkhW2g4rrLfptKKUnAN5=LnMLksErnjXHnVXWVr7Fw9xcnA(a)mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi all,
I had sent this email re improving the way that we pubish aerogear.org.
Some may have seen it and replied but as there is some problems with
aerogear-dev mailing and there has been some further discussions I wanted
to reopen a conversation re Aerogear.org.
With the move to the aerogear org there has been some conversation aroung
an overhaul of the aerogear.org website.
It was also suggested that we could go with a brand new site rather than
rejigging the old site.
I'm thinking that it would be worth having a discussion around how we would
go about this.
If anyone has particular interest in this and/or experience with the old
site and existing tech and wants to open a proposal/discussion re tech
stack, design, content etc I think it would be suitable to to do that via
the proposals repo [1] or via some discussion here.
I've been involved in adding some content recently with the Aerogear Digger
Project and my vote would be for creating something new and shiny!!!
Wdy guys t?
[1]https://github.com/aerogear/proposals
On Wed, Dec 6, 2017 at 11:07 AM, Laura Fitzgerald<lfitzger(a)redhat.com>
wrote:
> Hi all,
>
> I have recently gone through the process of publishing documentation for
> AeroGear Digger to aerogear.org.
>
> The process for adding docs for digger was as follows:
>
> - Make changes on Feature Branch over a period of time.
> - At some point merge lots of commits (difficult to review) from Feature
> Branch to master.
> - This publishes to staging.aerogear.org (build needs to be manually
> triggered in Jenkins)
> - At some point merge master (again with lots of commits) to production
> branch
> - This publishes to aerogear.org (build needs to be manually triggered)
>
> Out of this we attempted to improve the process by adding development
> steps to the README [1] outlining that
> -> each change should be verified on it's own -> merged to master -> and
> then merged to production
> removing the wait time and merges which involved lots of commits and
> changes.
>
> *I think there are a few things we can do to make this better. (simpler)*
>
> *1) How?*
>
> Remove the production branch (and related steps) altogether.
>
> *Why?*
>
> - All this documentation is done in the open.
> - All branches are visible to all users/developers.
> - staging.aerogear.org is not private so I don't see that we gain
> something by having this step.
> - Changes can be verified locally by building the website using the steps
> in the README [2] before being merged to master.
>
> *2) How?*
> Automate the publishing of the site
>
> *Why?*
> Right now the building of the site has to be triggered manually via a
> Jenkins instance on cloudbees. If we remove production and enforce that all
> changes are fully verified before being merged to master then we can
> automate that any new changes are published immediately once merged to
> master.
>
> *3) How?*
> Add some sort of versioning to the documentation. This could be in the
> form of tagging the repo once we have a release of a product.
>
> *Why?*
> If we are always publishing docs once a change is made to the product then
> we should version the documentation so we know which version of the docs
> matches older versions of the product.
>
> ~~~~~~~~~~~
>
> I'm really interested in some feedback on this. Let me know what you
> think. Is there a better/simpler way to do it than I suggested?
>
> [1]https://github.com/aerogear/aerogear.org/blob/
> master/README.md#development-steps
> [2]https://github.com/aerogear/aerogear.org/blob/
> master/README.md#building
> --
>
> LAURA FITZGERALD
>
> Red Hat Mobile<https://www.redhat.com/>
>
> Communications House, Cork Road
>
> Waterford City, Ireland X91NY33
>
> lfitzger(a)redhat.com IM: lfitzgerald
> <https://red.ht/sig>
>
>
8 years
1.2.0.Final (was: Re: UPS 1.2.0-beta.2 release)
by Matthias Wessendorf
Things are staged here:
https://repository.jboss.org/nexus/content/repositories/jboss_releases_st...
It's basically stable since we did the last beta releases, and requires now
WF10 or later, and Keycloak is required to be separated as well
-M
On Wed, Sep 13, 2017 at 4:33 PM, Matthias Wessendorf <matzew(a)apache.org>
wrote:
> RC2 is available for evaluation:
> https://repository.jboss.org/nexus/content/repositories/
> jboss_releases_staging_profile-12344/
>
> big difference between rc1 and rc2 is just this one JIRA:
> https://issues.jboss.org/browse/AGPUSH-1368
>
> -M
>
> On Mon, Sep 11, 2017 at 2:40 PM, Matthias Wessendorf <matzew(a)apache.org>
> wrote:
>
>> Tomorrow, I will start the 1.2.0.Final release
>>
>> afterwards will update the docker images
>>
>> On Wed, Sep 6, 2017 at 5:14 PM, Matthias Wessendorf <matzew(a)apache.org>
>> wrote:
>>
>>> release candidate 1 is here:
>>>
>>> https://repository.jboss.org/nexus/content/repositories/jbos
>>> s_releases_staging_profile-12288/
>>>
>>> -M
>>>
>>> On Wed, Sep 6, 2017 at 12:57 PM, Matthias Wessendorf <matzew(a)apache.org>
>>> wrote:
>>>
>>>> Ok, clicked the button.
>>>>
>>>> this will be online tomorrow
>>>>
>>>> In a few days, we might see a CR1 - and shortly after that a .Final :-)
>>>>
>>>> Cheers,
>>>> Matthias
>>>>
>>>> On Tue, Sep 5, 2017 at 6:00 PM, Matthias Wessendorf <matzew(a)apache.org>
>>>> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> after some month of time, we are running a new release of the master
>>>>> branch: 1.2.0-beta.2
>>>>>
>>>>> Main fixes did include:
>>>>> * WildFly 11 (CR1) support
>>>>> * Keycloak decoulping
>>>>> * SimplePush/MPNS removal
>>>>> * version updates of the non Java EE dependencies
>>>>>
>>>>> More details can be found here:
>>>>> https://issues.jboss.org/projects/AGPUSH/versions/12335470
>>>>>
>>>>> Staging repo is located here:
>>>>> https://repository.jboss.org/nexus/content/repositories/jbos
>>>>> s_releases_staging_profile-12282/
>>>>>
>>>>> Once the release is out, I will update the docker images and compose
>>>>> file (including a decouple Keycloak)
>>>>>
>>>>> Have fun!
>>>>> -Matthias
>>>>>
>>>>>
>>>>> --
>>>>> Matthias Wessendorf
>>>>>
>>>>> blog: http://matthiaswessendorf.wordpress.com/
>>>>> twitter: http://twitter.com/mwessendorf
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Matthias Wessendorf
>>>>
>>>> blog: http://matthiaswessendorf.wordpress.com/
>>>> twitter: http://twitter.com/mwessendorf
>>>>
>>>
>>>
>>>
>>> --
>>> Matthias Wessendorf
>>>
>>> blog: http://matthiaswessendorf.wordpress.com/
>>> twitter: http://twitter.com/mwessendorf
>>>
>>
>>
>>
>> --
>> Matthias Wessendorf
>>
>> blog: http://matthiaswessendorf.wordpress.com/
>> twitter: http://twitter.com/mwessendorf
>>
>
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> twitter: http://twitter.com/mwessendorf
>
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
twitter: http://twitter.com/mwessendorf
8 years
5.x Local Development
by David Martin
Thoughts on doing this welcome
TLDR
* Move the mcp-standalone repo to Aerogear github org
* remove the mcp server
* remove the mcp-standalone service from the Android, iOS & Cordova APBs
* remove the Mobile Tab from the UI
* use the remaining ansible stuff for local development
Goals of a 5.x local development environment
* environment for developing services
* a running OpenShift for developing the CLI against
* ability to develop the OpenShift UI with a quick feedback loop
* has the Service Catalog & OpenShift Ansible Broker (for developing APBs)
DETAILS
Move the mcp-standalone repo to Aerogear github org
* part of the overall shift to the aerogear community, and drawing a line
under the 5.x POC work
Remove the mcp server
* the mcp server is not going to be continued
* it was providing some smarts around openshift, which will ultimately live
in APBs or the CLI/UI
Remove the mcp-standalone service from the Android, iOS & Cordova APBs
* See last point as the server is not required
* these App APBs will just need to create a mobile app representation in
OpenShift e.g. a ConfigMap or Mobile App CRD [1] (Separate
proposal/discussion for switching to a CRD)
Remove the Mobile Tab from the UI
* Working with UX people, the Mobile tab is not the route we're taking
* Mobile will become more relevant on the main OpenShift Overview page
* UI development can continue similar to before (via UI extensions) until a
decision is made about how mobile bits make it into the Openshift Web
Console
Use the remaining ansible stuff for local development
* The ansible playbooks & roles in this repo are very useful for setting up
openshift with the ansible service broker
[1] https://kubernetes.io/docs/concepts/api-extension/custom-resources/
--
David Martin
Red Hat Mobile
Twitter: @irldavem
IRC: @irldavem (feedhenry, mobile-internal)
8 years
DELETED OLD IMAGES (was: Re: [feedhenry-dev] APB relocation ...)
by Matthias Wessendorf
Hi,
our ASB is now pointing to the new dockerhub org, and builds for our six
service are already there.
TODO: go and update your branch of 'mcp', and re-run the installer: that
will get images from the "aerogearcatalog" org.
In addition, I've - on Docker-Hub, deleted these six repos:
* feedhenry/keycloak-apb
* feedhenry/3scale-apb
* feedhenry/fh-sync-server-apb
* feedhenry/aerogear-digger-apb
* feedhenry/unifiedpush-apb
* feedhenry/prometheus-apb
greetings,
Matthias
On Fri, Dec 15, 2017 at 5:15 PM, Matthias Wessendorf <mwessend(a)redhat.com>
wrote:
>
>
> On Fri, Dec 15, 2017 at 5:08 PM, David Martin <davmarti(a)redhat.com> wrote:
>
>> +1 on deleting the image repos on docker hub
>> For anyone not up to date on mcp-standalone then, the catalog will not
>> show any of the mobile apbs.
>> Worth sending a follow up after they are deleted
>>
>
> yeah, a note - with drums and fire :) will be sent out
>
>
>>
>> On 15 December 2017 at 16:04, Matthias Wessendorf <mwessend(a)redhat.com>
>> wrote:
>>
>>> Hi,
>>>
>>> as discussed on IRC, I've forked the APBs to aerogearcatalog
>>> organization, and have 'archived' (aka read-only) the feedhenry matching
>>> repos:
>>>
>>> * https://github.com/feedhenry/keycloak-apb
>>> * https://github.com/feedhenry/prometheus-apb
>>> * https://github.com/feedhenry/aerogear-digger-apb
>>> * https://github.com/feedhenry/fh-sync-server-apb
>>> * https://github.com/feedhenry/3scale-apb
>>> * https://github.com/feedhenry/unifiedpush-apb
>>>
>>> You find them now in:
>>> https://github.com/aerogearcatalog
>>>
>>> I've also enabled the hub for automatic builds:
>>> https://hub.docker.com/r/aerogearcatalog/
>>>
>>> and a matching PR for the "MCP":
>>> https://github.com/feedhenry/mcp-standalone/pull/245/files
>>>
>>>
>>> Question (well, RECOMMENDATION):
>>> Are you OK I am DELETING the "feedhenry/blah-apb" repos, on the
>>> docker-hub?
>>>
>>> Ansible recently did the same... when they renamed "apb" to "apb-tools"
>>> - to avoid downloads from "old" stuff - I'd strongly recommend deleting the
>>> 'old' stuff, on the hub :)
>>>
>>> Cheers!
>>> Matthias
>>>
>>>
>>>
>>> --
>>> Project lead AeroGear.org
>>>
>>> _______________________________________________
>>> feedhenry-dev mailing list
>>> feedhenry-dev(a)redhat.com
>>> https://www.redhat.com/mailman/listinfo/feedhenry-dev
>>>
>>>
>>
>>
>> --
>> David Martin
>> Red Hat Mobile
>> Twitter: @irldavem
>> IRC: @irldavem (feedhenry, mobile-internal)
>>
>
>
>
> --
> Project lead AeroGear.org
>
--
Project lead AeroGear.org
8 years
Suggestion/Discussion - Removal of AeroGear.org Production Branch
by Laura Fitzgerald
Hi all,
I have recently gone through the process of publishing documentation for
AeroGear Digger to aerogear.org.
The process for adding docs for digger was as follows:
- Make changes on Feature Branch over a period of time.
- At some point merge lots of commits (difficult to review) from Feature
Branch to master.
- This publishes to staging.aerogear.org (build needs to be manually
triggered in Jenkins)
- At some point merge master (again with lots of commits) to production
branch
- This publishes to aerogear.org (build needs to be manually triggered)
Out of this we attempted to improve the process by adding development steps
to the README [1] outlining that
-> each change should be verified on it's own -> merged to master -> and
then merged to production
removing the wait time and merges which involved lots of commits and
changes.
*I think there are a few things we can do to make this better. (simpler)*
*1) How?*
Remove the production branch (and related steps) altogether.
*Why?*
- All this documentation is done in the open.
- All branches are visible to all users/developers.
- staging.aerogear.org is not private so I don't see that we gain something
by having this step.
- Changes can be verified locally by building the website using the steps
in the README [2] before being merged to master.
*2) How?*
Automate the publishing of the site
*Why?*
Right now the building of the site has to be triggered manually via a
Jenkins instance on cloudbees. If we remove production and enforce that all
changes are fully verified before being merged to master then we can
automate that any new changes are published immediately once merged to
master.
*3) How?*
Add some sort of versioning to the documentation. This could be in the form
of tagging the repo once we have a release of a product.
*Why?*
If we are always publishing docs once a change is made to the product then
we should version the documentation so we know which version of the docs
matches older versions of the product.
~~~~~~~~~~~
I'm really interested in some feedback on this. Let me know what you think.
Is there a better/simpler way to do it than I suggested?
[1]
https://github.com/aerogear/aerogear.org/blob/master/README.md#developmen...
[2] https://github.com/aerogear/aerogear.org/blob/master/README.md#building
--
LAURA FITZGERALD
Red Hat Mobile <https://www.redhat.com/>
Communications House, Cork Road
Waterford City, Ireland X91NY33
lfitzger(a)redhat.com IM: lfitzgerald
<https://red.ht/sig>
8 years
Android MCP SDK Goals Doc
by Summers Pittman
A few weeks ago we kicked off some discussions on the Android SDK. Since
we've had a lot of things happen since then I am recirculating the doc and
rekickstarting the conversation.
Cross posting with feedhenry-dev because the aerogear-dev list seems to be
being a bit ill.
8 years
