Re: Unified server/desktop config

On Tue, Aug 8, 2017 at 7:18 AM, Surinder Kumar <
surinder(dot)kumar(at)enterprisedb(dot)com> wrote:

> Hi
>
> On Ubuntu-14.04, I got error Application Server couldn't be contacted:
>
> *Steps performed:*
>
> - I have already installed pgAdmin4-1.4 which come with PostgreSQL-9.6
> installer.
> then I run root(at)ubuntu:/opt/PostgreSQL/9.6/pgAdmin 4/bin# ./pgAdmin4./.
> - Now took latest git pull from HEAD
> - Apply unified_config.diff patch.
> - Then compiled pgAdmin4 in runtime and then run ./pgAdmin.
> - Got error Application Server couldn't be contacted.
>
> But when I ran ./pgAdmin4 for the second time. pgAdmin4 runs without any
> issue.
> I didn’t get any error on the terminal and log file.
> ​ I couldn't find why it gives this error.​
>

I know Fahar has run into this with existing releases on Ubuntu. If you
enable debugging, can you see any clues? I assume it's going round the
retry loop before aborting?

> *Another issue related to Alembic:*
>
> If I am running pgAdmin4 already installed on my machine, then I upgrade
> pgAdmin4 using Python wheel:
>
> (test_p27) surinder(at)ubuntu:~/virtualenvs/test_p27$ python
> ~/virtualenvs/test_p27/lib/python2.7/site-packages/pgadmin4/pgAdmin4.py
>
> *I am getting error:*
>
> alembic.util.exc.CommandError: Can't locate revision identified by
> 'd85a62333272'
>
> To fix this, I have to delete existing pgadmin4.db file. I don’t know if
> it is a valid case or should I log an RM if it is?
>
That's an annoying side-effect of the move to Alembic. The previous DB code
would quite happily (and intentionally) run with a newer version of the
database, however, the new code does not. You'll see this issue whenever
you've run a newer version of pgAdmin and then go back to an older version
that uses an older schema version.

It would be nice to change this so it doesn't complain - but we'd have to
be cautious to only break compatibility on major releases.

> Apart for this, I didn’t see any functionality break. It works!!
>
> I liked the approach to set SEVER_MODE in runtime using built-ins.
>
Thanks. Do you think it warrants a 2.0 version number, given the potential
for breaking existing installations (I do, but would like other feedback)?
If we do that - and thus allow a parallel installation of 1.x and 2.x), how
would we resolve the Alembic issue you noted such that both versions could
be run against the same DB?

