Re: [openstack-dev] [tripleo] New "validation" subcommand for "openstack undercloud"
I opened this RFE: https://bugzilla.redhat.com/show_bug.cgi?id=1601739 Regards, Udi Kalifon; Senior QE; RHOS-UI Automation On Tue, Jul 17, 2018 at 8:42 AM, Cédric Jeanneret wrote: > > > On 07/17/2018 06:57 AM, Udi Kalifon wrote: > > We should also add support for the openstack client to launch the other > > validators that are used in the GUI. There are validators for the > > overcloud as well, and new validators are added all the time. > > > > These validators are installed under > > /usr/share/openstack-tripleo-validations/validations/ and they're > > launched by the command: > > ansible-playbook -i /usr/bin/tripleo-ansible-inventory > > /usr/share/openstack-tripleo-validations/validations/<< > validator-name.py>> > > Hey, funky - I'm currently adding the support for ansible-playbook (in > an "easy, fast and pre-step" way) to the tripleoclient in order to be > able to run validations from that very same location: > https://review.openstack.org/582917 > > Guess we're on the same track :). > > > > > Cedric, feel free to open an RFE. > > Will do once we have the full scope :). > > > > > > > > > > > Regards, > > Udi Kalifon; Senior QE; RHOS-UIAutomation > > > > > > On Mon, Jul 16, 2018 at 6:32 PM, Dan Prince > <mailto:dpri...@redhat.com>> wrote: > > > > On Mon, Jul 16, 2018 at 11:27 AM Cédric Jeanneret > > mailto:cjean...@redhat.com>> wrote: > > > > > > Dear Stackers, > > > > > > In order to let operators properly validate their undercloud node, > I > > > propose to create a new subcommand in the "openstack undercloud" > "tree": > > > `openstack undercloud validate' > > > > > > This should only run the different validations we have in the > > > undercloud_preflight.py¹ > > > That way, an operator will be able to ensure all is valid before > > > starting "for real" any other command like "install" or "upgrade". > > > > > > Of course, this "validate" step is embedded in the "install" and > > > "upgrade" already, but having the capability to just validate > without > > > any further action is something that can be interesting, for > example: > > > > > > - ensure the current undercloud hardware/vm is sufficient for an > update > > > - ensure the allocated VM for the undercloud is sufficient for a > deploy > > > - and so on > > > > > > There are probably other possibilities, if we extend the > "validation" > > > scope outside the "undercloud" (like, tripleo, allinone, even > overcloud). > > > > > > What do you think? Any pros/cons/thoughts? > > > > I think this command could be very useful. I'm assuming the > underlying > > implementation would call a 'heat stack-validate' using an ephemeral > > heat-all instance. If so way we implement it for the undercloud vs > the > > 'standalone' use case would likely be a bit different. We can > probably > > subclass the implementations to share common code across the efforts > > though. > > > > For the undercloud you are likely to have a few extra 'local only' > > validations. Perhaps extra checks for things on the client side. > > > > For the all-in-one I had envisioned using the output from the 'heat > > stack-validate' to create a sample config file for a custom set of > > services. Similar to how tools like Packstack generate a config file > > for example. > > > > Dan > > > > > > > > Cheers, > > > > > > C. > > > > > > > > > > > > ¹ > > > http://git.openstack.org/cgit/openstack/python-tripleoclient/tree/ > tripleoclient/v1/undercloud_preflight.py > > <http://git.openstack.org/cgit/openstack/python-tripleoclient/tree/ > tripleoclient/v1/undercloud_preflight.py> > > > -- > > > Cédric Jeanneret > > > Software Engineer > > > DFG:DF > > > > > > > > > __ > > > OpenStack Development Mailing List (not for usage questions) > > > Unsubscribe: > > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >
Re: [openstack-dev] [tripleo] New "validation" subcommand for "openstack undercloud"
We should also add support for the openstack client to launch the other validators that are used in the GUI. There are validators for the overcloud as well, and new validators are added all the time. These validators are installed under /usr/share/openstack-tripleo-validations/validations/ and they're launched by the command: ansible-playbook -i /usr/bin/tripleo-ansible-inventory /usr/share/openstack-tripleo-validations/validations/<> Cedric, feel free to open an RFE. Regards, Udi Kalifon; Senior QE; RHOS-UI Automation On Mon, Jul 16, 2018 at 6:32 PM, Dan Prince wrote: > On Mon, Jul 16, 2018 at 11:27 AM Cédric Jeanneret > wrote: > > > > Dear Stackers, > > > > In order to let operators properly validate their undercloud node, I > > propose to create a new subcommand in the "openstack undercloud" "tree": > > `openstack undercloud validate' > > > > This should only run the different validations we have in the > > undercloud_preflight.py¹ > > That way, an operator will be able to ensure all is valid before > > starting "for real" any other command like "install" or "upgrade". > > > > Of course, this "validate" step is embedded in the "install" and > > "upgrade" already, but having the capability to just validate without > > any further action is something that can be interesting, for example: > > > > - ensure the current undercloud hardware/vm is sufficient for an update > > - ensure the allocated VM for the undercloud is sufficient for a deploy > > - and so on > > > > There are probably other possibilities, if we extend the "validation" > > scope outside the "undercloud" (like, tripleo, allinone, even overcloud). > > > > What do you think? Any pros/cons/thoughts? > > I think this command could be very useful. I'm assuming the underlying > implementation would call a 'heat stack-validate' using an ephemeral > heat-all instance. If so way we implement it for the undercloud vs the > 'standalone' use case would likely be a bit different. We can probably > subclass the implementations to share common code across the efforts > though. > > For the undercloud you are likely to have a few extra 'local only' > validations. Perhaps extra checks for things on the client side. > > For the all-in-one I had envisioned using the output from the 'heat > stack-validate' to create a sample config file for a custom set of > services. Similar to how tools like Packstack generate a config file > for example. > > Dan > > > > > Cheers, > > > > C. > > > > > > > > ¹ > > http://git.openstack.org/cgit/openstack/python-tripleoclient/tree/ > tripleoclient/v1/undercloud_preflight.py > > -- > > Cédric Jeanneret > > Software Engineer > > DFG:DF > > > > > __ > > 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] quickstart failing due to unresolved dependencies
I'm trying to install Pike. The undercloud has versions: puppet-tripleo-7.1.1-0.20170627224658.f99b72a.el7.centos.noarch instack-undercloud-7.1.1-0.20170619172442.4de8226.el7.centos.noarch Regards, Udi Kalifon; Senior QE; RHOS-UI Automation On Mon, Jul 3, 2017 at 8:58 PM, Alex Schultz <aschu...@redhat.com> wrote: > On Sun, Jul 2, 2017 at 7:11 AM, Udi Kalifon <ukali...@redhat.com> wrote: > > Hi. > > > > I tried to install the latest TripleO with quickstart, and it failed in > the > > undercloud install. I logged in to the undercloud and checked the install > > log, and I see errors there like "ModuleLoader: module 'rabbitmq' has > > unresolved dependencies". I pasted the output here: > > http://paste.openstack.org/show/614247/ > > > > Any help on how to fix this will be appreciated ! > > It seems to have failed while trying to run puppet and it couldn't > find a specific class. > > 2017-07-02 12:37:12,614 INFO: Error: Evaluation Error: Error while > evaluating a Function Call, Could not find class > ::tripleo::profile::base::ui for undercloud at > /etc/puppet/manifests/puppet-stack-config.pp:585:3 on node undercloud > > What version are you deploying? This may happen if there's an > mismatch between the instack-undercloud and the puppet-tripleo > packages > > Thanks, > -Alex > > > > > > Regards, > > Udi Kalifon > > > > > __ > > 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] [TripleO] quickstart failing due to unresolved dependencies
Hi. I tried to install the latest TripleO with quickstart, and it failed in the undercloud install. I logged in to the undercloud and checked the install log, and I see errors there like "ModuleLoader: module 'rabbitmq' has unresolved dependencies". I pasted the output here: http://paste.openstack.org/show/614247/ Any help on how to fix this will be appreciated ! Regards, Udi Kalifon __ 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 session - July 28th
I think the agenda is great. At what time will the session be? Can you send an invite? Regards, Udi Kalifon; QE Automation; RHOS-UI On Mon, Jul 25, 2016 at 7:25 PM, Emilien Macchi <emil...@redhat.com> wrote: > Hi, > > I propose to lead the next TripleO Deep Dive session and it will be > about Puppet (go figure). > > Here's an agenda draft: > 1) Introduction about Puppet OpenStack modules. > 2) TripleO profiles under the hood > 3) Managing data using Hiera and composable services > 4) Write your own service step by step. > > To join the Meeting: > https://bluejeans.com/275264340 > > To join via Browser: > https://bluejeans.com/275264340/browser > > To join with Lync: > https://bluejeans.com/275264340/lync > > To join via Room System: > Video Conferencing System: bjn.vc -or-199.48.152.152 > Meeting ID : 275264340 > > To join via phone : > 1) Dial: > +44 203 574 6870 > (see all numbers - > > https://www.intercallonline.com/listNumbersByCode.action?confCode=3422501687 > ) > 2) Enter Conference ID : 3422501687 > > The session will be recorded and I'll present some slides using my > tablet; but I won't share my screen and do terminal things (not needed > in this session), since I'm experiencing CPU consumption issues with > bluejeans on my laptop. > > Any feedback is welcome, > -- > 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] [Heat][Keystone] Native keystone resources in Heat
I think the user resource should not have roles in it. There should be a Role Assignment resource that grants roles to users on either tenants (projects) or domains. On the other hand, the user resource should have a domain association. Also, consider adding support for groups and in the future maybe also federation. As for trusts, I don't think it should be Heat's responsibility to set them up, because it's up to the users themselves to create and grant trusts to their trustees. - Original Message - From: Zane Bitter zbit...@redhat.com To: openstack-dev@lists.openstack.org Sent: Tuesday, 3 February, 2015 12:26:41 AM Subject: Re: [openstack-dev] [Heat][Keystone] Native keystone resources in Heat On 30/01/15 02:19, Thomas Spatzier wrote: From: Zane Bitter zbit...@redhat.com To: openstack Development Mailing List openstack-dev@lists.openstack.org Date: 29/01/2015 17:47 Subject: [openstack-dev] [Heat][Keystone] Native keystone resources in Heat I got a question today about creating keystone users/roles/tenants in Heat templates. We currently support creating users via the AWS::IAM::User resource, but we don't have a native equivalent. IIUC keystone now allows you to add users to a domain that is otherwise backed by a read-only backend (i.e. LDAP). If this means that it's now possible to configure a cloud so that one need not be an admin to create users then I think it would be a really useful thing to expose in Heat. Does anyone know if that's the case? I think roles and tenants are likely to remain admin-only, but we have precedent for including resources like that in /contrib... this seems like it would be comparably useful. Thoughts? I am really not a keystone expert, so don't know what the security implications would be, but I have heard the requirement or wish to be able to create users, roles etc. from a template many times. I've talked to people who want to explore this for onboarding use cases, e.g. for onboarding of lines of business in a company, or for onboarding customers in a public cloud case. They would like to be able to have templates that lay out the overall structure for authentication stuff, and then parameterize it for each onboarding process. If this is something to be enabled, that would be interesting to explore. Thanks for the input everyone. I raised a spec + blueprint here: https://review.openstack.org/152309 I don't have any immediate plans to work on this, so if anybody wants to grab it they'd be more than welcome :) cheers, Zane. __ 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] [qa] Using any username/password to create tempest clients
Hi Andrea, I tried adding the tenant to the credentials I supply - and it didn't change the results I am getting. I opened a bug on this issue: https://bugs.launchpad.net/tempest/+bug/1356759 Can you devote some time to this bug, or let me know how to fix it and I will do it myself? Thanks a lot for your help, Udi. - Original Message - From: Andrea Frittoli andrea.fritt...@gmail.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Sent: Wednesday, August 13, 2014 7:24:42 PM Subject: Re: [openstack-dev] [qa] Using any username/password to create tempest clients Hello Udi, I don't see anything wrong in principle with your code. This said, the main use case I had in mind when I wrote the auth providers and credentials classes was to abstract authentication for all tests, so that it is possible to configure and target identity api version to be used for authentication, and all tests will use that to obtain a token. Identity tests are a bit different though, because when running an identity tests you typically want to specify which version of the identity API is to be used - like you did in your code. Nonetheless you you should be able to use the same code from auth provider and credentials classes - but because identity tests have use more complex scenarios you may find issues or restrictions in the current implementation. I see that your credentials do not have a tenant - even though there is a simple unit test for that case, that case is not used in any other test atm, so you may as well have hit a bug. I think it would be helpful if you could push a WIP change - it would be easier to see what is going wrong. andrea On 13 August 2014 10:41, Udi Kalifon ukali...@redhat.com wrote: Hello. I am writing a tempest scenario for keystone. In this scenario I create a domain, project and a user with admin rights on the project. I then try to instantiate a Manager so I can call keystone using the new user credentials: creds = KeystoneV3Credentials(username=dom1proj1admin_name, password=dom1proj1admin_name, domain_name=dom1_name, user_domain_name=dom1_name) auth_provider = KeystoneV3AuthProvider(creds) creds = auth_provider.fill_credentials() admin_client = clients.Manager(interface=self._interface, credentials=creds) The problem is that I get unauthorized return codes for every call I make with this client. I verified that the user is created properly and has the needed credentials, by manually authenticating and getting a token with his credentials and then using that token. Apparently, in my code I don't create the creds properly or I'm missing another step. How can I use the new user in tempest properly? Thanks in advance, Udi Kalifon. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] Contact information required for ICLA -- getting a server error
Hi. I am trying to update my contact information in order to submit my first gerrit review. I go to review.openstack.org and log in, then go to my account settings and click on Contact Information. I provide my address and click Save Changes and get: Code Review - Error Server Error Cannot store contact information This has been going on for 2 days already... Who is the admin responsible? Thanks in advance, Udi. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [qa] Using any username/password to create tempest clients
Hello. I am writing a tempest scenario for keystone. In this scenario I create a domain, project and a user with admin rights on the project. I then try to instantiate a Manager so I can call keystone using the new user credentials: creds = KeystoneV3Credentials(username=dom1proj1admin_name, password=dom1proj1admin_name, domain_name=dom1_name, user_domain_name=dom1_name) auth_provider = KeystoneV3AuthProvider(creds) creds = auth_provider.fill_credentials() admin_client = clients.Manager(interface=self._interface, credentials=creds) The problem is that I get unauthorized return codes for every call I make with this client. I verified that the user is created properly and has the needed credentials, by manually authenticating and getting a token with his credentials and then using that token. Apparently, in my code I don't create the creds properly or I'm missing another step. How can I use the new user in tempest properly? Thanks in advance, Udi Kalifon. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
