I do agree that there are storage issues that must be addressed but let's
not call them blockers for dogfooding.
Well, maybe it is a terminology issue.
I usually call blocking something preventing to reach the goal normally (workaround is the option to unblock).
IMO we have 2 things "like" this:
1. It is difficult to impossible to use ephemeral storage w/o syncing with something persistent b/c it probability of loose the changes is high (it is good for demo only)
2. It is difficult to impossible to use Gluster storage due to performance on massive write files operations and (which is more important for dogfooding) the issue with che-theia yarn build (which may or may not be a consequence of first).
Can we use hosted Che for dogfooding normally w/o addressing these issues?
If there are workarounds and developers use Hosted Che on a daily basis for
development we should encourage them to continue and address the
storage issues in parallel.
Definitely. Vitaliy's work is really appreciated and I had an opportunity to tell him that in person :) !
Another aspect is that the things he has done (using rsync) is VERY close to what we used for hosted version in
codenvy.io.
So, as the first option of addressing the storage issues could be trying to use this mechanism since it is workable and predictable.
WDYT?
On Thu, Jan 30, 2020 at 10:46 AM Gennady Azarenkov <gazarenk@xxxxxxxxxx>
wrote:
> @Thomas Mäder <tmader@xxxxxxxxxx>
>
> IMO a workaround proposed by Vitaliy address the persistence problem. He
> is rsyncing srcs from temporary instance storage (/tmp/) to permanent one,
> gluster on /projects.
>
> Totally agree that inability of having reasonable persistent storage is a
> blocker for dogfooding on Hosted Che.
>
>
> On Thu, Jan 30, 2020 at 11:28 AM Ilya Buziuk <ibuziuk@xxxxxxxxxx> wrote:
>
>> Thanks for sharing, Vitaliy
>> This is great that you are able to do the che-theia development on Hosted
>> Che! Any chance you can document the flow and make it available in the
>> dev-guide?
>>
>> Do we know where those limitations (3G for root and 1G for /projects) are
>> > configured? @Ilya Buziuk <ibuziuk@xxxxxxxxxx> any idea?
>>
>>
>> No those are not configurable and I believe after the increasing of RAM we
>> would need to start tackling the PVC size thingy (not sure if those two
>> efforts should be done in parallel)
>>
>> I would much rather we invest our efforts in a reliable build process for
>> > che-theia + theia: our approach based on source symlinks is broken. I
>> have
>> > ideas on how to fix it, but no time.
>>
>>
>> IMO this two efforts should be done in parralel and we should encourage
>> the
>> teams to use Hosted Che on a daily basis. I personally much appreciate the
>> fact that Vitalli is doing his every day job on che.openshift.io
>>
>>
>> On Thu, Jan 30, 2020 at 8:11 AM Thomas Mäder <tmader@xxxxxxxxxx> wrote:
>>
>> > Hi Vitaliy,
>> >
>> > I appreciate you investing time in dog-fooding, I really do. But any
>> > approach that loses my changes when my workspace is idled (which I
>> believe
>> > is true for your proposal) is an immediate non-starter for me.
>> >
>> > Personally, I have given up on developing on che.openshift.io until we
>> > have reliable persistent volumes. Currently, we do not.
>> >
>> > I would much rather we invest our efforts in a reliable build process
>> for
>> > che-theia + theia: our approach based on source symlinks is broken. I
>> have
>> > ideas on how to fix it, but no time.
>> >
>> > /Thomas
>> > On 29/01/2020 11:51, Vitaliy Gulyy wrote:
>> >
>> > Hello team,
>> >
>> > I'd like to share the way how to develop che-theia on che.openshift.io
>> > where we have a restriction on disk space for projects in one gigabyte
