13:03:49 <jasondotstar> #startmeeting openstack-salt
13:03:49 <openstack> Meeting started Tue May 10 13:03:49 2016 UTC and is due to finish in 60 minutes.  The chair is jasondotstar. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:03:50 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
13:03:51 <jasondotstar> hmm
13:03:53 <openstack> The meeting name has been set to 'openstack_salt'
13:03:55 <openstack> nmadhok: Error: Can't start another meeting, one is in progress.  Use #endmeeting first.
13:03:55 <jasondotstar> there we go
13:03:56 <cznewt> hello
13:04:04 <nmadhok> #endmeeting
13:04:06 <jasondotstar> #topic roll call
13:04:36 <jasondotstar> nmadhok: I've got chair, so the commands won't work for you
13:04:41 <jasondotstar> o/
13:04:44 <nmadhok> Ohh
13:04:52 <jasondotstar> it's cool
13:04:54 <nmadhok> Alright
13:04:55 <jasondotstar> we can shre
13:04:58 <jasondotstar> *share
13:05:04 <jasondotstar> that way it's not me all the time :-)
13:05:06 <genunix> o/
13:05:07 <nmadhok> I'm present for the role call :p
13:05:11 <jasondotstar> cool
13:05:16 <nmadhok> Hello Ales
13:05:24 <cznewt> \o/
13:05:51 <cznewt> Hello Nitin
13:06:01 <jpavlik> hello everyone
13:06:07 <jasondotstar> hi all
13:06:18 <jasondotstar> #topic Introduction
13:06:20 <nmadhok> @jpavlik Hello
13:06:24 <jasondotstar> This meeting is for the openstack-salt team
13:06:33 <jasondotstar> If you're interested in contributing to the discussion, please join #openstack-salt
13:06:43 <jasondotstar> Meetings are Weekly on Tuesdays at 1300UTC
13:06:50 <jasondotstar> #link http://eavesdrop.openstack.org/#OpenStack_Salt_Team_Meeting
13:06:58 <jasondotstar> #link http://eavesdrop.openstack.org/#OpenStack_Salt_Team_Meeting
13:07:15 <jasondotstar> #link https://wiki.openstack.org/wiki/Meetings/openstack-salt
13:07:27 <jasondotstar> sorry sent that link twice
13:07:31 <nmadhok> np
13:07:32 <jasondotstar> #topic Review past action items
13:07:47 <jasondotstar> we're going to go down the list
13:07:49 <jasondotstar> it's short today
13:07:55 <jasondotstar> then we can open up the floor for new stuff
13:08:01 <jasondotstar> nmadhok to connect with cznewt on the openSUSE conf
13:08:22 <jasondotstar> did you guys connect up?
13:08:24 <nmadhok> I did connect with @cznewt
13:08:41 <cznewt> The bio for the session is available at http://openstackdayprague.eu/#speakers
13:09:16 <nmadhok> I tried to add @cznewt to the presentation but guess he needs to register first?
13:09:40 <jasondotstar> #link http://openstackdayprague.eu/#speakers
13:09:44 <nmadhok> action item for this meeting would be to converge both projects
13:09:57 <jpavlik> what presentation @newt ?
13:10:02 <nmadhok> Ales sent an email last week but I didn't get back a response
13:10:35 <cznewt> david boucha sent an email today to specify steps for merging
13:10:41 <cznewt> It's on the agenda
13:11:00 <cznewt> for today
13:11:21 <nmadhok> I don't remember seeing email from him. Was I on the email thread?
13:11:23 <cznewt> nmadhok: can you send me link to the conference
13:11:44 <nmadhok> #link https://events.opensuse.org
13:12:04 <jasondotstar> nmadhok: which project efforts are we attempting to converge (perhaps I missed something) ?
13:12:11 <nmadhok> #link https://events.opensuse.org/conference/oSC16
13:12:13 <cznewt> nmadhok: yes you are on the reply list
13:13:04 <cznewt> jasondotstar: it's about aligning the formulas with salt-community ones
13:13:06 <nmadhok> See the email response to Ales's email
13:13:20 <cznewt> but it is long road ahead
13:13:33 <jasondotstar> yes, of course
13:13:41 <jasondotstar> i was thinking there was something else...
13:13:41 <jasondotstar> ok
13:13:49 <nmadhok> not exactly just aligning it with salt-community ones. Both will need to be changed to come to common standard
13:13:49 <cznewt> let's get to this in todays tasks please
13:14:17 <jasondotstar> #agreed the aligning the openstack-salt and salt-community efforts
13:14:21 <nmadhok> My talk at openSUSE conf in Germany is around the saltopenstack project
13:14:25 <jasondotstar> cznewt: I'll add it now
13:14:47 <nmadhok> so we may need to try and combine ideas for the presentation
13:15:05 <jpavlik> nmadhok: I think that there must be further discussion about aligning formulas
13:15:05 <jasondotstar> ok
13:15:11 <genunix> yes
13:15:25 <jasondotstar> let's move on to the next action item
13:15:30 <jasondotstar> nmadhok to schedule a hangout or Adobe connect session with the team to discuss current salt team progress
13:15:31 <nmadhok> @jpavlik absolutely.
13:16:00 <nmadhok> Ales contacted me late so I didn't have his email
13:16:20 <jasondotstar> why don't we put our email addresses in the etherpad
13:16:27 <jasondotstar> that way you have them all in one place?
13:16:29 <nmadhok> Couldn't schedule the Adobe connect session without an email and then I got pulled into a diff meeting since this one didn't get scheduled
13:16:37 <nmadhok> #agreed
13:16:37 <jasondotstar> nmadhok: no worries.
13:17:12 <nmadhok> What's the link to etherpad for this project?
13:17:31 <jasondotstar> #link https://etherpad.openstack.org/p/openstack-salt-weekly-meeting-20160510
13:17:41 <jasondotstar> it's for this meeting actually
13:18:16 <jasondotstar> the team here can add their emails
13:18:25 <jasondotstar> that way nmadhok can schedule the session with thie team
13:18:27 <nmadhok> I'm seeing an error accessing that link
13:18:28 <genunix> ok added mails
13:18:46 <jasondotstar> genunix: +1
13:18:46 <nmadhok> TypeError: null is not an object (evaluating 'pad.collabClient.setChannelState') in https://etherpad.openstack.org/javascripts/lib/ep_etherpad-lite/static/js/pad.js?callback=require.define at line 266'
13:18:56 <jasondotstar> #link https://etherpad.openstack.org/p/openstack-salt-weekly-meeting-20160510
13:18:59 <jasondotstar> hmm
13:19:08 <jasondotstar> seems to work ok
13:19:11 <nmadhok> works now
13:19:16 <jasondotstar> nmadhok: +1
13:19:25 <jasondotstar> ok last agenda item:
13:19:26 <jasondotstar> cznewt to get the project governance status moved to official level
13:19:43 <genunix> review was submitted
13:19:53 <genunix> #link https://review.openstack.org/#/c/314531/
13:20:53 <nmadhok> Once the project is official, it's going to be more difficult to tweak the architecture. Am I correct?
13:20:53 <jasondotstar> \0/
13:21:04 <jpavlik> Thiery Carrez should approve this.
13:21:18 <genunix> nmadhok: I don't think so
13:21:33 <genunix> nmadhok: there will not be much differences
13:21:50 <jasondotstar> we should still make our formulas conform to whatever the current standards are (from a salt community perspective), yes?
13:21:56 <nmadhok> we still have to discuss about aligning formulas and coming to an agreement
13:22:10 <jasondotstar> #agred
13:22:13 <jasondotstar> #agreed
13:22:20 <genunix> I don't that will result in some huge changes
13:22:27 <genunix> don't think ^
13:23:15 <jasondotstar> well, let's see what our discussion yields
13:23:41 <jasondotstar> ok any other items on last week's items?
13:24:03 <jasondotstar> if not let's move to today's agenda
13:24:04 <jasondotstar> #topic Today's Agenda
13:24:28 <jasondotstar> first, let's discuss salt orchestration and the complex testing of multiple reviews
13:25:12 <genunix> ok, so ad. orchestration, we are currently working on orchestrating cluster deployment using support metadata supplied with formulas.
13:25:19 <nmadhok> if there are changes to be made, I'm concerned if they will be difficult to make once project becomes official
13:25:23 <cznewt> we have created a new setup for salt to get the orchestrate workinf
13:25:43 <genunix> eg. https://github.com/tcpcloud/salt-formula-rabbitmq/tree/master/rabbitmq/orchestrate
13:26:32 <cznewt> nmadhok: the projects will merge eventually, but this will be well thought process, I have many concerns
13:27:00 <jasondotstar> #link https://github.com/tcpcloud/salt-formula-rabbitmq/tree/master/rabbitmq/orchestrate
13:27:23 <cznewt> I'll send reply to david with proposed way of functional merge
13:27:39 <nmadhok> @cznewt same here. I'll schedule a hangout this week for the emails listed in etherpad. What date/time works for everybody?
13:27:57 <jasondotstar> this timeframe works I think
13:27:58 <nmadhok> Also copy me on the response. I don't think I received his response
13:28:09 <jasondotstar> 1300UTC
13:28:15 <jasondotstar> unless other object...
13:28:18 <jasondotstar> *others
13:28:21 <nmadhok> What day?
13:30:05 <jpavlik> Thursday
13:30:06 <genunix> this thursday?
13:30:25 <jasondotstar> Thursday works for me.
13:30:29 <nmadhok> ok works for me. Thursday 13:00 UTC
13:30:32 <cznewt> yes for me as well
13:31:49 <jasondotstar> #agreed Hangout session is scheduled for Thurs at 1300UTC
13:33:40 <jasondotstar> ok are we good on the concerns regarding orchestration and testing?
13:34:11 <jasondotstar> im sure we will address more during the hangout session
13:34:41 <jasondotstar> if we're good for now, let's move on
13:34:44 <jpavlik> yes, leave it on hangout
13:34:49 <jasondotstar> next, discussion about generic formulas and functionality, role of linux formula
13:34:54 <cznewt> I'll reply to david's mail and pinpont problematic areas
13:35:47 <jpavlik> we need to concentrate on supporting OpenStack operation. I do not want to be like puppet
13:35:48 <jasondotstar> #action cznewt to reply to david's email and discuss the issues
13:35:58 <cznewt> the linux formula encapsulates a lot salt-community formulas in one
13:36:01 <jpavlik> nice code instead of production working
13:36:36 <jasondotstar> cznewt: is the aim to *not* be like or be like RDO?
13:36:53 <jpavlik> I prefer that if someone wants to do changes in desing to contribute first stuff like neutron DVR or openstack features what missing.
13:36:56 <cznewt> jasondotstar: I do not understand
13:37:05 <jasondotstar> i.e. where we have one formula that kicks off an install of everything?
13:37:06 <cznewt> RDO in what sense?
13:37:38 <nmadhok> if there are no dependencies, you should be able to combine each formula
13:37:38 <jpavlik> I mean that the biggest benefit of salt is that it implements production and operation configs instead of all features.
13:37:47 <jpavlik> it wors with RDO fine
13:38:12 <cznewt> not everything but the basics, I have to go through all formulas and figure what implements what
13:38:13 <nmadhok> user should be able to decide what part of the formula they want
13:38:18 <nmadhok> so they can pick and choose
13:38:32 <jpavlik> nmadhok: this is possible
13:38:35 <cznewt> yes this is correct
13:38:36 <genunix> I think user is not forced to use linux formula at all
13:38:41 <jpavlik> you can choose whatever formula you want
13:38:49 <nmadhok> within linux formula I meant.
13:38:49 <jasondotstar> ok that makes sense
13:38:58 <cznewt> the concern we were having is the repository enforcement
13:38:58 <genunix> user can choose by metadata
13:39:27 <jpavlik> nmadhok: linux formula is not part openstack-salt
13:39:29 <nmadhok> Like if they only want iptables functionality but not the entire linux build (some organizations and universities like us have our own build process and lot of custom built in house software)
13:40:05 <nmadhok> jpavlik: I know that part
13:40:07 <genunix> there's salt-formula-iptables, it's not part of linux formula afaik
13:40:34 <cznewt> all is model/metadata driven, you are free to switch, but you loose some of the functionality - monitoring metadata etc
13:40:41 <nmadhok> that's great. each formula should be independent but we could bring them all together and make it one giant formula if people want to use it
13:41:03 <jasondotstar> nmadhok: that's what I was after
13:41:19 <jasondotstar> well, it's what i wanted to understand I should say...
13:41:28 <jpavlik> nmadhok: one giant formula? We do not need devstack
13:41:28 <nmadhok> even in the openstack ecosystem, if user wants to use zeromq or qpid instead of rabbitmq, it should be configurable
13:41:45 <jpavlik> nmadhok: how many production environment do you run?
13:41:57 <nmadhok> openstack-salt is a giant formula that consists of individual formula if you look at it
13:42:02 <jpavlik> nmadhok: have you ever seen implementation on qpid?
13:42:23 <jpavlik> nmadhok: last thing what this project needs is to implement everything like other projects do
13:42:41 <jpavlik> nmadhok: this is the reason why this solution runs in more than 10 prod envs
13:42:42 <jasondotstar> can't that be optional?
13:42:49 <jpavlik> jasondotstar: can be
13:42:52 <cznewt> nmadhok: the metadata support various backends, this is free for contribution
13:42:59 <nmadhok> we have environments that run qpid, rabbitmq, zeromq
13:43:04 <jpavlik> jasondotstar: but tell me why?
13:43:08 <cznewt> anything, db, mq backends
13:43:10 <jpavlik> nmadhok: ok push the rerview
13:43:15 <nmadhok> user should not be locked into just using rabbitmq
13:43:16 <jpavlik> nmadhok: if you need that push review
13:43:20 <nmadhok> and just being restricted to using ubuntu
13:43:30 <jasondotstar> well, let's say it's not for a prod environment- perhaps is a AIO deployment
13:43:34 <jpavlik> nmadhok: everything is plugable
13:43:47 <jasondotstar> they could use the 'giant formula' to kick everything off
13:43:47 <jpavlik> for AIO we have single deployment
13:44:09 <jpavlik> jasondotstar: what is the purpose? I think that the biggest benefit of openstack-salt is operator view.
13:44:31 <jpavlik> jasondotstar: lets create single node deploy with OVS and easy setup
13:44:37 <nmadhok> reason a lot of users don't use other deployment methods is because they lock the user into using what they ship
13:44:45 <jpavlik> jasondotstar: but not develop one giat formula for everything, that what devstack does
13:45:07 <jasondotstar> the giant formula i speak of has includes
13:45:14 <nmadhok> yeah
13:45:18 <jpavlik> nmadhok: we do not force anything. It is plugable. Cinder has more than 10 storages
13:45:24 <genunix> nmadhok: this is not what we are doing, as cznewt wrote, everything is model driven
13:45:25 <nmadhok> +1
13:45:25 <jasondotstar> so it doesn't have everything
13:45:33 <jasondotstar> but it calls or includes everything
13:46:00 <jpavlik> jasondotstar: lets create metadata for single deploy, but not salt-formula-openstack
13:46:02 <jasondotstar> again, it's up to you whether you want to use it or not
13:46:13 <jasondotstar> jpavlik: i see what you mean
13:46:15 <jpavlik> jasondotstar: who will be maintain?
13:46:33 <jpavlik> yes
13:46:46 <jasondotstar> jpavlik: hmmm. good point. could be us, but if it's not where we want to go with the project that's fine
13:46:47 <jpavlik> jasondotstar: I do not have problem with plugins. But "make sense" plugins
13:47:01 <jpavlik> this is the reason why chef is used by nobody
13:47:38 <jasondotstar> perhaps we should focus on getting each of the individual salt formulas for each service built up first
13:47:40 <jpavlik> because it is not ready for operation. We need to show that our approach is operation driven. Otherwise it will be too complex with hundreds of useless plugins and Ansible won
13:47:59 <jasondotstar> then re-assess whether having a encapsulating formulas is worth the trouble.
13:48:01 <jpavlik> lets discuss this on hangout
13:48:11 <jpavlik> I want to have single node deployment
13:48:14 <nmadhok> jpavlik: +1
13:48:17 <jasondotstar> +1
13:48:18 <cznewt> We have the DVR review going on, I don't see reason not to support multiple db/mq backends, but we are mainly production driven, but anyone is free to contribute
13:48:23 <jpavlik> which can be setup in 5 minutes
13:48:49 <nmadhok> The presentation I gave in Tokyo last year, deployed 5 node cluster in 5 minutes
13:49:07 <jasondotstar> ok let's move to the last topic on the agenda
13:49:11 <jasondotstar> discussion about the alignment of the openstack and salt community efforts around standarizing our salt formulas
13:49:25 <nmadhok> let's discuss this on hangout
13:49:29 <cznewt> We have been talking about this pretty much all time :)
13:49:31 <jpavlik> I agree
13:49:33 <cznewt> yes the hangout
13:49:34 <jasondotstar> yeah we have
13:49:43 <jpavlik> I will explain my idea deeply
13:49:50 <jasondotstar> true
13:49:51 <jasondotstar> ok
13:50:00 <jasondotstar> #topic Open Discussion
13:50:42 <jasondotstar> ten minutes left here. floor is open.
13:51:02 <jpavlik> I said all what I want :)
13:51:38 <cznewt> Yes, I'll get the reply ready and post it to our channel
13:51:57 <aryan> perhaps I can use the opportunity and say a few things in 5min, as a new member of the community.
13:52:10 <aryan> A few observations:
13:52:44 <aryan> 1) the documentation are a bit misleading somethings. e.g. lack of links to relevant repos.
13:52:58 <cznewt> +1 to fix
13:53:06 <aryan> 2) Although, it's a good idea to separate repo management from package installation
13:53:15 <jpavlik> aryan: this is will be clean after official project. We want to put outside of our site to official.
13:53:30 <aryan> but, there are implicit dependencies between specific repos and states.
13:54:01 <genunix> yes, there may be issues in docs, reviews are always welcome :-)
13:54:09 <genunix> ad. pkg repos setup
13:54:16 <aryan> e.g. keystone formula needs a specific version, otherwise a few things breaks, such as dog.pile plugin
13:55:16 <jpavlik> aryan: what version?
13:55:28 <jpavlik> aryan: I am testing against ubuntu cloud archive without any issues.
13:55:40 <aryan> jpavlik: default ubuntu 14.04 repo wo/ cloud-archive
13:55:56 <jpavlik> aryan: openstack version?
13:55:57 <cznewt> the linux formula handles the repositories, I'll have to check if salt-community has formula with similar functionality
13:56:16 <jpavlik> aryan: create bug or write me on irc
13:56:17 <aryan> jpavlik: e.g. keystone 0.7.1
13:56:23 <jpavlik> aryan: I will take a look
13:56:28 <genunix> some formulas were setting up repositories, but in my opinion that's not a good idea as user may want to deliver packages from any source (custom mirror/repos, 3rd parties, etc.)
13:56:47 <genunix> that's the reason why formulas themselfs are not forcing users to use some specific repos
13:57:04 <aryan> genunix: that's why linux formula can be useful, but in my limited experience, it is too intrusive
13:57:25 <nmadhok> repos should be set up by any formula
13:57:30 <nmadhok> in my opinion
13:57:34 <nmadhok> *should not
13:57:40 <genunix> You don't have to use linux formula, but whatever method user wants - set repos using cloud-init, have them in image, whatever
13:58:06 <genunix> nmadhok: +1 (should not)
13:58:10 <jasondotstar> +1
13:58:28 <cznewt> repos should be setup from one place only according to model
13:58:38 <aryan> 3) and the thirds observation is the dependencies on salt-formula-salt
13:58:50 <aryan> e.g. salt-formula-salt/salt/files/minion.conf
13:59:09 <genunix> aryan: yes, that one needs fixing
13:59:10 <aryan> keystone, heat, and mysql formula are dependent on this
13:59:26 <genunix> aryan: you already did some fixes about this, can you make a reviews?
13:59:44 <aryan> genunix: pull request or gitreview
13:59:50 <cznewt> you can still provide this config in pillars
14:00:19 <jpavlik> cznewt: can we create pillar with samples?
14:00:24 <aryan> cznewt: yes you can, but there you're defining variables twice
14:00:57 <jasondotstar> ok team
14:00:58 <aryan> genunix: https://github.com/aryantaheri/salt-formula-keystone/commit/20412ee194343b9be76d11700ba49fdf84f7cd77
14:01:02 <jasondotstar> times up
14:01:09 <jasondotstar> we can continue our discussion in channel
14:01:12 <jasondotstar> thanks all
14:01:14 <jasondotstar> #endmeeting