[Openstack-operators] ubuntu-14.04 unable to ssh
Hi, I'm working on creating instances inside the openstack dashboard. I have two images of Ubuntu 12.04 and Ubuntu 14.04. What I'm noticing here is when I upgrade my instance of Ubuntu 12.04 to 14.04, I'm unable to ssh to that machine. I tried bringing up the instance through the image of Ubuntu 14.04 but I'm experiencing the same issue. Could someone point out how to rectify this situation. Thank you, Aishwarya This message is for the designated recipient only and may contain privileged, proprietary, or otherwise confidential information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the e-mail by you is prohibited. Where allowed by local law, electronic communications with Accenture and its affiliates, including e-mail and instant messaging (including content), may be scanned by our systems for the purposes of information security and assessment of internal compliance with Accenture policy. __ www.accenture.com ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] openstack and xen
On 02 Jul 2015 (19:26), gustavo panizzo (gfa) wrote: Hello Hi, has anybody moved from kvm to xen? i see the support for xen on nova's hypervisor support matrix got better on latest releases. We're using Xen from the beginning, back in Cactus IIRC. In the past we had to patch several things, but support has improved a lot. we found hard to isolate noisy vm on kvm, and the network problem (i sent on another email) is killing us besides, xen being used by rackspace and aws is not bad publicity at all so, is anybody using xen? what are they using? xenserver from citrix, xen4centos, xen on ubuntu, xen+libvirt? what are the results? We are using Ubuntu + Libvirt + Xen, and we're happy with it. The only thing that you have to take into account is that if you plan to use PyGrub you cannot use CoW, mainly because PyGrub cannot read qcow2 images. Cheers, -- Álvaro López García al...@ifca.unican.es Instituto de Física de Cantabria http://alvarolopez.github.io Ed. Juan Jordá, Campus UC tel: (+34) 942 200 969 Avda. de los Castros s/nskype: aloga.csic 39005 Santander (SPAIN) ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] [keystone][all] Deprecating slash ('/') in project names
I mean project names. You can, for example, create a project today with a name like dev/tests. Em seg, 6 de jul de 2015 às 03:56, Sam Morrison sorri...@gmail.com escreveu: Do you mean project names or project IDs? Sam On 3 Jul 2015, at 12:12 am, Henrique Truta henriquecostatr...@gmail.com wrote: Hi everyone, In Kilo, keystone introduced the concept of Hierarchical Multitenancy[1], which allows cloud operators to organize projects in hierarchies. This concept is evolving in Liberty, with the addition of the Reseller use case[2], where among other features, it’ll have hierarchies of domains by making the domain concept a feature of projects and not a different entity: from now on, every domain will be treated as a project that has the “is_domain” property set to True. Currently, getting a project scoped token can be made by only passing the project name and the domain it belongs to, once project names are unique between domains. However with those hierarchies of projects, in M we intend to remove this constraint in order to make a project name unique only in its level in the hierarchy (project parent). In other words, it won’t be possible to have sibling projects with the same name. For example. the following hierarchy will be valid: A - project with the domain feature /\ B C - “pure” projects, children of A | | A B - “pure” projects, children of B and C respectively Therefore, the cloud user faces some problems when getting a project scoped token by name to projects A or B, since keystone won’t be able to distinguish them only by their names. The best way to solve this problem is providing the full hierarchy, like “A/B/A”, “A/B”, “A/C/B” and so on. To achieve this, we intend to deprecate the “/” character in project names in Liberty and prohibit it in M, removing/replacing this character in a database migration**. Do you have some strong reason to keep using this character in project names? How bad would it be for existing deploys? We’d like to hear from you. Best regards, Henrique ** LDAP as assignment backend does not support Hierarchical Multitenancy. This change will be only applied to SQL backends. [1] http://specs.openstack.org/openstack/keystone-specs/specs/juno/hierarchical_multitenancy.html [2] http://specs.openstack.org/openstack/keystone-specs/specs/kilo/reseller.html ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] Ansible Playbook for OpenStack (juno)
Hi Kevin Carter, Thank you very much for the useful input. Actually i am very interested in deploying OpenStack using Ansible. The os-ansible-deployment project seems perfect,with some complexity though. Hopefully i will find some help on the IRC channel when the need arises. thank you and regards, Hamza On 6 July 2015 at 06:42, Kevin Carter kevin.car...@rackspace.com wrote: @Hamza if you get around to looking into the os-ansible-deployment project please consider joining our IRC channel on freenode at #openstack-ansible there almost always someone online and we'd be happy help you get started with the project. If you're just browsing, we have some installation documentation online that you have read through here: http://osad.readthedocs.org/en/latest/ Take care. -- Kevin Carter -- *From:* achi hara h16m...@gmail.com *Sent:* Sunday, July 5, 2015 10:14 AM *To:* Leslie-Alexandre DENIS *Cc:* openstack-operators@lists.openstack.org *Subject:* Re: [Openstack-operators] Ansible Playbook for OpenStack (juno) Hi Leslie Alexandre Thank you for providing me with the two links. i will try to use the second one. Regards, Hamza 2015-07-04 23:57 GMT+01:00 Leslie-Alexandre DENIS cont...@ladenis.fr: Hello, The best sources for that would be : - https://github.com/stackforge/os-ansible-deployment - https://github.com/blueboxgroup/ursula Actually these are well written and very modular, you probably don't really need all of the complexity for a standard deployment but at least you can start from that. Regards, Le 05/07/2015 00:40, achi hara a écrit : Hi everyone, I would like to deploy OpenStack (*Juno* release) using Ansible. could you please provide me with the playbooks for this purpose ? Your assistance is greatly appreciated. Sincerely Hamza ___ OpenStack-operators mailing listOpenStack-operators@lists.openstack.orghttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] Scaling the Ops Meetup
On Wed, Jul 1, 2015 at 3:29 AM, Tom Fifield t...@openstack.org wrote: Team, It's great to see so much passion! :) Here's an attempt at a summary email. I'll wait until a later email to wade into the discussion myself ;) Feel free to jump in on any point. =Things we tend to agree on= snip I agree on all those too. =Things still under discussion= Sell Tickets * Many people agreed that some moderate form of ticketing could be OK, but the question remains to what extent this should be priced (low fee? $100-200? cover costs?). A strong counterpoint was that paid ticketing makes it less accessible (see spirit), prevents some local attendance, and is unfair to smaller operators, though others noted that it may be the only practical way to raise funds in the future. I think everyone agrees this is best kept as low a barrier as possible. It would be interesting to know per attendee costs to help assess what kind of barrier it would be. Obviously if we get some corporate underwriting that meets the 'we all agree' low impact desires that would help minimize this and if it can be zero it should be. Break into Regional Events * A number of viewpoints, ranging from multiple regional events to one event only [maybe with a travel fund] to one event that moves around [maybe even outside USA] to make it in the centre of USA for easier travel on average. I think breaking into regional events would seriously undermine the utility of the event unless someone has a really clever idea how to run 3 or 4 locations as a single distributed event so we can actually gather and share ideas among all of them (I don't see how that would work). I am uncomfortable with the US-centric nature of the ops events even though it's been terribly convenient for me. I would suggest if we so start rotating continents (which I'm in favor of) we try and keep it opposite the summit locations so those least likely to make the summit are most likely to make the mid cycle that way no region gets left too far behind. Capping Numbers (inc. Limit Attendees per Company) * A lot of disagreement here. Many argued that any kind of cap or barrier to entry detracts from the accessibility of the event. Others put forth that too few restrictions could dilute the ops-heavy attendee base, and implied that large companies might send too many people. I think it's best to try addressing this socially at first. Make it clear space is at a premium and encourage attendees to send the minimum number of people necessary to cover the sessions. Setting a hard limit is hard because I can imagine larger and more complex sites may have a legitimate need to send more people due to greater role specialization or other reasons. Multiple Tracks * To help deal with room size, we could split into multiple tracks. The ideal number of tracks is not clear at this stage. I'm not even sure what I think is best here, but these are my thoughts: More tracks makes it harder for small to medium size sites to cover. Not saying we shouldn't expand parallelism but we should be cautious. My site is a private university cloud with order of 100 hypervisors, we're more or less happy to send 2 people to summits and one to mid cycles, at least that's what I've gotten them to pay for in the past. Obviously we don't come close to covering summits. The dual track (for one attendee) in PHL was OK and conflicts weren't too bad. The obvious alternative if we need more sessions would be to go longer and honestly I'm not keen on that either and would probably prefer wider over longer. -Jon ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] Scaling the Ops Meetup
On Mon, Jul 6, 2015 at 11:28 AM, Jonathan Proulx j...@jonproulx.com wrote: More tracks makes it harder for small to medium size sites to cover. Not saying we shouldn't expand parallelism but we should be cautious. My site is a private university cloud with order of 100 hypervisors, we're more or less happy to send 2 people to summits and one to mid cycles, at least that's what I've gotten them to pay for in the past. Obviously we don't come close to covering summits. The dual track (for one attendee) in PHL was OK and conflicts weren't too bad. The obvious alternative if we need more sessions would be to go longer and honestly I'm not keen on that either and would probably prefer wider over longer. +1 on wider vs longer. if we do go longer, let's limit it to half-day expansion (so folks can fly in or out that half day.) Of course if it is in Timbuktu, that 1/2 day won't buy much in terms of maximizing commute time. https://en.wikipedia.org/wiki/Timbuktu ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] Scaling the Ops Meetup
On Thu, Jul 2, 2015 at 2:26 PM, Jesse Keating j...@bluebox.net wrote: BoD, unless they feel the need to delegate, at which point then maybe an Operators committee. But I'd hate to see more committees created. I feel like this may be a User Committee thing, which is an existing committee and sort-of-kind-of how this started I think. Granted that's a bit of a shadowy cabal at this point but hopefully we're on a path to a better place with that... -Jon - jlk On Thu, Jul 2, 2015 at 11:23 AM, Matt Fischer m...@mattfischer.com wrote: Are you proposing an Operators committee or do you mean the OpenStack BoD? On Thu, Jul 2, 2015 at 12:15 PM, Jesse Keating j...@bluebox.net wrote: Honestly I'm fine with the elected board helping to make this decision. Folks that want to underwrite the event can submit a proposal to host, board picks from the submissions? Having a wide vote on it seems overkill to me. Open call for submissions, board votes. Is that unreasonable? - jlk On Thu, Jul 2, 2015 at 8:23 AM, Tom Fifield t...@openstack.org wrote: OK, so I'm just going to throw this one out there to re-stoke the discussion ... Venue selection process. At the moment, there's a few of us who work hard in the shadows to make the best choice we can from a range of generous offers :) In our brave new world, I think this should be a bit more open, what do you think? What kind of structure do we need to make the best decision? Regards, Tom On 01/07/15 15:29, Tom Fifield wrote: Team, It's great to see so much passion! :) Here's an attempt at a summary email. I'll wait until a later email to wade into the discussion myself ;) Feel free to jump in on any point. =Things we tend to agree on= Spirit of the event * The response most people had in common was that they didn't want to see vendor booths :) Several others noted the importance that the event should remain accessible and ensure there were no barriers to attendance, space for networking with others and sharing information about deployments without fear of vendor harassment. Multiple Sponsors * are OK, but they are more like underwriters who should be OK with only modest acknowledgement (see previous: no booths). Preference for operator sponsors. Several ways to recognise them possible. Current Schedule Format * It appeared like the current format is working well in general, but could do with minor tweaks. =Things still under discussion= Sell Tickets * Many people agreed that some moderate form of ticketing could be OK, but the question remains to what extent this should be priced (low fee? $100-200? cover costs?). A strong counterpoint was that paid ticketing makes it less accessible (see spirit), prevents some local attendance, and is unfair to smaller operators, though others noted that it may be the only practical way to raise funds in the future. Break into Regional Events * A number of viewpoints, ranging from multiple regional events to one event only [maybe with a travel fund] to one event that moves around [maybe even outside USA] to make it in the centre of USA for easier travel on average. Capping Numbers (inc. Limit Attendees per Company) * A lot of disagreement here. Many argued that any kind of cap or barrier to entry detracts from the accessibility of the event. Others put forth that too few restrictions could dilute the ops-heavy attendee base, and implied that large companies might send too many people. Multiple Tracks * To help deal with room size, we could split into multiple tracks. The ideal number of tracks is not clear at this stage. Evening Event * Several people said they found the PHL evening event uncomfortably packed, and suggested cancelling it on this basis, or on the basis of cost. Suggested alternate was posting a list of nearby venues. Lightening Talks * Have lightening talks, perhaps by renaming show and tell. More of them? Arranged differently? Unclear. =Ideas= * Video Recording - Might be worth a shot, starting small. * Travel Fund, Scholarship Fund, Slush Fund * Use Universities during the summer break for venues =Open Questions= * How will the number of attendees grow? * What are the costs involved in hosting one of these events? * Stuff about the summit - probably need a different thread for this Regards, Tom On 30/06/15 12:33, Tom Fifield wrote: Hi all, Right now, behind-the-scenes, we're working on getting a venue for next ops mid-cycle. It's taking a little longer than normal, but rest assured it is happening. Why is it so difficult? As you may have noticed, we're reaching the size of event where both physically and financially, only the largest organisations can host us. We thought we might get away with organising this one old-school with a single host and sponsor. Then, for the next, start a
Re: [Openstack-operators] Scaling the Ops Meetup
On Thu, Jul 2, 2015 at 9:23 AM, Tom Fifield t...@openstack.org wrote: Venue selection process. At the moment, there's a few of us who work hard in the shadows to make the best choice we can from a range of generous offers :) Maybe you could host in Taiwan Tom or Tim could host in Geneva/CERN? ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] Scaling the Ops Meetup
On Mon, Jul 6, 2015 at 12:14 PM, Anita Kuno ante...@anteaya.info wrote: Right now developers are asking for details so they can decide/plan on attending the next event. Are you close to deciding a location and/or perhaps some dates? Yep, this is becoming a big issue. Several others are just going to stomp all over August as they schedule their meetups. ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] Scaling the Ops Meetup
On 06/30/2015 12:33 AM, Tom Fifield wrote: Hi all, Right now, behind-the-scenes, we're working on getting a venue for next ops mid-cycle. It's taking a little longer than normal, but rest assured it is happening. Why is it so difficult? As you may have noticed, we're reaching the size of event where both physically and financially, only the largest organisations can host us. We thought we might get away with organising this one old-school with a single host and sponsor. Then, for the next, start a brainstorming discussion with you about how we scale these events into the future - since once we get up and beyond a few hundred people, we're looking at having to hire a venue as well as make some changes to the format of the event. However, it seems that even this might be too late. We already had a company that proposed to host the meetup at a west coast US hotel instead of their place, and wanted to scope out other companies to sponsor food. This would be a change in the model, so let's commence the discussion of how we want to scale this event :) So far I've heard things like: * my $CORPORATE_BENEFACTOR would be fine to share sponsorship with others * I really don't want to get to the point where we want booths at the ops meetup Which are promising! It seems like we have a shared understanding of what to take this forward with. So, as the ops meetup grows - what would it look like for you? How do you think we can manage the venue selection and financial side of things? What about the session layout and the scheduling with the growing numbers of attendees? Current data can be found at https://wiki.openstack.org/wiki/Operations/Meetups#Venue_Selection . I would also be interested in your thoughts about how these events have only been in a limited geographical area so far, and how we can address that issue. Regards, Tom ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators Hi: Right now developers are asking for details so they can decide/plan on attending the next event. Are you close to deciding a location and/or perhaps some dates? Thanks, Anita. ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] Scaling the Ops Meetup
On 07/06/2015 05:38 PM, Allison Price wrote: Hi everyone, We are currently finalizing the exact date and location for the ops meetup. We have two strong options that Tom will share more details on shortly, but we are aiming to hold the meetup the week of August 17 -21, leaning towards the beginning of the week so it does not conflict with OpenStack Day Seattle. We will be sharing more information shortly, but I wanted to put this on everyone’s radar as you plan travel and other meetups in August. Thanks, Allison Allison Price OpenStack Marketing alli...@openstack.org Thank you, Allison, having the dates help. (Or at least the range of dates.) Thank you, Anita. On Jul 6, 2015, at 1:16 PM, David Medberry openst...@medberry.net wrote: On Mon, Jul 6, 2015 at 12:14 PM, Anita Kuno ante...@anteaya.info mailto:ante...@anteaya.info wrote: Right now developers are asking for details so they can decide/plan on attending the next event. Are you close to deciding a location and/or perhaps some dates? Yep, this is becoming a big issue. Several others are just going to stomp all over August as they schedule their meetups. ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] [keystone][all] Deprecating slash ('/') in project names
Do you mean project names or project IDs? Sam On 3 Jul 2015, at 12:12 am, Henrique Truta henriquecostatr...@gmail.com wrote: Hi everyone, In Kilo, keystone introduced the concept of Hierarchical Multitenancy[1], which allows cloud operators to organize projects in hierarchies. This concept is evolving in Liberty, with the addition of the Reseller use case[2], where among other features, it’ll have hierarchies of domains by making the domain concept a feature of projects and not a different entity: from now on, every domain will be treated as a project that has the “is_domain” property set to True. Currently, getting a project scoped token can be made by only passing the project name and the domain it belongs to, once project names are unique between domains. However with those hierarchies of projects, in M we intend to remove this constraint in order to make a project name unique only in its level in the hierarchy (project parent). In other words, it won’t be possible to have sibling projects with the same name. For example. the following hierarchy will be valid: A - project with the domain feature /\ B C - “pure” projects, children of A | | A B - “pure” projects, children of B and C respectively Therefore, the cloud user faces some problems when getting a project scoped token by name to projects A or B, since keystone won’t be able to distinguish them only by their names. The best way to solve this problem is providing the full hierarchy, like “A/B/A”, “A/B”, “A/C/B” and so on. To achieve this, we intend to deprecate the “/” character in project names in Liberty and prohibit it in M, removing/replacing this character in a database migration**. Do you have some strong reason to keep using this character in project names? How bad would it be for existing deploys? We’d like to hear from you. Best regards, Henrique ** LDAP as assignment backend does not support Hierarchical Multitenancy. This change will be only applied to SQL backends. [1] http://specs.openstack.org/openstack/keystone-specs/specs/juno/hierarchical_multitenancy.html http://specs.openstack.org/openstack/keystone-specs/specs/juno/hierarchical_multitenancy.html [2] http://specs.openstack.org/openstack/keystone-specs/specs/kilo/reseller.html http://specs.openstack.org/openstack/keystone-specs/specs/kilo/reseller.html ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] ubuntu-14.04 unable to ssh
I would recommend that you don't do a 'dist-upgrade' of a cloud instance. In theory it *should* work, but it feels like an anti-pattern. You have images for 12.04, you have images for 14.04. If you need to use 12.04, choose that for your instances, if you need 14.04, choose that for your instances. Remember that the intention is for Cattle, not Pets. On Jul 6, 2015, at 3:08 AM, aishwarya.adyanth...@accenture.com wrote: Hi, I’m working on creating instances inside the openstack dashboard. I have two images of Ubuntu 12.04 and Ubuntu 14.04. What I’m noticing here is when I upgrade my instance of Ubuntu 12.04 to 14.04, I’m unable to ssh to that machine. I tried bringing up the instance through the image of Ubuntu 14.04 but I’m experiencing the same issue. Could someone point out how to rectify this situation. Thank you, Aishwarya This message is for the designated recipient only and may contain privileged, proprietary, or otherwise confidential information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the e-mail by you is prohibited. Where allowed by local law, electronic communications with Accenture and its affiliates, including e-mail and instant messaging (including content), may be scanned by our systems for the purposes of information security and assessment of internal compliance with Accenture policy. __ www.accenture.com http://www.accenture.com/ ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org mailto:OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators signature.asc Description: Message signed with OpenPGP using GPGMail ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
