I agree with Wojciech - we are more likely to get the addon proposal
accepted than the mobile specific one.
As a compromise, we could also propose adding support for a simple
--addon=mobile as an alias to the addon install & enable commands, where
the --foo flag is used to identify the name of the addon the install and
enable
e..g. oc cluster up --addon=mobile would run the following commands:
oc cluster addons install mobile oc cluster addons enable mobile oc cluster
up
and oc cluster up --addon=foobar would run the following commands:
oc cluster addons install foobar oc cluster addons enable foobar oc cluster
up
--
John Frizelle
Chief Architect, Red Hat Mobile
Consulting Engineer
mobile: *+353 87 290 1644 <//+353872901644>*
twitter:* @johnfriz*
skype: *john_frizelle*
mail: *jfrizell(a)redhat.com <jfrizell(a)redhat.com>*
On 12 January 2018 at 12:06, Matthias Wessendorf <mwessend(a)redhat.com>
wrote:
I'd actually prefer more --mobile - which than does exactly what
we need
On Fri, Jan 12, 2018 at 1:04 PM, Phil Brookes <pbrookes(a)redhat.com> wrote:
> I’ve discussed this privately with Wojciech as I had misunderstood his
> suggestion, so here’s my attempt to clarify the discussion:
>
> Rather than inserting our mobile oriented tasks into the upstream tool
> (oc), which doesn’t provide value to all users of that tool but rather only
> to the users who are interested in the mobile use-case; we should instead
> modify the tool so that it can accept addons, similar (ideally, identical)
> to minishift addons.
>
> The proposal here would be something like:
>
> oc cluster addons install mobilecore
> oc cluster addons enable mobilecore
> oc cluster up
>
> There a few benefits to this solution:
>
> - There is a clear value-add to the upstream tool
> - We only need to maintain one mobilecore plugin for both minishift
> and oc cluster up
> - The barrier to entry for mobile developers is low
> - The process for setting up a local cluster is the same with both
> tools
> - Future changes to the setup process of the Mobile-Core can be
> submitted to our own repo
>
> @Wojciech please correct me, if I’ve still misunderstood anything!
>
> Regards,
> Phil.
>
>
> On Fri, Jan 12, 2018 at 11:55 AM, Craig Brookes <cbrookes(a)redhat.com>
> wrote:
>
>> +1
>>
>> On Fri, Jan 12, 2018 at 11:46 AM, David Martin <davmarti(a)redhat.com>
>> wrote:
>>
>>> I think there's great value in --mobile flag.
>>> Its the same approach for metrics and logging (--metrics, --logging)
>>>
>>> It would do everything needed to enable the mobile extension and get
>>> the cluster into the state we want.
>>> Having to provide multiple flags would make it just that little more
>>> complex that it raises the barrier.
>>>
>>> I do think there's upstream value in allowing configuring a default org
>>> for the broker though, but I don't think it should be part of this
proposal.
>>>
>>> On 12 January 2018 at 11:39, Phil Brookes <pbrookes(a)redhat.com> wrote:
>>>
>>>> Hey Wojciech,
>>>>
>>>> Thanks a lot for the feedback.
>>>>
>>>> If I have understood you correctly, you are suggesting splitting this
>>>> task in to two discrete pieces of work:
>>>>
>>>> - Add parameters to oc cluster up, to be able to configure the
>>>> ansible-service-broker with custom docker credentials and docker org
to
>>>> pull in the ASBs from.
>>>> - Add the —mobile flag to enable the Mobile-Core UI extension.
>>>>
>>>> With the intention of making this an easier change to adopt.
>>>>
>>>> If that is correct then I am happy to proceed this way and I can
>>>> update the proposal to reflect this as a route to implementation.
>>>>
>>>> Maybe it would be best to bring this discussion to the proposal so
>>>> that the OpenShift team also have access to it?
>>>>
>>>> Thanks,
>>>> Phil.
>>>>
>>>>
>>>> On Fri, Jan 12, 2018 at 11:21 AM, Wojciech Trocki
<wtrocki(a)redhat.com>
>>>> wrote:
>>>>
>>>>> Mobile flag as it doesn't provide ability to change values and
>>>>> imposes some hard dependencies.
>>>>> That may be hard accept and maintain on upstream.
>>>>> Upstream works by generalization so if we want to contribute there
>>>>> it's best to pass something that can be used by many people.
>>>>>
>>>>> How about `oc cluster up --service-broker=true
>>>>> --service-broker-org=aerogearcatalog` and whatever else we need?
>>>>> That's easier to accept and contribute upstream.
>>>>> I have done changes for cluster up recently so if you need anything
>>>>> in that let me know - we can work on this together.
>>>>>
>>>>> Another idea is to specify oc cluster up pre/post actions (hooks)
>>>>> that will allow people to run ansible roles for things we need.
>>>>> That will be solid proposal that upstream may consider.
>>>>>
>>>>> Developers can still have simple command by doing alias:
>>>>>
>>>>>
>>>>> *alias oc-mobile-up=`oc cluster up --service-broker=true
>>>>> --service-broker-org=aerogearcatalog` *
>>>>>
>>>>>
>>>>> On Fri, Jan 12, 2018 at 10:51 AM, David Ffrench
<dffrench(a)redhat.com>
>>>>> wrote:
>>>>>
>>>>>> Fantastic Phil, This is 100% needed in my opinion. The mobile
>>>>>> services need to be a first class citizen in OpenShift to ensure
easy setup
>>>>>> and adoption.
>>>>>>
>>>>>> DAVID FFRENCH
>>>>>>
>>>>>> senior software engineer, RED HAT MOBILE
>>>>>>
>>>>>> Red Hat Waterford <
https://www.redhat.com/>
>>>>>>
>>>>>> Communications House, Cork Road
>>>>>>
>>>>>> Waterford, Ireland
>>>>>>
>>>>>> dffrench(a)redhat.com
>>>>>> <
https://red.ht/sig>
>>>>>>
>>>>>>
>>>>>> On Fri, Jan 12, 2018 at 10:36 AM, Matthias Wessendorf <
>>>>>> mwessend(a)redhat.com> wrote:
>>>>>>
>>>>>>> +9001
>>>>>>>
>>>>>>> On Fri, Jan 12, 2018 at 11:26 AM, Phil Brookes
<pbrookes(a)redhat.com
>>>>>>> > wrote:
>>>>>>>
>>>>>>>> Hey Everyone,
>>>>>>>>
>>>>>>>> I have opened a proposal with the OpenShift team, hoping
to start
>>>>>>>> a discussion around the addition of a --mobile=true flag
to the oc
>>>>>>>> cluster up command. Running oc cluster up --mobile=true
will
>>>>>>>> start a local OpenShift cluster with all of the MCP
features enabled.
>>>>>>>>
>>>>>>>> This would be a great way for us to gain some exposure
for the
>>>>>>>> Mobile Core and get it into the hands of developers more
quickly and
>>>>>>>> easily, so I’d love to see you share your thoughts on
this idea. You can
>>>>>>>> review / comment / support it here:
>>>>>>>>
https://github.com/openshift/origin/issues/18089
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Phil.
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Project lead
AeroGear.org
>>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> feedhenry-dev mailing list
>>>>>> feedhenry-dev(a)redhat.com
>>>>>>
https://www.redhat.com/mailman/listinfo/feedhenry-dev
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>>
>>>>> WOJCIECH TROCKI
>>>>>
>>>>> Red Hat Mobile <
https://www.redhat.com/>
>>>>>
>>>>> IM: wtrocki
>>>>> <
https://red.ht/sig>
>>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> David Martin
>>> Red Hat Mobile
>>> Twitter: @irldavem
>>> IRC: @irldavem (#aerogear)
>>>
>>
>>
>>
>> --
>> Craig Brookes
>> RHMAP
>> @maleck13 Github
>>
>
>
--
Project lead
AeroGear.org