Re: [openstack-dev] [openstack-ansible][compass] Support of Offline Install

2015-09-15 Thread Weidong Shao
Jesse, thanks for the information! I will look into this. The proxy server
and local repo option might just work for us.

On Tue, Sep 15, 2015 at 2:53 AM Jesse Pretorius <jesse.pretor...@gmail.com>
wrote:

> On 15 September 2015 at 05:36, Weidong Shao <weidongs...@gmail.com> wrote:
>
>> Compass, an openstack deployment project, is in process of using osad
>> project in the openstack deployment. We need to support a use case where
>> there is no Internet connection. The way we handle this is to split the
>> deployment into "build" and "install" phase. In Build phase, the Compass
>> server node can have Internet connection and can build local repo and other
>> necessary dynamic artifacts that requires Internet connection. In "install"
>> phase, the to-be-installed nodes do not have Internet connection, and they
>> only download necessary data from Compass server and other services
>> constructed in Build phase.
>>
>> Now, is "offline install" something that OSAD project shall also support?
>> If yes, what is the scope of work for any changes, if required.
>>
>
> Currently we don't have a offline install paradigm - but that doesn't mean
> that we couldn't shift things around to support it if it makes sense. I
> think this is something that we could discuss via the ML, via a spec
> review, or at the summit.
>
> Some notes which may be useful:
>
> 1. We have support for the use of a proxy server [1].
> 2. As you probably already know, we build the python wheels for the
> environment on the repo-server - so all python wheel installs (except
> tempest venv requirements) are done directly from the repo server.
> 3. All apt-key and apt-get actions are done against online repositories.
> If you wish to have these be done online then there would need to be an
> addition of some sort of apt-key and apt package mirror which we currently
> do not have. If there is a local repo in the environment, the functionality
> to direct all apt-key and apt-get install actions against an internal
> mirror is all there.
>
> [1]
> http://git.openstack.org/cgit/openstack/openstack-ansible/commit/?id=ed7f78ea5689769b3a5e1db444f4c16f3cc06060
> __
> 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] [openstack-ansible][compass] Support of Offline Install

2015-09-14 Thread Weidong Shao
Hi osad team,

Compass, an openstack deployment project, is in process of using osad
project in the openstack deployment. We need to support a use case where
there is no Internet connection. The way we handle this is to split the
deployment into "build" and "install" phase. In Build phase, the Compass
server node can have Internet connection and can build local repo and other
necessary dynamic artifacts that requires Internet connection. In "install"
phase, the to-be-installed nodes do not have Internet connection, and they
only download necessary data from Compass server and other services
constructed in Build phase.

Now, is "offline install" something that OSAD project shall also support?
If yes, what is the scope of work for any changes, if required.

Thanks,
Weidong
__
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] [Compass] Call for contributors

2015-08-13 Thread Weidong Shao
Jesse,

Many thanks for your message and the support of this planned integration
work. I added Xicheng, and Justin, who are looking into getting Compass
deployment to work with OSAD as of now.

Sorry I missed your meeting today and we will definitely join your meeting
next week. In the meantime, we will reach out to you if we run into any
issues.

Thanks,
Weidong

On Wed, Aug 12, 2015 at 11:20 PM Jesse Pretorius jesse.pretor...@gmail.com
wrote:

 On 12 August 2015 at 17:23, Weidong Shao weidongs...@gmail.com wrote:


 Compass is not new to OpenStack community. We started it as an OpenStack
 deployment tool at the HongKong summit. We then showcased it at the Paris
 summit.

 However, the project has gone through some changes recently. We'd like to
 re-introduce Compass and welcome new developers to expand our efforts,
 share in its design, and advance its usefulness to the OpenStack community.

 We intend to follow the 4 openness guidelines and enter the Big Tent.
 We have had some feedback from TC reviewers and others and realize we have
 some work to do to get there. More developers interested in working on the
 project will get us there easier.

 Besides the openness Os, there is critical developer work we need to get
 to one of the OpenStack Os.  For example, we have forked Chef cookbooks,
 and Ansible written from scratch for OpenStack deployment. We need to merge
 the Compass Ansible playbooks back to openstack upstream repo
 (os-ansible-deployment).

 We also need to reach out to other related projects, such as Ironic, to
 make sure that where our efforts overlap, we provided added value, not
 different ways of doing the same thing.

 Lot of work we think will add to the OpenStack community.


