Re: [openstack-dev] [horizon] Javascript development improvement
On 11/22/2013 02:49 PM, Maxime Vidori wrote: It seems a bit crazy to me to introduce NodeJS as a dependency just for the sake of an easy way to run jslint. There are other options available that run without NodeJS as a dependency. Sadly, the only solutions which try to implement jslint in pure python are in alpha or abandoned. If you have a python library which has the same quality as jslint (which is written by Douglas Crockford himself), I will be glad to take a look at it. There's a jslint fork called jshint which is able to run in the browser without any node.js dependency. I created a POC patch [1] long time ago to demonstrate its capabilities. It's integrated with qunit and runs automatically with the horizon test suite. The patch also contains a .jshintrc file for the node.js package but you can remove it since it's not used by the qunit+jshint test at all. Imre [1] https://review.openstack.org/#/c/41087/ ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [horizon] Javascript development improvement
On 11/22/2013 06:13 PM, Julie Pichon wrote: "Imre Farkas" wrote: On 11/22/2013 02:49 PM, Maxime Vidori wrote: It seems a bit crazy to me to introduce NodeJS as a dependency just for the sake of an easy way to run jslint. There are other options available that run without NodeJS as a dependency. Sadly, the only solutions which try to implement jslint in pure python are in alpha or abandoned. If you have a python library which has the same quality as jslint (which is written by Douglas Crockford himself), I will be glad to take a look at it. There's a jslint fork called jshint which is able to run in the browser without any node.js dependency. I created a POC patch [1] long time ago to demonstrate its capabilities. It's integrated with qunit and runs automatically with the horizon test suite. Thanks Imre, this is interesting. Would you mind restoring the patch? If you don't have time to work on it please indicate so (I don't think it's possible to pick up a patch if the status is 'Abandoned') and someone else can look into the test failures. Julie, Matthias, I restored the patch, rebased, fixed the tests, added the test files as Radomir suggested and removed the .jshintrc file. The original patch was WIP and I left the failing tests intentionally, so that it was easier to compare the two solutions (node.js vs pure qunit). But as I wrote, it's cleaned up by now and only contains the latter. Imre The patch also contains a .jshintrc file for the node.js package but you can remove it since it's not used by the qunit+jshint test at all. Sounds good. Julie Imre [1] https://review.openstack.org/#/c/41087/ ___ 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
Re: [openstack-dev] [Tripleo] Core reviewer update Dec
On 12/04/2013 08:12 AM, Robert Collins wrote: Hi, like most OpenStack projects we need to keep the core team up to date: folk who are not regularly reviewing will lose context over time, and new folk who have been reviewing regularly should be trusted with -core responsibilities. In this months review: - Ghe Rivero for -core +1 - Jan Provaznik for removal from -core - Jordan O'Mara for removal from -core - Martyn Taylor for removal from -core - Jiri Tomasek for removal from -core - Jamomir Coufal for removal from -core As a many of them expressed their further interests in TripleO, I vote for keeping them in core for now and let's wait a couple weeks/month to see how the stats change. Imre ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO][Tuskar] Icehouse Requirements
On 12/09/2013 11:56 AM, Jaromir Coufal wrote: On 2013/07/12 01:59, Robert Collins wrote: * Monitoring * assignment, availability, status * capacity, historical statistics (M) Why is this under 'nodes'? I challenge the idea that it should be there. We will need to surface some stuff about nodes, but the underlying idea is to take a cloud approach here - so we're monitoring services, that happen to be on nodes. There is room to monitor nodes, as an undercloud feature set, but lets be very very specific about what is sitting at what layer. We need both - we need to track services but also state of nodes (CPU, RAM, Network bandwidth, etc). So in node detail you should be able to track both. I agree. Monitoring services and monitoring nodes are both valid features for Tuskar. I think splitting it into two separate requirements as Mainn suggested would make a lot of sense. * searchable by status, name, cpu, memory, and all attributes from ironic * can be allocated as one of four node types Not by users though. We need to stop thinking of this as 'what we do to nodes' - Nova/Ironic operate on nodes, we operate on Heat templates. Discussed in other threads, but I still believe (and I am not alone) that we need to allow 'force nodes'. Yeah, having both approaches would be nice to have. Instead of using the existing 'force nodes' implementation, wouldn't it be better/cleaner to implement support for it in Nova and Heat? Imre ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] [Tuskar] [UI] Icehouse Requirements - Summary, Milestones
On 12/13/2013 11:36 AM, Jaromir Coufal wrote: *VERSION 0* === Enable user to deploy OpenStack with the simpliest TripleO way, no difference between hardware. Target: - end of icehouse-2 Features we need to get in: - Enable manual nodes registration (Ironic) - Get images available for user (Glance) - Node roles (hardcode): Controller, Compute, Object Storage, Block Storage - Design deployment (number of nodes per role) - Deploy (Heat + Nova) One note to deploy: It's not done only by Heat and Nova. If we expect a fully functional OpenStack installation as a result, we are missing a few steps like creating users, initializing and registering the service endpoints with Keystone. In TripleO this is done by the init-keystone and setup-endpoints scripts. Check devtest for more details: http://docs.openstack.org/developer/tripleo-incubator/devtest_undercloud.html Imre ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tuskar] How to install tuskar-ui from packaging point of view
On 12/16/2013 08:52 AM, Stephen Gran wrote: On 16/12/13 03:47, Thomas Goirand wrote: Hi, I've been working over the last 2 months to get Ironic, TripleO and Tuskar ready for an upload in Debian. However, for tuskar-ui, I'm facing the fact that there's a lack of documentation. It was easy to get Tuskar packaged. If I understand well, it only needs 2 daemons: tuskar-api, and tuskar-manager. Is this right? If not, what did I miss? Is tuskar-manager really a daemon? (I have to admit that I didn't find yet the time to try, so I would appreciate some guidance here) I think you are right here. As for tuskar-ui, the install.rst is quite vague about how to install. I got the python-tuskar-ui binary package done, with egg-info and all, that's not the problem. What worries me is this part: "Go into horizon and create a symlink to the tuskar-ui code: cd horizon ln -s ../tuskar-ui/tuskar_ui Then, install a virtual environment for your setup: Add this to debian/links or something? It sounds like it needs a dependency on horizon to make sure that the directory exists. Not sure how it translates to Debian packaging but you need to copy/symlink the Tuskar-UI source *inside* the Horizon directory. python tools/install_venv.py" This means "turn the list of dependencies in the source package into dependencies in the debian package", I would think. Yes, that's correct. 3/ The install.rst has: If everything has gone according to plan, you should be able to run: tools/with_venv.sh ./manage.py runserver and have the application start on port 8080. The Tuskar dashboard will be located at http://localhost:8080/infrastructure does this mean that on top of Horizon running through Apache, tuskar-ui needs to run independently? Why is that? Can't we just have tuskar-ui simply integrated with the rest of Horizon? Yes, Tuskar-UI runs on top of Horizon. You don't have to create a separate Horizon+Tuskar-UI installation, it does not run independently of the existing Horizon installation but you have to modify it. When you create a symlink into the Horizon source, that makes the Infrastructure dashboard provided by Tuskar-UI autodiscovered when the Horizon application boots up. Tuskar-UI creates and additional tab inside the Horizon application, which will be available at http://localhost:8080/infrastructure (or on whatever port you set Horizon up) and at http://localhost:8080/ you can access the Project and Admin dashboards provided by Horizon. It's not stated in tuskar-ui/install.rst but this guide is meant to set up the development environment. It is also worth mentioning that the current solution is only temporary, in the long term Tuskar-UI will be a part of Horizon (see the Horizon and Tuskar-UI merge thread). Imre ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] [Tuskar] [UI] Icehouse Requirements - Summary, Milestones
On 12/13/2013 05:22 PM, James Slagle wrote: On Fri, Dec 13, 2013 at 03:04:09PM +0100, Imre Farkas wrote: One note to deploy: It's not done only by Heat and Nova. If we expect a fully functional OpenStack installation as a result, we are missing a few steps like creating users, initializing and registering the service endpoints with Keystone. In TripleO this is done by the init-keystone and setup-endpoints scripts. Check devtest for more details: http://docs.openstack.org/developer/tripleo-incubator/devtest_undercloud.html Excellent point Imre, as the deployment isn't really useable until those steps are done. The link to the overcloud setup steps is actually: http://docs.openstack.org/developer/tripleo-incubator/devtest_overcloud.html Very similar to what is done for the undercloud. You are right, that's the correct link for the overcloud setup. However, I intentionally picked the one for the undercloud because I wanted to focus on the keystone configuration part and that's the same for the both (the init-keystone, setup-endpoints and keystone role-create workflow). There are some other stuff going on in the overcloud setup (eg. creating a vm for a user) which might distract those who are not familiar with devtest from what really is needed to deploy OpenStack. But it would have been better from me to note that the link is not for the overcloud. I think most of that logic could be reimplemented to be done via direct calls to the API using the client libs vs using a CLI. Not sure about "keystone-manage pki_setup" though, would need to look into that. Yeah, we can put big part of the needed configuration steps into Tuskar as most of it just uses CLI client of Keystone which can be replaced by using the direct API calls of the same library. The rest might go to Heat or os-refresh-config or else. Imre ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] Tuskar CLI after architecture changes
On 12/20/2013 12:25 PM, Ladislav Smola wrote: 2. Heat stack create, update This is locked in the process of the operation, so nobody can mess with it while it is updating or creating. Once we will pack all operations that are now aside in this, we should be alright. And that should be doable in I. So we should push towards this, rather then building some temporary locking solution in Tuskar-API. It's not the issue of locking, but the goal of Tuskar with the Provision button is not only a single stack creation. After Heat's job is done, the overcloud needs to be properly configured: Keystone needs to be initialized, the services need to be registered, etc. I don't think Horizon wants to add a background worker to handle such operations. Imre ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO][Tuskar] Domain Model Locations
Thanks Jay, this is a very useful summary! Some comments inline: On 01/09/2014 06:22 PM, Jay Dobies wrote: I'm trying to hash out where data will live for Tuskar (both long term and for its Icehouse deliverables). Based on the expectations for Icehouse (a combination of the wireframes and what's in Tuskar client's api.py), we have the following concepts: = Nodes = A node is a baremetal machine on which the overcloud resources will be deployed. The ownership of this information lies with Ironic. The Tuskar UI will accept the needed information to create them and pass it to Ironic. Ironic is consulted directly when information on a specific node or the list of available nodes is needed. = Resource Categories = A specific type of "thing" that will be deployed into the overcloud. These are static definitions that describe the entities the user will want to add to the overcloud and are owned by Tuskar. For Icehouse, the categories themselves are added during installation for the four types listed in the wireframes. Since this is a new model (as compared to other things that live in Ironic or Heat), I'll go into some more detail. Each Resource Category has the following information: == Metadata == My intention here is that we do things in such a way that if we change one of the original 4 categories, or more importantly add more or allow users to add more, the information about the category is centralized and not reliant on the UI to provide the user information on what it is. ID - Unique ID for the Resource Category. Display Name - User-friendly name to display. Description - Equally self-explanatory. == Count == In the Tuskar UI, the user selects how many of each category is desired. This stored in Tuskar's domain model for the category and is used when generating the template to pass to Heat to make it happen. These counts are what is displayed to the user in the Tuskar UI for each category. The staging concept has been removed for Icehouse. In other words, the wireframes that cover the "waiting to be deployed" aren't relevant for now. == Image == For Icehouse, each category will have one image associated with it. Last I remember, there was discussion on whether or not we need to support multiple images for a category, but for Icehouse we'll limit it to 1 and deal with it later. Metadata for each Resource Category is owned by the Tuskar API. The images themselves are managed by Glance, with each Resource Category keeping track of just the UUID for its image. = Stack = There is a single stack in Tuskar, the "overcloud". A small nit here: in the long term Tuskar will support multiple overclouds. > The Heat template for the stack is generated by the Tuskar API based on the Resource Category data (image, count, etc.). The template is handed to Heat to execute. Heat owns information about running instances and is queried directly when the Tuskar UI needs to access that information. -- Next steps for me are to start to work on the Tuskar APIs around Resource Category CRUD and their conversion into a Heat template. There's some discussion to be had there as well, but I don't want to put too much into one e-mail. Thoughts? There's few pieces of concepts which I think is missing from the list: - overclouds: after Heat successfully created the stack, Tuskar needs to keep track whether it applied the post configuration steps (Keystone initialization, registering services, etc) or not. It also needs to know the name of the stack (only 1 stack named 'overcloud' for Icehouse). - service endpoints of an overcloud: eg. Tuskar-ui in the undercloud will need the url of the overcloud Horizon. The overcloud Keystone owns the information about this (after post configuration is done) and Heat owns the information about the overcloud Keystone. - user credentials for an overcloud: it will be used by Heat during stack creation, by Tuskar during post configuration, by Tuskar-ui querying various information (eg. running vms on a node) and finally by the user logging in to the overcloud Horizon. Now it can be found in the Tuskar-ui settings file [1]. Imre [1] https://github.com/openstack/tuskar-ui/blob/master/local_settings.py.example#L351 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO][Tuskar] Domain Model Locations
On 01/10/2014 04:27 PM, Jay Dobies wrote: Thanks for the feedback :) = Stack = There is a single stack in Tuskar, the "overcloud". A small nit here: in the long term Tuskar will support multiple overclouds. Yes, absolutely. I should have added "For Icehouse" like I did in other places. Good catch. There's few pieces of concepts which I think is missing from the list: - overclouds: after Heat successfully created the stack, Tuskar needs to keep track whether it applied the post configuration steps (Keystone initialization, registering services, etc) or not. It also needs to know the name of the stack (only 1 stack named 'overcloud' for Icehouse). I assumed this sort of thing was captured by the resource status, though I'm far from a Heat expert. Is it not enough to assume that if the resource started successfully, all of that took place? I am also far from a Heat expert, I just had a some really hard times when I previously expected from my Tuskar deployed overcloud that it's ready to use. :-) In short, having the resources started is not enough, Heat stack-create is only a part of the deployment story. There was a few emails on the mailing list about this: http://lists.openstack.org/pipermail/openstack-dev/2013-December/022217.html http://lists.openstack.org/pipermail/openstack-dev/2013-December/022887.html There was also a discussion during the last TripleO meeting in December, check the topic 'After heat stack-create init operations (lsmola)' http://eavesdrop.openstack.org/meetings/tripleo/2013/tripleo.2013-12-17-19.02.log.html - service endpoints of an overcloud: eg. Tuskar-ui in the undercloud will need the url of the overcloud Horizon. The overcloud Keystone owns the information about this (after post configuration is done) and Heat owns the information about the overcloud Keystone. - user credentials for an overcloud: it will be used by Heat during stack creation, by Tuskar during post configuration, by Tuskar-ui querying various information (eg. running vms on a node) and finally by the user logging in to the overcloud Horizon. Now it can be found in the Tuskar-ui settings file [1]. Both of these are really good points that I haven't seen discussed yet. The wireframes cover the allocation of nodes and displaying basic details of what's created (even that is still placeholder) but not much beyond that. I'd like to break that into a separate thread. I'm not saying it's unrelated, but since it's not even wireframed out I'd like to have a dedicated discussion about what it might look like. I'll start that thread up as soon as I collect my thoughts. Fair point, sorry about that. I haven't seen the latest wireframes, I had a few expectations based on the previous version. Imre [1] https://github.com/openstack/tuskar-ui/blob/master/local_settings.py.example#L351 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO][Tuskar] Dealing with passwords in Tuskar-API
On 02/19/2014 06:10 PM, Ladislav Smola wrote: Hello, I would like to have your opinion about how to deal with passwords in Tuskar-API The background is, that tuskarAPI is storing heat template parameters in its database, it's a preparation for more complex workflows, when we will need to store the data before the actual heat stack-create. So right now, the state is unacceptable, we are storing sensitive data(all the heat passwords and keys) in a raw form in the TuskarAPI database. That is wrong right? Right, that is definitely wrong. So is anybody aware of the reasons, why we would need to store the passwords? Storing them for a small amount of time (rather in a session) should be fine, so we can use them for latter init of the stack. Do we need to store them for heat stack-update? Cause heat throws them away. You will need those passwords after Heat finished creating the stack and Tuskar is going to initialize Keystone and register the services. Keystone can't be used for that because a) Tuskar will need the password, not a token, b) Keystone is not yet initialized. Since stack creation is an asynchronous operation, the session might have gone long time ago. So storing it in the session would not work, Tuskar has to store it in a more permanent place. You will also need the password every time a service need reregistered. Eg. user decides to get rid of swift, then changes his mind, but can't undo the operation because the password is gone. If yes, this bug should change to encrypting of the all sensitive data, right? Cause it might be just me, but dealing with sensitive data like this the 8th deadly sin. The second thing is, if users will update their passwords, info in the TuskarAPI will be obsolete and can't be used anyway. I don't think that the user is going to change the password for different services. We should also investigate if the service will work after someone changes its password. I don't see any problem in storing passwords for the overcloud, since Tuskar *is* the management interface. But I agree, we should do it more securely. Imre There is a bug filled for it: https://bugs.launchpad.net/tuskar/+bug/1282066 Thanks for the feedback, seems like the bug is not as straightforward as I thought. Kind Regards, Ladislav ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO][Tuskar] Dealing with passwords in Tuskar-API
On 02/20/2014 10:12 AM, Radomir Dopieralski wrote: On 19/02/14 18:29, Dougal Matthews wrote: The question for me, is what passwords will we have and when do we need them? Are any of the passwords required long term. We will need whatever the Heat template needs to generate all the configuration files. That includes passwords for all services that are going to be configured, such as, for example, Swift or MySQL. I'm not sure about the exact mechanisms in Heat, but I would guess that we will need all the parameters, including passwords, when the templates are re-generated. We could probably generate new passwords every time, though. That is an excellent point. Tuskar will need the passwords every time it needs to regenerate the Heat template (basically when running stack-update). I don't think, changing the password every time would work. If eg. the MySQL password is changed, then os-refresh-config will fail during the db migration scripts because it no longer can access the existing db with the new password. Imre ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO][Tuskar] Dealing with passwords in Tuskar-API
On 02/20/2014 03:57 PM, Tomas Sedovic wrote: On 20/02/14 15:41, Radomir Dopieralski wrote: On 20/02/14 15:00, Tomas Sedovic wrote: Are we even sure we need to store the passwords in the first place? All this encryption talk seems very premature to me. How are you going to redeploy without them? What do you mean by redeploy? 1. Deploy a brand new overcloud, overwriting the old one 2. Updating the services in the existing overcloud (i.e. image updates) 3. Adding new machines to the existing overcloud 4. Autoscaling 5. Something else 6. All of the above I'd guess each of these have different password workflow requirements. I am not sure if all these use cases have different password requirement. If you check devtest, no matter whether you are creating or just updating your overcloud, all the parameters have to be provided for the heat template: https://github.com/openstack/tripleo-incubator/blob/master/scripts/devtest_overcloud.sh#L125 I would rather not require the user to enter 5/10/15 different passwords every time Tuskar updates the stack. I think it's much better to autogenerate the passwords for the first time, provide an option to override them, then save and encrypt them in Tuskar. So +1 for designing a proper system for storing the passwords. Imre ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO][Tuskar] Dealing with passwords in Tuskar-API
On 02/24/2014 09:39 AM, Ladislav Smola wrote: On 02/23/2014 01:16 AM, Clint Byrum wrote: Excerpts from Imre Farkas's message of 2014-02-20 15:24:17 +: On 02/20/2014 03:57 PM, Tomas Sedovic wrote: On 20/02/14 15:41, Radomir Dopieralski wrote: On 20/02/14 15:00, Tomas Sedovic wrote: Are we even sure we need to store the passwords in the first place? All this encryption talk seems very premature to me. How are you going to redeploy without them? What do you mean by redeploy? 1. Deploy a brand new overcloud, overwriting the old one 2. Updating the services in the existing overcloud (i.e. image updates) 3. Adding new machines to the existing overcloud 4. Autoscaling 5. Something else 6. All of the above I'd guess each of these have different password workflow requirements. I am not sure if all these use cases have different password requirement. If you check devtest, no matter whether you are creating or just updating your overcloud, all the parameters have to be provided for the heat template: https://github.com/openstack/tripleo-incubator/blob/master/scripts/devtest_overcloud.sh#L125 I would rather not require the user to enter 5/10/15 different passwords every time Tuskar updates the stack. I think it's much better to autogenerate the passwords for the first time, provide an option to override them, then save and encrypt them in Tuskar. So +1 for designing a proper system for storing the passwords. Tuskar does not need to reinvent this. Use OS::Heat::RandomString in the templates. If any of them need to be exposed to the user, use an output on the template. If they need to be regenerated, you can pass a "salt" parameter. Do we actually need to expose to the user something else than AdminPassword? I think we should not. The MySQL password or any of the service passwords are "implementation details" of the cloud, it should not be used by anyone, except for OpenStack internally. The administrator should setup separate user accounts with the proper privileges to access these services. Imre We are using tripleo-heat-templates currently, so we will need to make the change there. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ironic] Cleaning up spec review queue.
On 11/19/2014 12:07 PM, Dmitry Tantsur wrote: On 11/18/2014 06:13 PM, Chris K wrote: Hi all, In an effort to keep the Ironic specs review queue as up to date as possible, I have identified several specs that were proposed in the Juno cycle and have not been updated to reflect the changes to the current Kilo cycle. I would like to set a deadline to either update them to reflect the Kilo cycle or abandon them if they are no longer relevant. If there are no objections I will abandon any specs on the list below that have not been updated to reflect the Kilo cycle after the end of the next Ironic meeting (Nov. 24th 2014). Below is the list of specs I have identified that would be affected: https://review.openstack.org/#/c/107344 - *Generic Hardware Discovery Bits* Killed it with fire :D https://review.openstack.org/#/c/102557 - *Driver for NetApp storage arrays* https://review.openstack.org/#/c/108324 - *DRAC hardware discovery* Imre, are you going to work on it? I think it's replaced by Lucas' proposal: https://review.openstack.org/#/c/125920 I will discuss it with him and abandon one of them. Imre ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ironic] Do we need an IntrospectionInterface?
On 11/26/2014 02:20 PM, Dmitry Tantsur wrote: Hi all! As our state machine and discovery discussion proceeds, I'd like to ask your opinion on whether we need an IntrospectionInterface (DiscoveryInterface?). Current proposal [1] suggests adding a method for initiating a discovery to the ManagementInterface. IMO it's not 100% correct, because: 1. It's not management. We're not changing anything. 2. I'm aware that some folks want to use discoverd-based discovery [2] even for DRAC and ILO (e.g. for vendor-specific additions that can't be implemented OOB). Any ideas? Dmitry. [1] https://review.openstack.org/#/c/100951/ [2] https://review.openstack.org/#/c/135605/ Hi Dmitry, I see the value in using the composability of our driver interfaces, so I vote for having a separate IntrospectionInterface. Otherwise we wouldn't allow users to use eg. the DRAC driver with an in-band but more powerful hw discovery. Imre ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] os-cloud-config ssh access to cloud
On 03/07/2014 10:30 AM, Jiří Stránský wrote: Hi, there's one step in cloud initialization that is performed over SSH -- calling "keystone-manage pki_setup". Here's the relevant code in keystone-init [1], here's a review for moving the functionality to os-cloud-config [2]. The consequence of this is that Tuskar will need passwordless ssh key to access overcloud controller. I consider this suboptimal for two reasons: * It creates another security concern. * AFAIK nova is only capable of injecting one public SSH key into authorized_keys on the deployed machine, which means we can either give it Tuskar's public key and allow Tuskar to initialize overcloud, or we can give it admin's custom public key and allow admin to ssh into overcloud, but not both. (Please correct me if i'm mistaken.) We could probably work around this issue by having Tuskar do the user key injection as part of os-cloud-config, but it's a bit clumsy. This goes outside the scope of my current knowledge, i'm hoping someone knows the answer: Could pki_setup be run by combining powers of Heat and os-config-refresh? (I presume there's some reason why we're not doing this already.) I think it would help us a good bit if we could avoid having to SSH from Tuskar to overcloud. Yeah, it came up a couple times on the list. The current solution is because if you have an HA setup, the nodes can't decide on its own, which one should run pki_setup. Robert described this topic and why it needs to be initialized externally during a weekly meeting in last December. Check the topic 'After heat stack-create init operations (lsmola)': http://eavesdrop.openstack.org/meetings/tripleo/2013/tripleo.2013-12-17-19.02.log.html Imre ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] reviewer update march
On 04/03/2014 01:02 PM, Robert Collins wrote: Getting back in the swing of things... Hi, like most OpenStack projects we need to keep the core team up to date: folk who are not regularly reviewing will lose context over time, and new folk who have been reviewing regularly should be trusted with -core responsibilities. In this months review: - Dan Prince for -core - Jordan O'Mara for removal from -core - Jiri Tomasek for removal from -core - Jamomir Coufal for removal from -core Existing -core members are eligible to vote - please indicate your opinion on each of the three changes above in reply to this email. ACK for all proposed changes. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] reviewer update march [additional cores]
On 04/08/2014 01:50 AM, Robert Collins wrote: tl;dr: 3 more core members to propose: bnemec greghaynes jdon +1 Imre ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Tuskar] [TripleO] The vision and looking ahead
On 09/19/2013 10:08 AM, Tomas Sedovic wrote: Hi everyone, Some of us Tuskar developers have had the chance to meet the TripleO developers face to face and discuss the visions and goals of our projects. Tuskar's ultimate goal is to have to a full OpenStack management solution: letting the cloud operators try OpenStack, install it, keep it running throughout the entire lifecycle (including bringing in new hardware, burning it in, decommissioning), help to scale it, secure the setup, monitor for failures, project the need for growth and so on. And to provide a good user interface and API to let the operators control and script this easily. Now, the scope of the OpenStack Deployment program (TripleO) includes not just installation, but the entire lifecycle management (from racking it up to decommissioning). Among other things they're thinking of are issue tracker integration and inventory management, but these could potentially be split into a separate program. That means we do have a lot of goals in common and we've just been going at them from different angles: TripleO building the fundamental infrastructure while Tuskar focusing more on the end user experience. We've come to a conclusion that it would be a great opportunity for both teams to join forces and build this thing together. The benefits for Tuskar would be huge: * being a part of an incubated project * more eyballs (see Linus' Law (the ESR one)) * better information flow between the current Tuskar and TripleO teams * better chance at attracting early users and feedback * chance to integrate earlier into an OpenStack release (we could make it into the *I* one) TripleO would get a UI and more developers trying it out and helping with setup and integration. This shouldn't even need to derail us much from the rough roadmap we planned to follow in the upcoming months: 1. get things stable and robust enough to demo in Hong Kong on real hardware 2. include metrics and monitoring 3. security What do you think? That is an excellent idea! Does it mean from the practical point of view that the Tuskar code will be merged into the TripleO repos and the project will be deleted from StackForge and Launchpad? Imre Tomas ___ 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
Re: [openstack-dev] [ironic] [inspector] Proposing Anton Arefiev (aarefiev) for ironic-inspector-core
+1 from me. Thanks for your work Anton and congrats! ;-) Imre On 04/05/2016 12:24 PM, Dmitry Tantsur wrote: Hi! I'd like to propose Anton to the ironic-inspector core reviewers team. His stats are pretty nice [1], he's making meaningful reviews and he's pushing important things (discovery, now tempest). Members of the current ironic-inspector-team and everyone interested, please respond with your +1/-1. A lazy consensus will be applied: if nobody objects by the next Tuesday, the change will be in effect. Thanks [1] http://stackalytics.com/report/contribution/ironic-inspector/60 __ 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] [ironic] wsmanclient
Hi all, We have the openwsman bug[1] for long which affects the AMT and DRAC drivers. I added a simple protocol implementation[2] to python-dracclient a couple months ago using requests and lxml and refactored the DRAC driver to use that instead of openwsman. It's far from being a complete implementation of the protocol specification, just a subset which is needed for the driver. I used it since then without issues and since folks expressed their interest in it for the AMT driver, I proposed changes to project-config[3] and governance[4] to register a new project with the intent to move the code to there from the DRAC specific python-dracclient. Let me know what you think. Thanks, Imre [1] https://bugs.launchpad.net/ironic/+bug/1454492 [2] https://github.com/openstack/python-dracclient/blob/master/dracclient/wsman.py [3] https://review.openstack.org/#/c/269122/ [4] https://review.openstack.org/#/c/269137/ __ 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] [Ironic] [Inspector] Addition to ironic-inspector-core: Sam Betts
On 08/25/2015 12:53 PM, Dmitry Tantsur wrote: Hi all! Please join me in welcoming Sam to our team! He has been doing very smart reviews recently, was contributing core features and expressed clear interest in the ironic-inspector project. Thanks and welcome! Congrats Sam, well deserved! Imre __ 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] [Ironic] [Inspector] Addition to ironic-inspector-core, switching to 2x +2 rule
On 07/01/2015 10:56 AM, Dmitry Tantsur wrote: Hi all! Please welcome Yuiko Takada to ironic-inspector-core team. Yuiko has been with the team for some time already. She did substantial work on porting ironic-inspector to Oslo libraries and on our new devstack gate job. Thanks Yuiko, it's a pleasure to work with you. Congrats Yuiko, that is very well deserved! As our core team grows, I'd like us to try to stick with 2x +2 rules. Up to now it was mostly "Dmitry approves everything" rule, now let us make sure we have at least 2 +2 on a patch before merging it, unless it's critical for release or fixing gate. Don't wait for me to W+1 if you see that patch already has 2x +2. I'd ask the core team to review all the incoming patches. Once our devstack gate is finally working, review will be a lot easier. +1 Imre __ 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] [Ironic] ironic-discoverd release plans
Hi Dmitry, Sounds good to me! ;-) Imre On 03/20/2015 01:59 PM, Dmitry Tantsur wrote: This is an informational email about upcoming ironic-discoverd-1.1.0 [1]. If you're not interested in discoverd, you may safely skip it. Hi all! Do you know what time is coming? Release time! I'm hoping to align this ironic-discoverd release with the OpenStack one. Here's proposed plan, which will be in effect, unless someone disagrees: Apr 9: feature freeze. The goal is to leave me some time to test it with Ironic RC and in-progress devstack integration [2]. Between this point and the release day, git master can be considered a release candidate :) Apr 30: release and celebration. stable/1.1 is branched and master is opened for features. For better scoping I've untargeted everything from 1.1.0 milestone [1], except for thing I see as particularly important. We might add more if we have time before FF. Please let me know what you think. Cheers, Dmitry [1] https://launchpad.net/ironic-discoverd/+milestone/1.1.0 [2] https://etherpad.openstack.org/p/DiscoverdDevStack __ 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] [ironic] ironic-inspector-core team update
On Mon, Sep 26, 2016 at 11:24 AM, Dmitry Tantsur wrote: > Hi folks! > > As you probably know, Imre has decided to leave us for other challenges, > so our small core team has become even smaller. I'm removing him on his > request. > > I suggest adding Milan Kovacik (milan or mkovacik on IRC) to the > ironic-inspector-core team. He's been pretty active on ironic-inspector > recently, doing meaningful reviews, and he's driving our HA work forward. > > Please vote with +1/-1. If no objections are recorded, the change will be > in effect next Monday. > +1 to both. :-) Congrats Milan, very well deserved! Imre > > Thanks! > > __ > 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
