14:58:10 <trevor_intel> #startmeeting OPNFV Pharos
14:58:10 <collabot> Meeting started Wed Sep  2 14:58:10 2015 UTC.  The chair is trevor_intel. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:58:10 <collabot> Useful Commands: #action #agreed #help #info #idea #link #topic.
14:58:10 <collabot> The meeting name has been set to 'opnfv_pharos'
14:58:18 <trevor_intel> #info trevor_intel
14:58:38 <iMSWynne> #info iMSWynne
14:58:47 <narindergupta> #info Narinder Gupta
14:58:57 <ChrisPriceAB> #info Chris Price
14:58:59 <fdegir> #info Fatih Degirmenci
15:00:19 <trevor_intel> #info Proposal for agenda topics ... 1) MAAS PoC 2) Rls B Planning (includes CI usage of labs, phaors spec, tooling topics) 3) Lab mangement (but unlikely to get there today)
15:00:44 <trevor_intel> #info Comments / suggestions on agenda please
15:01:33 <ChrisPriceAB> Lab requirements?  Might be part of b rls planning
15:02:34 <trevor_intel> Yes lets list out all rls B topics when we get there, ok?
15:02:56 <ChrisPriceAB> IRC only?
15:03:01 <trevor_intel> yes
15:03:07 <ChrisPriceAB> Ok for me.  :)
15:03:13 <narindergupta> trevor_intel: ok for me too
15:03:36 <trevor_intel> ok if we struggle I will setup a bridge for future
15:03:47 <trevor_intel> #topic MAAS PoC
15:03:47 <ChrisPriceAB> Good not to
15:03:57 <narindergupta> trevor_intel: :)
15:04:03 <iben> i can give us a webex if you want to have voice and recording?
15:04:21 <trevor_intel> lets try IRC for now
15:04:34 <lmcdasm> hello
15:04:34 <trevor_intel> thanks Iben
15:04:43 <iben> #info Iben Rodriguez
15:05:05 <iben> everyone - please info in so we know who you are...
15:05:12 <narindergupta> trevor_intel:  https://wiki.opnfv.org/maas_requirement is the maas requirement page which i put together to setup MAAS in LF lab so that it can assign the community lab for deployment
15:05:17 <fdegir> iben: we already did that
15:05:24 <iben> sorry I’m late - missed it
15:05:25 <lmcdasm> #info daniel smith
15:05:26 <trevor_intel> #Info MAAS team did a demo, made a video and wrote up some requirements
15:05:53 <arturt> #info artur tyloch
15:05:55 <trevor_intel> #info Desire is to do a POC using a community lab and LF infra
15:06:25 <trevor_intel> #info A plan to execute is needed
15:06:30 <iben> so if I want to use MaaS in my community lab it can be “driven” by the central controller already in LF?
15:07:06 <trevor_intel> There is a regional controller in LF lab
15:07:08 <narindergupta> iben: i do not have idea about central controller. is it something like jumpstart?
15:07:45 <iben> and the cluster controller is what I setup in my remote lab - outside the LF infra - right?
15:08:21 <narindergupta> iben: correct
15:08:27 <iben> so communication between regional controller and cluster controller take place over internet - wide area network?
15:08:35 <trevor_intel> Yes ... lets focus on planning for the PoC
15:08:37 <fdegir> have some questions regarding inclusion of LF into POC
15:08:44 <iben> that sounds great - let’s do it.
15:08:46 <narindergupta> iben: basically cluster controller controls the dns/dhcp/tftp on that local cluster of hardware
15:09:17 <trevor_intel> fdegir: questions?
15:09:19 <fdegir> #info do we need to reserve hw in LF dedicated to MAAS?
15:09:41 <fdegir> #info Sicne we already lack hw so it won't be good to lose yet another one
15:10:11 <narindergupta> fdegir: if possible we can live with a VM provided we have bridges on the existing controller server.
15:10:22 <iben> both the regional controller and the cluster controller can be virtual - no?
15:10:44 <narindergupta> iben: yes it can be as far as it has bridges to admin and ipmi network
15:10:49 <fdegir> our plan is to use 6 servers coming from POD1 for builds, virt deploys etc.
15:11:06 <fdegir> if MAAS VM can be colocated with one of the other purposed servers, like build server
15:11:07 <iben> but region controller won’t ipmi - that is the job of the cluster controller inthe remote lab
15:11:11 <fdegir> than it could be OK
15:11:15 <narindergupta> iben: correct
15:11:19 <ChrisPriceAB> Isolating the MaaS on LF & remote would be good. Tunneled VM's if possible.
15:11:48 <iben> is there a desire for 2 region controllers for HA ?
15:11:49 <narindergupta> ChrisPriceAB: cluster controller do the rpc calls to regional controller
15:12:13 <lmcdasm> uh.. Tunneled' VM's through MAAS?  that doesnt make sense to me
15:12:33 <lmcdasm> MAAS will deploy a OStack Infrastructure and then youw ould have to use OStack to do a chaining between the two networks
15:12:48 <lmcdasm> MAAS will only deploy your enviornment.. not have view of the VMs under OStack control.
15:12:48 <narindergupta> lmcdasm: agreed
15:13:15 <narindergupta> lmcdasm: maas just a deployment tool not a monitoring service tool
15:13:24 <ChrisPriceAB> Running MaaS in VM's
15:14:37 <lmcdasm> ?
15:14:38 <fdegir> another question: would MAAS controlled LF POD require changes on installers?
15:15:02 <iben> MasS if being discussed here only to controll remote labs now
15:15:09 <iMSWynne> what is the recommended resource allocation for a cluster controller MAAS VM?
15:15:10 <lmcdasm> Chris - you want to have multple MAAS VM's that deploy to hardware talking to each other?
15:15:21 <iben> there isn’t hardware in LF to control yet - is there?
15:15:25 <narindergupta> fdegir: MAAS can install the installers on bare metal or VM and then handover to different installers to move forward
15:15:59 <fdegir> iben: the subject of the discussion is
15:16:02 <fdegir> Desire is to do a POC using a community lab and LF infra
15:16:13 <fdegir> so that's why I question inclusion of LF into MAAS POC
15:16:21 <fdegir> for community labs, I'm fine
15:16:51 <iben> understood - jsut trying to clarrify - we are talking (I think) about a few vms (just 1?) in the lf lab controlling remote systems in community labs
15:17:34 <fdegir> and that was my other question; if MAAS VM can be colocated on a server located in LF
15:17:36 <lmcdasm> sorry - what is the benefit of having a Controller in LF that does deployment over a VPN tunnel to Metal Machines in other Dcs?
15:17:39 <fdegir> without costing us the entire server
15:17:43 <fdegir> than I'm fine with that as well
15:17:46 <lmcdasm> i dont see the value in the use case - maybe i dont understand the case
15:17:47 <iben> from the drawing - https://wiki.opnfv.org/maas_requirement - there is a HA for the region controller in the LF lab - wanted to know if that needed 2 VMs
15:18:09 <fdegir> given that the LF POD is not included into POC in the beginning
15:18:30 <narindergupta> iben: HA needed mutiple vms yes for clustering
15:18:35 <iben> it’s like having jenkins central infra in lf lab - tho control slaves in remote labs
15:18:47 <iben> is that right MaaS experts?
15:19:16 <lmcdasm> well.. except that jenkins can call mutlple deployrs (the cluster controllers at local site in he digram)
15:19:23 <lmcdasm> whereas MAAS will only deploy that one cluster type
15:20:03 <lmcdasm> so you see a chain where JJB, when its a JOID test CI run, will call the reginal controller that will hook to a communicty lab and do a buikd, merge, verify, etc?
15:20:52 <fdegir> I'm not sure how Jenkins can fit into this picture
15:20:56 <lmcdasm> me neither -
15:21:00 <fdegir> we can request resources from MAAS
15:21:05 <lmcdasm> but maybe for the deployment poc it doesnt matter
15:21:11 <fdegir> by a job
15:21:14 <lmcdasm> since MAAS is the same FUEL essentiall
15:21:18 <fdegir> and once the resource becomes available
15:21:22 <lmcdasm> they are both metal deployers
15:21:23 <fdegir> we do the rest of the stuff
15:21:28 <fdegir> which might complicate things a bit
15:21:33 <lmcdasm> so this POC is to hooku p the chain between the Over Cluster and local cluster
15:21:35 <lmcdasm> which is fine
15:21:42 <fdegir> and
15:21:46 <fdegir> I want to ask another question
15:21:46 <lmcdasm> but im trying to see the case / afterwards - otehr than just a higher level of control
15:21:51 <fdegir> what is the purpose of the POC?
15:22:05 <fdegir> is it making resources available for CI/automation?
15:22:17 <fdegir> or making resources managed for community use/development purposes?
15:22:23 <fdegir> or both?
15:22:36 <fdegir> or deploying fuel/foreman through MAAS
15:22:43 <lmcdasm> fair questino - what is the "proof point" here
15:22:57 <lmcdasm> for the Proof of Concept - that we can do a chained deploytment through two controllers
15:22:58 <lmcdasm> ?
15:23:12 <trevor_intel> Is it not to make community labs multipurpose?
15:23:22 <lmcdasm> hmm. ok -
15:23:27 <lmcdasm> what do we mean multipurpose a
15:23:33 <lmcdasm> and how does this poc satify that?
15:23:44 <narindergupta> fdegir: lmcdasm POC was for automate the deployment once release is available on community lab through LF lab
15:23:58 <fdegir> narindergupta: deployment of what?
15:24:04 <lmcdasm> im wondering of what -
15:24:05 <fdegir> opnfv?
15:24:12 <narindergupta> fdegir: depoloyment of didferent installers
15:24:15 <lmcdasm> since FOREMAN and FUEL already are able to deploy
15:24:30 <lmcdasm> and i see this as something you would want to run under those deployers?
15:24:40 <fdegir> so this will essentially add another layer between jenkins and the deployment mechanism
15:24:55 <fdegir> which will require changes in CI definitely
15:24:59 <fdegir> and perhaps in installers
15:24:59 <lmcdasm> so you would have MAAS calling a FUEL install to deploy OSTACK (you have a second VM you dont need then).
15:25:02 <lmcdasm> yup!
15:25:09 <fdegir> jenkins -> MAAS -> fuel/foreman
15:25:18 <lmcdasm> hmm.
15:25:25 <fdegir> is this the use case?
15:25:33 <narindergupta> fdegir: correct  jenkins -> MAAS -> fuel/foreman/JOID
15:25:51 <fdegir> can we do other way
15:25:54 <iben> there are two huge benefits with MaaS in LF (1) - we get centralized visibility for build out in community labs - yet they remain isolated - good for security and such - (2) - we get fast multi-os bare metal and virtual OS installation with all the juju charms and other such giving us rapid provisioing for OpenDaylight and other fun things we want
15:25:58 <fdegir> jenkins requests resource fro  MAAS
15:26:06 <iben> oh yeah - IPv6 is supported too
15:26:09 <fdegir> and once we get the resources, jenkins does the deploy
15:26:36 <iben> also - i thoguht we were getting hardware for LF lab and would use the MaaS for that
15:26:39 <fdegir> since I thought the first benefit we can get from MAAS is to ability to manage labs
15:26:54 <fdegir> not do full stuff - perhaps right in the first place
15:26:55 <narindergupta> fdegir: jenkins can tell MAAS to deploy a particualr install in community lab 1/2/3
15:27:08 <fdegir> that I understand
15:27:17 <fdegir> but why do we want to do that?
15:27:30 <fdegir> that's my question
15:27:47 <fdegir> as long as we get CI dedicated resources from lab
15:27:48 <iben> BTW - will lab 1 admins be able to run MaaS jobs in Lab 1 only?  or how will we split up roles here?
15:27:55 <fdegir> we can do the same with existing CI setup
15:28:11 <fdegir> or once we get resource reserved for CI temporarily by MAAS
15:28:16 <fdegir> we can do the same again
15:28:23 <narindergupta> fdegir: as per my undrstanding there is no standard way to deploy Arno release right now in community labs through linux foundation lab and no flexibility or reuse of the comunity labs
15:28:34 <lmcdasm> iben - we already have the second point - just fyi with the auto deployer on FUel/Foreman
15:28:51 <lmcdasm> hmm.. i dont know about that narinder
15:28:56 <fdegir> narindergupta: and that is where I think maas can help us
15:29:04 <trevor_intel> Can we organise a small team to drive the PoC and figure the usage model questions? We need to get to other topics.
15:29:05 <fdegir> no flexibility or reuse of the cocmmunity labs
15:29:06 <iben> i can’t use fuel/forman today to push an os to my lab
15:29:12 <trevor_intel> #info iMSWynne (Michael Wynne) will help drive the PoC from Intel side.
15:29:12 <iben> i don’t use physical
15:29:14 <fdegir> that is our first problem to solve
15:29:21 <fdegir> at least for me personally
15:29:28 <fdegir> we don't have visibility of the labs
15:29:28 <lmcdasm> Iben - what do you mean "push" your lab - are you talking about nightly automated builds
15:29:29 <fdegir> or usability
15:29:37 <lmcdasm> or doing a deployment through jenkines
15:29:42 <fdegir> deploying stuff on them via MAAS is secondary
15:29:45 <fdegir> for me again
15:29:46 <lmcdasm> since a deployment and test in the CI pipelines works fine
15:30:01 <lmcdasm> ok - well - i would say
15:30:03 <iben> nightly would be great - how about manual automated builds?  say i want to run arno in a vm?
15:30:04 <fdegir> and I'm not against any next steps
15:30:12 <fdegir> just trying to get our priorities aligned
15:30:12 <lmcdasm> that if the goal is to provide a view to the lab usage and what is deployed int he communicty
15:30:20 <lmcdasm> we can get away with that without using a full metal deployer
15:30:32 <lmcdasm> again Iben
15:30:35 <lmcdasm> FUEL already has this
15:30:40 <iben> or I want to give someone else permission to use some capacity in my lab?
15:30:43 <lmcdasm> you can deploy to metal or a libvirt/KVM automatically
15:30:52 <ChrisPriceAB> Guys, I think the POC will help answer a lot of these questions.  Let's see how it goes and get answers from the activity.
15:30:53 <lmcdasm> well -= that capacity question is a Metal issue in your lab
15:31:09 <lmcdasm> i would not be in a position to put a regional controller in LF that would allow Resource allocation in a community lab
15:31:11 <fdegir> trevor_intel: I think it's a good idea to have POC team
15:31:13 <iben> we need to be able to do this centrally and with shared visibility
15:31:22 <lmcdasm> i think the "Use cases" need to be cleaned up cause there are "alot of them" and they are all good
15:31:26 <fdegir> with clear priorities
15:31:38 <lmcdasm> but as Fatih said - the "purpose of the Proof of concept" remember its a proof
15:31:44 <fdegir> then we can evaluate different cases
15:31:47 <lmcdasm> cause so far i havent seen in the links anything that we cant do today
15:31:47 <fdegir> and see the value
15:31:57 <lmcdasm> so im trying to see the "new concept" we are trying to prove
15:32:04 <lmcdasm> since we know the reginal MAAs thing will work
15:32:14 <lmcdasm> we know we can auto deploy from Jenkins with what we have today
15:32:21 <lmcdasm> we have support for BM and nested environments
15:32:40 <lmcdasm> so i just trying to see how if we combine this it comes as a "new thing" that we can sing about :)
15:32:51 <lmcdasm> i think its a good idea to have a session to nail down what we want to see / accomplish
15:32:54 <trevor_intel> Lets stop here please
15:33:05 <trevor_intel> Who will help drive the PoC?
15:33:22 <trevor_intel> iMSWynne from Intel side
15:33:49 <fdegir> I definitely want to signup as CI/automation rep
15:33:51 <iben> the spirent lab is available - we can setup the cluster controller there with some dedicated networks
15:34:06 <trevor_intel> I think we need somebody to lead it
15:34:23 <iben> someone with MaaS experience?
15:34:23 <trevor_intel> Volunteer?
15:34:36 <lmcdasm> who know the desired use cases best
15:34:43 <lmcdasm> since it woulud seem it would be theirs to drive
15:34:45 <ChrisPriceAB> I volunteer narinder !!!  ;)
15:34:49 <lmcdasm> haha
15:34:51 <narindergupta> trevor_intel: iben: i know MAAS
15:35:01 <trevor_intel> Ok Narinder?
15:35:04 <iben> +1 narindergupta
15:35:13 <fdegir> +1
15:35:16 <trevor_intel> +1
15:35:25 <ChrisPriceAB> +1
15:35:46 <uli-k> +1
15:35:56 <ChrisPriceAB> I'd like to lurk but will not be useful.
15:35:59 <lmcdasm> So Narinder will be in charge or clarifying the use cases and outlining the "proof point"
15:36:01 <lmcdasm> +1
15:36:03 <ChrisPriceAB> In general
15:36:33 <trevor_intel> narindergupta: do you accept the nomination?
15:36:46 <narindergupta> trevor_intel: yeah sure i will work towards it
15:37:13 <trevor_intel> #info narindergupta will lead MAAS PoC
15:38:02 <trevor_intel> narindergupta: lets get an update next week?
15:38:17 <trevor_intel> #topic Rls B planning for Pharos
15:38:22 <narindergupta> trevor_intel: sure
15:38:30 <fdegir> narindergupta: can you please start an etherpad or somethin
15:38:33 <lmcdasm> for you MAAS experts - here is my first qestion - having tried it - since MAAS expects to have a) control on the BM via PXE and b) expects pre-defined images for deployment - how do you get around having the FOREMAN and FUEL images being booted/intalled with config and then they will bring up their own PXE server to boot the remainder.. I wasnt able to find how to tell MAAS to stop PXE and let HW control go down to the other installers
15:38:33 <lmcdasm> without rebooting the nodes a couple of times (which breaks automation).
15:38:49 <trevor_intel> MAAS topic has ended
15:38:54 <lmcdasm> sorry - was typing
15:38:55 <lmcdasm> next time .
15:38:56 <lmcdasm> :)
15:38:59 <trevor_intel> :)
15:40:07 <trevor_intel> We have a few weeks to plan requirements/milestones/dependenceies for Pharos to get to rls misetone "C"
15:40:57 <fdegir> we have collected very basic/initial reqs for CI parts
15:41:15 <fdegir> and added that to Pharos Release B spec
15:41:17 <trevor_intel> Should we list out all teh topics to start?
15:41:45 <fdegir> trevor_intel: I think we had a list from before the summer
15:41:56 <fdegir> Pharos B deliverables
15:42:08 <fdegir> compliance, lab spec, etc.
15:42:09 <trevor_intel> So lets prioritise
15:43:12 <trevor_intel> CI usage of community labs is one where there has been some requirements documented
15:44:06 <trevor_intel> What other lab requirements do we need from other projects?
15:44:26 <wshao_> For CI part of the specs, how is it related to releng project?
15:44:51 <wshao_> Sorry I am new to the projects
15:45:11 <fdegir> wshao_: I don't see any mention to any project
15:45:15 <fdegir> in those reqs
15:45:29 <fdegir> it is just plain old CI
15:45:35 <wshao> Ok
15:45:52 <trevor_intel> #link   https://wiki.opnfv.org/pharos_rls_b_plan
15:46:06 <fdegir> meaning that any activity that is running in automated fashion requires certain things
15:46:14 <fdegir> and that's what we tried to capture
15:47:38 <trevor_intel> fdegir: lets go through them?
15:47:53 <trevor_intel> shall provide means/utilities to (re)configure them automatically when necessary
15:48:21 <trevor_intel> Is this not what MAAS gets at?
15:48:23 <fdegir> automatic (re)configuration: this is actually valid for automated activities and for developer
15:48:43 <fdegir> trevor_intel: that was my other question regarding MAAS which I've forgotten to ask
15:48:50 <fdegir> can MAAS do that?
15:50:16 <fdegir> some more info about this
15:50:24 <wshao> Installers should handle that. We should not require MAAS. It is just one of the ways to do Bare metal provisioning
15:50:26 <trevor_intel> For now at least in my mind I have MAAS against that requirement ... can that be a goal of the PoC to prove out?
15:50:28 <fdegir> Peter Bandzi written a utility to do this for LF lab
15:50:44 <fdegir> wshao: it is not installer thingy
15:50:58 <fdegir> it is done via UCS if I'm not terribly mistaken
15:51:03 <fdegir> for LF lab
15:51:08 <fdegir> https://gerrit.opnfv.org/gerrit/gitweb?p=releng.git;a=tree;f=utils/lab-reconfiguration
15:51:23 <trevor_intel> Community labs are not UCS
15:51:36 <fdegir> yes
15:51:46 <fdegir> the reason I mention what we have is to give an example regarding this requirement
15:51:54 <trevor_intel> and pehaps if LF infra grows it will not be either
15:52:04 <fdegir> each lab should provide mechanisms to do what we are doing for LF
15:52:12 <fdegir> UCS or not
15:52:22 <lmcdasm> question if i can?
15:52:24 <wshao> fdegir: why not? Are we talking about re-configure a stack?
15:53:03 <fdegir> lab infra is something handled by pharos
15:53:04 <lmcdasm> with the exception of doing a Virtual Setup - wher eyou can specific / fake out the networking, how do you plan to deal with the physical environments in the labs
15:53:05 <fdegir> not via installers
15:53:20 <lmcdasm> those that use VLANs, dont, specific switch settings?  since each installer will need different configurations.
15:53:36 <lmcdasm> if you are going to switch between installers doing deployments (from MAAS or not).
15:54:10 <lmcdasm> will you require that community labs provide a generic (one configuratnoi that meets all installers) approach for hardware networking cofiiguration
15:54:19 <lmcdasm> or will we just mandate all virtual deployments or?
15:54:44 <lmcdasm> my point is that while you can use whatever PXE/TFTP boot server combo with IPMI you want to the hardware and boot OS
15:54:45 <trevor_intel> All community labs need to adhere to teh Pharos spec
15:54:59 <lmcdasm> that is easy - but eac installer bring different topologies so how to deal with that change?
15:55:18 <lmcdasm> thx trevor- and the pharos spec is matches the changing reqs of the installers coming online?
15:55:59 <lmcdasm> or just the reference arch?
15:57:01 <trevor_intel> Installers should beable to be confgured to a baseline specificaiton of compute, netowrk and storage
15:57:27 <lmcdasm> hmm. ok - well ni the LF / ARNO release, we have two toplogies
15:57:36 <lmcdasm> and this required a script and networking setip to support both
15:57:45 <lmcdasm> if we are doing to say "they should just support it" fine.
15:57:57 <lmcdasm> i bring it up that community labs will not have the resources necessarily to do this
15:57:59 <lmcdasm> thats all
15:58:24 <trevor_intel> That is what we have to define ... the resources needed
15:58:39 <trevor_intel> And put this on the labs to support
15:58:54 <lmcdasm> hmm. ok.. seems chicken and egg but lets go with it
15:58:54 <lmcdasm> :)
15:58:57 <trevor_intel> That IS the Pharos spec I think
15:59:03 <fdegir> just to highlight again; ability to configure or rollback labs to initial/original state stuff is valid for non-CI uses
15:59:40 <fdegir> and I'm not sure if we should expect everyone to be able to do this if labs are not going to provide it
15:59:52 <fdegir> or provide a dedicated person to do this for each and every request
16:00:01 <fdegir> that's why the scripted configuration is there
16:01:00 <trevor_intel> Next requirement: labs shall be integrated to (yet to be defined/created) Pharos Booking System so they be booked by CI or individual developers
16:01:15 <trevor_intel> Any ideas on this?
16:01:57 <trevor_intel> Or this one: labs shall be integrated to (yet to be defined/created) Pharos Dashboard so the availability of them can be tracked realtime
16:02:23 <lmcdasm> hmm.. well
16:02:35 <lmcdasm> for this part i have been workng on a lab dashboard for our own management
16:02:47 <fdegir> this also depends on maas poc perhaps
16:02:51 <trevor_intel> There are other less difficult requirements ... the 3 mentioned are the hard ones ... agree?
16:02:52 <lmcdasm> but nothing that could be put forth.
16:03:07 <lmcdasm> agreed- cause the scope is a bit interdepedent.
16:03:25 <fdegir> yes
16:03:31 <lmcdasm> for example - the last one could mean that we just want the monitoring of the lab usage on a HW level, or more granular
16:03:40 <lmcdasm> and the permission and admin/operator cases come into play
16:03:46 <lmcdasm> so the scope could be really really big or simple
16:03:55 <fdegir> lmcdasm: :)
16:03:59 <lmcdasm> i think we need to refine those three biggies into something more concrete and manageble
16:04:10 <lmcdasm> so that we can deliver something specific.. and with expected results / features
16:04:10 <trevor_intel> Need help to define next steps
16:04:11 <fdegir> agree
16:04:14 <trevor_intel> agree!
16:04:21 <iben> regarding pharos spec can there be only one choice?  Or can you, for example, say here are 3 ways: access ports and trunk ports or vxlan
16:04:23 <fdegir> why they need to be integrated to dashboard/booking system
16:04:35 <lmcdasm> iben - its a possible method
16:04:37 <iben> we should offer flexibility
16:04:37 <fdegir> I can try to add some more details
16:04:48 <lmcdasm> we can say " you need to support a subnet of these tech" or something like that
16:04:55 <lmcdasm> and have that match the various installer requirements.
16:05:00 <lmcdasm> (which we would need to get / fetch)
16:05:07 <iben> i agree with standards but we can’t say everyone should do things exactly the same way
16:05:32 <lmcdasm> im a bit fuzzy as to how MAAS (Not the POC but in general) fits inot the OPNFV picture, since it would be an installer on par (not undercloud) to FOREMAN/FUEL at thisp oint i would think - not discounting the POC ideas at all
16:05:33 <trevor_intel> no but we need a minimum, otherwise teh concept of Pharos goes away
16:05:38 <trevor_intel> and everythign is proivate
16:05:46 <lmcdasm> but in terms of getting requiremetns, since MAAS would have to fit the mold for FOREMAN and FUEL set so far
16:05:55 <lmcdasm> agreed trevor
16:06:05 <lmcdasm> and we have the ref architecture and some structure alrady
16:06:28 <lmcdasm> we have a configuration spec required to run CI, i think we should look to expand on what we have with some 'new things" that lead towards a goal (MAAS POC or something else)
16:06:34 <lmcdasm> rathe than bite off too much to start
16:06:35 <trevor_intel> I think we all grap the problem :)
16:06:38 <trevor_intel> grasp
16:06:39 <lmcdasm> with something 'new"
16:07:06 <lmcdasm> for example
16:07:18 <lmcdasm> rather than 'montior,view and deploy" to all community labs from central case
16:07:35 <lmcdasm> what about for milestone - we have "we have connectivity from a centreal spot" to view HW resources
16:07:36 <lmcdasm> (stop)
16:07:47 <lmcdasm> if we get further we can add "and you can order/delte/move/etc"
16:07:55 <lmcdasm> but getting a view would be enough to start i think
16:08:19 <lmcdasm> and then we can look at SW / tools to do this (im in favour of a Cloud-OSS myself - openNMS works nice for running my labs) but it can start the discussion
16:08:28 <lmcdasm> and maybe we can cut down on the big ones like that
16:08:30 <lmcdasm> ?
16:08:34 * lmcdasm just an idea
16:08:51 <trevor_intel> lmcdasm: do you want to write up ideas for the milestones on Wiki?
16:08:57 <fdegir> about config spec: we have basic examples for fuel and foreman
16:09:11 <lmcdasm> i can try to water down what is there
16:09:13 <fdegir> which can perhaps be used as base for the other installers
16:09:27 <lmcdasm> although the link you sent and the lines you quote in this IRC dont match so i might be looking at the wrong page
16:09:28 <fdegir> and then labs can take those things to see if they can come up with corresponding stuff
16:09:42 <lmcdasm> we can yes - i think its a question of how we want to position
16:09:48 <lmcdasm> are we saying "these are the rules and you must"
16:09:54 <lmcdasm> or "here is things you can and try this"
16:09:55 <fdegir> lmcdasm: CI requirements are here https://wiki.opnfv.org/pharos_rls_b_spec
16:10:01 <fdegir> together with others
16:10:03 <lmcdasm> thx Fatih for the link
16:11:39 <lmcdasm> Trevor - i can try it sure - so far i have the paros_rls_b_plan and b_spec doc
16:11:50 <trevor_intel> I htink we are saying here are some basic rules that you must for purposes A (e.g. CI) B (e.g. dev)  C(...)   AND here are some things you can try for D E F
16:11:51 <lmcdasm> are there any other inputs i should look at to come up with targets?
16:12:10 <lmcdasm> ok - sounds good trevor
16:12:15 <trevor_intel> lmcdasm: that is is so far
16:12:37 <lmcdasm> ok... so put and action on me ot have some tangilble targets baed on the spec
16:12:52 <lmcdasm> and ill create a wiki and come up with a "thing we can see/measure/" for some of the spec
16:13:09 <lmcdasm> at the very lesat it will start converstaion since i might not "guess" the motive of each of the lines
16:13:13 <lmcdasm> but it might help!
16:13:47 <fdegir> lmcdasm: will try to clarify those lines, especially CI lines for you
16:13:56 <trevor_intel> #action lmcdasm to draft draft of milestones based on  spec requirements
16:14:00 <fdegir> and make them simpler
16:14:23 <trevor_intel> that will help us get going for sure
16:14:24 <lmcdasm> narider_gupta
16:14:43 <lmcdasm> what is a good time for you - since i would like to pick your brain some more about the "Ragional Controller" ability and functions
16:14:55 <lmcdasm> do you have availability tomorrow / friday for a 30 minute session ?
16:15:23 <trevor_intel> fdegir: what else can we do today?
16:15:39 <fdegir> trevor_intel: I think this is a good start
16:15:43 <fdegir> we have 2 names to bug
16:15:51 <fdegir> for POC and reqs
16:16:05 <trevor_intel> indeed ... and bug we must
16:16:19 <fdegir> the other stuff we had like having labs to provide their capabilities in common format
16:16:28 <fdegir> and for installers to provide their reqs in common format
16:16:31 <fdegir> the template stuff
16:16:56 <fdegir> at least we know that we should have them for B release
16:17:06 <fdegir> we just  need to define the templates
16:17:13 <fdegir> and then expected information from labs/installers
16:17:15 <trevor_intel> Should I try to thow them against some miletones?
16:17:22 <iben> requirements should use specifc type of language - right?  should, must, could
16:17:26 <fdegir> which we have examples from either arno or from current installers
16:17:36 <fdegir> they shall use shall I think
16:17:56 <fdegir> trevor_intel: can't say if they should be tied to milestons
16:18:01 <fdegir> but they should at least be in the backlog
16:18:10 <lmcdasm> well..
16:18:14 <lmcdasm> my two cents
16:18:17 <trevor_intel> But that is expected for rls plan?
16:18:38 <lmcdasm> the plan is high level - we should generate a requiremnts document with the milesontes
16:18:45 <lmcdasm> (fatih and i will take a first stab and send that around)
16:18:56 <lmcdasm> iben - you are right - if we do "requirements" then should,must, etc will be used
16:18:57 <trevor_intel> Ok perfect, thanks!
16:19:02 <lmcdasm> however its a good question
16:19:06 <fdegir> trevor_intel: tbh, I don't remember all the milestones
16:19:19 <lmcdasm> since i would wonder if we dont follow others and use user-stories and JIRA ticktes
16:19:31 <trevor_intel> We should
16:19:33 <lmcdasm> and get our stuff all up in there (and that way we could be free to use whatever language a person likes best)
16:19:58 <fdegir> lmcdasm: As an OPNFV developer, I want to have ... so that I can ...
16:20:02 <trevor_intel> I am still ramping up on Jira :(
16:20:02 <lmcdasm> if Iben wnats to do a requirement like "An Community Lab must provie a Node that can run VM's that is connected to a central hub"
16:20:04 <lmcdasm> then he can
16:20:09 <trevor_intel> You guysa are it
16:20:10 <fdegir> reqs -> user stories
16:20:26 <lmcdasm> and if I want to put "As a opnfv installer developer, i want to have CI pipeline test my nightly build" i can ass well
16:20:37 <lmcdasm> then we can cut a list of "features" (subsets of those in JIRA)
16:20:38 <fdegir> yep
16:20:54 <lmcdasm> and you can sort out targets (to assign to make people do the work) with expected results
16:21:02 <lmcdasm> and then at some point- you see what you got and call a release :)
16:21:05 <fdegir> it must be written from user point of view as you did above
16:21:15 <fdegir> so that story actually needs to be written by me
16:21:17 <fdegir> for you
16:21:27 <trevor_intel> Ok start writing!
16:21:31 <trevor_intel> :)
16:21:32 <lmcdasm> ok.. one question
16:21:45 <lmcdasm> is jira setup for pharos?
16:21:51 <trevor_intel> Yes
16:21:54 <lmcdasm> groovy
16:22:06 <lmcdasm> can you send the link around
16:22:08 <fdegir> https://jira.opnfv.org/browse/PHAROS
16:22:11 <iben> lmcdasm: i would say could or should - but not must - at this point - we need to rate or rank the labs as to their purpose - some are more for research and development at this point
16:22:16 <lmcdasm> and have everyone join in as a watches
16:22:27 <lmcdasm> sure iben - the language you use is what you think is best
16:22:31 <lmcdasm> agreed Must was wrong *
16:22:36 <iben> ha ha - np
16:23:00 <fdegir> need to do clean pharos backlog
16:23:28 <fdegir> will take a look at it and perhaps with Daniel we can convert some of the requirements to stories
16:24:04 <lmcdasm> we have to keep in mind our capacity - there arent alot of people in there, less labs and hardware, so i think (and im just putting it out there)
16:24:06 <fdegir> with clear definition of done/acceptance criteria so they make sense for the lab owners and for us
16:24:35 <lmcdasm> that our vision / goal for the releae should be something along the lines of achieveing "interconncted and visibilyt to all community labs
16:24:51 <trevor_intel> fdegir: Thansk if you can clean and start the stories we can move forward
16:24:52 <fdegir> that is what I call is the theme
16:25:04 <fdegir> so we can say the Pharos theme for B-release
16:25:12 <fdegir> "interconnected ..."
16:25:13 <lmcdasm> if we can get so far as a documented framework and common method that they will connect (i.e a mulit-use jumphost that talks to central ndoe somewhere" and we can see "all the hardare" (ipmi scan")
16:25:21 <lmcdasm> and show that on a web page with a map under it
16:25:27 <trevor_intel> I like the theme
16:25:28 <lmcdasm> i would say we would have accomplished alot
16:25:31 <fdegir> so everyone can get 1 sentence with regards to what pharos is trying to deliver for B-release
16:25:40 <lmcdasm> and then from there - people can tack on their features (add/remove/mass, etc)
16:26:01 <lmcdasm> sorry - my typing is really bad today - new keyboard and its a clacky one *
16:26:26 <lmcdasm> is that something we agree on then maybe
16:26:42 <lmcdasm> that we will limit our scope to (supported wise - not saying we cant go furhter if things pick up)
16:27:05 <lmcdasm> but saying " we will show that we have a link between all labs, and can view the aggregate of OPNFV deployments / uses around the world"
16:27:08 <lmcdasm> from a common portal
16:27:13 <lmcdasm> - i think it sounds sexy
16:27:14 <fdegir> I think it is better to overestimate the time it takes we complete stuff
16:27:23 <fdegir> to reduce the risk of failing
16:27:29 <fdegir> rather than promising lots of things
16:27:32 <lmcdasm> yup
16:27:34 <trevor_intel> Makes sense
16:27:39 <fdegir> if we can get the visibility and usability of labs increased
16:27:44 <fdegir> that's a big deal
16:27:49 <lmcdasm> since to be honest, in all my IRC's this is the smaller list of people on the right i have seen :)
16:27:51 <trevor_intel> Yes agree that is the goal
16:28:04 <lmcdasm> for sure - im thinking about something simple- and ill show ya next week if you like
16:28:11 <fdegir> and pharos is one of the projects we always market opnfv with
16:28:15 <lmcdasm> in a drawing.. but it would be super neat - allow for us to grow
16:28:17 <fdegir> federated labs - come and use them
16:28:19 <lmcdasm> and not take alot of tech/coding
16:28:39 <fdegir> I think we know what to do
16:28:41 <lmcdasm> anyway - sounds like we have agreed on what we wanna do for Bre
16:28:44 <lmcdasm> B-rel*
16:29:03 <fdegir> hopefully next week we can have an initial backlog populated using refined requirements
16:29:10 <lmcdasm> good target for next week!
16:29:12 <trevor_intel> Great
16:29:12 <fdegir> + some stories for template stuff + POC story
16:29:22 <fdegir> then we can point people to there
16:29:23 <lmcdasm> one question - is there anything to think about for SR1 in pharos ?
16:29:36 <lmcdasm> and its Nardiner will define with Iben the POC story then?
16:29:37 <fdegir> I think we should release sr1 as we did for arno
16:29:46 <fdegir> with no changes
16:30:00 <lmcdasm> ok.. so nothing to do for Sr1 in this project then Trevor?
16:30:13 <fdegir> and for POC story, we can create one where narindergupta and iben can reword it
16:30:24 <lmcdasm> hmm.
16:30:27 <lmcdasm> its alot for you and i
16:30:28 <trevor_intel> err ... not sure
16:30:35 <lmcdasm> and i would like to keep the requiremenst and the POC seperate
16:30:40 <lmcdasm> since one is our goal
16:30:43 <lmcdasm> and the other is a method to get them done
16:30:50 <lmcdasm> maybe they can run with the POC idea and we can beat it up
16:30:50 <fdegir> but we have to show POC as well
16:30:54 <iben> the joid project is one poc for pharos - can we say that?
16:30:54 <lmcdasm> and they can do that for our stuff
16:30:57 <fdegir> it is just a line story
16:30:58 <trevor_intel> yes agree keep separate
16:31:00 <lmcdasm> yup
16:31:04 <lmcdasm> i mean - we can all do it
16:31:06 <fdegir> separate story I mean
16:31:14 <lmcdasm> but Fatih - you and i just took a big chunk
16:31:20 <lmcdasm> of the reqs and work for next weds
16:31:28 <fdegir> lmcdasm: I'm good with JIRA
16:31:35 <fdegir> and you're good with words :D
16:31:40 <lmcdasm> i would hope someone else can run with coming up with a one/ two pager for the POC and give us a drawing of what the end to end loosk like
16:31:41 <fdegir> so you tell I write
16:31:52 <fdegir> lmcdasm: that's part of the story
16:31:54 <lmcdasm> and the pros/cons for it / how to deal with some of the installer reqs going forward, etc
16:31:56 <fdegir> POC Spec
16:31:59 <lmcdasm> ok
16:31:59 <fdegir> 1 story
16:32:01 <lmcdasm> ok
16:32:01 <lmcdasm> ok
16:32:03 <lmcdasm> :)
16:32:04 <trevor_intel> ok
16:32:20 <trevor_intel> I feel a lot better suddenly
16:32:27 <trevor_intel> thanks guys!
16:32:40 <lmcdasm> :)
16:32:57 <fdegir> thanks trevor_intel for starting this up
16:33:54 <trevor_intel> my pleasure
16:33:58 <trevor_intel> #endmeeting