- The project wiki page is at https://wiki.openstack.org/wiki/Compass
- The launchpad is: https://launchpad.net/compass
- The weekly IRC meeting is on openstack-meeting4 0100 Thursdays UTC
(or Wed 6pm PDT)
- Code repo is under stackforge
https://github.com/stackforge/compass-core
https://github.com/stackforge/compass-web
https://github.com/stackforge/compass-adapters

 Hi Weidong,

 This looks like an excellent project and we (the openstack-ansible
 project) love to assist you with the integration of Compass with
 openstack-ansible (aka os-ansible-deployment).

 I'd like to discuss with your team how we can work together to facilitate
 Compass' consumption of the playbooks/roles we produce in a suitable way
 and will try to attend the next meeting as I seem to have missed this
 week's meeting). We'd like to understand the project's needs so that we can
 work towards defined goals to accommodate them, while also maintaining our
 stability for other downstream consumers.

 We also invite you to attend our next meeting on Thu 16:00 UTC in
 #openstack-meeting-4 - details are here for reference:
 https://wiki.openstack.org/wiki/Meetings/openstack-ansible#Community_Meeting

 Looking forward to working with you!

 Best regards,

 Jesse

 __
 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] [Compass] [Meeting] Weekly Meeting Agenda

2015-08-12 Thread Weidong Shao
On openstack-meeting-4  starting soon (6PDT today)

Today's tentative agenda:

1) Ansible playbook and upstream
2) Blueprint review

Weidong
__
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] [Compass] Call for contributors

2015-08-12 Thread Weidong Shao
Hi OpenStackers,

Compass is not new to OpenStack community. We started it as an OpenStack
deployment tool at the HongKong summit. We then showcased it at the Paris
summit.

However, the project has gone through some changes recently. We'd like to
re-introduce Compass and welcome new developers to expand our efforts,
share in its design, and advance its usefulness to the OpenStack community.

We intend to follow the 4 openness guidelines and enter the Big Tent. We
have had some feedback from TC reviewers and others and realize we have
some work to do to get there. More developers interested in working on the
project will get us there easier.

Besides the openness Os, there is critical developer work we need to get to
one of the OpenStack Os.  For example, we have forked Chef cookbooks, and
Ansible written from scratch for OpenStack deployment. We need to merge the
Compass Ansible playbooks back to openstack upstream repo
(os-ansible-deployment).

We also need to reach out to other related projects, such as Ironic, to
make sure that where our efforts overlap, we provided added value, not
different ways of doing the same thing.

Lot of work we think will add to the OpenStack community.


   - The project wiki page is at https://wiki.openstack.org/wiki/Compass
   - The launchpad is: https://launchpad.net/compass
   - The weekly IRC meeting is on openstack-meeting4 0100 Thursdays UTC (or
   Wed 6pm PDT)
   - Code repo is under stackforge
   https://github.com/stackforge/compass-core
   https://github.com/stackforge/compass-web
   https://github.com/stackforge/compass-adapters


Thanks,
Weidong
__
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] [Compass] Regarding Ansible Playbook vs upstream repo

2015-08-12 Thread Weidong Shao
[+ openstack-dev as suggested]

Steven,

Thank you for the candid comments and suggestions! We are revising our
mission to be openstack-centric as we plan our next phase. We will follow
the suggested steps by you and other TC reviewers that make sense for our
project.

On the specific question on Ansible playbook, it is good that we understand
why Kolla's Ansible is different. In Compass, we are trying to deprecate
ours and adopt os-ansible-deployment instead.

more in line:

On Mon, Aug 10, 2015 at 5:47 PM Steven Dake (stdake) std...@cisco.com
wrote:

 Xicheng.  Comments inline.  This discussion should probably be on the
 openstack-dev mailing list, but I understand if you don’t feel comfortable
 asking such questions there.  IMO this is part  of the problem with Compass
 in big tent…

 I have copied Sam Yaple, one of our core reviewers because I think this is
 relevant to him.

 From: Xicheng Chang mr.xch...@gmail.com
 Date: Monday, August 10, 2015 at 2:46 PM
 To: Steven Dake std...@cisco.com
 Cc: Weidong Shao weidongs...@gmail.com, Xicheng Chang 
 xicheng.ch...@huawei.com
 Subject: Ansible playbook for openstack

 Hi Steven,

 This is Xicheng from Compass dev-team. I heard from Weidong that Kolla has
 its own Ansible playbooks for deployment and I would like to learn more
 about the following aspects:

 - What is the github url of this ansible project?


 http://github.com/stackforge/kolla

 We are not just an ansible project.  The goal of our project is deployment
 using thin container technology and providing a reference implementation of
 deployment tooling.  We fully expect TripleO will provide an integration
 with Kolla using puppet to our thin container technology.


 - Does it have anything to do with the upstream
 stackforge/os-ansible-deployment?


 No we are a completely separate project.  We can’t use OSADs ansible
 scripts because our Ansible implementation is tightly integrated with our
 container technology.  Maybe some day we can merge but getting the two
 independently formed communities on board with such a merger would be
 difficult.



 - What effort did your team make on ansible playbooks in order to get
 inducted to the openstack big-tent? I think it is required to use upstream
 deployment cookbooks/manifests/playbooks.(we currently have our own
 deployment repo at

 github.com/stackforge/compass-adapters)


 My take on the TC is they are willing to accept many different deployment
 tools into the Big Tent assuming they offer something unique and are a
 legitimate OpenStack project, following OpenStack processes, with a
 properly diversified community.

 Kolla’s big tent application for reference:
 https://review.openstack.org/206789

 I hope you don’t mistake my directness at answering the question I think
 you really want answered for rudeness, but as a casual observer of the
 Compass big tent application I noticed the following problems:


