Re: [openstack-dev] [Ironic][Tripleo] ipmitool issues HP machines

[Sanjay Upadhyay]

On Wed, Apr 4, 2018 at 6:09 PM, Dan Prince <dpri...@redhat.com> wrote:

> Kind of a support question but figured I'd ask here in case there are
> suggestions for workarounds for specific machines.
>
> Setting up a new rack of mixed machines this week and hit this issue
> with HP machines using the ipmi power driver for Ironic. Curious if
> anyone else has seen this before? The same commands work great with my
> Dell boxes!
>
>
Are you using ILO Drivers?
https://docs.openstack.org/ironic/latest/admin/drivers/ilo.html
/sanjay

> -
>
> [root@localhost ~]# cat x.sh
> set -x
> # this is how Ironic sends its IPMI commands it fails
> echo -n password > /tmp/tmprmdOOv
> ipmitool -I lanplus -H 172.31.0.19 -U Adminstrator -f /tmp/tmprmdOOv
> power status
>
> # this works great
> ipmitool -I lanplus -H 172.31.0.19 -U Administrator -P password power
> status
>
> [root@localhost ~]# bash x.sh
> + echo -n password
> + ipmitool -I lanplus -H 172.31.0.19 -U Adminstrator -f /tmp/tmprmdOOv
> power status
> Error: Unable to establish IPMI v2 / RMCP+ session
> + ipmitool -I lanplus -H 172.31.0.19 -U Administrator -P password power
> status
> Chassis Power is on
>
> Dan
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Sanjay Upadhyay
IRC #saneax
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tripleo] rename ovb jobs?

[Sanjay Upadhyay]

On Fri, Dec 1, 2017 at 2:17 PM, Bogdan Dobrelya  wrote:

> On 11/30/17 8:11 PM, Emilien Macchi wrote:
>
>> A few months ago, we renamed ovb-updates to be
>> tripleo-ci-centos-7-ovb-1ctlr_1comp_1ceph-featureset024.
>> The name is much longer but it describes better what it's doing.
>> We know it's a job with one controller, one compute and one storage
>> node, deploying the quickstart featureset n°24.
>>
>> For consistency, I propose that we rename all OVB jobs this way.
>> For example, tripleo-ci-centos-7-ovb-ha-oooq would become
>> tripleo-ci-centos-7-ovb-3ctlr_1comp-featureset001
>> etc.
>>
>> Any thoughts / feedback before we proceed?
>> Before someone asks, I'm not in favor of renaming the multinode
>> scenarios now, because they became quite familiar now, and it would
>> confuse people to rename the jobs.
>>
>> Thanks,
>>
>>
> I'd like to see featuresets clarified in names as well. Just to bring the
> main message, w/o going into the test matrix details, like
> tripleo-ci-centos-7-ovb-3ctlr_1comp-featureset001-ovn/ceph/k8s/tempest
> whatever it is.
>
>
How is this looking?

tripleo-ci/os/centos/7/ovb/ha/nodes/3ctrlr_1comp.yaml
tripleo-ci/os/centos/7/ovb/ha/featureset/ovn_ceph_k8s_with-tempest.yaml

