Re: [openstack-dev] [Nova] should 'ip address' be retrived when decribe host?
Yes, host is from service table and hypervisor is from compute_nodes table, I think that there are some discussion for this in Paris Summit and there might be some change for this in Kilo. - Detach service from compute node: https://review.openstack.org/#/c/126895/ (implementation on a patch series https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/detach-service-from-computenode,n,z) https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/detach-service-from-computenode,n,z%29 - Goal : Only provide resources to the ComputeNode object, not anything else - The primary goal of this blueprint is to decouple the servicegroup API from the ideas of tracking resources, since they are two wholly separate things I'm not sure if there are some changes for those commands when host was added to compute_nodes table. 2014-12-30 14:52 GMT+08:00 Lingxian Kong anlin.k...@gmail.com: Thanks, Jay Pipes and Jay Lau, for your reply! Just as what Jay Lau said, 'nova hypervisor-show hypervisor_id' indeed returns host ip address, and there are more other information included than 'nova host-describe hostname'. I feel a little confused about the 'host' and 'hypervisor', what's the difference between them? For cloud operator, maybe 'host' is more usefull and intuitive for management than 'hypervisor'. From the implementation perspective, both 'compute_nodes' and 'services' database tables are used for them. Should them be combined for more common use cases? 2014-12-29 21:40 GMT+08:00 Jay Lau jay.lau@gmail.com: Does nova hypervisor-show help? It already include the host ip address. 2014-12-29 21:26 GMT+08:00 Jay Pipes jaypi...@gmail.com: On 12/29/2014 06:51 AM, Lingxian Kong wrote: Hi Stackers: As for now, we can get the 'host name', 'service' and 'availability zone' of a host through the CLI command 'nova host-list'. But as a programmer who communicates with OpenStack using its API, I want to get the host ip address, in order to perform some other actions in my program. And what I know is, the ip address of a host is populated in the 'compute_nodes' table of the database, during the 'update available resource' periodic task. So, is it possible of the community to support it in the future? I apologize if the topic was once covered and I missed it. Hi! I see no real technical reason this could not be done. It would require waiting until all of the API microversioning bits are done, and a micro-increment of the API, along with minimal changes of code in the hosts extension to return the host_ip field from the nova.objects.ComputeNode objects returned to the HostController object. Are you interested in working on such a feature? I would be happy to guide you through the process of making a blueprint and submitting code if you'd like. Just find me on IRC #openstack-nova. My IRC nick is jaypipes. Best, -jay ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Thanks, Jay ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Regards! --- Lingxian Kong ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Thanks, Jay ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Manila]Rename driver mode
Hi list, There are two driver modes in manila currently, multi_svm_mode and single_svm_mode. multi_svm_mode means usage of share-networks that contain network information for dynamic creation of share-servers (SVMs). single_svm_mode means usage of predefined some endpoint, without need to provide share-network and without creation of share-servers (SVMs). Currently, the name of driver mode describes how many servers the driver can handle. For multi, it says that share driver can handle more than one server. And, if someone share server is just already exist from share driver, but it uses some server anyway with host address, username, password, NFS daemon, etc... are defined as works in single_svm mode too. But, as a new user to manila, these names make me really confusing. Because I thought the driver mode names describe how drivers works with share-servers. I thought multi- and single- indicate the number of share-servers would been created when we create a share, if we are using the driver. Obviously, my understanding is wrong. When we're working under driver generic, one share-server would be created for one share-network. When we're working under driver glusterfs, no share-server would be created at all. I believe I would not be the only one who is making this mistake. To make code more readable, I'd like to suggest to rename driver mode names. Name them based on behavior but not ability. I think three driver modes are needed: - dynamic_svm_mode : Usage of share-networks that contain network information for dynamic creation of share-servers (SVMs). This is how current generic driver works. Under this mode, driver manages share servers itself, and share-server would be created and deleted with related shares. - static_svm_mode: Using pre-create share servers. The case as https://review.openstack.org/#/c/144342/ Under this mode, driver do not manage share servers, but work with them. - no_svm_mode: the case as driver glusterfs working currently, no share-server would be created. Thanks. -chen ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel][Nailgun] Web framework
Hello all, What is the current situation with choosing web framework? Was there any progress in the topic? I would like to avoid forgetting about it. 2014-12-08 15:47 GMT+01:00 Ryan Petrello ryan.petre...@dreamhost.com: Feel free to ask any questions you have in #pecanpy on IRC; I can answer a lot more quickly than researching docs, and if you have a special need, I can usually accommodate with changes to Pecan (I've done so with several OpenStack projects in the past). On 12/08/14 02:10 PM, Nikolay Markov wrote: Yes, and it's been 4 days since last message in this thread and no objections, so it seems that Pecan in now our framework-of-choice for Nailgun and future apps/projects. We still need some research to do about technical issues and how easy we can move to Pecan. Thanks to Ryan, we now have multiple links to solutions and docs on discussed issues. I guess we'll dedicate some engineer(s) responsible for doing such a research and then make all our decisions on subject. On Mon, Dec 8, 2014 at 11:07 AM, Sebastian Kalinowski skalinow...@mirantis.com wrote: 2014-12-04 14:01 GMT+01:00 Igor Kalnitsky ikalnit...@mirantis.com: Ok, guys, It became obvious that most of us either vote for Pecan or abstain from voting. Yes, and it's been 4 days since last message in this thread and no objections, so it seems that Pecan in now our framework-of-choice for Nailgun and future apps/projects. So I propose to stop fighting this battle (Flask vs Pecan) and start thinking about moving to Pecan. You know, there are many questions that need to be discussed (such as 'should we change API version' or 'should be it done iteratively or as one patchset'). IMHO small, iterative changes are rather obvious. For other questions maybe we need (draft of ) a blueprint and a separate mail thread? - Igor ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Best regards, Nick Markov ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Ryan Petrello Senior Developer, DreamHost ryan.petre...@dreamhost.com ___ 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] [Fuel][plugins] Fuel 6.0 plugin for Pacemaker STONITH (HA fencing)
Hello. There is a long living blueprint [0] about HA fencing of failed nodes in Corosync and Pacemaker cluster. Happily, in 6.0 release we have a pluggable architecture supported in Fuel. I propose the following implementation [1] (WIP repo [2]) for this feature as a plugin for puppet. It addresses the related blueprint for HA Fencing in puppet manifests of Fuel library [3]. For initial version, all the data definitions for power management devices should be done manually in YAML files (see the plugin's README.md file). Later it could be done in a more user friendly way, as a part of Fuel UI perhaps. Note that the similar approach - YAML data structures which should be filled in by the cloud admin and passed to Fuel Orchestrator automatically at PXE provision stage - could be used as well for Power management blueprint, see the related ML thread [4]. Please also note, there is a dev docs for Fuel plugins merged recently [5] where you can find how to build and install this plugin. [0] https://blueprints.launchpad.net/fuel/+spec/ha-fencing [1] https://review.openstack.org/#/c/144425/ [2] https://github.com/bogdando/fuel-plugins/tree/fencing_puppet_newprovider/ha_fencing [3] https://blueprints.launchpad.net/fuel/+spec/fencing-in-puppet-manifests [4] http://lists.openstack.org/pipermail/openstack-dev/2014-November/049794.html [5] http://docs.mirantis.com/fuel/fuel-6.0/plugin-dev.html#what-is-pluggable-architecture -- Best regards, Bogdan Dobrelya, Skype #bogdando_at_yahoo.com Irc #bogdando ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Openstack-operators] The state of nova-network to neutron migration
On Tue, Dec 30, 2014 at 12:56 AM, Anita Kuno ante...@anteaya.info wrote: On 12/24/2014 04:07 AM, Oleg Bondarev wrote: On Mon, Dec 22, 2014 at 10:08 PM, Anita Kuno ante...@anteaya.info wrote: On 12/22/2014 01:32 PM, Joe Gordon wrote: On Fri, Dec 19, 2014 at 9:28 AM, Kyle Mestery mest...@mestery.com wrote: On Fri, Dec 19, 2014 at 10:59 AM, Anita Kuno ante...@anteaya.info wrote: Rather than waste your time making excuses let me state where we are and where I would like to get to, also sharing my thoughts about how you can get involved if you want to see this happen as badly as I have been told you do. Where we are: * a great deal of foundation work has been accomplished to achieve parity with nova-network and neutron to the extent that those involved are ready for migration plans to be formulated and be put in place * a summit session happened with notes and intentions[0] * people took responsibility and promptly got swamped with other responsibilities * spec deadlines arose and in neutron's case have passed * currently a neutron spec [1] is a work in progress (and it needs significant work still) and a nova spec is required and doesn't have a first draft or a champion Where I would like to get to: * I need people in addition to Oleg Bondarev to be available to help come up with ideas and words to describe them to create the specs in a very short amount of time (Oleg is doing great work and is a fabulous person, yay Oleg, he just can't do this alone) * specifically I need a contact on the nova side of this complex problem, similar to Oleg on the neutron side * we need to have a way for people involved with this effort to find each other, talk to each other and track progress * we need to have representation at both nova and neutron weekly meetings to communicate status and needs We are at K-2 and our current status is insufficient to expect this work will be accomplished by the end of K-3. I will be championing this work, in whatever state, so at least it doesn't fall off the map. If you would like to help this effort please get in contact. I will be thinking of ways to further this work and will be communicating to those who identify as affected by these decisions in the most effective methods of which I am capable. Thank you to all who have gotten us as far as well have gotten in this effort, it has been a long haul and you have all done great work. Let's keep going and finish this. Thank you, Anita. Thank you for volunteering to drive this effort Anita, I am very happy about this. I support you 100%. I'd like to point out that we really need a point of contact on the nova side, similar to Oleg on the Neutron side. IMHO, this is step 1 here to continue moving this forward. At the summit the nova team marked the nova-network to neutron migration as a priority [0], so we are collectively interested in seeing this happen and want to help in any way possible. With regard to a nova point of contact, anyone in nova-specs-core should work, that way we can cover more time zones. From what I can gather the first step is to finish fleshing out the first spec [1], and it sounds like it would be good to get a few nova-cores reviewing it as well. [0] http://specs.openstack.org/openstack/nova-specs/priorities/kilo-priorities.html [1] https://review.openstack.org/#/c/142456/ Wonderful, thank you for the support Joe. It appears that we need to have a regular weekly meeting to track progress in an archived manner. I know there was one meeting November but I don't know what it was called so so far I can't find the logs for that. It wasn't official, we just gathered together on #novamigration. Attaching the log here. Ah, that would explain why I couldn't find the log. Thanks for the attachment. So if those affected by this issue can identify what time (UTC please, don't tell me what time zone you are in it is too hard to guess what UTC time you are available) and day of the week you are available for a meeting I'll create one and we can start talking to each other. I need to avoid Monday 1500 and 2100 UTC, Tuesday 0800 UTC, 1400 UTC and 1900 - 2200 UTC, Wednesdays 1500 - 1700 UTC, Thursdays 1400 and 2100 UTC. I'm available each weekday 0700-1600 UTC, 1700-1800 UTC is also acceptable. Thanks, Oleg Wonderful, thank you Oleg. We will aim for a meeting time in this range. I also understand holidays in Russia start on January 1 and go until the 11th or the 12th, I'm guessing this includes you. Correct. However I'll be available since January 5. Thanks Anita. Thanks, Oleg Thanks, Anita. Thanks, Anita. Thanks, Kyle [0] https://etherpad.openstack.org/p/kilo-nova-nova-network-to-neutron [1]
Re: [openstack-dev] [Fuel][Nailgun] Web framework
Hi Sebastian, Nobody is forgetting this topic, especially me :) We're going to dedicate an engineer to do some research on topic based on Ryan's comments and my old pull request on Nailgun with Pecan. The only thing is that it's not very high priority topic in our roadmap. Don't worry, I'm sure we'll get to it already in January. 30 Дек 2014 г. 15:25 пользователь Sebastian Kalinowski skalinow...@mirantis.com написал: Hello all, What is the current situation with choosing web framework? Was there any progress in the topic? I would like to avoid forgetting about it. 2014-12-08 15:47 GMT+01:00 Ryan Petrello ryan.petre...@dreamhost.com: Feel free to ask any questions you have in #pecanpy on IRC; I can answer a lot more quickly than researching docs, and if you have a special need, I can usually accommodate with changes to Pecan (I've done so with several OpenStack projects in the past). On 12/08/14 02:10 PM, Nikolay Markov wrote: Yes, and it's been 4 days since last message in this thread and no objections, so it seems that Pecan in now our framework-of-choice for Nailgun and future apps/projects. We still need some research to do about technical issues and how easy we can move to Pecan. Thanks to Ryan, we now have multiple links to solutions and docs on discussed issues. I guess we'll dedicate some engineer(s) responsible for doing such a research and then make all our decisions on subject. On Mon, Dec 8, 2014 at 11:07 AM, Sebastian Kalinowski skalinow...@mirantis.com wrote: 2014-12-04 14:01 GMT+01:00 Igor Kalnitsky ikalnit...@mirantis.com: Ok, guys, It became obvious that most of us either vote for Pecan or abstain from voting. Yes, and it's been 4 days since last message in this thread and no objections, so it seems that Pecan in now our framework-of-choice for Nailgun and future apps/projects. So I propose to stop fighting this battle (Flask vs Pecan) and start thinking about moving to Pecan. You know, there are many questions that need to be discussed (such as 'should we change API version' or 'should be it done iteratively or as one patchset'). IMHO small, iterative changes are rather obvious. For other questions maybe we need (draft of ) a blueprint and a separate mail thread? - Igor ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Best regards, Nick Markov ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Ryan Petrello Senior Developer, DreamHost ryan.petre...@dreamhost.com ___ 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] Why nova mounts FS for LXC container instead of libvirt?
Hello, Libvirt can create loop or nbd device for LXC container and mount it by itself, for instance, you can add something like this to xml config: filesystem type='file' driver type='loop' format='raw'/ source file='/fedora-20-raw'/ target dir='/'/ /filesystem But nova mounts filesystem for container by itself. Is this because rhel-6 doesn't support filesystems with type='file' or there are some other reasons? -- Dmitry Guryanov ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [all] Proper use of 'git review -R'
Many times when I review a revision of an existing patch, I can't see just the change from the previous version due to other rebases. The git-review documentation mentions this issue and suggests using -R to make life easier for reviewers when submitting new revisions. Can some one explain when we should *not* use -R after doing 'git commit --amend'? Or is using -R just something that should be done but many folks don't know about it? -David From git-review doc: -R, --no-rebase Do not automatically perform a rebase before submitting the change to Gerrit. When submitting a change for review, you will usually want it to be based on the tip of upstream branch in order to avoid possible conflicts. When amending a change and rebasing the new patchset, the Gerrit web interface will show a difference between the two patchsets which contains all commits in between. This may confuse many reviewers that would expect to see a much simpler differ‐ ence. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Why does nova mount FS for LXC container instead of libvirt?
On Tuesday 30 December 2014 17:18:19 Dmitry Guryanov wrote: Hello, Libvirt can create loop or nbd device for LXC container and mount it by itself, for instance, you can add something like this to xml config: filesystem type='file' driver type='loop' format='raw'/ source file='/fedora-20-raw'/ target dir='/'/ /filesystem But nova mounts filesystem for container by itself. Is this because rhel-6 doesn't support filesystems with type='file' or there are some other reasons? You can define domain with such filesystem in rhel-6's libvirt, but container will use host's root fs, probably there is a bug. -- Dmitry Guryanov ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [QA] check-grenade-dsvm-ironic-sideways failing, blocking much code
On 2014-12-29 23:09:20 -0800 (-0800), Adam Gandelman wrote: [...] I've proposed temporary workaround to devstack-gate, which will hopefully allow those two to backport: https://review.openstack.org/#/c/144408/ [...] That wasn't going to work since it ran too late. We need to catch it between when the stack user is created and when DevStack runs anything as that same user, so the patch has to go into the openstack-dev/devstack stable/icehouse branch and work its way forward from there. See https://review.openstack.org/144475 for my counterproposal. -- Jeremy Stanley ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] Proper use of 'git review -R'
The default behavior, rebasing automatically, is the sane default to avoid having developers run into unexpected merge conflicts on new patch submissions. But if git-review can check to see if a review already exists in gerrit *before* doing the local rebase, I'd be in favor of it skipping the rebase by default if the review already exists. Require developers to rebase existing patches manually. (This is my way of saying I can't think of a good answer to your question.) While we're on the topic, it's also worth noting that --no-rebase becomes critically important when a patch in the review sequence has already been approved, because the entire series will be rebased, potentially pulling patches out of the gate, clearing the Workflow+1 bit, and resetting the gate (probably unnecessarily). A tweak to the default behavior would help avoid this scenario. -Dolph On Tue, Dec 30, 2014 at 8:46 AM, David Kranz dkr...@redhat.com wrote: Many times when I review a revision of an existing patch, I can't see just the change from the previous version due to other rebases. The git-review documentation mentions this issue and suggests using -R to make life easier for reviewers when submitting new revisions. Can some one explain when we should *not* use -R after doing 'git commit --amend'? Or is using -R just something that should be done but many folks don't know about it? -David From git-review doc: -R, --no-rebase Do not automatically perform a rebase before submitting the change to Gerrit. When submitting a change for review, you will usually want it to be based on the tip of upstream branch in order to avoid possible conflicts. When amending a change and rebasing the new patchset, the Gerrit web interface will show a difference between the two patchsets which contains all commits in between. This may confuse many reviewers that would expect to see a much simpler differ‐ ence. ___ 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] [Nova] should 'ip address' be retrived when decribe host?
On Tue, 2014-12-30 at 14:52 +0800, Lingxian Kong wrote: Just as what Jay Lau said, 'nova hypervisor-show hypervisor_id' indeed returns host ip address, and there are more other information included than 'nova host-describe hostname'. I feel a little confused about the 'host' and 'hypervisor', what's the difference between them? For cloud operator, maybe 'host' is more usefull and intuitive for management than 'hypervisor'. From the implementation perspective, both 'compute_nodes' and 'services' database tables are used for them. Should them be combined for more common use cases? Well, the host and the hypervisor are conceptually distinct objects. The hypervisor is, obviously, the thing on which all the VMs run. The host, though, is the node running the corresponding nova-compute service, which may be separate from the hypervisor. For instance, on Xen-based setups, the host runs in a VM on the hypervisor. There has also been discussion of allowing one host to be responsible for multiple hypervisors, which would be useful for providers with large numbers of hypervisors. -- Kevin L. Mitchell kevin.mitch...@rackspace.com Rackspace ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] Proper use of 'git review -R'
On 2014-12-30 09:46:35 -0500 (-0500), David Kranz wrote: [...] Can some one explain when we should *not* use -R after doing 'git commit --amend'? [...] In the standard workflow this should never be necessary. The default behavior in git-review is to attempt a rebase and then undo it before submitting. If the rebase shows merge conflicts, the push will be averted and the user instructed to deal with those conflicts. Using -R will skip this check and allow you to push changes which can't merge due to conflicts. From git-review doc: -R, --no-rebase Do not automatically perform a rebase before submitting the change to Gerrit. When submitting a change for review, you will usually want it to be based on the tip of upstream branch in order to avoid possible conflicts. When amending a change and rebasing the new patchset, the Gerrit web interface will show a difference between the two patchsets which contains all commits in between. This may confuse many reviewers that would expect to see a much simpler differ‐ ence. While not entirely incorrect, it could stand to be updated with slightly more clarification around the fact that git-review (since around 1.16 a few years ago) does not push an automatically rebased change for you unless you are using -F/--force-rebase. If you are finding changes which are gratuitously rebased, this is likely either from a contributor who does not use the recommended change update workflow, has modified their rebase settings or perhaps is running a very, very old git-review version. -- Jeremy Stanley ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ironic] thoughts on the midcycle
I could definitely make a Bay Area meetup. On Mon Dec 29 2014 at 3:50:04 PM Jim Rollenhagen j...@jimrollenhagen.com wrote: On Mon, Dec 29, 2014 at 10:45:57PM +, Devananda van der Veen wrote: I'm sending the details of the midcycle in a separate email. Before you reply that you won't be able to make it, I'd like to share some thoughts / concerns. In the last few weeks, several people who I previously thought would attend told me that they can't. By my informal count, it looks like we will have at most 5 of our 10 core reviewers in attendance. I don't think we should cancel based on that, but it does mean that we need to set our expectations accordingly. Assuming that we will be lacking about half the core team, I think it will be more practical as a focused sprint, rather than a planning design meeting. While that's a break from precedent, planning should be happening via the spec review process *anyway*. Also, we already have a larger back log of specs and work than we had this time last cycle, but with the same size review team. Rather than adding to our backlog, I would like us to use this gathering to burn through some specs and land some code. That being said, I'd also like to put forth this idea: if we had a second gathering (with the same focus on writing code) the following week (let's say, Feb 11 - 13) in the SF Bay area -- who would attend? Would we be able to get the other half of the core team together and get more work done? Is this a good idea? I'm +1 on a Bay Area meetup; however, if it happens I likely won't be making the Grenoble meetup. There's a slim chance I can do both. I'd like to figure this out ASAP so I can book travel at a reasonable price. A second meetup certainly can't be bad; I'm sure we can get a ton of work done with the folks that I assume would attend. :) // jim OK. That's enough of my musing for now... Once again, if you will be attending the midcycle sprint in Grenoble the week of Feb 3rd, please sign up HERE https://www.eventbrite.com/e/openstack-ironic-kilo-midcycle -sprint-in-grenoble-tickets-15082886319 . Regards, Devananda ___ 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
Re: [openstack-dev] [all] Proper use of 'git review -R'
On 2014-12-30 10:32:22 -0600 (-0600), Dolph Mathews wrote: The default behavior, rebasing automatically, is the sane default to avoid having developers run into unexpected merge conflicts on new patch submissions. Please show me an example of this in the wild. I suspect a lot of reviewers are placing blame on this without due investigation. But if git-review can check to see if a review already exists in gerrit *before* doing the local rebase, I'd be in favor of it skipping the rebase by default if the review already exists. Require developers to rebase existing patches manually. (This is my way of saying I can't think of a good answer to your question.) It already requires contributors to take manual action--it will not automatically rebase and then push that without additional steps. While we're on the topic, it's also worth noting that --no-rebase becomes critically important when a patch in the review sequence has already been approved, because the entire series will be rebased, potentially pulling patches out of the gate, clearing the Workflow+1 bit, and resetting the gate (probably unnecessarily). A tweak to the default behavior would help avoid this scenario. The only thing -R is going to accomplish is people uploading changes which can never pass because they're merge-conflicting with the target branch. -- Jeremy Stanley ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ironic] thoughts on the midcycle
On Dec 29, 2014, at 2:45 PM, Devananda van der Veen devananda@gmail.commailto:devananda@gmail.com wrote: That being said, I'd also like to put forth this idea: if we had a second gathering (with the same focus on writing code) the following week (let's say, Feb 11 - 13) in the SF Bay area -- who would attend? Would we be able to get the other half of the core team together and get more work done? Is this a good idea? +1 I’d be willing and able to attend this. - Jay Faulkner ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova] Why nova mounts FS for LXC container instead of libvirt?
On Tuesday 30 December 2014 17:18:19 Dmitry Guryanov wrote: Hello, Libvirt can create loop or nbd device for LXC container and mount it by itself, for instance, you can add something like this to xml config: filesystem type='file' driver type='loop' format='raw'/ source file='/fedora-20-raw'/ target dir='/'/ /filesystem But nova mounts filesystem for container by itself. Is this because rhel-6 doesn't support filesystems with type='file' or there are some other reasons? Sorry, forgot to add [Nova] prefix in the first message. -- Dmitry Guryanov ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] Proper use of 'git review -R'
On Tue, Dec 30, 2014 at 8:46 AM, David Kranz dkr...@redhat.com wrote: Many times when I review a revision of an existing patch, I can't see just the change from the previous version due to other rebases. I've gotten used to this. Typically when I review a new patch set I look for my comments and make sure they were addressed. Then I go back to compare with the base revision and look through the patch again. It's quicker this time since I remember what it was about. The git-review documentation mentions this issue and suggests using -R to make life easier for reviewers when submitting new revisions. Can some one explain when we should *not* use -R after doing 'git commit --amend'? A developer updating a patch is going to want to test the change using the latest master and not an old buggy version, so before you make your changes you rebase and -R isn't going to make a difference. You could be really considerate and re-rebase on the original parent. (Or you could be lazy and not test your changes locally with the latest master.) When you have a chain of commits rebasing gets more complicated since gerrit shows a dependent review as out of date if the parent review is changed in any way, and if there's a merge conflict far down the chain you have to rebase the whole chain. Rebasing the patch on master does make one thing easier -- if you want to download the patch and try it out and your newer environment (tox or devstack for example) doesn't work with the patch repo's old environment you'll need to rebase first to get it to work. Or is using -R just something that should be done but many folks don't know about it? -David From git-review doc: -R, --no-rebase Do not automatically perform a rebase before submitting the change to Gerrit. When submitting a change for review, you will usually want it to be based on the tip of upstream branch in order to avoid possible conflicts. When amending a change and rebasing the new patchset, the Gerrit web interface will show a difference between the two patchsets which contains all commits in between. This may confuse many reviewers that would expect to see a much simpler differ‐ ence. ___ 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] [all] Proper use of 'git review -R'
On 12/30/2014 11:37 AM, Jeremy Stanley wrote: On 2014-12-30 09:46:35 -0500 (-0500), David Kranz wrote: [...] Can some one explain when we should *not* use -R after doing 'git commit --amend'? [...] In the standard workflow this should never be necessary. The default behavior in git-review is to attempt a rebase and then undo it before submitting. If the rebase shows merge conflicts, the push will be averted and the user instructed to deal with those conflicts. Using -R will skip this check and allow you to push changes which can't merge due to conflicts. From git-review doc: -R, --no-rebase Do not automatically perform a rebase before submitting the change to Gerrit. When submitting a change for review, you will usually want it to be based on the tip of upstream branch in order to avoid possible conflicts. When amending a change and rebasing the new patchset, the Gerrit web interface will show a difference between the two patchsets which contains all commits in between. This may confuse many reviewers that would expect to see a much simpler differ‐ ence. While not entirely incorrect, it could stand to be updated with slightly more clarification around the fact that git-review (since around 1.16 a few years ago) does not push an automatically rebased change for you unless you are using -F/--force-rebase. If you are finding changes which are gratuitously rebased, this is likely either from a contributor who does not use the recommended change update workflow, has modified their rebase settings or perhaps is running a very, very old git-review version. Thanks for the replies. The rebases I was referring to are not gratuitous, they just make it harder for the reviewer. I take a few things away from this. 1. This is really a UI issue, and one that is experienced by many. What is desired is an option to look at different revisions of the patch that show only what the author actually changed, unless there was a conflict. 2. Using -R is dangerous unless you really know what you are doing. The doc string makes it sound like an innocuous way to help reviewers. -David ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] Proper use of 'git review -R'
On 2014-12-30 12:31:35 -0500 (-0500), David Kranz wrote: [...] 1. This is really a UI issue, and one that is experienced by many. What is desired is an option to look at different revisions of the patch that show only what the author actually changed, unless there was a conflict. I'm not sure it's entirely a UI issue. It runs deeper. There simply isn't enough metadata in Git to separate intentional edits from edits made to solve merge conflicts. Using merge commits instead of rebases mostly solves this particular problem but at the expense of introducing all sorts of new ones. A rebase-oriented workflow makes it easier for merge conflicts to be resolved along the way, instead of potentially nullifying valuable review effort at the very end when it comes time to approve the change and it's no longer relevant to the target branch. There is a potential work-around, though it currently involves some manual effort (not sure whether it would be sane to automate as a feature of git-review). When you notice your change conflicts and will need a rebase, first reset and stash your change, then reset --hard to the previous patchset already in Gerrit, then rebase that and push it (solving the merge conflicts if any), then pop your stashed edits (solving any subsequent merge conflicts) and finally push that as yet another patchset. This separates the rebase from your intentional modifications though at the cost of rather a lot of extra work. Alternatively you could push your edits with git review -R and _then_ follow up with another patchset rebasing on the target branch and resolving the merge conflicts. Possibly slightly easier? 2. Using -R is dangerous unless you really know what you are doing. The doc string makes it sound like an innocuous way to help reviewers. Not necessarily dangerous, but it does allow you to push changes which are just going to flat fail all jobs because they can't be merged to the target branch to get tested. -- Jeremy Stanley ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ironic] thoughts on the midcycle
I'll attend. Whether it's in-person or remote is up in the air though. Clif On 12/30/2014 10:51 AM, Jay Faulkner wrote: On Dec 29, 2014, at 2:45 PM, Devananda van der Veen devananda@gmail.com mailto:devananda@gmail.com wrote: That being said, I'd also like to put forth this idea: if we had a second gathering (with the same focus on writing code) the following week (let's say, Feb 11 - 13) in the SF Bay area -- who would attend? Would we be able to get the other half of the core team together and get more work done? Is this a good idea? +1 I’d be willing and able to attend this. - Jay Faulkner ___ 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] [third-party] Third-party CI meeting change
There will be a new working group meeting for improving the consumability of infra CI components and documentation. The vote has been tallied and the meeting times will be Wednesdays at 1500/0400 UTC alternating. The existing meeting at 1800 UTC on Monday January 5th (and all future meetings at that time) will be cancelled and we will start the new time on January 7th with 1500 UTC. The following week, January 14th, will be at the alternating time 0400 UTC. The other times on Monday and Tuesday will remain unchanged for helping new CI operators in understanding the infra tools and processes. Refer to the meetings page for more details: https://wiki.openstack.org/wiki/Meetings#Third_Party_Meeting Thanks, Kurt Taylor (krtaylor) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Magnum] Proposed Changes to Magnum Core
Thanks for your votes. Changes have been applied. Welcome Motohiro/Yuanying Otsuka to the core group. Regards, Adrian On Dec 26, 2014, at 12:44 PM, Adrian Otto adrian.o...@rackspace.com wrote: Magnum Cores, I propose the following addition to the Magnum Core group[1]: + Motohiro/Yuanying Otsuka (ootsuka) Please let me know your votes by replying to this message. Thanks, Adrian [1] https://review.openstack.org/#/admin/groups/473,members Current Members ___ 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] [qa] What does it mean when a network's admin_state_up = false?
Hi, I have a VM with an interface attached to network “provider-net-1” and assigned IP 66.0.0.8. localadmin@qa4:~/devstack$ nova list +--+--+++-+--+ | ID | Name | Status | Task State | Power State | Networks | +--+--+++-+--+ | d4815a38-ea64-4189-95b2-fefe82a07b72 | vm-1 | ACTIVE | - | Running | provider_net-1=66.0.0.8 | +--+--+++-+--+ Verify ping 66.0.0.8 from the router namespace is successful. Then I set the admin_state_up = false for the network. localadmin@qa4:~/devstack$ neutron net-update --admin_state_up=false provider_net-1 Updated network: provider_net-1 localadmin@qa4:~/devstack$ neutron net-show provider_net-1 +---+--+ | Field | Value| +---+--+ | admin_state_up| False| | id| 9532b759-68a2-4dc0-bcd4-b372fccabe3c | | name | provider_net-1 | | provider:network_type | vlan | | provider:physical_network | physnet1 | | provider:segmentation_id | 399 | | router:external | False| | shared| False| | status| ACTIVE | | subnets | 8e75c110-9b31-4268-ba5c-e130fa139d32 | | tenant_id | e217fbc20a3b4f4fab49ec580e9b6a15 | +---+--+ Afterwards, the ping is still successful. I expect the ping to fail since the network admin_state_up= false. What is the expected behavior? What does it mean when a network's admin_state_up = false? Thanks, Danny ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Solum] Addition to solum core
+1 2014-12-27 19:02 GMT+01:00 Devdatta Kulkarni devdatta.kulka...@rackspace.com: +1 -- *From:* James Y. Li [yuel...@gmail.com] *Sent:* Saturday, December 27, 2014 9:03 AM *To:* OpenStack Development Mailing List *Subject:* Re: [openstack-dev] [Solum] Addition to solum core +1! -James Li On Dec 27, 2014 2:02 AM, Adrian Otto adrian.o...@rackspace.com wrote: Solum cores, I propose the following addition to the solum-core group[1]: + Ed Cranford (ed--cranford) Please reply to this email to indicate your votes. Thanks, Adrian Otto [1] https://review.openstack.org/#/admin/groups/229,members Current Members ___ 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
Re: [openstack-dev] [Nova] should 'ip address' be retrived when decribe host?
Thanks Kevin for your clarification, which further affirms my belief that ip address should be included in the host info. I will contact Jay Pipes on IRC, to see what can I help towards this effort, soon after the New Year's Day in China. :) 2014-12-31 0:34 GMT+08:00 Kevin L. Mitchell kevin.mitch...@rackspace.com: On Tue, 2014-12-30 at 14:52 +0800, Lingxian Kong wrote: Just as what Jay Lau said, 'nova hypervisor-show hypervisor_id' indeed returns host ip address, and there are more other information included than 'nova host-describe hostname'. I feel a little confused about the 'host' and 'hypervisor', what's the difference between them? For cloud operator, maybe 'host' is more usefull and intuitive for management than 'hypervisor'. From the implementation perspective, both 'compute_nodes' and 'services' database tables are used for them. Should them be combined for more common use cases? Well, the host and the hypervisor are conceptually distinct objects. The hypervisor is, obviously, the thing on which all the VMs run. The host, though, is the node running the corresponding nova-compute service, which may be separate from the hypervisor. For instance, on Xen-based setups, the host runs in a VM on the hypervisor. There has also been discussion of allowing one host to be responsible for multiple hypervisors, which would be useful for providers with large numbers of hypervisors. -- Kevin L. Mitchell kevin.mitch...@rackspace.com Rackspace ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Regards! --- Lingxian Kong ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