1. You have your own domain name vs using OpenStack infrastructure for
user interaction and marketing.  Openstack has all our infrastructure to
engage the community in one place not spread them all out all over.

 Good suggestion. We will move all related content to our wiki page on
OpenStack. This also helps us as it is easier to keep a single location up
to date and consistent than two.


1. According to Jay, compass installs all different kinds of
infrastructure.  This is a non-starter.  Generic tools have always been
rejected for openstack namespace.  It shows a lack of commitment to
OpenStack’s success and a desire to “hedge your bets”.

 The project is focused on OpenStack, but deployment spans many thing not
strictly OpenStack.  Just as Ironic installs baremetal systems, ours deploy
them.  Ironic is expected to be key in Compass going forward.  If a
customer wants to deploy a baremetal instance with a container with a
legacy app, we don't expect Compass to not allow it, but we won't be
providing special tooling to specifically enable it, either.


1. This email is an example of not participating in the open.  You
would get the same exact response from me on openstack-dev.  It would be
better if the entire community could learn from my opinions rather then a
couple people.

 correcting it right now.


1. I get that other systems like open daylight, NFV, and all the other
new networking systems are becoming popular.  It is appealing to want to
compete with these in the same deployment tool that deploys OpenStack.
That is a nonstarter.

 As I mentioned above,  the scope of Compass, as an (hoping to be)
Openstack project is being adjusted to focus on OpenStack deployment.


1. I think including CEPH is fine.  Everyone is in love with ceph.  We
are going to use it in Kolla for our persistent storage.  No openstack
project solves this problem in a suitable way.

 A course of action to correct the deficiencies pointed out by the TC:


1. Commit entirely to OpenStack

Re: [openstack-dev] [swift] auth migration and user data migration

2015-03-12 Thread Weidong Shao
Thanks for the info.

On Wed, Mar 11, 2015 at 10:50 AM, Clay Gerrard clay.gerr...@gmail.com
wrote:



 On Mon, Mar 9, 2015 at 12:27 PM, Weidong Shao weidongs...@gmail.com
 wrote:


 I noticed swauth project is not actively maintained. In my local testing,
 swauth did not work after I upgraded swift to latest.


 Hrm... I think gholt would be open to patches/support, I know of a number
 of deployers of Swauth - so maybe if there's issues we should try to
 enumerate them.


​With this, I think I will try to stick with swauth. I will do some further
testing and let you know.
​


 I want to migrate off swauth. What are the auth alternative beside
 tempauth?



 Keystone.  The only other systems I know about are proprietary - what are
 your needs?


 On account-to-account server-side copy, is there an operation that is
 similar to mv? i.e., I want the data associated with an account to assume
 ownership of  a new account, but I do not want to copy the actual data on
 the disks.



 The account url is encoded in the object hash - the only realistic way to
 change the location (account/container/object) of an entity to swift is to
 read from it's current location and write it to the new location the delete
 the old object.


​the url is encoded in the object hash​! This somehow entangles the data
storage/validity with its account and makes it difficult to migrate the
data. I guess it is too late to debate on the design of this. Do you know
the technical reasons for doing this?



 -Clay

 __
 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] [swift] auth migration and user data migration

2015-03-09 Thread Weidong Shao
hi,

I have a standalone swift cluster with swauth as the auth module. By
standalone, I mean the cluster is not in the context of OpenStack, or
keystone server.

