| *** ozstacker has joined #openstack-community | 00:04 | |
| *** Marga_ has quit IRC | 00:11 | |
| *** Marga_ has joined #openstack-community | 00:13 | |
| *** Marga_ has quit IRC | 00:31 | |
| *** electroc_ has joined #openstack-community | 01:08 | |
| *** electrocucaracha has quit IRC | 01:11 | |
| *** electrocucaracha has joined #openstack-community | 01:12 | |
| *** electroc_ has quit IRC | 01:13 | |
| *** sarob has quit IRC | 01:22 | |
| *** Marga_ has joined #openstack-community | 01:49 | |
| *** annegentle has joined #openstack-community | 02:14 | |
| *** electrocucaracha has quit IRC | 02:18 | |
| *** annegentle has quit IRC | 02:19 | |
| *** sarob has joined #openstack-community | 02:41 | |
| *** sarob has quit IRC | 02:43 | |
| *** sarob_ has joined #openstack-community | 02:45 | |
| *** sarob_ has quit IRC | 02:49 | |
| *** sarob has joined #openstack-community | 03:30 | |
| *** Marga_ has quit IRC | 03:50 | |
| *** Marga_ has joined #openstack-community | 03:50 | |
| *** coolsvap|afk is now known as coolsvap | 04:31 | |
| *** sarob has quit IRC | 04:31 | |
| *** coolsvap is now known as coolsvap|afk | 04:32 | |
| *** mrmartin has joined #openstack-community | 04:44 | |
| *** jcoufal has joined #openstack-community | 05:12 | |
| *** jcoufal has quit IRC | 05:15 | |
| *** rbowen has quit IRC | 05:22 | |
| *** jcoufal has joined #openstack-community | 05:25 | |
| *** rbowen has joined #openstack-community | 05:34 | |
| *** yfauser has joined #openstack-community | 05:58 | |
| *** yfauser has left #openstack-community | 05:59 | |
| *** jtomasek has joined #openstack-community | 06:24 | |
| *** Marga_ has quit IRC | 06:31 | |
| *** jtomasek has quit IRC | 06:44 | |
| *** neeti has joined #openstack-community | 07:00 | |
| *** jcoufal_ has joined #openstack-community | 07:07 | |
| *** jcoufal has quit IRC | 07:11 | |
| *** jcoufal_ has quit IRC | 07:15 | |
| *** jcoufal has joined #openstack-community | 07:15 | |
| *** jcoufal has quit IRC | 07:40 | |
| *** jcoufal has joined #openstack-community | 07:41 | |
| *** GonZo2K has quit IRC | 07:45 | |
| *** jcoufal has quit IRC | 07:45 | |
| *** coolsvap|afk is now known as coolsvap | 07:52 | |
| *** coolsvap is now known as coolsvap|afk | 07:53 | |
| *** jcoufal has joined #openstack-community | 07:54 | |
| *** GonZo2K has joined #openstack-community | 08:01 | |
| *** dizquierdo has joined #openstack-community | 08:04 | |
| *** jtomasek has joined #openstack-community | 08:06 | |
| *** GonZo2K has quit IRC | 09:03 | |
| *** jcoufal_ has joined #openstack-community | 09:10 | |
| *** jcoufal has quit IRC | 09:13 | |
| *** ozstacker has quit IRC | 09:37 | |
| *** ozstacker has joined #openstack-community | 09:38 | |
| *** jcoufal_ is now known as jcoufal | 09:55 | |
| *** mrmartin has quit IRC | 10:21 | |
| *** inhumanitas has left #openstack-community | 10:21 | |
| *** cdent has joined #openstack-community | 10:32 | |
| *** Harry51S has joined #openstack-community | 11:20 | |
| *** dizquierdo has quit IRC | 11:57 | |
| *** mattgriffin has joined #openstack-community | 12:00 | |
| *** mattgriffin has quit IRC | 12:07 | |
| *** mattgriffin has joined #openstack-community | 12:08 | |
| *** mattgriffin has quit IRC | 12:09 | |
| *** cdent has quit IRC | 12:13 | |
| *** cdent has joined #openstack-community | 12:14 | |
| *** GonZo2K has joined #openstack-community | 12:18 | |
| *** GonZo2K has quit IRC | 12:18 | |
| *** GonZo2K has joined #openstack-community | 12:18 | |
| *** dizquierdo has joined #openstack-community | 12:21 | |
| *** neeti_ has joined #openstack-community | 12:37 | |
| *** neeti has quit IRC | 12:38 | |
| *** tiswanso has joined #openstack-community | 12:40 | |
| *** tiswanso has quit IRC | 12:45 | |
| *** tiswanso has joined #openstack-community | 12:47 | |
| *** tiswanso_ has joined #openstack-community | 12:51 | |
| *** tiswanso has quit IRC | 12:52 | |
| *** sarob has joined #openstack-community | 13:09 | |
| *** Marga_ has joined #openstack-community | 13:14 | |
| *** sarob has quit IRC | 13:20 | |
| *** sarob has joined #openstack-community | 13:22 | |
| *** annegentle has joined #openstack-community | 13:22 | |
| *** neeti_ has quit IRC | 13:27 | |
| *** mattgriffin has joined #openstack-community | 13:34 | |
| *** Marga_ has quit IRC | 13:52 | |
| *** sarob has quit IRC | 14:30 | |
| *** Marga_ has joined #openstack-community | 14:34 | |
| *** Marga_ has quit IRC | 14:36 | |
| *** Marga_ has joined #openstack-community | 14:37 | |
| *** sarob has joined #openstack-community | 14:52 | |
| *** sarob has quit IRC | 14:58 | |
| *** sarob has joined #openstack-community | 15:00 | |
| *** Marga_ has quit IRC | 15:13 | |
| *** Marga_ has joined #openstack-community | 15:13 | |
| *** electrocucaracha has joined #openstack-community | 15:15 | |
| *** Marga_ has quit IRC | 15:18 | |
| *** dizquierdo has quit IRC | 15:21 | |
| *** mwagner_lap has quit IRC | 16:31 | |
| *** jcoufal has quit IRC | 16:41 | |
| *** yfauser has joined #openstack-community | 16:57 | |
| *** yfauser has left #openstack-community | 16:57 | |
| *** GonZo2K has quit IRC | 17:07 | |
| *** Youcef has joined #openstack-community | 17:09 | |
| *** yfauser has joined #openstack-community | 17:15 | |
| *** yfauser has left #openstack-community | 17:16 | |
| *** GonZo2K has joined #openstack-community | 17:45 | |
| *** GonZo2K has quit IRC | 17:45 | |
| *** GonZo2K has joined #openstack-community | 17:45 | |
| *** annegent_ has joined #openstack-community | 17:46 | |
| *** annegentle has quit IRC | 17:50 | |
| *** jehb has quit IRC | 18:11 | |
| *** mrmartin has joined #openstack-community | 18:25 | |
| *** cdent has quit IRC | 18:27 | |
| reed | mrmartin, hello | 18:30 |
|---|---|---|
| mrmartin | hi | 18:30 |
| reed | mrmartin, did you see the comment from fungi and clark? | 18:30 |
| mrmartin | on which review? the pinning one? | 18:30 |
| reed | since now openid by google is gone, we have already ran out of time | 18:30 |
| reed | yes, pinning | 18:30 |
| reed | we missed the deadline, we're late and I'm not happy :( | 18:31 |
| mrmartin | yeah, I saw it, they want to create a separate branch | 18:31 |
| mrmartin | which deadline? | 18:31 |
| reed | the advantage is that once there is a feature branch they don't need to approve every change | 18:31 |
| reed | the deadline for upgrading askbot to a release that supports migration of users from openid google to oauth | 18:32 |
| mrmartin | where was that deadline written? | 18:33 |
| reed | I didn't make it clear enough that pinning the theme was time sensitive | 18:33 |
| reed | you I and evgeny talked about upgrading askbot as soon as possible, but I don't think I nor Evgeny conveyed effectively the urgency of that upgrade | 18:34 |
| mrmartin | Yeah, basically my problem here, that the patch was there since april 7 | 18:34 |
| reed | exactly | 18:35 |
| reed | i never ever thought that a ridicoulously simple patch would be debated for so long | 18:35 |
| mrmartin | today is april 23, everybody saw the changeset, and we got this two very interesting comments | 18:35 |
| mrmartin | anyway | 18:35 |
| mrmartin | I'm working on this askbot-staging patchset too, and I was talking with Jeremy and Clarkb yesterday and the day before, | 18:35 |
| reed | not only that, but jeremy was on the meeting and he may have been the one suggesting to pin to a commit | 18:36 |
| reed | just a quick and dirty hack in order to upgrade | 18:36 |
| mrmartin | how we can do the seamless upgrade between the actuall askbot-puppet that deploys from pip directly | 18:36 |
| reed | mrmartin, so now, let's forget about the deadline, we're screwing google users for a while... | 18:36 |
| mrmartin | and the new askbot-puppet that can brake interface compatibility and deploys askbot-puppet from git repositories | 18:37 |
| reed | can you quickly send a second patchset with the feature branch thing or shall I insist on just merging that now and you'll fix that later? | 18:37 |
| mrmartin | let's accept this theme pinning | 18:38 |
| mrmartin | I don't feel that it is so serious thing that infra cannot approve | 18:38 |
| mrmartin | if we are rolling out the askbot-staging, at one point we need also upgrade the ask.o.o to this model | 18:39 |
| reed | they're concerned that they'll have to approve yet another pinning in two weeks and then another and another | 18:39 |
| mrmartin | askbot-staging won't contain this pinning thing | 18:39 |
| mrmartin | and if we roll out this github based model to ask.o.o we'll avoid this pinning again | 18:40 |
| reed | because the theme will be imported differently? | 18:40 |
| mrmartin | anyway we are doing the same for openstackid releases, and it was not a conern there | 18:40 |
| mrmartin | yes, because we need to deploy from github repository, and it is totally different, because pip downloads a lot of dependencies | 18:41 |
| mrmartin | and repo upgrades both from askbot-devel and askbot-theme must trigger a site structure rebuild | 18:41 |
| mrmartin | so it is different | 18:42 |
| mrmartin | and pip deployment also seems to be broken for me, I was testing that locally, and it had some dependency problem, I need to recheck whether it was a network connectivity issue or something else | 18:43 |
| mrmartin | clark's notice sounds great, if we are following a single project, but the askbot-devel is out of infra | 18:44 |
| mrmartin | and we cannot do gating there | 18:44 |
| reed | what do you mean? | 18:45 |
| reed | oh, I see | 18:45 |
| mrmartin | that is the core of the problem, that we have a wonderful CI/CD system, but if a project lives outside our infra | 18:45 |
| mrmartin | we cannot trigger events, do gating | 18:45 |
| mrmartin | so on an usual project clarkb's arguments are perfect, but this askbot is a very special case | 18:46 |
| mrmartin | we are consuming software from two different source, where we don't have a control over the testing / gating | 18:47 |
| mrmartin | and any change in both source must trigger a complete rebuild of the django stack | 18:47 |
| mrmartin | using prepackaged softwares from a debian repository can be an ultimate solution here, but we don't have the processes and packaging system for that | 18:48 |
| *** clarkb has joined #openstack-community | 18:49 | |
| clarkb | reed: hi | 18:49 |
| mrmartin | hi clarkb | 18:49 |
| *** fungi has joined #openstack-community | 18:49 | |
| reed | clarkb, we were talking about the packaging of askbot-theme and askbot-devel | 18:49 |
| reed | i think you and mrmartin spoke already about askbot-staging | 18:50 |
| clarkb | re 171066, if we use a feature branch we can abandon that change. The process would instead be: make feature branch called something like feature/new-theme, continue to deploy theme from master so do not push any breaking changes there, instead push new theme updates that are problematic to feature/new-theme, when feature/new-theme is ready merge it to master and it will be automatically deployed | 18:50 |
| clarkb | this way you do not need any infra changes to get the work done | 18:50 |
| clarkb | and if you find bugs on the old theme you can still address them by making changes to master | 18:50 |
| mrmartin | ok, but first we need to solve the askbot-staging instance | 18:51 |
| fungi | the concern which has been expressed on 171066 is mainly that it encourages having a master branch which is not actually usable, but also any time you want to change what version you've pinned to it'e yet another review against the system-config repo for the infrastructure core reviewers to need to review | 18:51 |
| mrmartin | tagging the repos, and consuming tagged versions could solve that issue | 18:52 |
| reed | the other problem I see is teaching Evgeny that he has to avoid using master | 18:52 |
| fungi | why would pushing new commits to a feature branch need askbot-staging to exist when 171066 doesn't? | 18:52 |
| mrmartin | we are using that model for groups.o.o | 18:52 |
| reed | I think he has +2+w rights on that repo | 18:52 |
| mrmartin | fungi: because I think we need to test those changes somewhere, on a staging server | 18:53 |
| fungi | mrmartin: and pushing them to master doesn't have that same need? | 18:53 |
| mrmartin | and if everything is perfect there, we can roll out a new release, that can be deployed to production | 18:53 |
| reed | I marton and Evgeny have core status on that project | 18:54 |
| mrmartin | so the model is this: dev -> master branch / production -> tagged version | 18:54 |
| fungi | the risk with deploying tags from master is that you'll ultimately need branches anyway, because you're likely to get yourself into a state where master is an unusable work-in-progress and you need to backport a fix of some sort to production, which either means reverting everything on master so you can push and tag your trivial fix, or having a branch for production (master?) and a different | 18:54 |
| fungi | branch for development (feature/something?) | 18:54 |
| clarkb | yes we ran into this with pbr pretty badly | 18:55 |
| clarkb | and I would like to avoid it in the future with other projects as much as possible | 18:55 |
| mrmartin | ok. | 18:55 |
| clarkb | (we broke master but then had to release to fix other bugs so ended up branching anyways) | 18:55 |
| mrmartin | if we are open a new branch for development, what is the proper way to send patches into that specific branch? | 18:56 |
| clarkb | mrmartin: `git review $branchname` you can also edit the .gitreview file on that branch to make it push to that branch by default | 18:56 |
| mrmartin | so, if I understand, than master branch is the production one, and feature/something dedicated for development | 18:57 |
| fungi | right. and clarkb or i can go create that feature branch right now, whatever name you want it to have | 18:57 |
| mrmartin | ok, but with feature branches, if we like to maintain a staging server, we need to introduce a staging branch too? | 18:57 |
| fungi | only takes a second and you're off to the races | 18:57 |
| fungi | mrmartin: you could, or you could just deploy the feature branch on your staging server | 18:58 |
| clarkb | mrmartin: no, I think we can just deploy the staging server off of the feature branch? | 18:58 |
| mrmartin | or we need to use a single branch dedicated for all development things | 18:58 |
| mrmartin | ok, but how do you select which feature branch the staging server need consume? | 18:58 |
| clarkb | whichever is most appropriate, like the branch for the new theme | 18:59 |
| fungi | ahh, you're asking in the event you have more than one feature branch. i would probably just stick with one long-lived feature branch in this case and not bother getting rid of it. just merge to and from it as appropriate once it's tested the ways you want (e.g. on the staging server or whatever) | 18:59 |
| mrmartin | ok, but I have a system-config for staging server, where I need to set which will be the proper git branch I like to deploy | 18:59 |
| mrmartin | fungi: exactly | 18:59 |
| mrmartin | it'll mean a system-config change too | 18:59 |
| reed | askbot doesn't even have proper versioning | 18:59 |
| mrmartin | reed, yeah, but we are on it | 19:00 |
| clarkb | mrmartin: yes ut its a one time change unlike the current proposal which requires changes each time you wantto update the theme | 19:00 |
| mrmartin | clarkb: I don't get the difference | 19:00 |
| mrmartin | imagine that, askbot is working on multiple features | 19:00 |
| clarkb | mrmartin: the difference is the reviewers for system-config don't need to be in the pipeline for typical theme updates | 19:00 |
| clarkb | mrmartin: instead you would just merge to master and it would automatically get deployed | 19:00 |
| fungi | mrmartin: what i'm suggesting, and what i think clarkb is suggesting, is not to do development in lots of feature branches. just keep one called feature/development or feature/next or something | 19:01 |
| clarkb | (or merge to the feature branch in the case of staging) | 19:01 |
| mrmartin | so for this branching model we have a master for production, and need feature/development | 19:01 |
| clarkb | yup | 19:01 |
| reed | i think I understand the difference: you always deploy from master, so you merge the feature branch in master and you're done | 19:01 |
| mrmartin | ok. so we can agree, that we have a master branch for production | 19:01 |
| reed | no waiting for system-config change to review | 19:01 |
| fungi | right, and forward-port production fixes into the feature/development branch as needed | 19:01 |
| fungi | so that you don't end up with regressions in your featu5re branch | 19:02 |
| mrmartin | and we have a staging branch dedicated for staging sizes | 19:02 |
| mrmartin | sites | 19:02 |
| reed | the issue then is education for core *not* to merge in master | 19:02 |
| mrmartin | so if somebody like to merge a feature branch, first he need to merge into staging one | 19:02 |
| reed | until the features are tested | 19:02 |
| mrmartin | and if everything seems to be perfect, then merge to master, right? | 19:02 |
| clarkb | mrmartin: or you can direct deploy staging from the feature ranch then when you are happy with staging merge feature into master | 19:03 |
| mrmartin | ok. | 19:03 |
| mrmartin | it is a bit simpler | 19:03 |
| fungi | well, i don't think you even need a staging branch separate from feature/development necessarily. if your proposed changes to feature/development in gerrit are well tested then they're unlikely to break staging, and if they do break staging, you just put up a fix for that | 19:03 |
| clarkb | fungi: yup | 19:03 |
| mrmartin | so a two branch model | 19:03 |
| *** mwagner_lap has joined #openstack-community | 19:03 | |
| reed | since we'll be rolling updates to theme, I suggest the name of the feature to be feature/asktheme-dev or something | 19:03 |
| mrmartin | so you release from staging | 19:04 |
| fungi | right, release from staging by merging it to master | 19:04 |
| fungi | once you're satisfied it's working the way you want | 19:04 |
| mrmartin | what is the difference between master/HEAD and tagging for prod? | 19:05 |
| clarkb | mrmartin: if you tag for prod then each new tag has to be specifically added as a system-config change | 19:05 |
| fungi | you could also tag that merge commit to add versioning in git that way if you wanted | 19:05 |
| fungi | and just not rely on that for deployment automation | 19:05 |
| fungi | simply as informational metadata | 19:06 |
| reed | system-config changes are painful so less of them is good | 19:06 |
| clarkb | this is similar to how we deploy zuul and nodepool | 19:06 |
| clarkb | except we don't use a branch we just always roll forwrad in a working state (thats the goal at least) | 19:06 |
| reed | I think an educational article here, with pictures, would be good | 19:06 |
| mrmartin | ok, my question here, the actual askbot.o.o relies on a pip askbot package and the askbot-theme git master branch | 19:07 |
| mrmartin | so we need to ask Evgeny to follow our new branching model | 19:07 |
| reed | yes | 19:07 |
| mrmartin | and create this staging branch for both askbot-devel and askbot-theme | 19:07 |
| reed | i'll remove his rights to askbot-theme-core | 19:08 |
| *** Youcef has quit IRC | 19:08 | |
| mrmartin | why do you like to remove his rights? | 19:08 |
| reed | just in case | 19:08 |
| reed | :) | 19:08 |
| mrmartin | we need to let him commit into the staging branch | 19:08 |
| reed | no, I'll call a meeting to educate him | 19:08 |
| mrmartin | ok. | 19:08 |
| mrmartin | so the actions here: | 19:08 |
| mrmartin | 1. create the staging branch for askbot-theme | 19:09 |
| fungi | _if_ you decide it's necessary, we can separately control who can approve changes to the feature branch vs master, and who can propose merge commits from the feature branch to master for more fine-grained access | 19:09 |
| mrmartin | 2. create the staging branch for askbot-devel | 19:09 |
| mrmartin | my concern here, that askbot-devel lives at Evgeny's separate github repository | 19:09 |
| mrmartin | and we don't have control on that | 19:09 |
| clarkb | mrmartin: I don't think askbot-devel needs to follow the same process | 19:09 |
| clarkb | this is purely for the repo we do control | 19:10 |
| fungi | the bigger issue with askbot-devel is that i guess he's not doing releases consistently? | 19:10 |
| mrmartin | the plan that we like to rolling upgrade the askbot-devel in the same way | 19:10 |
| reed | for askbot-devel we pin to what we prefer in our puppet-askbot manifests, right? | 19:10 |
| mrmartin | he is adding patches constantly | 19:10 |
| mrmartin | reed: no, it is a system-config setting | 19:10 |
| reed | fungi, right, that's the issue there | 19:11 |
| fungi | does he release from askbot-devel in some way once it's tested/ready? | 19:11 |
| reed | fungi, I have the impression he can be taught how to do a proper release | 19:11 |
| mrmartin | https://github.com/openstack-infra/puppet-askbot/blob/master/manifests/init.pp#L18 | 19:11 |
| reed | but it'll take time and an investment in education on our side | 19:11 |
| mrmartin | ok, it's a puppet-askbot, but if we follow the proper patterns, we need to move to ask.pp in system-config | 19:12 |
| fungi | we could also consider having the askbot-theme source embed an askbot-devel git ref with which it should be deployed, and then have the deployment tooling key off that | 19:12 |
| mrmartin | so we need to change the whole deployment model for ask.o.o too | 19:12 |
| clarkb | I don't think we do | 19:13 |
| clarkb | askbot is independent | 19:13 |
| clarkb | we aer not the upstream, we can deal with the upstream's release model as appropriate | 19:13 |
| clarkb | but for projects where we are the upstream we can make a release model that makes sense for ease of deployment | 19:13 |
| mrmartin | ok, but if he need to change anything for a new feature or theme, that affects upstream | 19:13 |
| mrmartin | than he need to do a full pip release | 19:13 |
| mrmartin | for example, adding openstackid auth to askbot | 19:14 |
| mrmartin | we need to propagate those changes into askbot-staging.o.o | 19:14 |
| mrmartin | and for that, we need to consume askbot-devel and theme from git, together | 19:15 |
| clarkb | ya so I think for asbot-staging we can consume latest and greatest. If it breaks we work with upstream to fix it | 19:15 |
| clarkb | then for ask.o.o we deploy specific versions that make everyone happy (assuming that is the upstream release model) | 19:15 |
| mrmartin | so it is much better to change the deployment model of ask.o.o to consume both askbot-theme and askbot-devel directly from git | 19:15 |
| reed | from master you mean? | 19:16 |
| mrmartin | yes | 19:16 |
| mrmartin | but we need to ask Evgeny to follow our release model for whole ask-devel repo | 19:16 |
| reed | and that's the point of the feature branch, right? | 19:16 |
| mrmartin | yes | 19:16 |
| reed | ok, we're getting there | 19:16 |
| reed | :) | 19:16 |
| mrmartin | and that way, we can avoid system-config changes, and version pining | 19:16 |
| mrmartin | we need to write it down somewhere | 19:17 |
| reed | i'll give it a shot | 19:17 |
| mrmartin | we've this openstackid etherpad somewhere | 19:17 |
| reed | i'm calling for a meeting with evgeny on Monday | 19:17 |
| mrmartin | not askbot etherpad | 19:17 |
| reed | meanwhile, please review and merge https://review.openstack.org/#/c/176624/ | 19:17 |
| reed | it's urgent | 19:18 |
| mrmartin | my only concern, that new puppet-askbot that support the consume of git, will break the compatibility of actual one | 19:18 |
| mrmartin | the other thing, that Evgeny need properly handle the requirements.txt | 19:19 |
| mrmartin | and enlist all of required python lib dependencies | 19:19 |
| mrmartin | because a lot of thing is missing | 19:20 |
| *** jtomasek has quit IRC | 19:20 | |
| mrmartin | reed: I'm not a core on 176624, so I gave a +1 | 19:20 |
| reed | right, there are issues with his approach, we'll have to spend time to educate him | 19:20 |
| reed | why are you not core there? | 19:21 |
| mrmartin | because it is tied to infra | 19:21 |
| mrmartin | I'm not an infra core | 19:21 |
| reed | ah, right | 19:21 |
| reed | clarkb, fungi: can you please review and approve https://review.openstack.org/#/c/176624/? there is a critical bug (prevents one user from logging in the site) | 19:22 |
| mrmartin | https://etherpad.openstack.org/p/askbot-integration | 19:23 |
| clarkb | reed: mrmartin in that table only LP is allowed which is openid | 19:23 |
| clarkb | what is the distinction there? | 19:23 |
| reed | clarkb, there is a different module for launchpad | 19:23 |
| clarkb | sure but if only launchpad is allowed then how does adding openid help? | 19:24 |
| reed | launchpad is *only* launchpad, openid is generic enter your url | 19:24 |
| mrmartin | we'll mess up user accounts :) | 19:24 |
| reed | ok, wait a sec | 19:24 |
| clarkb | maybe I need more background on what is broken | 19:24 |
| reed | check the bug | 19:24 |
| reed | check what Evgeny suggested to fix the issue | 19:25 |
| reed | if we still have the old machine up, check how the config is there | 19:25 |
| clarkb | the bug doesn't help me | 19:25 |
| clarkb | only launchpad is allowed so how did they ever login with a non lp user before? | 19:25 |
| fungi | apparently this was a regression | 19:25 |
| clarkb | I guess thats my question | 19:26 |
| reed | clarkb, because in the old site openid was working | 19:26 |
| clarkb | oh I thought we specifically made that one single sign on | 19:26 |
| reed | I could enable and disable via the settings | 19:26 |
| fungi | nope, it's multi-signin already | 19:26 |
| clarkb | gah | 19:26 |
| mrmartin | maybe a missing dependency? | 19:26 |
| reed | on the UI | 19:26 |
| clarkb | I thought we weren't going to allow that anywhere bceause it leads to these problems | 19:26 |
| mrmartin | fungi: we need to diff installed pip packages | 19:26 |
| reed | fungi, i don't udnerstand. Did you check the old machine? | 19:26 |
| mrmartin | pip freeze on both new and old server | 19:26 |
| clarkb | (as a user I hate that I can never remember whichopenid I used so then end up having 10 accounts on a service) | 19:27 |
| mrmartin | migrate everyone to openstackid o.o profile | 19:27 |
| fungi | reed: no, surmising because the bug reporter claims they were previously able to log in with a freeform openid url | 19:27 |
| reed | clarkb, askbot was born with multiple sources of identities | 19:27 |
| clarkb | reed: when I was told to spin one up many months ago requirement 1 was LP openid login only | 19:28 |
| fungi | yeah, right now when i go to the login page my options are yahoo and launchpad | 19:28 |
| clarkb | I guess that changed | 19:28 |
| reed | i'm assuming that the configuration was copied over differently | 19:28 |
| clarkb | but if this is a regression I will approve the puppet change | 19:28 |
| fungi | google was there at one point as well, but when google dropped openid support that was removed i think | 19:28 |
| mrmartin | As I remember, I made the template from original config of the old server | 19:28 |
| reed | i disabled Google today because we failed to upgrade Askbot in time before GOogle disabled openid | 19:29 |
| reed | we now have many users who cannot login anymore | 19:29 |
| clarkb | mrmartin: ya I am pretty sure it was LP only at one point but that may have changed? in any case fix is approved | 19:29 |
| reed | thanks clarkb, let's hope it fixes the issue | 19:29 |
| mrmartin | let's try to approve the fix, if it won't work, then it can be a missing dependency issue | 19:29 |
| fungi | i believe the reason it ended up not being lp-only was to encourage people to participate more freely without needing an lp account | 19:29 |
| clarkb | fungi: and now they don't have working accounts because google gonna google | 19:30 |
| fungi | indeed | 19:30 |
| reed | yeah | 19:30 |
| fungi | pypi has been dealing with similar madness | 19:30 |
| fungi | because they allowed google logins to pypi.python.org but only had openid support for that | 19:31 |
| reed | I was told I would have had openstackid for askbot a lot earlier than it actually shipped | 19:31 |
| reed | eventually, we'll have to migrate all of them to our and be over with google | 19:31 |
| mrmartin | we still don't have openstackid support there, right? | 19:31 |
| reed | mrmartin, next thing in line | 19:31 |
| clarkb | we should once openid is enabled right? | 19:31 |
| clarkb | just type in the openid path | 19:31 |
| mrmartin | I still not see, what is the proper way of migrate users between different auth systems | 19:31 |
| fungi | mrmartin: it varies a lot depending on the system | 19:32 |
| mrmartin | :) | 19:32 |
| mrmartin | same email address? | 19:32 |
| reed | clarkb, when I tried with the old server that didnt'w rok | 19:32 |
| fungi | there is no one clean way | 19:32 |
| mrmartin | it's a trap | 19:32 |
| reed | ok, I have to move on to another task | 19:33 |
| clarkb | this is actually one of the nice features of mozillas persona thing iirc | 19:33 |
| reed | are we good with the feature branch? | 19:33 |
| clarkb | you have all of the private side data for auth and you own it | 19:33 |
| clarkb | so you end up with a single identity that is usedeverywhere | 19:33 |
| clarkb | rather than multiple identities proxied by multiple services | 19:33 |
| fungi | what name did we pick for it? feature/development? i'll create it right now and get the acl update in | 19:33 |
| reed | feature/development sounds good | 19:34 |
| mrmartin | fungi: can you override the .gitreview file too? | 19:34 |
| fungi | mrmartin: sure. i'll propose that first thing | 19:34 |
| mrmartin | to tie the commits to feature/development branch? | 19:34 |
| mrmartin | and can we prevent somehow the commits into master? | 19:34 |
| mrmartin | or changing .gitreview is enough here? | 19:35 |
| clarkb | mrmartin: .gitreview should be enough for anyone using git review | 19:35 |
| fungi | well, you prevent them by not approving then, but we can also change who's able to approve commits to master if you want | 19:35 |
| mrmartin | ok. | 19:35 |
| clarkb | mrmartin: if you get any stray changes on master you can abandon or -2 them | 19:35 |
| mrmartin | yes | 19:35 |
| fungi | clarkb: what's the trick for avoiding merging the modified .gitreview file from the feature branch into master, out of curiosity? | 19:36 |
| clarkb | fungi: I think it shows up as a merge conflict? | 19:36 |
| clarkb | its a good question | 19:36 |
| mrmartin | ;) | 19:37 |
| notmyname | `git checkout master -- .gitreview && git commit --amend` is what I do | 19:37 |
| notmyname | for the merge commit | 19:37 |
| fungi | notmyname: awesome--thanks! | 19:37 |
| fungi | we should probably update our feature branch instructions in the infra manual with that tip | 19:37 |
| mrmartin | yeap | 19:38 |
| mrmartin | and update in our heads | 19:38 |
| fungi | mrmartin: https://review.openstack.org/176954 is the .gitreview change | 19:39 |
| fungi | i'll have the acl and gerritbot addition for this up momentarily | 19:39 |
| notmyname | a git alias for "amend = commit --amend" (so that you can do `git amend`) is also really handy. makes common errors like `git commit -amend` not happend (which will commit every modified file and give it the commit message "end") | 19:40 |
| fungi | oh, yeah _that's_ a rather nasty typo | 19:40 |
| *** annegent_ has quit IRC | 19:40 | |
| clarkb | ha | 19:40 |
| mrmartin | notmyname: argh | 19:40 |
| mrmartin | similare to rm -rf/ | 19:41 |
| *** annegentle has joined #openstack-community | 19:41 | |
| mrmartin | ok, so we need to ask Evgeny to setup the same branching model, and follow the merging policy for releases | 19:41 |
| fungi | mrmartin: https://review.openstack.org/176958 is the merge commit support patch. when that lands i'll add you to the new askbot-theme-release group for that | 19:45 |
| mrmartin | fungi: thnx. | 19:46 |
| fungi | just need to start being careful to not accidentally push merge commits for review (though if you do accidentally, they should be easy to spot--just don't approve them if they're an accident!) | 19:47 |
| mrmartin | yeah, need to learn that | 19:47 |
| *** jtomasek has joined #openstack-community | 19:48 | |
| reed | mrmartin, i'm writing to Evgeny telling him about the feature branch and calling a meeting on Monday (on our scheduled meeting, 10am PDT) | 19:53 |
| mrmartin | ok, great, and I'm working on this askbot-puppet module that is based on git repos using this new branching model | 19:54 |
| *** Harry51S has quit IRC | 19:54 | |
| reed | BTW, OpenID now works | 20:00 |
| reed | but when trying to use openstakcid, i still get "OpenID https://openstackid.org/stefano.maffulli is invalid" | 20:01 |
| reed | oh well... it should work now | 20:01 |
| mrmartin | eh | 20:06 |
| reed | we'll debug openstackid integration another time, that's what I mean | 20:10 |
| *** cdent has joined #openstack-community | 20:18 | |
| *** mrmartin has quit IRC | 20:25 | |
| *** electrocucaracha has quit IRC | 20:43 | |
| *** electrocucaracha has joined #openstack-community | 20:58 | |
| *** sarob has quit IRC | 20:59 | |
| *** tiswanso_ has quit IRC | 20:59 | |
| *** annegentle has quit IRC | 21:15 | |
| *** annegentle has joined #openstack-community | 21:20 | |
| *** cdent has quit IRC | 21:22 | |
| *** annegentle has quit IRC | 21:44 | |
| *** jtomasek has quit IRC | 21:53 | |
| *** Guest47750 has joined #openstack-community | 22:03 | |
| *** openstackstatus has quit IRC | 22:09 | |
| *** electrocucaracha has quit IRC | 22:11 | |
| *** electrocucaracha has joined #openstack-community | 22:23 | |
| *** Guest47750 has quit IRC | 22:44 | |
| *** annegentle has joined #openstack-community | 23:03 | |
| *** annegentle has quit IRC | 23:14 | |
| *** mattgriffin has quit IRC | 23:28 | |
| *** julim has quit IRC | 23:28 | |
| *** Marga_ has joined #openstack-community | 23:38 | |
| *** electrocucaracha has quit IRC | 23:54 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!