> Thanks,
> Surinder
> ​
>
> On Mon, Aug 7, 2017 at 7:01 PM, Dave Page <dpage(at)pgadmin(dot)org> wrote:
>
>>
>>
>> On Mon, Aug 7, 2017 at 1:43 PM, Surinder Kumar <
>> surinder(dot)kumar(at)enterprisedb(dot)com> wrote:
>>
>>> Hi,
>>>
>>> The patch seems to work in Runtime mode, but fails in Server mode with
>>> error:
>>>
>>> (pgAdmin_27)Laptop195:pgadmin4 surinder$ python web/pgAdmin4.py
>>> Traceback (most recent call last):
>>> File "web/pgAdmin4.py", line 55, in <module>
>>> exec(open(file_quote(setupfile), 'r').read())
>>> File "<string>", line 35, in <module>
>>> File "/Users/surinder/Documents/Projects/pgadmin4/web/pgadmin/setup/data_directory.py", line 23, in create_app_data_directory
>>> _create_directory_if_not_exists(os.path.dirname(config.SQLITE_PATH))
>>> File "/Users/surinder/Documents/Projects/pgadmin4/web/pgadmin/setup/data_directory.py", line 15, in _create_directory_if_not_exists
>>> os.mkdir(_path)
>>> OSError: [Errno 13] Permission denied: '/var/lib/pgadmin'
>>> (pgAdmin_27)Laptop195:pgadmin4 surinder$
>>>
>>> This is because the directory /var/lib/ has root only access and I am
>>> running pgAdmin4 with the non-root user.
>>>
>>> Also pgadmin directory is not created.
>>>
>>> (pgAdmin_35)Laptop195:pgadmin4 surinder$ ls /var/lib/pgadmin
>>> ls: /var/lib/pgadmin: No such file or directory
>>>
>>> I got same error with MacOSX and Ubuntu-14.04 machines irrespective of
>>> Python version.
>>>
>>> Meanwhile, I am testing patch with other test cases.
>>>
>> That's fully expected. In the case of Linux, the packages will be
>> responsible for creating those directories with the appropriate ownership.
>> In other cases, the user would.
>>
> ​ok, I got it.​
>
>>
>> There's not really much we can do about that - and it's exactly what
>> would happen if you try to run many other packages yourself when standard
>> *nix paths are used.
>>
>
>>
>>
>>> Thanks,
>>> Surinder
>>> ​
>>>
>>> On Mon, Aug 7, 2017 at 4:33 PM, Surinder Kumar <
>>> surinder(dot)kumar(at)enterprisedb(dot)com> wrote:
>>>
>>>> On Mon, Aug 7, 2017 at 4:11 PM, Ashesh Vashi <
>>>> ashesh(dot)vashi(at)enterprisedb(dot)com> wrote:
>>>>
>>>>> On Mon, Aug 7, 2017 at 3:59 PM, Dave Page <dpage(at)pgadmin(dot)org> wrote:
>>>>>
>>>>>> Anyone?
>>>>>>
>>>>> Surinder - please give this one priority.
>>>>>
>>>> Sure
>>>> ​.​
>>>>
>>>>
>>>>>
>>>>> --
>>>>>
>>>>> Thanks & Regards,
>>>>>
>>>>> Ashesh Vashi
>>>>> EnterpriseDB INDIA: Enterprise PostgreSQL Company
>>>>> <http://www.enterprisedb.com/>
>>>>>
>>>>>
>>>>> *http://www.linkedin.com/in/asheshvashi*
>>>>> <http://www.linkedin.com/in/asheshvashi>
>>>>>
>>>>>>
>>>>>> On Thu, Jul 20, 2017 at 5:03 PM, Dave Page <dpage(at)pgadmin(dot)org> wrote:
>>>>>>
>>>>>>> All,
>>>>>>>
>>>>>>> Attached is a patch that aims to allow us to have a standardised
>>>>>>> config that will work out of the box for both web and desktop modes. It
>>>>>>> does this by doing two things:
>>>>>>>
>>>>>>> 1) The runtime sets SERVER_MODE in the Python environment before
>>>>>>> starting the app. If this value is set, then it overrides the default value
>>>>>>> of SERVER_MODE in the config.
>>>>>>>
>>>>>>> 2) The config file then offers default values for the various file
>>>>>>> locations for both server and desktop mode, setting them appropriately
>>>>>>> based on the derived SERVER_MODE value.
>>>>>>>
>>>>>>> The only downsides I can see from this are:
>>>>>>>
>>>>>>> - You cannot run in server mode in the runtime without manually
>>>>>>> reconfiguring SERVER_MODE and likely a bunch of paths in config_local.py
>>>>>>>
>>>>>>> - If you want to override SERVER_MODE, you'll probably also need to
>>>>>>> redefine the various paths in config_local.py.
>>>>>>>
>>>>>>> I don't see either being something 99.9% of users would need though.
>>>>>>>
>>>>>>> Can anyone see if the patch breaks anything, or if I missed any side
>>>>>>> effects?
>>>>>>>
>>>>>>> Is it likely to break things during upgrades? I suspect so... so
>>>>>>> maybe this should prompt v2.0?
>>>>>>>
>>>>>>> I'd appreciate multiple reviews of this, as it could break things.
>>>>>>> Note that I haven't yet updated the docs.
>>>>>>>
>>>>>>> --
>>>>>>> Dave Page
>>>>>>> Blog: http://pgsnake.blogspot.com
>>>>>>> Twitter: @pgsnake
>>>>>>>
>>>>>>> EnterpriseDB UK: http://www.enterprisedb.com
>>>>>>> The Enterprise PostgreSQL Company
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Dave Page
>>>>>> Blog: http://pgsnake.blogspot.com
>>>>>> Twitter: @pgsnake
>>>>>>
>>>>>> EnterpriseDB UK: http://www.enterprisedb.com
>>>>>> The Enterprise PostgreSQL Company
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>>
>> --
>> Dave Page
>> Blog: http://pgsnake.blogspot.com
>> Twitter: @pgsnake
>>
>> EnterpriseDB UK: http://www.enterprisedb.com
>> The Enterprise PostgreSQL Company
>>
>
>

--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company