Now I have moved ACL logic to application level and decided to have all
data in swift under one user account. I have a few questions on this change:

1) is it possible to migrate swauth to the tempAuth? (assuming tempauth
will be supported in newer swift versions).

2) Is there a way to migrate data associated with one user account to
another user?

Thanks,
Weidong
__
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] [swift] auth migration and user data migration

2015-03-09 Thread Weidong Shao
John,

thanks for the reply. See questions inline.

thanks,
Weidong

On Mon, Mar 9, 2015 at 8:23 AM John Dickinson m...@not.mn wrote:


  On Mar 9, 2015, at 9:46 AM, Weidong Shao weidongs...@gmail.com wrote:
 
  hi,
 
  I have a standalone swift cluster with swauth as the auth module. By
 standalone, I mean the cluster is not in the context of OpenStack, or
 keystone server.

 That's completely fine (and not uncommon at all).

 
  Now I have moved ACL logic to application level and decided to have all
 data in swift under one user account. I have a few questions on this change:
 
  1) is it possible to migrate swauth to the tempAuth? (assuming tempauth
 will be supported in newer swift versions).

 Why?

 Yes, tempauth is still in swift. It's mostly there for testing. I wouldn't
 recommend using it in production.


I noticed swauth project is not actively maintained. In my local testing,
swauth did not work after I upgraded swift to latest.

I want to migrate off swauth. What are the auth alternative beside tempauth?



 
  2) Is there a way to migrate data associated with one user account to
 another user?

 user account Do you mean the identity or the account part of the Swift
 URL? If the former, then changing the reference in the auth system should
 probably work. If the latter, then you'll need to copy from one account to
 the other (Swift supports account-to-account server-side copy).



I think it is for both.

The former applies because I plan to change auth, I hope that all the data
access in intact with a auth url change, so that I do not need to migrate
the data after the auth change.

On account-to-account server-side copy, is there an operation that is
similar to mv? i.e., I want the data associated with an account to assume
ownership of  a new account, but I do not want to copy the actual data on
the disks.


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

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

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


[openstack-dev] Heat: autoscaling across availability zones

2015-02-28 Thread Weidong Shao
From the  heat template reference doc, it seems that auto-scaling across
AZs is not supported.   Is there any blueprint or plan in adding this
support?

Thanks,
Wei
__
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] [Magnum] Mid-Cycle Meetup Planning

2015-02-27 Thread Weidong Shao
Could you post the detailed agenda for both days?  Thanks!

On Mon, Jan 26, 2015 at 3:54 PM Adrian Otto adrian.o...@rackspace.com
wrote:

 Team,

 Thanks for participating in the poll. Due to considerable scheduling
 conflicts, I am expanding the poll to include the following Monday
 2015-03-02+Tuesday 2015-03-03. Hopefully these alternate dates can get more
 of us together on the same days.

 Please take a moment to respond to the poll a second time to indicate your
 availability on the newly proposed dates:

 http://doodle.com/ddgsptuex5u3394m

 Thanks,

 Adrian

 On Jan 8, 2015, at 2:24 PM, Adrian Otto adrian.o...@rackspace.com wrote:

  Team,
 
  If you have been watching the Magnum project you know that things have
 really taken off recently. At Paris we did not contemplate a Mid-Cycle
 meet-up but now that we have come this far so quickly, and have such a
 broad base of participation now, it makes sense to ask if you would like to
 attend a face-to-face mid-cycle meetup. I propose the following for your
 consideration:
 
  - Two full days to allow for discussion of Magnum architecture, and
 implementation of our use cases.
  - Located in San Francisco.
  - Open to using Los Angeles or another west coast city to drive down
 travel expenses, if that is a concern that may materially impact
 participation.
  - Dates: February 23+24 or 25+26
 
  If you think you can attend (with 80+% certainty) please indicate your
 availability on the proposed dates using this poll:
 
  http://doodle.com/ddgsptuex5u3394m
 
  Please also add a comment on the Doodle Poll indicating what Country/US
 City you will be traveling FROM in order to attend.
 
  I will tabulate the responses, and follow up to this thread. Feel free
 to respond to this thread to discuss your thoughts about if we should meet,
 or if there are other locations or times that we should consider.
 
  Thanks,
 
  Adrian
 
  PS: I do recognize that some of our contributors reside in countries
 that require Visas to travel to the US, and those take a long time to
 acquire. The reverse is also true. For those of you who can not attend in
 person, we will explore options for remote participation using
 teleconferencing technology, IRC, Etherpad, etc for limited portions of the
 agenda.
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

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