#solum

devkulkarni: hey!

hi pt_15

devkulkarni: i was looking through the error and the codes for other dashboards, it just seems like the jenkins environment itself checks for the earlier version of pbr in the case of solum

other dashboards have also just implemented just pbr>=1.6, like i did, and it even works in my environment if i change my tox requirements like i mentioned yesterday

pt_15: I see.. in that case I would recommend pinging folks on the openstack-infra irc channel to understand why the gate failure is happening. you can explain to them that above point

devkulkarni: hmm, ok, cool, I'll try doing that! :)

vijendar: ping

vijendar: have you created the bug about issue when deleting an app with the same name as a previously created app?

devkulkarni: yes

devkulkarni: I have created a bug

vijendar: can you send me the link to that bug

I am working on fixing the PlanAssembly adapter code in the workflow_handler.. the issue that we found last week

ok.

give me a sec

basically, we want to create a plan only once, if it is not present

sure

correct

thanks

oh, were you already working on it?

vijendar: ^

I haven't started

If you are on it, you can take it

devkulkarni: ^

cool, ok

I just started on it

will reassign to myself

vijendar: btw, one question

yesterday I was looking at the cli to figure out if we can remove plans from the cli code

essentially the OldAppCommands from solum.py in the cli

ok

I realized that there is the whole githubAuth stuff in the OldAppCommands

I saw that we have some of that in the AppCommands

I remember you had last worked on it

do you know if we have completely moved over the current functionality from OldAppCommands to AppCommands as far as github integration is concerned?

vijendar: also, btw, yesterday I was telling pt_15 that you had attended a workshop on building angularjs plugin with horizon.. I was wondering if there were any tutorials/links etc. that the workshop organizer shared with the attendees?

devkulkarni: they promised to share the presentation and example code. I will check if they have sent any email

vijendar: btw, currently when we deploy an app, the state of the workflow is 'READY' .. I remember you were thinking of changing this to 'DEPLOYMENT_COMPLETE'

do you have a bug for that?

devkulkarni: I think did not move the github related code to new app commands

devkulkarni: yes. I think I have that bug with me

vijendar: oh okay.. that means we cannot yet delete the OldAppCommands

devkulkarni: yeah.

I think we should create a bug to move the github stuff from OldAppCommand to AppCommand

sure

devkulkarni: let me know if you want me to create the bug

vijendar: sure

Swati Dewan proposed openstack/solum-dashboard: Get the solum-horizon plugin working again https://review.openstack.org/289021

vijendar: do you remember any other outstanding bugs that we need to file and work on?

pt_15: what did openstack-infra folks say?

devkulkarni: they said i needed to change the hacking file being used, the version i had been using was the old one

hacking file?

umm, the hacking folder, which i think checks the requirements, not sure what it really does....

pt_15: you mean this https://github.com/openstack/solum-dashboard/bl... ?

yeah

pt_15: which hacking folder? there is no hacking folder in: https://github.com/openstack/solum-dashboard

yeah, i just needed to change the version it looks for to a later version

currently it uses 0.8.1, which in turn checks for the older pbr versions

I see

i actually changed that and submitted another patch, and now i am getting a different error

pt_15: btw, in addition to openstack-infra, you also want to keep yourself in the loop with horizon folks

pt_15: try to attend their irc meetings to keep yourself in the loop on horizon

devkulkarni: ok, sure! :)

vijendar: just filed this: https://bugs.launchpad.net/solum/+bug/1578275

pt_15: for "#from solumclient.openstack.common.apiclient import exceptions as solumclient" you need to give a space after '#'

same for "#git_url = tables.Column('git_url', verbose_name=_('GitUrl'))"

devkulkarni: yeah, I did that, i was just trying to see what to do for the class errors

ok

Swati Dewan proposed openstack/solum-dashboard: Get the solum-horizon plugin working again https://review.openstack.org/289021

devdatta-kulkarni proposed openstack/solum: Creating single plan per app https://review.openstack.org/312612

vijendar: https://review.openstack.org/#/c/311348/

vijendar: https://review.openstack.org/#/c/306579/

pt_15: looks like there is incompatible requirements issue now

pt_15: "gate-solum-dashboard-requirements http://logs.openstack.org/21/289021/8/check/gat... : Incompatible requirement found; see http://docs.openstack.org/developer/requirements/ in 2m 36s"

hit the 'Toggle CI' button to see it

the only one i can see is actually different is the hacking version

although the logs are showing 3 other requirements as different too

the only difference i can see in those is the added u before the package name

devkulkarni: ^

pt_15: which requirements the logs is showing as different?

python-keystoneclient, pbr, netaddr, pytz, and hacking

for the first 4, its showing an added u in the package strings

so i dont really know if it even is a proble

* problem

how are corresponding values specified for other projects?

they're specified the same way

u is used to specify unicode as far as i know, right?

yes

I suggest checking with the infra team on what might be going on

hmm, ok, i'll check with them then

devkulkarni: posted one comment on https://review.openstack.org/#/c/306579/1 please let me know your thoughts

vijendar: ok, let me take a look

vijendar: so a general problem with using a special string in the value is that we won't be able to create a languagepack by that name.. this affects any value that we select ('false', 'no-languagepack', 'languagepack-not-provided', etc.). probably we should add another field to the app data model to indicate that a lp is not provided instead of re-using the 'languagepack' field.. what do you think?

devkulkarni: you are right. we cannot create languagepack with the special string that we use

yeah.. let me change that patch to use a new field

I will put -1 on both the patches

devkulkarni: but these constants does not seems to be a reasonable name for languagepack

true.. but it will be very easy for someone to exploit

they may create lp with that name and then their app won't build if they are using that lp

what happens if they take advantage of this?

they are shooting in their foot….right?

basically the app build and deploy won't work for them..

right

probably we can have some validation on not allowed languagepack names

that is another option

if we go the validation route, then I think 'false' is better than 'no-languagepack' or 'languagepack-not-provided'

no?

ppl will understand if we say that you cannot name your lp as 'true' or 'false'

as those strings have special meaning

since this is not user visible stuff, I was thinking having no-languagepack as constant makes the code more readable for developers

or we could even make it as 'not-provided'