I also think we should have clear demarcation of the oooq variables ie
machine specific goes to nodes/* and feature related goes to featureset/*

regards
/sanjay



> --
> Best regards,
> Bogdan Dobrelya,
> Irc #bogdando
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tripleo] Proposing Saravanan KR core

[Sanjay Upadhyay]

On Mon, Jul 24, 2017 at 12:10 PM, Marios Andreou 
wrote:

>
>
> On Fri, Jul 21, 2017 at 6:01 PM, Emilien Macchi 
> wrote:
>
>> Saravanan KR has shown an high level of expertise in some areas of
>> TripleO, and also increased his involvement over the last months:
>> - Major contributor in DPDK integration
>> - Derived parameter works
>> - and a lot of other things like improving UX and enabling new
>> features to improve performances and networking configurations.
>>
>> I would like to propose Saravanan part of TripleO core and we expect
>> his particular focus on t-h-t, os-net-config and tripleoclient for now
>> but we hope to extend it later.
>>
>> As usual, we'll vote :-)
>> Thanks,
>>
>
>
> +1
>
>
>

+1


> --
>> Emilien Macchi
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [TripleO] Let's use Ansible to deploy OpenStack services on Kubernetes

[Sanjay Upadhyay]

On Tue, Jul 18, 2017 at 12:21 PM, Flavio Percoco  wrote:

> On 17/07/17 16:48 -0400, Ryan Hallisey wrote:
>
>> One other thing to mention. Maybe folks can speed up writing these
>> playbooks by using kolla-ansible's playbooks as a shell. Here's an
>> example: [1] Take lines 1-16 and replace it with helm install mariadb
>> or
>> kubectl create -f mariabd-pod.yaml and set inventory to localhost.
>> Just a thought.
>>
>> There may be some other playbooks out there I don' know about that you
>> can use, but that could at least get some of the collaboration started
>> so folks don't have to start from scratch.
>>
>> [1] - https://github.com/openstack/kolla-ansible/blob/afdd11b9a22e
>> cca70962a4637d89ad50b7ded2e5/ansible/roles/mariadb/tasks/start.yml#L1-L16
>>
>
> +1 This is why I think there's still room for collaboration and we can
> re-use
> several of the existing things. I don't think everything would have to be
> written from scratch.
>
>

Not sure if this is an important criteria, however, are we also looking at
using OCI, so that users can perhaps choose between Container platforms?

On the upgrade path we are already using ansible playbooks. How hard would
it be to do a major migrate from current tripleo to a new standard,
whatever is chosen.

One more thing I needed to emphasize is that probably *only* tripleo as it
is now, addresses datacenter/telco specific network paradigm ie what is
done via os-net-config (bonding,sriov,dpdk). We would want to have that
addressed, or at least have a plan in whatever path we chose.

regards
/sanjay


> Flavio
>
> --
> @flaper87
> Flavio Percoco
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Tripleo] Status of monitoring tools

[Sanjay Upadhyay]

Hi Folks,

I recently started work with a requirement to integrate a security tool
with monitoring framework for alerting and logging. I fail to  find
relevant docs in this direction. After looking around for more information,
it seems we do not have the server side implementation at all.

I have created a bug for this
https://bugs.launchpad.net/tripleo/+bug/1676407. IMO, architecturally we
have no place for opstools in the tripleo deployment, yet.

Ideally, there could be a role like MonServer, which can be a specific role
for all the monitoring services (server side). If one wants to reduce the
no of nodes can probably have all the monitoring services on the controller
node.

I am still looking at directions on monitoring services.

regards
/sanjay
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [openstack-docs] [tripleo] Creating official Deployment guide for TripleO

[Sanjay Upadhyay]

On Mon, Mar 20, 2017 at 5:31 PM, Emilien Macchi  wrote:

> I proposed a blueprint to track the work done:
>
> https://blueprints.launchpad.net/tripleo/+spec/tripleo-deploy-guide
> Target: pike-3
>
> Volunteers to work on it with me, please let me know.
>

Please add me (irc handle - saneax), I am interested on this.

regards
/sanjay


> Thanks,
>
> On Tue, Mar 14, 2017 at 7:00 AM, Alexandra Settle 
> wrote:
> > Hey Emilien,
> >
> > You pretty much covered it all! Docs team is happy to provide guidance,
> but in reality, it should be a fairly straight forward process.
> >
> > The Kolla team just completed their deploy-guide patches and were able
> to help refine the process a bit further. Hopefully this should help the
> TripleO team :)
> >
> > Reach out if you have any questions at all :)
> >
> > Thanks,
> >
> > Alex
> >
> > On 3/13/17, 10:32 PM, "Emilien Macchi"  wrote:
> >
> > Team,
> >
> > [adding Alexandra, OpenStack Docs PTL]
> >
> > It seems like there is a common interest in pushing deployment guides
> > for different OpenStack Deployment projects: OSA, Kolla.
> > The landing page is here:
> > https://docs.openstack.org/project-deploy-guide/newton/
> >
> > And one example:
> > https://docs.openstack.org/project-deploy-guide/
> openstack-ansible/newton/
> >
> > I think this is pretty awesome and it would bring more visibility for
> > TripleO project, and help our community to find TripleO documentation
> > from a consistent place.
> >
> > The good news, is that openstack-docs team built a pretty solid
> > workflow to make that happen:
> > https://docs.openstack.org/contributor-guide/project-
> deploy-guide.html
> > And we don't need to create new repos or do any crazy changes. It
> > would probably be some refactoring and sphinx things.
> >
> > Alexandra, please add any words if I missed something obvious.
> >
> > Feedback from the team would be welcome here before we engage any
> work,
> >
> > Thanks!
> > --
> > Emilien Macchi
> >
> >
>
>
>
> --
> Emilien Macchi
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [TripleO][CI] Isolated Network Testing

[Sanjay Upadhyay]

On Thu, Oct 13, 2016 at 4:28 AM, Dan Sneddon  wrote:

> I recently evaluated our needs for testing coverage for TripleO
> isolated networking. I wanted to post my thoughts on the matter for
> discussion, which will hopefully lead to a shared understanding of what
> improvements we need to make. I think we can cover the majority of
> end-user requirements by testing the following minimum scenarios:
>
> 1. single-nic-vlans (one nic, all VLANs trunked, great for virt and POCs)
>
> 2. Provisioning + bond (to test basic bonding functionality)
>
> 3. Bonded provisioning (perhaps one bond with all VLANs)
>
> 4. Spine and leaf (in the near future)
>
>
Is linux bridges, in the list?

Within those four scenarios, we should ensure that we are testing both
> IPv4 and IPv6, and both traditional Neutron SNAT/Floating IPs and DVR.
>
> The first scenario is well covered. I think scenario 2 is covered by a
> review posted by Ben Nemec recently [1].
>
> I would very much like to see us testing scenario 3 with a resilient
> bond for the provisioning interface as well. This used to require LACP
> and fallback to a single link, but I believe recent changes to the PXE
> boot images may allow this over links without special switch
> configuration. I'm currently doing testing in my lab, I hope I can work
> with the TripleO CI team to help make this happen upstream.
>
> Spine and leaf (routed networks) support may require specific
> configuration of the routing hardware in order to support PXE booting
> across router boundaries. Specifically, a DHCP proxy needs to be
> configured in order to forward DHCP requests from a remote VLAN to the
> Undercloud. If this is not possible in our bare-metal CI environments,
> then we may need to develop a method of testing this in OVB.
>
> I'm very interested in finding out about whether it may be possible to
> have DHCP proxy (or "DHCP helper-address") configured on the router
> hardware for CI VLANs. If we can deploy this in bare metal, I think it
> will save us a lot of time and effort over recreating a routed
> environment in OVB. I believe we could use use Open Daylight or another
> OpenFlow controller to simulate routers in virtual environments, or
> perhaps use dnsmasq in DHCP proxy mode on the OVB host to forward
> requests from the various bridges representing remote VLANs to the
> Undercloud br-ctlplane bridge. But it would be a fair amount of work to
> put that together.
>
> I don't believe we currently test IPv6 or DVR (please correct me if I'm
> mistaken). Do we have plans in the works to add these to any jobs?
>
> Finally, I wonder if we need to test any exotic configurations, such as
> OVS+DPDK, OpenDaylight, etc.
>
>
We have SR-IOV as well, which requires specific nics.
Could Tripleo be a good candidate to have different sets of 3rd party CI,
wherein we can run the specific test cases.


> OVS+DPDK would require compatible hardware. I'm interested in hearing
> feedback about how critical this would be in the grand scheme of
> things. It isn't yet clear to me that OVS+DPDK is going to have
> widespread adoption, but I do recognize that there are some NFV users
> that depend on this technology.
>
> OpenDaylight does not require hardware changes AFAIK, but the drivers
> and network interface config differs significantly from ML2+OVS. I'm
> helping some ODL developers make changes that will allow deployment via
> TripleO, but these changes won't be tested by CI.
>
> Of course, there are elements of OVS+DPDK and ODL that get tested as
> part of Neutron CI, but now we are implementing TripleO-based
> deployment of these technologies, I wonder if we should endeavor to
> test them in CI. I suppose that begs the question, if we are testing
> those, then why not Contrail, etc.? I don't know where we draw the
> line, but it seems that we might want to at least periodically test
> deploying some other Neutron drivers via TripleO.
>
>
Adding OVN to the list as well.

regards
/sanjay


> [1] - https://review.openstack.org/#/c/385562
>
> --
> Dan Sneddon |  Senior Principal OpenStack Engineer
> dsned...@redhat.com |  redhat.com/openstack
> dsneddon:irc|  @dxs:twitter
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [TripleO] TripleO Core nominations

[Sanjay Upadhyay]

+1 to all.
we got a lot of constructive inputs and help from @beagles and @dsneddon.
/sanjay

On Fri, Sep 16, 2016 at 8:05 PM, Jason Rist  wrote:

> On 09/15/2016 03:20 AM, Steven Hardy wrote:
> > Hi all,
> >
> > As we work to finish the last remaining tasks for Newton, it's a good
> time
> > to look back over the cycle, and recognize the excellent work done by
> > several new contributors.
> >
> > We've seen a different contributor pattern develop recently, where many
> > folks are subsystem experts and mostly focus on a particular project or
> > area of functionality.  I think this is a good thing, and it's hopefully
> > going to allow our community to scale more effectively over time (and it
> > fits pretty nicely with our new composable/modular architecture).
> >
> > We do still need folks who can review with the entire TripleO
> architecture
> > in mind, but I'm very confident folks will start out as subsystem experts
> > and over time broaden their area of experience to encompass more of
> > the TripleO projects (we're already starting to see this IMO).
> >
> > We've had some discussion in the past[1] about strictly defining
> subteams,
> > vs just adding folks to tripleo-core and expecting good judgement to be
> > used (e.g only approve/+2 stuff you're familiar with - and note that it's
> > totally fine for a core reviewer to continue to +1 things if the patch
> > looks OK but is outside their area of experience).
> >
> > So, I'm in favor of continuing that pattern and just welcoming some of
> our
> > subsystem expert friends to tripleo-core, let me know if folks feel
> > strongly otherwise :)
> >
> > The nominations, are based partly on the stats[2] and partly on my own
> > experience looking at reviews, patches and IRC discussion with these
> folks
> > - I've included details of the subsystems I expect these folks to focus
> > their +2A power on (at least initially):
> >
> > 1. Brent Eagles
> >
> > Brent has been doing some excellent work mostly related to Neutron this
> > cycle - his reviews have been increasingly detailed, and show a solid
> > understanding of our composable services architecture.  He's also
> provided
> > a lot of valuable feedback on specs such as dpdk and sr-iov.  I propose
> > Brent continues this exellent Neutron focussed work, while also expanding
> > his review focus such as the good feedback he's been providing on new
> > Mistral actions in tripleo-common for custom-roles.
> >
> > 2. Pradeep Kilambi
> >
> > Pradeep has done a large amount of pretty complex work around Ceilomenter
> > and Aodh over the last two cycles - he's dealt with some pretty tough
> > challenges around upgrades and has consistently provided good review
> > feedback and solid analysis via discussion on IRC.  I propose Prad
> > continues this excellent Ceilomenter/Aodh focussed work, while also
> > expanding review focus aiming to cover more of t-h-t and other repos over
> > time.
> >
> > 3. Carlos Camacho
> >
> > Carlos has been mostly focussed on composability, and has done a great
> job
> > of working through the initial architecture implementation, including
> > writing some very detailed initial docs[3] to help folks make the
> transition
> > to the new architecture.  I'd suggest that Carlos looks to maintain this
> > focus on composable services, while also building depth of reviews in
> other
> > repos.
> >
> > 4. Ryan Brady
> >
> > Ryan has been one of the main contributors implementing the new Mistral
> > based API in tripleo-common.  His reviews, patches and IRC discussion
> have
> > consistently demonstrated that he's an expert on the mistral
> > actions/workflows and I think it makes sense for him to help with review
> > velocity in this area, and also look to help with those subsystems
> > interacting with the API such as tripleoclient.
> >
> > 5. Dan Sneddon
> >
> > For many cycles, Dan has been driving direction around our network
> > architecture, and he's been consistently doing a relatively small number
> of
> > very high-quality and insightful reviews on both os-net-config and the
> > network templates for tripleo-heat-templates.  I'd suggest Dan continues
> > this focus, and he's indicated he may have more bandwidth to help with
> > reviews around networking in future.
> >
> > Please can I get feedback from exisitng core reviewers - you're free to
> +1
> > these nominations (or abstain), but any -1 will veto the process.  I'll
> > wait one week, and if we have consensus add the above folks to
> > tripleo-core.
> >
> > Finally, there are quite a few folks doing great work that are not on
> this
> > list, but seem to be well on track towards core status.  Some of those
> > folks I've already reached out to, but if you're not nominated now,
> please
> > don't be disheartened, and feel free to chat to me on IRC about it.  Also
> > note the following:
> >
> >  - We need folks to regularly show up, establishing a long-term pattern
> of
> >doing useful reviews, but 

[openstack-dev] [TripleO] Third party CI setup for OVS-DPDK and SRIOV

[Sanjay Upadhyay]

HI Folks,

I am reaching out to understand how best to setup a third party CI for
OVS-DPDK  and SRIOV
.

Since, we have put forth the patches for both sr-iov and ovs-dpdk, I think
its a requirement to test the functionality. Since, this requires specific
h/w, I guess this comes in the purview of third party CI. So, how best to
approach this.

If there is a vendor to back such an initiative, what kind of requirements
we need to post them. I can understand this is very specific question, but
do let me know from Openstack Infra side what are the requirements to
suffice this.

Any pointers on how to setup a third party CI, would be greatly
appreciated. As a part of my commitment, I can assure to document this for
others :)

Many thanks,
/sanjay
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tripleo] TripleO CI mentoring

[Sanjay Upadhyay]

On Tue, Jul 5, 2016 at 10:59 PM, Wesley Hayutin  wrote:

>
>
> On Tue, Jul 5, 2016 at 1:06 PM, Steven Hardy  wrote:
>
>> Hi all,
>>
>> At last weeks meeting, we discussed the idea of some sort of rotation
>> where
>> folks would volunteer their time to both help fix CI when it breaks, and
>> also pass on some of the accrued knowledge within the team to newer folks
>> wishing to learn.
>>
>> I'm hoping this will achive a few things:
>> - Reduce the load on the subset of folks constantly fixing CI by getting
>>   more people involved and familiar
>> - Identify areas where we need to document better so 1-1 mentoring isn't
>>   needed in the future.
>>
>> Note that this is explicitly *not* about volunteering to be the one person
>> that fixes all-the-things in CI, everyone is still encouraged to do that,
>> it's more about finding folks willing to set aside some time to be
>> responsive on IRC, act as a point of contact, and take some extra time to
>> pass on knowledge around the series of steps we take when a trunk
>> regression or other CI related issue occurs.
>>
>> I started this etherpad:
>>
>> https://etherpad.openstack.org/p/tripleo-ci-mentoring
>>
>> I'd suggest we start from the week after the n-2 milestone, and I've
>> volunteered as the first mentor for that week.
>>
>> Feel free to update if you're willing in participating in the ongoing task
>> of keeping TripleO CI running smoothly in any capacity, and hopefully we
>> can get more folks involved and communicating.
>>
>>
+1 to all the effort you guys are putting in. I have added myself under
mentees.

regards
/sanjay

> If anyone has any thoughts around this process feel free to reply here and
>> we can hopefully refine things so they are helpful to folks.
>>
>> Thanks!
>>
>> Steve
>>
>
> Awesome, thanks Steve!
>
>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tripleo] Nodes management in our shiny new TripleO API

[Sanjay Upadhyay]

On Mon, Jul 4, 2016 at 5:12 PM, Steven Hardy  wrote:

> Hi Dmitry,
>
> I wanted to revisit this thread, as I see some of these interfaces
> are now posted for review, and I have a couple of questions around
> the naming (specifically for the "provide" action):
>
> On Thu, May 19, 2016 at 03:31:36PM +0200, Dmitry Tantsur wrote:
> 
> > The last step before the deployment it to make nodes "available" using
> the
> > "provide" provisioning action. Such nodes are exposed to nova, and can be
> > deployed to at any moment. No long-running configuration actions should
> be
> > run in this state. The "manage" action can be used to bring nodes back to
> > "manageable" state for configuration (e.g. reintrospection).
>
> So, I've been reviewing https://review.openstack.org/#/c/334411/ which
> implements support for "openstack overcloud node provide"
>
> I really hate to be the one nitpicking over openstackclient verbiage, but
> I'm a little unsure if the literal translation of this results in an
> intuitive understanding of what happens to the nodes as a result of this
> action. So I wanted to have a broaded discussion before we land the code
> and commit to this interface.
>
> More info below:
> 
> > what do you propose?
> > 
> >
> > I would like the new TripleO mistral workflows to start following the
> ironic
> > state machine closer. Imagine the following workflows:
> >
> > 1. register: take JSON, create nodes in "manageable" state. I do believe
> we
> > can automate the enroll->manageable transition, as it serves the purpose
> of
> > validation (and discovery, but lets put it aside).
> >
> > 2. provide: take a list of nodes or all "managable" nodes and move them
> to
> > "available". By using this workflow an operator will make a *conscious*
> > decision to add some nodes to the cloud.
>
> Here, I think the problem is that while the dictionary definition of
> "provide" is "make available for use, supply" (according to google), it
> implies obtaining the node, not just activating it.
>
> So, to me "provide node" implies going and physically getting the node that
> does not yet exist, but AFAICT what this action actually does is takes an
> existing node, and activates it (sets it to "available" state)
>
> I'm worried this could be a source of operator confusion - has this
> discussion already happened in the Ironic community, or is this a TripleO
> specific term?
>
> To me, something like "openstack overcloud node enable" or maybe "node
> activate" would be more intuitive, as it implies taking an existing node
> from the inventory and making it active/available in the context of the
> overcloud deployment?
>


My 2 cents, as a operator, the part wherein a node is enrolled, manageable,
available is a bit confusing to first timers.
If we have something more simple ie all baremetal nodes (baremetal nodes
are the nodes enrolled or manageable states), all cluster nodes (are either
available or deployed states).

I do not know if there is a deployed state :)
regards
/sanjay


>
> Anyway, not a huge issue, but given that this is a new step in our nodes
> workflow, I wanted to ensure folks are comfortable with the terminology
> before we commit to it in code.
>
> Thanks!
>
> Steve
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [TripleO] TripleO deep dive hour?

[Sanjay Upadhyay]

+1 great, looking forward to it.

On Wed, Jun 29, 2016 at 5:29 AM, Victoria Martínez de la Cruz <
victo...@vmartinezdelacruz.com> wrote:

> +1 Awesome idea!
>
> 2016-06-28 20:01 GMT-03:00 Emilien Macchi :
>
>> Excellent idea, it would also be a good opportunity to take notes and
>> improve our documentation.
>>
>> ---
>> Emilien Macchi
>>
>> On Jun 28, 2016 6:24 PM, "Qasim Sarfraz"  wrote:
>>
>>> +2, that would be great.
>>>
>>> On Wednesday, June 29, 2016, James Slagle 
>>> wrote:
>>>
 We've got some new contributors around TripleO recently, and I'd like
 to offer up a "TripleO deep dive hour".

 The idea is to spend 1 hour a week in a high bandwidth environment
 (Google Hangouts / Bluejeans / ???) to deep dive on a TripleO related
 topic. The topic could be anything TripleO related, such as general
 onboarding, CI, networking, new features, etc.

 I'm by no means an expert on all those things, but I'd like to
 facilitate the conversation and I'm happy to lead the first few
 "dives" and share what I know. If it proves to be a popular format,
 hopefully I can convince some other folks to lead discussions on
 various topics.

 I think it'd be appropriate to record these sessions so that what is
 discussed is available to all. However, I don't intend these to be a
 presentation format, and instead more of a q discussion. If I don't
 get any ideas for topics though, I may choose to prepare something to
 present :).

 Our current meeting time of day at 1400 UTC seems to suit a lot of
 folks, so how about 1400 UTC on Thursdays? If folks think this is
 something that would be valuable and want to do it, we could start
 next Thursday, July 7th.


 --
 -- James Slagle
 --


 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe:
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

>>>
>>>
>>> --
>>> Regards,
>>> Qasim Sarfraz
>>>
>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Puppet] Suggestions for Dynamic enabling of SRIOV nic agent

[Sanjay Upadhyay]

Hello Folks,

Wondering what is the best approach to dynamically generating info of SRIOV
capable hosts in a cluster?

The problem is, user want to deploy sriov-nic-agent on compute nodes, with
mixed set of h/w configuration, ie set of compute nodes which do not have
SR-IOV nics and a set of nodes which have SR-IOV capable nics.

>From the perspective of nova, nova can spawn hosts requiring sr-iov via
host aggregation or flavors (scheduler_default_filters =
RamFilter,ComputeFilter,AvailabilityZoneFilter,ComputeCapabilitiesFilter,ImagePropertiesFilter,PciPassthroughFilter
)

However, from puppet side, we should enable sriov nic agent only on the
nodes with sr-iov nics. What is the best approach to address this?

regards
/sanjay
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [TripleO] supporting OVS-DPDK and SRIOV

[Sanjay Upadhyay]

Hello Folks,

We have been working on Triple-O and NFV client for some time now.

We would like to work and get this feature (ovs-dpdk and sr-iov) rolled out
into tripleo installer.

We look for support and suggestions for the spec files -
ovs-dpdk - https://review.openstack.org/313871
sr-iov - https://review.openstack.org/313872

As it's our new steps into hacking tripleo, we welcome any suggestions.

regards
/sanjay
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [puppet] [fuel] more collaboration request

[Sanjay Upadhyay]

+1 for the thread, I would also like to hear from Mirantis on this.

The Fork on fuel/puppet has been actively seen patching and
consolidation.It seems like parallel effort why not merge it.

regards
/sanjay

On Thu, Jun 11, 2015 at 9:12 AM, Emilien Macchi emil...@redhat.com wrote:

 Hi,

 Before reading this e-mail, please keep in mind:

 * I have a lot of admiration for Fuel and since I'm working on OpenStack
 Installers (at eNovance and now Red Hat), Fuel is something I always
 consider a good product.
 * This e-mail is about Fuel and Puppet, nothing about Mirantis.
 * I'm writing on behalf of my thoughts, and not on our group.
 * I'm using open mailing-list for open discussion. There is not bad
 spirit in this e-mail and I want to have a productive thread.

 I have some concerns I would like to share with you and hopefully find
 some solutions together.

 Since I've been working on Puppet OpenStack (2 years now), I see some
 situations that happen - according to me - too often:

 * A bug is reported in both Fuel Library and the Puppet module having
 trouble. A patch is provided in Fuel Library (your fork of Puppet
 OpenStack modules) but not in Puppet upstream module. That means you fix
 the bug for Fuel, and not for Puppet OpenStack community. It does not
 happen all the time but quite often.

 * A patch is submitted in a Puppet module and quite often does not land
 because there is no activity, no tests or is abandonned later because
 fixed in Fuel Library. I've noticed the patch is fixed in Fuel Library
 though.

 * RAW copy/paste between upstream modules code and your forks. In term
 of Licensing, I'm even not sure you have the right to do that (I'm not a
 CLA expert though) but well... in term of authorship and statistics on
 code, I'm not sure it's fair. Using submodules with custom patches would
 have been great to respect the authors who created the original code and
 you could have personalize the manifests.

 Note: you can see that I don't give any example because I'm not here to
 blame people or judge anyone.

 So the goal of my e-mail is to open the discussion and have a *real*
 collaboration between Fuel team which seems to have a lot of good Puppet
 engineers and Puppet OpenStack team.

 We had this kind of discussion at the Summit (in Vancouver and also
 Paris, and even before). Now I would like to officialy know if you are
 interested or not to be more involved.
 I'm also open at any feedback about Puppet OpenStack group and if
 something blocks you to contribute more.

 We have the same goals, having Puppet modules better. I think it can be
 win/win: you have less diff with upstream and we have more hands in our
 module maintenance.
 Thank you for reading so far, and I'm looking forward to reading from you.

 Best regards,
 --
 Emilien Macchi


 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




-- 
Sanjay Upadhyay
http://saneax.blogspot.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev