19:00:48 <catherineD|2> #startmeeting refstack
19:00:49 <openstack> Meeting started Tue Jun  7 19:00:48 2016 UTC and is due to finish in 60 minutes.  The chair is catherineD|2. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:00:51 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:00:54 <openstack> The meeting name has been set to 'refstack'
19:01:46 <pvaneck> o/
19:02:11 <sslypushenko> o/
19:02:21 <catherineD|2> #link meeting agenda https://etherpad.openstack.org/p/refstack-meeting-16-06-07
19:02:32 <Rockyg> o/
19:03:25 <catherineD|2> hi everyone
19:03:46 <catherineD|2> #topic RefStack branches decision for refstack.openstack.org site
19:04:54 <catherineD|2> so last week we discuss using feature,  production or point-in-time branch (like 2016.06, 2016.10 ...)
19:05:40 <catherineD|2> do we have any further info ?
19:05:59 <pvaneck> I think the cleanesst way is to just make a single branch called 'prod' then have puppet pull from that instead of master.
19:06:14 <sslypushenko> no
19:06:23 <sslypushenko> no prod)
19:06:34 <catherineD|2> sslypushenko: reason?
19:06:49 <sslypushenko> current tags even better than prod)
19:07:03 <sslypushenko> it will take to much resources to support
19:07:19 <sslypushenko> we need release branches
19:07:21 <catherineD|2> currently the tag is created from the master
19:07:28 <sslypushenko> definately
19:07:36 <pvaneck> what if master has a change that we dont want in the site just yet?
19:07:42 <pvaneck> cant cherry pick into tags
19:08:16 <sslypushenko> yeap... but it does not cost us any efforts for support)
19:08:47 <pvaneck> i was testing the prod branch setup with a local gerrit/git
19:09:06 <catherineD|2> sslypushenko: but it does not support what we want to do which is cherry pick commit that we want
19:09:10 <pvaneck> it works reasonably well. all we need is the pushMerge acl permission added for the refstack-release group
19:09:16 <sslypushenko> so.. again... we need branch per release... and maybe tags from these branches to publish it
19:09:35 <Rockyg> catherineD|2, branches support cherry picking
19:09:49 <catherineD|2> Rockyg: tag does not
19:10:08 <Rockyg> right which is why we need branches
19:10:08 <sslypushenko> catherineD|2:  what wrong with idea, that we agreed last meeting?
19:10:40 <sslypushenko> I meant idea of release branches?
19:10:55 <Rockyg> once branched, you can tag until you have an incompatibility that requires a new branch
19:11:12 <Rockyg> sslypushenko, yup
19:11:19 <catherineD|2> sslypushenko:  I agreed on creating a branch .... whether we call it release or prod or point-in-time
19:11:52 <Rockyg> should follow release numbe scheme that rest of community uses.
19:11:55 <catherineD|2> so let's do this ...please +1 if you agree that we need to create a branch
19:12:03 <Rockyg> +1
19:12:13 <sslypushenko> catherineD|2:  again... I have some experience with prod-branch-workflow... it was awful
19:12:20 <Rockyg> semver numbering
19:12:42 <catherineD|2> let discuss that later ... first let's agree on creating a branch
19:12:50 <Rockyg> yeah.  don't call it prod.
19:13:08 <pvaneck> we dont have the ability to delete branches also
19:13:28 <sslypushenko> but it should be just some branch... I should kind of release
19:13:43 <sslypushenko> It is the main point
19:13:44 <Rockyg> give it a number when it's a release.
19:13:55 <Rockyg> don't call it release, either.
19:14:03 <catherineD|2> pvaneck: sslypushenko: I take that you agree on creating a branch ... we will discuss kind of branch later
19:14:18 <sslypushenko> ok... lets do it in this way)
19:14:29 <Rockyg> talk to dhellmann.  he'll help work this naming out
19:14:45 <catherineD|2> Rockyg: will do
19:15:12 <catherineD|2> Rockyg: how about invite him here if he is available?
19:15:17 <pvaneck> so from puppet's perspective...
19:16:04 <pvaneck> if we have multiple branches, puppet will get the last one when a branch list is sorted?
19:16:32 <sslypushenko> yeap
19:16:47 <Rockyg> That's why I used his nick;-)
19:16:47 <sslypushenko> latest one, matches to
19:16:56 <sslypushenko> schema
19:17:00 <catherineD|2> pvaneck: that is presumably that we deploy from branch master not tag ?
19:17:16 <catherineD|2> Rockyg: ic
19:18:56 <Rockyg> Also, you can go to openstack-release and talk with thieery, dhellmann, dims for help.
19:18:58 <pvaneck> catherineD|2, just trying to determine how puppet should be configured. Will likely have to do some pre-calculation to determine which branch puppet should pull from
19:19:25 <catherineD|2> Rockyg: ok
19:20:25 <catherineD|2> sslypushenko: pvaneck: I am OK if we go with multuple branches and let puppet to choose the last one
19:20:47 <sslypushenko> catherineD|2:  great)
19:20:57 <catherineD|2> no tag then?
19:21:18 <pvaneck> wont be neccessary
19:21:25 <Rockyg> yup
19:21:32 <Rockyg> highest number
19:21:51 <catherineD|2> we will check with the release team on how to name the branch
19:21:59 <catherineD|2> but we agreed that ...
19:23:02 <catherineD|2> #agreed  Use multuple branches and name the branches in such a way to let puppet to choose the last one
19:23:34 <catherineD|2> hopefully we do not need to create too many branches
19:23:48 <catherineD|2> any other thoughts on this subject?
19:24:41 <catherineD|2> in this case we also do not need to delete previous branches right?
19:24:48 <Rockyg> should only need a branch for a major release, not for bugfixes or new/expanded features.
19:25:12 <catherineD|2> Rockyg: yea
19:25:15 <Rockyg> Major only happens on incompatible changes
19:25:28 <catherineD|2> anything else?
19:26:13 <catherineD|2> Rockyg: In our case Major will be exposing the new UI entity like allowing for vendor and product registration
19:26:31 <catherineD|2> moving on ...
19:26:43 <Rockyg> thanks
19:26:49 <catherineD|2> #topic Allow passing of a custom guideline URL in report page UI
19:27:26 <catherineD|2> The concern on custom URL is security
19:28:14 <catherineD|2> currently refstack fetches the guidelines from DefCore repository which is a known site  ...
19:28:54 <pvaneck> yea, the only way to ensure we can pull data from external URLs is if we have the Refstack server do it
19:28:54 <sslypushenko> catherineD|2:  now we are going to have schema validation
19:28:56 <catherineD|2> is there security concern on a random and unknown URL
19:29:48 <Rockyg> I would certainly think so.
19:29:51 <sslypushenko> so we can ensure that this url serves exactly some schema
19:29:56 <catherineD|2> pvaneck: is there security concern with API server pull it?
19:31:17 <catherineD|2> sslypushenko: is valication of schema good enough .. do we concern about the content for security reason?
19:31:24 <pvaneck> catherineD|2, probably, but not sure if we need other precautions other than schema validation
19:32:06 <sslypushenko> validation based on jsonschema is good enough
19:32:25 <catherineD|2> ok
19:33:03 <sslypushenko> I don't want to deal with storing artifacts which can require versioing
19:33:16 <catherineD|2> so we agree on pulling the external guideline from the API server ?
19:34:01 <catherineD|2> sslypushenko: could you explain ...
19:34:01 * dhellmann looks at the scrollback for branch question
19:34:27 <catherineD|2> dhellmann: thank you!
19:34:48 <sslypushenko> I guess API server can work only as cache proxy, like it now works
19:35:20 <sslypushenko> just with user's url
19:35:29 <dhellmann> catherineD|2 : let me know when you're ready to discuss that again, I don't want to derail the current topic
19:35:55 <catherineD|2> dhellmann: I think we are ready now ... thanks for your help
19:36:06 <catherineD|2> let me give some back ground info
19:36:08 <dhellmann> catherineD|2 : so it sounds like you need branches for stable releases?
19:36:24 <catherineD|2> sort of ...
19:36:29 <sslypushenko> dhellmann:  yeap
19:36:53 <dhellmann> hmm, ok, I'll wait for clarification of that "sort of" :-)
19:37:06 <catherineD|2> currently the refstack.openstack.org site is deployed from tag created from the master branch
19:37:17 <Rockyg> the key here is that the production server would need to update based on new release.
19:37:27 <sslypushenko> not related to OpenStack releases, but we assume that these release will be stable
19:38:18 <catherineD|2> we do have new features in development that we do not want to deploy to the site until later ... so we think of creating a branch that not include the new feature in the master branch
19:38:31 <dhellmann> ok
19:38:56 <dhellmann> the way our tools work right now, we can support stable/* branches for releasing off of old things, but it doesn't sound like that's what you want
19:39:03 <catherineD|2> so we will create a point-in-time branch for the site
19:39:07 <dhellmann> instead it sounds like you want to use feature/* branches for doing work that isn't ready to release
19:39:14 <dhellmann> and then merge those into master
19:39:24 <dhellmann> OTOH, that gets a bit expensive in terms of creating and deleting branches all the time
19:39:48 <dhellmann> most of the other teams are developing in a way that allows for continuous deployment, whether a feature is fully implemented or not
19:39:53 <dhellmann> is that possible for you?
19:41:08 <catherineD|2> we are operating in the CD now ... and think that it does not work for us ... for example we do not want to expose some of the UI prematurely
19:41:44 <catherineD|2> our thought that the new features will be developed in master ... deployment will be from a brach
19:42:05 <dhellmann> that's going to be a lot more work for you to merge changes from master into the branch when you're ready to deploy
19:42:06 <catherineD|2> and hope that the puppet will choose the last branch that we create
19:42:17 <dhellmann> our gerrit workflow is not set up to make that especially easy, because we don't do that anywhere else
19:42:41 <catherineD|2> dhellmann: ic ...
19:42:50 <dhellmann> I don't know how hard it would be to convince puppet to pick the "latest" branch like that
19:43:23 <dhellmann> what sort of UI changes would you consider "premature"?
19:43:43 <catherineD|2> we are working on allowing vendor registration ...
19:44:09 <catherineD|2> product registration will follow ...
19:44:11 <sslypushenko> dhellmann:  catherineD|2: to simplify things we can create a tag from top of  required brach. then gerrit will deploy code from this tag
19:44:17 <Rockyg> dhellmann, so work the branch like a stable release.  Tags for bugfixes, small, compatible changes, new branch for big changes
19:44:37 <dhellmann> if you have a small number of large features like that, feature branches can work well. if you want a lot of new branches, it's going to be more work for you than other approaches like feature flags to turn features off until they're complete
19:45:06 <catherineD|2> we do not want user to see the UI allowing creation of vendor and then have no link to the data etc ..
19:45:15 <dhellmann> Rockyg : the difference is that you only ever want one deployment branch, if there is only one deployed instance
19:45:27 <Rockyg> similar release cycle, but not coordinated with the dev cycles
19:46:07 <Rockyg> dhellmann, thinking on that...
19:46:25 <dhellmann> how often do these sorts of things come up for you? is this one big new feature? or is this how features are always added to refstack?
19:47:23 <catherineD|2> dhellmann: not very often .. this is the first time with big feature and we do not want user to see yet
19:47:53 <dhellmann> ok, in that case I recommend creating a feature/ branch, develop the feature there, merge the results into master when you're ready, then delete the branch
19:47:56 <dhellmann> that way you can keep deploying from master
19:48:28 <catherineD|2> dhellmann: ic
19:48:53 <catherineD|2> dhellmann: thank you very much for your time....
19:49:04 <Rockyg> Thanks!
19:49:51 <catherineD|2> dhellmann: thank for preventing us from go down the wrong path ...
19:50:12 <sslypushenko> dhellmann:  Thx!
19:50:18 <dhellmann> I'm glad I could help! I'm not sure who will have permissions to create the branch for you, but if you don't either I or the infra team should be able to.
19:51:00 <catherineD|2> dhellmann: do we need to submit a patch to create the feature branch?
19:51:18 <dhellmann> catherineD|2 : no, you can try to do that directly in gerrit. Let me find the right page for you...
19:51:24 <dhellmann> https://review.openstack.org/#/admin/projects/openstack/refstack,branches
19:51:38 <sslypushenko> catherineD|2:  yeap, we need extra permissions
19:51:48 <dhellmann> it looks like I can create branches in that repo, so if you tell me the SHA of the commit where you want it, and the name you want to use, I can do it for you
19:51:49 <catherineD|2> dhellmann: thanks again!
19:52:15 <catherineD|2> dhellmann: ok will contact you later !
19:52:26 <dhellmann> sounds good, drop by #openstack-release to find me
19:52:48 <catherineD|2> dhellmann: will do
19:53:12 <catherineD|2> team ... we will need to revoke our agreement to create multiple branches earlier
19:53:40 <sslypushenko> catherineD|2:  feature braches works for me
19:54:22 <sslypushenko> I guess it will work for others too
19:54:42 <Rockyg> +1 for feature branches.
19:56:05 <pvaneck> sure, can make it now if you want since you have permission
19:56:28 <catherineD|2> #agreed Use feature branch for development of new features and master branch for deployment (business as usual) ... (this supersedes the earlier agreement)
19:56:34 <catherineD|2> great
19:56:38 <catherineD|2> 4 mins left
19:56:59 <catherineD|2> let go back to the external guideline discussion
19:57:01 <pvaneck> i guess i will work on the vendor/product UI stuff on that feature branch?
19:57:12 <catherineD|2> pvaneck: I think so
19:57:59 <sslypushenko> catherineD|2:  for external guideline - only one thing we need - is validation
19:58:11 <catherineD|2> I guess we all agree that the external guidelines should be served from the API server (not sure whether we have logged that agreement
19:59:00 <sslypushenko> than API server will cache it and operate like we do now with Defcore one
19:59:36 <sslypushenko> catherineD|2:  I'd prefer to not stote guidelines in RefStack
19:59:51 <sslypushenko> because it requires versioning
20:00:04 <sslypushenko> lets go to #refstack channel
20:00:15 <catherineD|2> #agreed External guideline will be served from the API server.  Schema validation of the guidelines are required. Guideline will be cached and not store on the API server
20:00:24 <catherineD|2> #endmeeting