| *** annegentle has joined #openstack-community | 00:16 | |
| *** annegentle has quit IRC | 00:22 | |
| *** sarob has joined #openstack-community | 00:28 | |
| *** sarob has quit IRC | 00:28 | |
| *** sarob has joined #openstack-community | 00:28 | |
| *** tiswanso has joined #openstack-community | 00:55 | |
| *** tiswanso has quit IRC | 00:56 | |
| *** annegentle has joined #openstack-community | 00:57 | |
| *** tiswanso has joined #openstack-community | 00:57 | |
| *** Marga_ has quit IRC | 01:19 | |
| *** Marga_ has joined #openstack-community | 01:20 | |
| *** annegentle has quit IRC | 01:22 | |
| *** annegentle has joined #openstack-community | 01:52 | |
| *** annegentle has quit IRC | 02:24 | |
| *** Marga_ has quit IRC | 02:26 | |
| *** Marga_ has joined #openstack-community | 02:26 | |
| *** Marga_ has quit IRC | 02:31 | |
| *** coolsvap|afk is now known as coolsvap | 04:00 | |
| *** sarob has quit IRC | 04:00 | |
| *** tiswanso has quit IRC | 04:01 | |
| *** yfauser has joined #openstack-community | 04:25 | |
| *** yfauser has left #openstack-community | 04:26 | |
| *** yfauser has joined #openstack-community | 04:32 | |
| *** yfauser has left #openstack-community | 04:32 | |
| *** sarob has joined #openstack-community | 04:36 | |
| *** sarob has quit IRC | 04:41 | |
| *** neeti has joined #openstack-community | 04:41 | |
| *** mrmartin has joined #openstack-community | 05:07 | |
| *** jcoufal has joined #openstack-community | 05:59 | |
| *** sarob has joined #openstack-community | 06:25 | |
| *** teh_slack has quit IRC | 06:29 | |
| *** sarob has quit IRC | 06:29 | |
| *** teh_slack has joined #openstack-community | 06:31 | |
| *** mrmartin has quit IRC | 06:42 | |
| *** mrmartin has joined #openstack-community | 08:27 | |
| *** dizquierdo has joined #openstack-community | 08:40 | |
| *** cdent has joined #openstack-community | 08:40 | |
| *** jtomasek has joined #openstack-community | 08:53 | |
| *** pcaruana has joined #openstack-community | 09:17 | |
| *** coolsvap is now known as coolsvap|afk | 09:18 | |
| *** coolsvap|afk is now known as coolsvap | 09:24 | |
| *** kristian1 has joined #openstack-community | 09:36 | |
| *** jcoufal has quit IRC | 10:04 | |
| *** coolsvap is now known as coolsvap|afk | 10:06 | |
| *** neeti has quit IRC | 10:10 | |
| *** neeti has joined #openstack-community | 10:16 | |
| *** kristian1 has left #openstack-community | 10:26 | |
| *** jcoufal has joined #openstack-community | 10:29 | |
| *** neeti has quit IRC | 10:30 | |
| *** jcoufal has quit IRC | 10:36 | |
| *** neeti has joined #openstack-community | 10:55 | |
| *** mrmartin has quit IRC | 11:27 | |
| *** hogepodge has quit IRC | 11:47 | |
| *** hogepodge has joined #openstack-community | 12:04 | |
| *** neeti has quit IRC | 12:24 | |
| *** rbowen has joined #openstack-community | 12:28 | |
| *** sarob has joined #openstack-community | 12:34 | |
| *** neeti has joined #openstack-community | 12:36 | |
| *** sarob has quit IRC | 12:39 | |
| *** sarob has joined #openstack-community | 12:58 | |
| *** tiswanso has joined #openstack-community | 13:09 | |
| *** neeti has quit IRC | 13:15 | |
| *** jcoufal has joined #openstack-community | 13:48 | |
| *** sarob has quit IRC | 13:56 | |
| *** pcaruana has quit IRC | 14:17 | |
| *** electrocucaracha has joined #openstack-community | 14:20 | |
| *** jcoufal has quit IRC | 14:26 | |
| *** jcoufal has joined #openstack-community | 14:27 | |
| *** jcoufal has quit IRC | 14:29 | |
| *** electrocucaracha has quit IRC | 14:48 | |
| *** electrocucaracha has joined #openstack-community | 14:48 | |
| *** Piet has quit IRC | 14:51 | |
| *** jcoufal has joined #openstack-community | 14:54 | |
| *** mrmartin has joined #openstack-community | 15:01 | |
| *** jcoufal has quit IRC | 15:06 | |
| *** sarob has joined #openstack-community | 15:16 | |
| *** cdent has quit IRC | 15:18 | |
| *** cdent has joined #openstack-community | 15:18 | |
| *** jtomasek has quit IRC | 15:47 | |
| *** Marga_ has joined #openstack-community | 15:53 | |
| *** Marga_ has quit IRC | 15:53 | |
| *** Marga_ has joined #openstack-community | 15:54 | |
| *** dizquierdo has quit IRC | 16:11 | |
| *** Evgeny has joined #openstack-community | 16:27 | |
| *** sarob has quit IRC | 16:30 | |
| mrmartin | er | 16:30 |
|---|---|---|
| mrmartin | reed | 16:31 |
| reed | hi mrmartin | 16:32 |
| mrmartin | hi | 16:32 |
| mrmartin | meeting? | 16:32 |
| reed | yes, and Evgeny is also here, I see | 16:32 |
| mrmartin | great | 16:33 |
| Evgeny | hello | 16:33 |
| mrmartin | hi | 16:33 |
| mrmartin | so the topic is ask-staging and askbot upgrade | 16:33 |
| reed | alright, so we have a few topics to cover | 16:33 |
| reed | damn, let me try one thing | 16:33 |
| reed | my irc client is not working properly | 16:33 |
| reed | give me a sec | 16:33 |
| mrmartin | bitchx | 16:34 |
| *** cdent has quit IRC | 16:34 | |
| reed | lets see if this works better | 16:34 |
| reed | no | 16:34 |
| reed | damn | 16:34 |
| reed | ok, i'll make do | 16:34 |
| mrmartin | :) | 16:34 |
| reed | one day I'll convert myself to bitchx | 16:35 |
| reed | let me pull the agenda | 16:35 |
| reed | first thing: there are some small things regarding the new server | 16:35 |
| reed | there are some issues with the avatars | 16:36 |
| reed | and the server was down for about 11 hours yesterday | 16:36 |
| reed | fungi noticed redis eating up all the memory https://review.openstack.org/172105 | 16:37 |
| Evgeny | for that we should upgrade Askbot and theme | 16:37 |
| mrmartin | what it means that it was down? | 16:37 |
| reed | for the avatar stuff, I and evgeny discussed yesterday | 16:37 |
| Evgeny | redis maxmemory setting is not quite faithful | 16:37 |
| Evgeny | you might want to reduce it to maybe 15% of total ram | 16:37 |
| mrmartin | ok, so you made an investiagtion with infra team? | 16:38 |
| reed | fungi did some research | 16:38 |
| mrmartin | ok, I see that | 16:39 |
| mrmartin | what's wrong with the avatars? | 16:39 |
| reed | https://bugs.launchpad.net/openstack-community/+bug/1441398 | 16:40 |
| openstack | Launchpad bug 1441398 in OpenStack Community Project "ask.openstack profile photo is not functional" [High,Confirmed] - Assigned to Evgeny Fadeev (evgeny-fadeev) | 16:40 |
| mrmartin | Evgeny, fungi's patch is increasing the redis maxmemory size to double size | 16:40 |
| reed | avatars are not loaded and the link to upload a picture goes to a non-existent anchor in the faq | 16:40 |
| reed | because I rewrote the faq page :) | 16:40 |
| reed | the faq/help pages are another mess we should discuss at some point | 16:41 |
| mrmartin | "django-avatar lib is likely not installed. At this point better to wait till the upgrade because up to recently avatar library was not from the release. Now there is a new released avatar app and support for it built into askbot" | 16:41 |
| reed | so, the solution to the avatar is to upgrade | 16:41 |
| mrmartin | what we need to upgrade, the whole askbot or just install a django-avatar lib ? | 16:41 |
| Evgeny | to coordinate fix of avatars, firstly I need to update your theme and make Askbot release which supports latest version of the avatar app | 16:41 |
| reed | the whole askbot | 16:41 |
| Evgeny | some changes will be needed in the settings.py file | 16:42 |
| Evgeny | It would be good to have a staging instance | 16:42 |
| reed | mrmartin, how long would it take to setup staging in the same automatic way as groups? | 16:43 |
| mrmartin | yeap, we need some open issues first | 16:43 |
| mrmartin | two major things here: a, packaging of dev snaphosts b, staging those snapshot into a staging server | 16:44 |
| Evgeny | that would be good | 16:44 |
| Evgeny | if the snapshot is copied into the staging server | 16:44 |
| mrmartin | basically, we have a little advantage with groups, because it lives in our git repository, which is well integrated with jenkins jobs | 16:44 |
| Evgeny | and then we test not only the final state after the migration, but also the migration process | 16:44 |
| mrmartin | Evgeny, the question here, how the staging server knows that we have a new dev snapshot | 16:45 |
| reed | Evgeny, how do you usually develop on askbot? do you have dev environment, vagrant machines or something like that? | 16:45 |
| mrmartin | so the first question here, what is the release process of askbot dev? | 16:45 |
| *** cdent has joined #openstack-community | 16:45 | |
| Evgeny | my development environment is very simple | 16:45 |
| mrmartin | the whole release / upgrade automatization based on that | 16:45 |
| reed | mrmartin, maybe you can give an example to Evgeny | 16:46 |
| Evgeny | does not involve virtual machines, etc. | 16:46 |
| mrmartin | we have several options to consider | 16:46 |
| Evgeny | maybe we can have a "staging" branch? | 16:46 |
| mrmartin | the ideal solution: move everything under openstack-infra github | 16:46 |
| Evgeny | on your puppet recipes | 16:46 |
| reed | mrmartin, do you mean keep a fork? | 16:47 |
| mrmartin | Evgeny, usually we just have a master branch, and tagging this branch for releases | 16:47 |
| Evgeny | ok | 16:47 |
| mrmartin | reed: It can be a fork, or can be the origin of development :) | 16:47 |
| mrmartin | or as an alternative, we could setup somehow a sync between the actual askbot repo and our git, but it seems to be a bit complicated | 16:48 |
| reed | sync is complicated | 16:48 |
| Evgeny | well, afaik you've used pip releases of askbot, no? | 16:48 |
| mrmartin | so the root of the problems here, that our git repo is triggering different actions on the build system, invokes gerrit jobs | 16:48 |
| mrmartin | gerrit / jenkins jobs | 16:48 |
| Evgeny | if so, you could stick to marking the release number | 16:48 |
| Evgeny | in the puppet recipes | 16:48 |
| reed | Evgeny, do you publish regularly to pip? | 16:49 |
| Evgeny | alternatively, pin puppet scripts to git repo hashes | 16:49 |
| mrmartin | ok, but doing pip releases for major versions is ok | 16:49 |
| mrmartin | doing pip release snapshot is a question for me | 16:49 |
| reed | if askbot is released regularly and pip-packaged then we can pull from pip | 16:49 |
| Evgeny | reed: it depends | 16:49 |
| Evgeny | last year there was a long gap and all the sites I maintain were off the github | 16:50 |
| reed | got it | 16:50 |
| Evgeny | i.e. last year there was a long wait between the pip releases | 16:50 |
| mrmartin | I guess we need to focus on development and release process first | 16:50 |
| reed | and are you planning on using pip more this year or just tag the git repos with 'stable' branches? | 16:51 |
| Evgeny | and testing of the upgrade I'd think as you have the automatic deployment now | 16:51 |
| Evgeny | reed: Are you asking me regarding the askbot releases? | 16:51 |
| reed | mrmartin, agreed, let's focus on that | 16:51 |
| reed | Evgeny, yes | 16:51 |
| Evgeny | I consider master branch as stable | 16:51 |
| reed | Evgeny, we can adapt based on your ideas, plans, needs | 16:51 |
| Evgeny | it's rarely badly broken as production sites are running right from there | 16:52 |
| reed | so you would say that pulling from trunk/master would give us constantly new features? | 16:52 |
| Evgeny | I would suggest using either git hashes or pip releases in your recipes | 16:52 |
| Evgeny | making releases is very simple | 16:53 |
| Evgeny | the only thing maybe is that possibly it does not make sense to make a pip release way too often | 16:53 |
| Evgeny | reed: yes | 16:53 |
| mrmartin | what I like to avoid, to use a very different staging server from the production one | 16:54 |
| reed | right, like waiting for a set of things to merge and call it a new version | 16:54 |
| mrmartin | so I like to implement a similar deployment model for both instances, because using different methods can be a root of problems we need to resolve in prod later | 16:54 |
| Evgeny | absolutely, especially with the automatic deployment | 16:55 |
| reed | how about we maintain the pip package? | 16:55 |
| Evgeny | which package? | 16:55 |
| reed | pip, we pull from trunk at intervals, when enough new interesting features are ready, build the pip package and upload it | 16:56 |
| mrmartin | ok, from the deployment aspect we need to fetch a versioned distribution somewhere, it can be a pip, git repo, tar.gz etc. | 16:56 |
| reed | and pull back from pip to upgrade staging first and production later | 16:56 |
| Evgeny | have an extra pip repo for Askbot? | 16:56 |
| mrmartin | reed, do you know about a project which is releasing snapshot pip packages? | 16:57 |
| reed | mrmartin, the problem, from what I understand, is that Evgeny doesn't provide those at the moment | 16:57 |
| Evgeny | what is a "snapshot pip package"? | 16:58 |
| reed | Evgeny, I think he means a package pulled from a running master trunk | 16:58 |
| Evgeny | meaning automate the pip releases? | 16:59 |
| mrmartin | what we are doing in our deployment pipeline, that a jenkins job is packaging the git repo master of a project | 16:59 |
| reed | Evgeny, since it seems to me that you're not following a model where you release a "new version", you have more of a 'rolling release' approach | 16:59 |
| mrmartin | and the staging / dev server is fetching those packages. | 16:59 |
| reed | where every commit is a new version | 16:59 |
| Evgeny | I see, honestly I'm not a big fan of this, there will be thousands of versions | 17:00 |
| Evgeny | well, eventually | 17:00 |
| mrmartin | ok, but if we like to test something in a staging are before letting that into production, we need to separate somehow the dev and production versions. | 17:00 |
| reed | we don't have a way to say 'oh, look, askbot is now tagged version 2.3 and we run 2.2, let's pull the new release and run it' | 17:00 |
| mrmartin | so the model is, that you are adding commit A, B, C, D, and if it seems stable, we are tagging this "D" commit, and deploying to prod | 17:01 |
| Evgeny | my preference would be pinning the puppet recipes to specific hash or tags in askbot and theme | 17:01 |
| mrmartin | yeah, but reed, let's storyboard which is not following this staging / prod model, and it have constant issues | 17:01 |
| Evgeny | tags could work | 17:02 |
| mrmartin | let's / let's see | 17:02 |
| Evgeny | meaning git tags | 17:02 |
| *** Youcef has joined #openstack-community | 17:02 | |
| mrmartin | ok, git tags is great for this, we are using that | 17:02 |
| reed | git tags work | 17:02 |
| reed | cool, very cool | 17:02 |
| mrmartin | ok, so you're sending commits to master branch, and if think it is stable, we are tagging that | 17:03 |
| reed | we get closer to a solution | 17:03 |
| *** tiswanso has quit IRC | 17:03 | |
| Evgeny | mrmartin: but how you want to mark the "deployment" releases of the puppet recipes, I think it's more up to you, since the whole process is in your hands | 17:03 |
| mrmartin | the puppet recipe versions handled manually for production | 17:04 |
| * reed goes on to pull the groups example | 17:04 | |
| mrmartin | manually for openstackid | 17:04 |
| mrmartin | but automatized for groups, because jenkins jobs are creating a manifest file with version information. | 17:05 |
| mrmartin | http://tarballs.openstack.org/groups/drupal-updates/release-history/groups/7.x | 17:05 |
| Evgeny | what I could do on my side is to give you info about tags/commit hashes in Askbot and theme, or make a pull request with those to your puppet recipe repo, then you make a "staging release" and test the upgrade | 17:05 |
| mrmartin | and I made a little middleware, that constantly checking the dev release | 17:06 |
| Evgeny | if successful, mark it as a "deployment release" | 17:06 |
| reed | http://git.openstack.org/cgit/openstack-infra/system-config/tree/modules/openstack_project/manifests/groups.pp and http://git.openstack.org/cgit/openstack-infra/system-config/tree/modules/openstack_project/manifests/groups_dev.pp | 17:06 |
| mrmartin | it is very similar for example to debian packages | 17:06 |
| reed | package_branch => 'dev', or package_branch => 'stable', | 17:06 |
| mrmartin | one of my project, we made separate debian packages for development snapshots and have a separate repo for development one | 17:07 |
| mrmartin | production one | 17:07 |
| mrmartin | the difference here, that drupal have a built-in packaging tool that can identify updates based on this manifest file. | 17:07 |
| reed | Evgeny, I think that if you have a predictable way to mark a git repository with a 'new' version, at intervals, we can figure out how to automatically pull from there | 17:08 |
| reed | or semi-automatically | 17:08 |
| *** tiswanso has joined #openstack-community | 17:13 | |
| mrmartin | ok, Evgeny, if you like to keep the development of askbot in-house, why don't you clone the development model of openstack? | 17:13 |
| Evgeny | dunno:) what I have is simple enough a bicycle:) | 17:13 |
| mrmartin | so don't need to reinvent the wheel, and you have all the trigger points that can activate different events, like testing, releasing etc. | 17:13 |
| Evgeny | I'm not familiar with your development model well enough to talk about it right now | 17:13 |
| reed | i get it | 17:13 |
| *** openstack has quit IRC | 17:13 | |
| *** openstack has joined #openstack-community | 17:14 | |
| mrmartin | ok, so we need to reach a solution, where we are getting versioned packages first, and package information (independently of pkg and manifest format) | 17:15 |
| mrmartin | if we have that, we need to provide a deployment model, that deploys this pkg into the server | 17:15 |
| reed | evgeny mentioned git tags: are those enough? | 17:15 |
| *** Evgeny has quit IRC | 17:15 | |
| mrmartin | or if it already exists, doing the upgrades, including schema changes, etc. | 17:15 |
| mrmartin | so for deployment, we are implementing a green/blue deployment model, as I see Evgeny_ was already using something similar for his deployments | 17:16 |
| Evgeny_ | ok | 17:16 |
| mrmartin | for openstackid this deployment middleware is just a bunch of bash script :), and for drupal it is a drush extensions in php | 17:17 |
| mrmartin | but the model is very similar, and it will be the same for askbot too | 17:17 |
| mrmartin | reed, don't have such a deployment in stackforge or in OpenStack? | 17:18 |
| mrmartin | this piece is really missing for me | 17:18 |
| reed | mrmartin, ? | 17:18 |
| mrmartin | ok | 17:18 |
| reed | mrmartin, I don't understand the question | 17:18 |
| mrmartin | I try to explain, thinking faster than I can write | 17:19 |
| mrmartin | so | 17:19 |
| mrmartin | we need an abstract model that can deploy or upgrade an application in green/blue model (slot0/slot1) from a package source (that can be .tgz, pip, git repo, etc.) | 17:20 |
| mrmartin | the deployment and upgrade patch for each application is the same, including groups, openstackid, and askbot | 17:20 |
| reed | the wiki works that way, IIRC, there are two slots on the same host | 17:20 |
| mrmartin | reed, ok, but it is not automatized | 17:21 |
| reed | right | 17:21 |
| *** Marga_ has quit IRC | 17:21 | |
| mrmartin | I was playing with CloudFoundry, and provides a very cool application environment | 17:21 |
| reed | mrmartin, you're talking about deployment here, right? | 17:21 |
| mrmartin | yes, deployment | 17:21 |
| reed | I want to understand how Evgeny_ is involved in this step | 17:22 |
| mrmartin | but even a CloudFoundry not solving this problem area. | 17:22 |
| mrmartin | http://docs.pivotal.io/pivotalcf/devguide/deploy-apps/blue-green.html | 17:22 |
| mrmartin | so it is a manual thing even for CF. | 17:22 |
| reed | he said he can tag his github/askbot repository when he things there is enough material to justify a 'release'... is that correct Evgeny_? | 17:22 |
| Evgeny_ | reed, that works | 17:23 |
| reed | ok, so the development side seems to be covered, right mrmartin? | 17:23 |
| Evgeny_ | a question | 17:23 |
| mrmartin | ok, so the simplest way for Evgeny_ just simple publish the dev changes into git's master repo, and tag production-grade releases | 17:23 |
| mrmartin | so it covers the dev / production release process. | 17:24 |
| Evgeny_ | how do we keep an update in askbot + update of theme as one unit? | 17:24 |
| reed | perfect | 17:24 |
| reed | Evgeny_, great question | 17:24 |
| *** Marga_ has joined #openstack-community | 17:24 | |
| Evgeny_ | consider that I tag an Askbot release and want to tag your theme | 17:24 |
| Evgeny_ | but haven't done the latter yet | 17:24 |
| mrmartin | askbot + theme update is a packaging question again | 17:24 |
| mrmartin | :) | 17:24 |
| Evgeny_ | and meanwhile your server tries to autoupgrade | 17:24 |
| reed | you know what changes in the code will require an update in the theme | 17:24 |
| mrmartin | from our aspect, the ideal way is make a common package from an askbot and a theme | 17:25 |
| reed | so they should be separate, until there is a commit that breaks compatibility with themes | 17:25 |
| reed | at least that's the way I consider themes | 17:25 |
| mrmartin | and if you are upgrading a theme, it means a new version, and if you upgrade askbot, it is another version. | 17:25 |
| mrmartin | because it is easy to break things here | 17:25 |
| reed | they are finished products, independent from the main code | 17:25 |
| Evgeny_ | mrmartin, a puppet package gives that already, if it maintains proper references to both askbot and theme | 17:26 |
| mrmartin | yeah it is providing that, but from operation aspect it is easier to handle a single package | 17:26 |
| mrmartin | actually, the theme and askbot can be out of sync, if we are not carefully handling that | 17:27 |
| mrmartin | Evgeny_, do you have automated tests for askbot? | 17:27 |
| mrmartin | unit or function tests | 17:27 |
| Evgeny_ | mrmartin, that may be a bit dangerous | 17:27 |
| reed | alright, but that's not that big of an issue | 17:27 |
| Evgeny_ | yes | 17:27 |
| reed | let me see if I have this right | 17:27 |
| Evgeny_ | I run test cases with almost every commit | 17:28 |
| mrmartin | Evgeny_, do you have some UX test using behat or something similar | 17:28 |
| Evgeny_ | UX meaning the front end browser side tests? Those, no I don't have | 17:28 |
| reed | askbot code develops on one repo, and the theme is in another repo... they can be developed independently and *deployed* independently... until code breaks compatilibty with the theme | 17:28 |
| Evgeny_ | UX changes are tested manually | 17:28 |
| *** Marga_ has quit IRC | 17:29 | |
| mrmartin | reed, until it not breaks | 17:29 |
| reed | right, and that's why we have the staging env | 17:29 |
| Evgeny_ | currently I can't suggest anything better than having your puppet repo keep references and and keep theme and askbot in separate packages | 17:29 |
| reed | I would like to end this meeting with a path forward | 17:30 |
| mrmartin | ok, basically, it is an existing situation, that we handling themes separately, we can live with that | 17:30 |
| reed | when there is a need to upgrade the theme or the askbot code, we change the reference in the puppet repo, pull from git tab | 17:30 |
| *** Piet has joined #openstack-community | 17:30 | |
| reed | s/tab/tag | 17:30 |
| Evgeny_ | on your side you might repackage that recipe as one package living in your repo | 17:30 |
| mrmartin | the major question here is the releasing, but I think we can agree on this github repo as source of deployments | 17:31 |
| reed | is that a possible way forward for a few weeks? | 17:31 |
| Evgeny_ | marking releases and informing about tags is simple enough on my side | 17:31 |
| mrmartin | reed, it can work, need to write it into release docs | 17:31 |
| reed | mrmartin, yes, github/slackbot is the source, and Evgeny_ will use git tags to 'release' | 17:31 |
| reed | now... | 17:32 |
| mrmartin | ok, so we can agree on this integration point of packages | 17:32 |
| reed | we have to upgrade :) | 17:32 |
| Evgeny_ | I guess release-0.7.51.1 | 17:32 |
| Evgeny_ | where the number would be a subversion of the current release? | 17:32 |
| reed | Evgeny_, can you document in askbot how you're going to name the release tags? | 17:33 |
| Evgeny_ | the sub-versions could be kept on github only | 17:33 |
| mrmartin | we don't have this multislot green/blue deployment for askbot yet. | 17:33 |
| reed | pick a standard and we'll adapt | 17:33 |
| Evgeny_ | ok | 17:33 |
| Evgeny_ | rev-<version>.<subversion> | 17:34 |
| Evgeny_ | would that be ok? | 17:34 |
| Evgeny_ | what about theme? | 17:34 |
| mrmartin | reed, don't we have a versioning standard for python? | 17:34 |
| Evgeny_ | should it be tagged similarly? | 17:34 |
| reed | mrmartin, there is... more than one, I guess :) | 17:34 |
| mrmartin | :) | 17:35 |
| mrmartin | ok, we can use the similar tagging model for themes | 17:35 |
| Evgeny_ | meaning rev-<version>.<subversion> being the format of git tag | 17:35 |
| Evgeny_ | mrmartin: python uses pip and version inside packages | 17:36 |
| reed | https://www.python.org/dev/peps/pep-0440/ | 17:36 |
| Evgeny_ | most frequent is module.__version__ variable | 17:36 |
| reed | but there are others... I remember reading a bunch of discussions on openstack-dev mlist about this | 17:36 |
| Evgeny_ | in the package | 17:36 |
| mrmartin | I think pip also maintaining a catalogue about the available versions | 17:36 |
| Evgeny_ | Do you guys want to make an assumption about syncing tags in askbot and theme? | 17:37 |
| mrmartin | it is a good question, are you plan to use same versions for theme and askbot | 17:37 |
| Evgeny_ | they do need to be paired for the deployment | 17:37 |
| mrmartin | or you like to keep some dependency information somewhere about compatible askbot versions / or themes | 17:37 |
| reed | crazy idea popped into my mind | 17:37 |
| Evgeny_ | it could be that askbot is updated but theme is not, and vs versa | 17:38 |
| *** cdent has quit IRC | 17:38 | |
| mrmartin | like this composer.json file: https://github.com/openstack-infra/openstackid/blob/master/composer.json | 17:38 |
| reed | maybe (maybe) it makes sense to keep one fork on our side and merge upstream github with the theme | 17:38 |
| reed | would that solve this issue of syncing the theme? | 17:38 |
| Evgeny_ | me still thinks that keeping refs in the puppet repo is simple and reliable enough | 17:39 |
| reed | in order to deploy we first pull from github the tagged release, deploy on staging, test the theme integration | 17:39 |
| mrmartin | Evgeny_: or what you think about not breaking the compatibility of major versions? 1.1 1.2 1.3 still works with theme 1.x and 2.1 2.2 2.3 works with 2.x | 17:39 |
| reed | Evgeny_, probably ... and maybe I don't understand what you mean with the pairing of the theme | 17:39 |
| mrmartin | reed do we have an etherpad for this? | 17:40 |
| reed | mrmartin, no | 17:41 |
| Evgeny_ | the theme + askbot releases must match, so either way this must be recorded somewhere | 17:41 |
| reed | mrmartin, feel free to start on | 17:41 |
| Evgeny_ | so a git repo for puppet does that | 17:41 |
| reed | Evgeny_, what do you mean by 'must match'? | 17:41 |
| Evgeny_ | otherwise we can make extra assumptions about tags on both sides | 17:42 |
| mrmartin | it must not break each other. | 17:42 |
| reed | how often does the theme break? | 17:42 |
| mrmartin | https://etherpad.openstack.org/p/askbot-integration | 17:42 |
| Evgeny_ | by match I mean - being compatible | 17:42 |
| reed | got it... so are the theme very delicate? do they break often? | 17:42 |
| Evgeny_ | there are not too many templates in your theme, so quite reliable | 17:43 |
| mrmartin | Evgeny_: what is your experience of theme compatibility at different customers ? | 17:43 |
| Evgeny_ | customized parts are not functionally rich in your theme | 17:44 |
| reed | we have a way to specify a version of the theme (pinned to a git tag/commit) and a version of the code, pinned to git tags | 17:44 |
| Evgeny_ | It depends on how many templates were customized | 17:44 |
| Evgeny_ | your's is on a light side | 17:44 |
| reed | ok | 17:45 |
| reed | so for the next upgrade we'll have to get a git tag from upstream and a new theme, probably | 17:46 |
| reed | right? | 17:46 |
| mrmartin | Evgeny_: how django is handling the dependencies ? | 17:46 |
| mrmartin | https://github.com/ASKBOT/askbot-devel/blob/master/askbot_requirements.txt | 17:46 |
| mrmartin | can't we use something similar for theme? | 17:47 |
| Evgeny_ | mrmartin: django is doing it via distutils, and the setup.py script in the root of the repo | 17:47 |
| Evgeny_ | also a copy of deps is in the askbot_requirements.txt file | 17:47 |
| Evgeny_ | it could be, although theme is not a python package | 17:48 |
| mrmartin | what you think about handling the theme as a separate component, similarly to other python projects? | 17:48 |
| Evgeny_ | there is not a single line of python | 17:48 |
| mrmartin | I know it | 17:48 |
| reed | i think for the next upgrade we can reference to a specific commit to askbot-theme in the puppet manifest | 17:49 |
| mrmartin | but if you see the abstraction for example in Drupal, a theme is a module there, with all of the versioning and dependency resolution as every other modules. | 17:49 |
| reed | and refactor the theme as a django package in the future | 17:49 |
| reed | Evgeny_, would that work for you? | 17:50 |
| Evgeny_ | reed: meaning it would be put on pip? | 17:50 |
| mrmartin | Evgeny_: I don't like to refactor your whole askbot project, but after a complexity level, those things makes the life easier | 17:51 |
| reed | Evgeny_, not necessarily, but it would be treated as a dependency | 17:51 |
| Evgeny_ | there are django-apps, not packages | 17:51 |
| Evgeny_ | mrmartin: I too prefer a simple and more decoupled solution | 17:51 |
| reed | Evgeny_, right, whatever makes sense from deployment automation perspective | 17:52 |
| Evgeny_ | I've put a suggestion in the etherpad, don't have anything better atm | 17:52 |
| reed | so, I think we need to come up with a short term plan | 17:52 |
| Evgeny_ | the only potential downside is that it's not quite automatic | 17:52 |
| reed | right, we can get more automatic as we go on | 17:52 |
| reed | the most important thing is to upgrade now and fix/refacto things as we go | 17:53 |
| mrmartin | ok, we don't need to solve every issue know, just understand the challenges here first | 17:53 |
| mrmartin | so yeap, release and upgrade are the top priority | 17:53 |
| reed | for the next upgrade, we need a staging machine, right? | 17:53 |
| mrmartin | don't need :) | 17:53 |
| mrmartin | but good to have | 17:53 |
| reed | ok | 17:53 |
| reed | how fast can we have one? | 17:54 |
| Evgeny_ | so on my side: a release and theme testing, then I'll let you know or make a pull request into the puppet repo | 17:54 |
| reed | great, Evgeny_ | 17:54 |
| Evgeny_ | this can be done by Sunday | 17:54 |
| reed | Evgeny_, and set a standard for versioning the releases, put that into your README so we all know what to expect | 17:54 |
| mrmartin | ok, I can work on something that can fetch askbot from github | 17:54 |
| Evgeny_ | I will work on this tomorrow | 17:54 |
| Evgeny_ | and might be done tomorrow | 17:54 |
| mrmartin | and prepare an initial patch for staging-askbot server | 17:55 |
| mrmartin | because it need to go through infra | 17:55 |
| Evgeny_ | ok | 17:55 |
| mrmartin | so the strategy can be here to publish a basic staging-askbot server, accepted by infra, and we can extend that later using smaller patches | 17:55 |
| Evgeny_ | mrmartin: the "prepare an initial patch for staging-askbot server" I don't understand well | 17:55 |
| Evgeny_ | is this on your side? | 17:55 |
| mrmartin | somebody need to provision that instance | 17:56 |
| *** Marga_ has joined #openstack-community | 17:56 | |
| reed | Evgeny_, yes, it's on the openstack-infra side | 17:56 |
| Evgeny_ | better on your side make a clone of the production | 17:56 |
| mrmartin | so I need to create a patch in system-configm including the site.pp changes and askbot-staging.pp server definition. | 17:56 |
| Evgeny_ | sure | 17:56 |
| reed | ok, we have a plan | 17:56 |
| mrmartin | it is easier to push through in smaller steps, than publishing a huge mega patch | 17:56 |
| *** electrocucaracha has quit IRC | 17:57 | |
| reed | next meeting: how about Monday? | 17:57 |
| mrmartin | the solr, pgsql, etc. is the samle | 17:57 |
| mrmartin | same | 17:57 |
| mrmartin | I can reuse that environment from ask.o.o | 17:57 |
| mrmartin | and I can focus on deployment / upgrade part meanwhile the infra is approving the initial patch | 17:57 |
| reed | sounds good | 17:58 |
| mrmartin | sound like a plan | 17:58 |
| Evgeny_ | Monday sounds good for me | 17:58 |
| reed | on Monday, next meeting? | 17:58 |
| reed | cool | 17:58 |
| reed | Evgeny_, here are the times for the meeting https://wiki.openstack.org/wiki/Meetings/Community | 17:58 |
| reed | i'll update the agenda | 17:58 |
| reed | I think we're done here | 17:58 |
| mrmartin | I'll be on meetup in Monday at Prezi office, but try to grab my notebook | 17:58 |
| reed | mrmartin, uhm | 17:59 |
| mrmartin | ok, so the initial steps are clear | 17:59 |
| reed | we can do Thursday then | 17:59 |
| reed | or I'll just sync up with Evgeny_ | 17:59 |
| reed | let's stick to Monday | 17:59 |
| mrmartin | let's try Monday | 17:59 |
| mrmartin | Thursday not better :) | 17:59 |
| reed | if mrmartin can't make it, we'll have a shorter meeting but still would like to hear from Evgeny_ how it's going | 17:59 |
| mrmartin | I'll try to make it | 18:00 |
| reed | ok | 18:00 |
| reed | monday then | 18:00 |
| reed | thank you both | 18:00 |
| mrmartin | thanks | 18:00 |
| reed | i'm always available if you need anything | 18:00 |
| reed | i have znc bouncer now :) | 18:00 |
| reed | so if you leave a message on irc I'm likely to get it | 18:00 |
| Evgeny_ | ok thank you | 18:00 |
| reed | cheers | 18:00 |
| *** dizquierdo has joined #openstack-community | 18:01 | |
| * reed goes to grab coffee | 18:01 | |
| *** sarob has joined #openstack-community | 18:06 | |
| *** Marga_ has quit IRC | 18:07 | |
| *** sarob has quit IRC | 18:12 | |
| *** Piet has quit IRC | 18:16 | |
| *** Marga_ has joined #openstack-community | 18:18 | |
| *** Piet has joined #openstack-community | 18:18 | |
| *** Marga_ has quit IRC | 18:20 | |
| *** Marga_ has joined #openstack-community | 18:20 | |
| *** rbowen has quit IRC | 18:27 | |
| *** SergeyLukjanov has quit IRC | 18:31 | |
| *** rbowen has joined #openstack-community | 18:32 | |
| *** SergeyLukjanov has joined #openstack-community | 18:32 | |
| *** sarob has joined #openstack-community | 18:36 | |
| *** electrocucaracha has joined #openstack-community | 18:36 | |
| *** sarob has quit IRC | 18:43 | |
| *** jtomasek has joined #openstack-community | 18:43 | |
| *** dizquierdo has quit IRC | 19:00 | |
| *** Marga_ has quit IRC | 19:03 | |
| *** Marga_ has joined #openstack-community | 19:05 | |
| *** Marga_ has quit IRC | 19:06 | |
| *** Marga_ has joined #openstack-community | 19:06 | |
| *** Harry51S has quit IRC | 19:08 | |
| *** electrocucaracha has quit IRC | 19:21 | |
| *** electrocucaracha has joined #openstack-community | 19:24 | |
| *** Piet has quit IRC | 19:37 | |
| *** sarob has joined #openstack-community | 19:39 | |
| *** Marga_ has quit IRC | 19:39 | |
| *** Marga_ has joined #openstack-community | 19:40 | |
| *** Piet has joined #openstack-community | 19:40 | |
| *** Marga_ has quit IRC | 19:40 | |
| *** sarob has quit IRC | 19:40 | |
| *** Marga_ has joined #openstack-community | 19:40 | |
| *** sarob has joined #openstack-community | 19:40 | |
| *** Marga_ has quit IRC | 19:45 | |
| *** electrocucaracha has quit IRC | 19:57 | |
| *** electrocucaracha has joined #openstack-community | 20:05 | |
| *** Piet has quit IRC | 20:05 | |
| *** Marga_ has joined #openstack-community | 20:36 | |
| *** jtomasek has quit IRC | 20:37 | |
| *** Marga_ has quit IRC | 20:38 | |
| *** Evgeny_ has quit IRC | 20:44 | |
| *** mattgriffin has joined #openstack-community | 20:51 | |
| *** Marga_ has joined #openstack-community | 20:51 | |
| *** tiswanso has quit IRC | 21:05 | |
| *** Piet has joined #openstack-community | 21:10 | |
| *** jcoufal has joined #openstack-community | 21:12 | |
| *** electrocucaracha has quit IRC | 21:13 | |
| *** yfauser has joined #openstack-community | 21:18 | |
| *** yfauser has left #openstack-community | 21:19 | |
| *** electrocucaracha has joined #openstack-community | 21:22 | |
| *** electrocucaracha has quit IRC | 21:24 | |
| *** electrocucaracha has joined #openstack-community | 21:37 | |
| *** mrmartin has quit IRC | 21:48 | |
| *** sarob has quit IRC | 22:03 | |
| *** jcoufal has quit IRC | 22:14 | |
| *** Marga_ has quit IRC | 22:43 | |
| *** electrocucaracha has quit IRC | 22:48 | |
| *** sarob has joined #openstack-community | 22:54 | |
| *** sarob has quit IRC | 22:58 | |
| *** electrocucaracha has joined #openstack-community | 22:58 | |
| *** Marga_ has joined #openstack-community | 23:14 | |
| *** mattgriffin has quit IRC | 23:18 | |
| *** jcoufal has joined #openstack-community | 23:34 | |
| *** Marga_ has quit IRC | 23:35 | |
| *** Marga_ has joined #openstack-community | 23:36 | |
| *** Marga_ has quit IRC | 23:38 | |
| *** Marga_ has joined #openstack-community | 23:47 | |
| *** Marga_ has quit IRC | 23:48 | |
| *** Marga_ has joined #openstack-community | 23:48 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!