cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Cahill <dcah...@midokura.jp>
Subject Re: SystemVM keypair setting in developer mode
Date Wed, 16 Jan 2013 01:09:51 GMT
Thanks for the feedback all - I had switched it to an && in my local copy
for the time being, good to hear it's being fixed in master. :)


On Wed, Jan 16, 2013 at 6:47 AM, Alex Huang <Alex.Huang@citrix.com> wrote:

> My mistake there.  Thanks Marcus for reverting it and David for pointing
> it out.
>
> The windows developer deployment fails because of this check and I changed
> it to make it work for a training session but checked it in by mistake when
> I checked in the sample plugin code.
>
> Reverting will mean windows will break again.  I need to study it a little
> bit to figure out why it breaks.
>
> --Alex
>
> > -----Original Message-----
> > From: Marcus Sorensen [mailto:shadowsor@gmail.com]
> > Sent: Tuesday, January 15, 2013 1:24 PM
> > To: cloudstack-dev@incubator.apache.org
> > Subject: Re: SystemVM keypair setting in developer mode
> >
> > Ok, I'm going to put it back for now, and if there's an issue that can't
> be
> > resolved some other way then we can address it further. I'm fairly
> > confident that it was ok previously since 4.0 seems to deploy fine. I
> just
> > didn't want to get into a commit war where someone keeps changing it back
> > because it causes some other problem, without bringing it up.
> >
> > On Tue, Jan 15, 2013 at 2:17 PM, Hugo Trippaers <
> > HTrippaers@schubergphilis.com> wrote:
> >
> > > I ran into the same problem as well, but I didn't do the check where it
> > > came from. I just "fixed" it in the openvswitch branch and continued
> > > working.
> > >
> > > I think it's a plain and simple mistake.
> > >
> > > Cheers,
> > >
> > > Hugo
> > >
> > > Verstuurd vanaf mijn iPad
> > >
> > > Op 15 jan. 2013 om 22:08 heeft "Marcus Sorensen"
> > <shadowsor@gmail.com>
> > > het volgende geschreven:
> > >
> > > > Yes, I just got bitten by this as well. I'm hoping Alex can comment
> on
> > > the
> > > > commit because I'm not super familiar with this or what was being
> fixed
> > > by
> > > > the change to an OR. It used to be that they keys would generate if
> you
> > > > were running as user 'cloud' OR the developer configuration flag was
> set.
> > > > This was accomplished with an &&, which is confusing. The commit
> > changed
> > > it
> > > > to an ||, which means that it only sets up the keys if you're
> running as
> > > > user 'cloud' AND the developer flag is set.
> > > >
> > > > Went from:
> > > >
> > > > if (!username.equalsIgnoreCase("cloud") && !devel) {
> > > >
> > > > to:
> > > >
> > > > if (!username.equalsIgnoreCase("cloud") || !devel) {
> > > >
> > > > I think this will actually break KVM altogether in 4.1, because now
> the
> > > > management server needs to be run as user cloud AND the devel flag
> has
> > to
> > > > be set in order to generate keys.
> > > >
> > > > This sounds lame, but I was confused enough by that if statement
> that I
> > > put
> > > > it into some test code to verify:
> > > >
> > > > public class TestCase {
> > > >   public static void main(String[] args) {
> > > >        String username = args[0];
> > > >        String devel = args[1];
> > > >        if (!username.equalsIgnoreCase("cloud") ||
> !devel.equals("1")) {
> > > >             System.out.println("skipping keys");
> > > >        } else {
> > > >             System.out.println("generating keys");
> > > >        }
> > > >   }
> > > > }
> > > >
> > > > How it was, looks right. If you're running as cloud it will generate
> > > > regardless, otherwise the dev flag has to be set:
> > > >
> > > > marcus@mlsorensen-bsdesk:~$ java TestCase cloud 0
> > > > generating keys
> > > > marcus@mlsorensen-bsdesk:~$ java TestCase cloud 1
> > > > generating keys
> > > > marcus@mlsorensen-bsdesk:~$ java TestCase root 0
> > > > skipping keys
> > > > marcus@mlsorensen-bsdesk:~$ java TestCase root 1
> > > > generating keys
> > > >
> > > > How it is now. You have to be cloud and you need to have the dev flag
> > > set:
> > > >
> > > > marcus@mlsorensen-bsdesk:~$ java TestCase cloud 0
> > > > skipping keys
> > > > marcus@mlsorensen-bsdesk:~$ java TestCase cloud 1
> > > > generating keys
> > > > marcus@mlsorensen-bsdesk:~$ java TestCase root 0
> > > > skipping keys
> > > > marcus@mlsorensen-bsdesk:~$ java TestCase root 1
> > > > skipping keys
> > > >
> > > >
> > > > On Wed, Dec 19, 2012 at 10:34 PM, Dave Cahill <dcahill@midokura.jp>
> > > wrote:
> > > >
> > > >> Hi,
> > > >>
> > > >> There seem to be crossed wires about systemVM keypairs and whether
> > the
> > > >> management server can be run as a user other than "cloud".
> > > >>
> > > >> On Nov 1st, in the mailing list thread "Setting the ssh.publickey
> and
> > > >> ssh.privatekey options", we decided that if a user is in developer
> mode
> > > >> (used mvn -P developer -pl developer -Ddeploydb), the "developer"
> > key
> > > >> should be inserted into the database, allowing systemvm keypairs to
> be
> > > set
> > > >> even if the user is not "cloud". This was reviewed (
> > > >> https://reviews.apache.org/r/7861/) and committed (
> > > >>
> > > >>
> > > https://github.com/apache/incubator-
> > cloudstack/commit/476e771c1c8f81b87a77883922bc1b35dea213fc
> > > >> ).
> > > >>
> > > >> However, a Dec 1st commit changes the condition from:
> > > >> Disallow setting systemvm keypairs if the user is not "cloud" user
> AND
> > > is
> > > >> not in developer mode
> > > >> to
> > > >> Disallow setting systemvm keypairs if the user is not "cloud" user
> OR is
> > > >> not in developer mode
> > > >>
> > > >> This effectively means the management server can't be run as a non-
> > cloud
> > > >> user.
> > > >>
> > > >> I can't tell form the commit message if this effect is intentional:
> > > >> "Removed that darn exceptions when cloudstack is running in windows.
> > > It's a
> > > >> simple or check that was written as an and check"
> > > >>
> > > >>
> > > https://github.com/apache/incubator-
> > cloudstack/commit/6036f73725889b3557263e1a4a80106f11217974
> > > >>
> > > >> Anyone have any insights?
> > > >>
> > > >> Thanks,
> > > >> Dave.
> > > >>
> > >
>



-- 
Thanks,
Dave.

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message